TL;DR: Setiap kali menguji kinerja AMP, ingatlah bahwa pengujian dari situs aslinya akan berpotensi mencakup penyetelan server yang kurang optimal seperti header cache yang buruk atau optimalisasi gambar yang hilang. Serta hasil kecepatan terbesar (mendekati muat instan selama prerendering) tidak akan tercermin dalam alat kinerja dan metrik yang biasa digunakan.
Developer yang mengimplementasikan AMP menginginkan loading yang sangat cepat, dan karenanya sering penasaran ingin melihat seberapa cepat situs mereka meningkat dengan AMP. Namun, ketika menjalankan salah satu dari banyak alat kinerja yang ada (mis.
PageSpeed Insights atau
Lighthouse) terkadang memberikan hasil yang mengejutkan dan tampaknya kurang optimal.
Untuk memahami mengapa hal ini terjadi, penting untuk disadari bahwa AMP mempercepat situs web pada tiga level yang berbeda:
- AMP sendiri sudah sangat cepat, karena JS kustom dilarang, critical path tidak diblokir, CSS dibuat inline dan banyak optimalisasi lainnya. Namun, mungkin masih ada hambatan dari sisi server, mis. gambar yang tidak dioptimalkan atau header cache yang tidak memadai, yang sulit diatasi oleh library AMP sisi klien.
- Level percepatan kedua dicapai melalui caching oleh AMP Cache (mis. Google AMP Cache), yang akan mengoptimalkan gambar, menambahkan petunjuk prefetch, mempersingkat html, menyajikan melalui HTTP/2, serta banyak optimalisasi lainnya. Perlu diingat bahwa sebagian besar optimalisasi tersebut juga bisa dilakukan di situs aslinya.
- Level peningkatan percepatan ketiga (dan yang paling berpengaruh) adalah berdasarkan fakta bahwa AMP bisa dirender terlebih dahulu dengan cara yang aman dan terlindungi, dengan melakukan pra-perenderan aset saja di viewport pertama, dan tidak mengeksekusi skrip pihak ketiga. Hal ini dijelaskan secara lebih detail di sini.
Jadi, jika pemeriksaan kinerja dilakukan pada AMP di situs aslinya, skor kecepatan (meskipun biasanya jauh lebih cepat daripada kanonis) belum mewakili semuanya. Cara lebih baik untuk mengujinya adalah dengan menjalankan uji kinerja di situs yang sama dengan yang disediakan salah satu AMP Cache (Anda bisa menggunakan
alat ini untuk mendapatkan URL cache bagi Google AMP Cache). Ini akan memasukkan optimalisasi melalui cache ke dalam pengukuran. Skor ini sudah jauh lebih baik, dan pada dasarnya juga menunjukkan apa yang bisa Anda capai di host Anda sendiri dengan menerapkan optimalisasi seperti yang telah dijelaskan sebelumnya.
Sayangnya, kejadian ketiga dan terpenting (nyaris langsung dimuat selama pra-perenderan) sulit diukur dengan alat biasa, karena ini harus diukur dalam aliran yang berasal dari situs atau aplikasi yang dikunjungi sebelumnya. Namun, tentu saja suatu halaman bisa langsung ditampilkan, asalkan semua konten yang terlihat sudah dirender sebelumnya.
Webpagetest.org memungkinkan untuk menguji aliran seperti ini melalui
opsi pembuatan skrip, tetapi rumit dan rawan-error untuk dipersiapkan serta dipelihara. Skrip terlihat seperti ini:
// don’t log data for first navigation step
logData 0
// navigate to the first page (e.g. Google SRP) which prerenders AMP
navigate INSERT_URL_CALLED_BEFORE_AMP
// sleep a bit to give prerendering time,
// a user normally also doesn’t click through immediately
sleep 10
// start logging now for clickthrough to AMP
logData 1
// click through, insert correct query expression
// to find the right link to click for your doc
execAndWait document.querySelector(‘[…]’).click();
Saat menambahkannya, perbandingan lengkap ketiga mode tersebut terlihat seperti ini (dengan hasil terperinci bisa dilihat
di sini):
Ini menunjukkan keuntungan dari pra-perenderan, sehingga render bisa dimulai hampir seketika itu juga (66ms) dan secara visual lengkap serta interaktif setelah kira-kira 1 detik.
Jadi, setiap kali pengujian kinerja AMP dilakukan, ingatlah bahwa tidak semua keuntungan kecepatan itu langsung terlihat jelas, karena beberapa akan masuk melalui caching dan terutama pra-perenderan.
Diposting di Medium oleh Martin Schierle, Mobile Solutions Consultant, Google
