Cara membuat AMP lebih cepat


Kami baru saja memublikasikan panduan baru di ampproject.org: “Mengoptimalkan halaman AMP yang dihosting” menjelaskan cara mengoptimalkan dokumen AMP sehingga memuat lebih cepat.
Anda mungkin berpikir: tunggu dulu – bukankah AMP seharusnya sudah cepat? Dan Anda memang benar: waktu proses AMP dioptimalkan untuk kecepatan dan semua halaman AMP yang valid dimuat dengan cepat. Namun, ada tambahan optimalisasi kinerja yang bisa Anda terapkan untuk membantu browser memuat halaman AMP lebih cepat lagi. Perubahannya sedikit, tetapi secara signifikan bisa meningkatkan kinerja pemuatan tanpa merusak validitas AMP.
Misalnya, plugin AMP WordPress, yang dikembangkan oleh XWP, sudah menerapkan beberapa teknik yang dijelaskan dalam panduan ini. Ini mengakibatkan waktu pemuatan xwp.co meningkat sebesar 12,6%.
Contoh lainnya adalah Evening Standard, mereka selangkah lebih jauh lagi dan memublikasikan AMP yang dioptimalkan dengan server-side-rendering (SSR). Ini mengakibatkan FCP mereka meningkat sebesar 69% dibandingkan versi AMP valid.

Kenapa Anda harus peduli?

Mari mundur selangkah. Apakah ini penting? Bukankah dokumen AMP selalu ditayangkan oleh AMP cache yang secara otomatis melakukan semua optimalisasi ini? Hal itu benar untuk beberapa kasus, seperti ketika dokumen AMP ditampilkan di hasil penelusuran Google atau Bing. Namun ada kasus lain ketika dokumen AMP ditayangkan dari halaman asalnya:

1. Ketika halaman web seluler atau resmi Anda di-build dengan AMP, seperti https://tasty.co.
2. Platform lain menautkan ke dokumen AMP di halaman asalnya. Misalnya, Twitter mulai menautkan ke halaman AMP sebagai ganti mengirimkan versi seluler standar. Ini berarti bahwa jika pengguna mengklik link di salah satu aplikasi seluler Twitter, link akan mengarah ke versi AMP halaman Anda di server Anda sendiri.

Untuk kasus-kasus ini, ketika Anda menayangkan halaman AMP dari server Anda sendiri, harap pastikan halaman AMP Anda menawarkan kinerja pemuatan optimal.

Bagaimana cara membantu browser memuat halaman AMP lebih cepat?

Mari kita lihat sekilas bagaimana cara mengoptimalkan kinerja pemuatan AMP. Waktu proses AMP harus dimuat untuk elemen khusus AMP seperti amp-img atau amp-video agar berfungsi. Ini berarti amp-img baru akan mulai mendownload gambar setelah waktu proses AMP dimuat.
Ini memberi kita dua peluang untuk membuat halaman AMP memuat lebih cepat:

1. Pastikan browser mendownload waktu proses AMP secepat mungkin.
2. Beri tahu browser agar mulai mendownload aset penting seperti gambar bahkan sebelum waktu proses AMP tersedia.

Kunci untuk mencapai ini adalah menggunakan petunjuk sumber daya seperti rel=preload untuk memprioritaskan sumber daya penting yang telah didownload. Panduan optimalisasi AMP menjelaskan berbagai cara bagaimana Anda bisa menggunakan petunjuk sumber daya untuk mengoptimalkan halaman AMP. Ada baiknya juga mempertimbangkan AMP Boilerplate Generator yang memungkinkan Anda membuat template AMP yang dioptimalkan dengan cepat.

Bagaimana cara meningkatkan first-contentful-paint?

Kita juga bisa melakukan optimalisasi kinerja selangkah lebih maju. Waktu proses AMP mengimplementasikan sistem layout halaman statis untuk mengurangi rendering dan scroll sampah. Cara kerjanya adalah kode AMP Boilerplate akan terlebih dahulu menyembunyikan dokumen hingga waktu proses AMP dimuat. Setelah dimuat, waktu proses melakukan kalkulasi layout dan menampilkan konten. Kelemahan dari pendekatan ini menyebabkan pengguna melihat halaman kosong hingga waktu proses AMP dimuat dan ia tidak mendukung rendering progresif.
Untuk menutup kelemahan tersebut, waktu first-contentful-paint (FCP) bisa ditingkatkan dengan menggunakan server-side-rendering AMP. Dengan cara ini, Anda bisa menghapus AMP boilerplate sehingga dokumen AMP dapat ditayangkan tanpa menjalankan JavaScript waktu proses AMP. Sebagai contoh, versi server-side-rendering AMP Boilerplate Generator merender dua kali lebih cepat daripada versi AMP normal:

Lihat AMP Optimizer untuk mempelajari cara mengoptimalkan dokumen AMP di server Anda.

Apa yang dimaksud dengan peningkatan kinerja?

Untuk mengetahui bagaimana pengoptimalan memengaruhi kinerja pemuatan, saya telah membuat tiga versi berbeda dari halaman landing template AMP Start Bike Shop:

