Cara kerja AMP
Gabungan berbagai optimasi berikut ini adalah sebab halaman AMP begitu cepat sehingga kelihatannya dimuat seketika. Ada tujuh sebab, tetapi jika itu terlalu banyak untuk dibaca, cukup tonton video penjelasannya:
Menjalankan semua JavaScript AMP secara asinkronus
JavaScript sangat kuat, dapat memodifikasi hampir semua aspek halaman, tetapi juga dapat memblokir konstruksi DOM dan menunda perenderan halaman (lihat juga Menambahkan interaktivitas dengan JavaScript). Agar JavaScript tidak menunda perenderan halaman, AMP hanya mengizinkan JavaScript asinkronus.
Komponen AMP mungkin memiliki JavaScript yang bekerja di balik layar, tetapi JavaScript ini dirancang secara hati-hati agar tidak menyebabkan penurunan kinerja.
Walaupun JS kustom diizinkan dalam amp-script, dan JS pihak ketiga diizinkan dalam iframe, JS tidak boleh memblokir perenderan. Misalnya, jika JS pihak ketiga menggunakan API document.write yang sangat buruk untuk kinerja, ini tidak memblokir perenderan halaman utama.
Menentukan ukuran semua sumber daya secara statis
Sumber daya eksternal seperti gambar, iklan atau, iframe harus menyatakan ukurannya dalam HTML sehingga AMP dapat menentukan ukuran dan posisi setiap elemen sebelum sumber daya diunduh. AMP memuat tata letak halaman tanpa menunggu pengunduhan sumber daya apa pun.
AMP memisahkan tata letak dokumen dari tata letak sumber daya. Hanya satu permintaan HTTP yang diperlukan untuk menata letak seluruh dokumen (+fonts). Karena AMP dioptimalkan untuk menghindari perhitungan ulang gaya dan tata letak yang mahal di browser, tidak akan ada penataletakan ulang saat sumber daya dimuat.
Tidak membiarkan mekanisme ekstensi memblokir perenderan
AMP tidak membiarkan mekanisme ekstensi memblokir perenderan halaman. AMP mendukung ekstensi untuk hal-hal seperti lightbox, sematan instagram, cuitan, dll. Meskipun hal-hal tersebut memerlukan permintaan HTTP tambahan, permintaan ini tidak memblokir tata letak halaman dan perenderan.
Setiap halaman yang menggunakan skrip khusus harus memberi tahu sistem AMP bahwa nantinya ia akan memiliki tag khusus. Misalnya, skrip amp-iframe memberi tahu sistem bahwa akan ada tag amp-iframe. AMP menciptakan kotak iframe bahkan sebelum tahu apa yang akan ada di dalamnya:
<script async custom-element="amp-iframe" src="https://cdn.ampproject.org/v0/amp-iframe-0.1.js"></script>
Menjauhkan semua JavaScript pihak ketiga dari jalur kritis
JS pihak ketiga senang menggunakan pemuatan JS sinkron. Mereka juga senang menggunakan document.write pada lebih banyak skrip sinkron. Misalnya, jika ada lima iklan di halaman Anda, dan tiap iklan menyebabkan tiga pemuatan sinkron, masing-masing dengan koneksi latensi 1 detik, maka terjadi waktu muat 15 detik hanya untuk memuat JS.
Halaman AMP mengizinkan JavaScript pihak ketiga, tetapi hanya dalam iframe berkotak pasir. Karena dibatasi dalam iframe, JavaScript pihak ketiga tidak dapat memblokir eksekusi halaman utama. Bahkan jika mereka memicu beberapa perhitungan ulang gaya, iframe mungil mereka memiliki DOM yang sangat sedikit.
Waktu yang diperlukan untuk melakukan perhitungan ulang gaya dan tata letak dibatasi oleh ukuran DOM, sehingga perhitungan ulang iframe sangat cepat dibandingkan menghitung ulang gaya dan tata letak untuk halaman.
Semua CSS harus inline dan terikat ukuran
CSS memblokir semua perenderan, memblokir pemuatan halaman, dan cenderung membengkak. Pada halaman AMP HTML, hanya gaya inline yang diizinkan. Hal ini menghapus satu—atau sering kali lebih—permintaan HTTP dari jalur perenderan kritis dibandingkan dengan sebagian besar halaman web.
Selain itu, lembar gaya inline memiliki ukuran maksimum 50 kilobyte. Meskipun ukuran ini cukup besar untuk halaman yang sangat canggih, pembuat halaman harus tetap mempraktikkan kebersihan CSS yang baik.
Pemicuan font harus efisien
Font web berukuran sangat besar, jadi optimasi font web sangat penting untuk kinerja. Pada halaman biasa yang memiliki beberapa skrip sinkronisasi dan lembar gaya eksternal, browser terus menunggu untuk mulai mengunduh font besar ini hingga seluruh prosesnya terjadi.
Sistem AMP menyatakan nol permintaan HTTP sampai font mulai diunduh. Ini dapat terjadi karena semua JS di AMP memiliki atribut asinkron dan hanya lembar gaya inline yang diizinkan; tidak ada permintaan HTTP yang memblokir browser untuk mengunduh font.
Meminimalkan perhitungan ulang gaya
Setiap kali Anda mengukur sesuatu, tindakan ini memicu perhitungan ulang gaya yang mahal karena browser harus menata seluruh halaman. Di halaman AMP, semua pembacaan DOM terjadi terlebih dahulu sebelum semua penulisan. Hal ini memastikan terjadi paling banyak satu perhitungan ulang gaya per frame.
Pelajari lebih lanjut tentang dampak perhitungan ulang gaya dan tata letak terhadap kinerja perenderan.
Hanya menjalankan animasi yang dipercepat oleh GPU
Satu-satunya cara untuk mendapatkan optimasi cepat adalah menjalankannya di GPU. GPU tahu tentang lapisan, tahu cara melakukan berbagai hal pada lapisan ini, dapat memindahkannya, dapat memudarkannya, tetapi tidak dapat memperbarui tata letak halaman; GPU akan menyerahkan tugas itu ke browser, dan itu tidak baik.
Aturan untuk CSS yang berhubungan dengan animasi memastikan bahwa animasi dapat dipercepat oleh GPU. Secara khusus, AMP hanya memungkinkan animasi dan transisi pada transformasi dan opasitas sehingga tata letak halaman tidak diperlukan. Pelajari lebih lanjut cara menggunakan transformasi dan opasitas untuk perubahan animasi.
Memprioritaskan pemuatan sumber daya
AMP mengendalikan semua unduhan sumber daya, yakni memprioritaskan pemuatan sumber daya, hanya memuat hal-hal yang dibutuhkan, dan mem-prefetch sumber daya "lazy load".
Ketika mengunduh sumber daya, AMP mengoptimalkan unduhan sehingga sumber daya terpenting saat ini diunduh terlebih dahulu. Gambar dan iklan hanya diunduh jika berpeluang dilihat oleh pengguna, terdapat di paruh atas halaman, atau jika pengguna berpeluang untuk menggulir dengan cepat ke sana.
AMP juga mem-prefetch sumber daya "lazy load". Sumber daya dimuat seakhir mungkin, tetapi diambil sesegera mungkin. Dengan cara ini, elemen-elemen dimuat dengan sangat cepat, tetapi CPU hanya digunakan ketika sumber daya benar-benar ditampilkan kepada pengguna.
Memuat halaman dalam sekejap
API prakoneksi yang baru banyak digunakan untuk memastikan permintaan HTTP berkecepatan setinggi mungkin saat dibuat. Dengan begitu, halaman dapat dirender sebelum pengguna secara eksplisit menyatakan ingin bernavigasi ke sana; halaman tersebut mungkin sudah tersedia saat pengguna benar-benar memilihnya, sehingga dapat dimuat secara seketika.
Walaupun pra-render dapat diterapkan pada semua konten web, proses ini bisa jadi menggunakan banyak bandwidth dan CPU. AMP dioptimalkan untuk mengurangi kedua faktor ini. Pra-render hanya mengunduh sumber daya pada paruh atas halaman dan pra-render tidak merender elemen yang mungkin terlalu memakan CPU.
Ketika dokumen AMP diprarender agar dapat dimuat seketika, hanya sumber daya di paruh atas halaman yang benar-benar diunduh. Ketika dokumen AMP diprarender agar dapat dimuat seketika, sumber daya yang mungkin menggunakan banyak CPU (seperti iframe pihak ketiga) tidak diunduh.
Pelajari lebih lanjut alasan AMP HTML tidak mengambil manfaat penuh dari pemindai pramuat.