1. 1. Tanpa Gambar: untuk menyimulasikan skenario kejadian terbaik ketika tidak ada konten visual yang bergantung pada waktu proses AMP yang dimuat.
   2. Dengan Gambar: untuk menampilkan waktu pemuatan saat konten bergantung pada waktu proses AMP yang dimuat.
   3. Font yang di-host sendiri: untuk menunjukkan dampak pemuatan font khusus.

Untuk masing-masing halaman, saya menguji empat varian berbeda:

1. Asli: versi AMP valid yang asli.
2. Dioptimalkan: versi AMP valid yang dioptimalkan, yang mengimplementasikan optimalisasi berikut:
   1. pengoptimalan pemuatan waktu proses
   2. pramuat gambar tokoh (bila relevan)
   3. pengoptimalan font khusus (bila relevan).
3. Dioptimalkan + SSR: mengimplementasikan optimalisasi yang sama seperti versi sebelumnya, tetapi menggunakan server-side-rendering melalui AMP Optimizer. Catatan: versi ini bukan AMP valid.
4. Cache: sebagai referensi versi yang ditayangkan oleh Google AMP Cache.

Semua pengujian dijalankan tiga kali dengan Webpagetest di Chrome pada Motorola G (gen 4) dengan koneksi 3G 1,6 Mbps dengan latensi 300ms. Anda bisa melihat hasil lengkapnya termasuk link ke Webpagetest di dokumen ini. Karena pengujian dijalankan di perangkat sungguhan, waktu eksekusi dapat bervariasi.
Sekarang, mari kita lihat hasilnya:

Tanpa Gambar

	Waktu Muat		Mulai Render		Interaktif Pertama
Asli	4,569		4,569		4,424
Dioptimalkan	4,564	-0,11%	4,564	-0,11%	4,423	-0,02%
Dioptimalkan + SSR	2,233	-51,13%	2,233	-51,13%	4,48	1,27%
AMP Cache	2,039	-55,37%	2,039	-55,37%	3,508	-20,71%

Waktu pemuatan yang >50% lebih cepat untuk versi server-side-rendering dengan jelas menunjukkan keuntungan dari AMP server-side-rendering. Namun, waktu interaksi tidak berubah karena masih bergantung pada waktu proses AMP yang dimuat.

Gambar 

	Waktu Muat		Mulai Render		Interaktif Pertama
Asli	5,435		4,591		5,367
Dioptimalkan	4,591	-15,53%	4,566	-0,54%	5,094	-5,09%
Dioptimalkan + SSR	4,095	-24,66%	1,892	-58,79%	4,818	-10,23%
AMP Cache	3,827	-29,59%	1,834	-60,05%	4,13	-23,05%

Di sini kita bisa melihat bahwa melakukan pramuat gambar akan secara signifikan mempercepat waktu pemuatan. Versi AMP dioptimalkan yang valid memuat 15% lebih cepat, sedangkan versi Dioptimalkan + SSR "hanya" memuat 24% lebih cepat. Ini karena rendering gambar bergantung pada waktu proses AMP yang dimuat.

Font yang di-host sendiri

	Waktu Muat		Mulai Render		Interaktif Pertama
Asli	5,509		4,609		5,424
Dioptimalkan	4,55	-17,41%	4,53	-1,71%	5,112	-5,75%
Dioptimalkan + SSR	4,478	-18,71%	1,989	-56,85%	5,203	-4,07%
AMP Cache	3,978	-27,79%	1,847	-59,93%	4,317	-20,41%

Dalam kasus ini, perbedaan waktu muat keseluruhan antara Dioptimalkan dan Dioptimalkan + SSR menjadi sangat kecil karena versi server-side-rendering tertahan oleh download font tambahan. Namun, rendering masih dimulai jauh lebih cepat dengan server-side-rendering.
Catatan: AMP Cache lebih cepat dalam semua kasus. Ada dua alasan utama:

1. ia melakukan optimalisasi gambar tambahan
2. ia tidak perlu membuat koneksi https kedua untuk mendownload waktu proses AMP karena waktu proses ditayangkan dari domain yang sama.
   

Kesimpulan

Kami melihat kemungkinan untuk membuat halaman AMP yang memuat lebih cepat lagi di server Anda sendiri. Kunci untuk semua pengguna yang ingin memublikasikan halaman AMP adalah:

1. Situs web yang melakukan hosting AMP tersambung harus mengimplementasikan rekomendasi dalam panduan optimalisasi AMP untuk memastikan kinerja pemuatan terbaik dari Twitter dan platform lain yang terhubung ke dokumen AMP non-cache. Sedikit perubahan bisa berarti bahwa halaman AMP memuat 1 detik lebih cepat.
2. Situs web yang di-build dengan AMP harus mempertimbangkan penggunaan AMP Optimizer karena ia mengaktifkan rendering progresif dan meningkatkan waktu FCP secara signifikan.

Kami secara aktif berupaya menemukan optimalisasi baru dan meningkatkan pengalaman pemuatan AMP.
Ditulis oleh Sebastian Benz, Partner Developer Advocate, Google