Proyek AMP: Akankah Membuat Situs Anda Lebih Cepat?

Pada tanggal 24 Februari, hasil pencarian Google telah dimulai termasuk tautan ke versi halaman mobile yang dibuat menggunakan Accelerated Mobile Pages, atau  "AMP", sebuah proyek open source yang telah backed. AMP memiliki tujuan untuk membuat situs mobile memuat lebih cepat dan memberikan pengalaman yang lebih baik bagi pengguna.

Google dan Proyek AMP membuat dorongan besar untuk membawa AMP diadopsi di seluruh web, dan semuanya sudah berjalan dengan baik. Automattic  menambahkan dukungan AMP ke WordPress.com, Pinterest adalah AMPing sendiri, Twitter pledged support seperti halnya Chartbeat, Parse.ly, Adobe Analytics & LinkedIn, dan kami melihat versi AMP masuk ke dalam campuran untuk situs populer Wall Street. Journal, Buzzfeed, The Guardian, BBC News, The New York Times dan beberapa lainnya.

Alasan mengapa semua perusahaan ini menggunakannya sederhana: kecepatan pemuatan. Tidak ada perdebatan bahwa situs yang lebih cepat lebih baik, jadi dalam artikel ini saya tidak akan banyak membahas semua alasan mengapa hal itu terjadi. Saya juga akan menghindari terlalu banyak memusatkan perhatian pada informasi yang bisa Anda dapatkan dengan mudah hanya dengan mengunjungi situs AMP Project, atau menonton film promo mereka.

Sebaliknya, kita akan menuju ke hal-hal yang penting dari apa arti AMP bagi Anda saat Anda benar-benar mengkodekan situs web. Kita akan melihat secara jelas apa sebenarnya apa yang Anda butuhkan ketika menggunakan AMP dalam praktiknya, potensi dan kekurangan potensial yang dapat Anda harapkan, dan yang terpenting, apakah itu akan membuat situs Anda lebih cepat atau tidak.

Mengapa Saya Harus Memperhatikan

Nah, pada dasarnya, karena itu Google. Seperti kebanyakan hal yang terkait dengan Google, ada baiknya Anda melampaui perkembangan baru karena Anda tidak pernah tahu kapan atau bagaimana keberadaan mereka dapat mempengaruhi kinerja situs Anda di mesin pencari. Ini sangat mungkin bahwa situs yang menggunakan AMP mungkin menetapkan batasan kecepatan dan kinerja yang

Seperti yang dikemukakan oleh Richard Gingras, Direktur Utama Produk Berita dan Sosial Google, saat  membicarakan AMP:

"... Jika kita memiliki dua artikel dari perspektif pensinyalan yang sama dalam semua karakteristik lain tapi untuk kecepatan, maka ya, kita akan memberi penekanan pada yang satu dengan kecepatan ..."

Jadi, bahkan jika Anda tidak berencana menggunakan AMP, Anda mungkin disarankan untuk memeriksanya dan bertujuan memastikan bahwa situs mobile Anda dioptimalkan ke tingkat yang sebanding.

The⚡ Highlighting pada Hasil Pencarian

Saat ini, situs AMP yang terdaftar di hasil pencarian mendapatkan highlighting berupa petir kecil.  Anda tidak bisa tidak membayangkan itu akan membuat situs ini menonjol lebih dari yang lain.

Apakah Menggunakan AMP Membuat Situs Saya Lebih Cepat? Inilah jawaban lurus dan jujur:  mungkin, tapi belum tentu.

Apakah Menggunakan AMP Membuat Situs Saya Lebih Cepat?

Inilah jawaban lurus dan jujur: mungkin, tapi belum tentu.

Itu karena pertanyaan tandingan yang harus ditanyakan adalah: "lebih cepat dari apa?"

Lebih cepat dari situs media berat dengan standar, optimalisasi yang tidak memiliki sesuatu yang tidak biasa atau aspek spesial? Mungkin.

Lebih cepat dari pada situs yang menggunakan desain minimalis dan optimasi yang canggih? Belum tentu.

Sebenarnya tidak ada di AMP itu peluru ajaib. Ini bukan jenis HTML baru (seperti yang beberapa komentator katakan), atau teknologi yang belum pernah ada sebelumnya yang dijamin membuat situs Anda lebih cepat. Dalam kata-kata Google itu sendiri   adalah:

"... dibangun sepenuhnya dari teknologi web yang ada, yang memungkinkan membangun situs web dengan halaman web yang ringan."

Jika Anda memiliki keunggulan optimal dan memiliki tingkat pengetahuan teknis yang tinggi tentang bagaimana membuat situs berjalan cepat, AMP mungkin tidak membantu Anda sama sekali. Sebenarnya, mungkin saja kita bisa melihat kehilangan kecepatan dalam keadaan tertentu, meski mungkin akan berubah seiring perkembangan proyek.

Sebenarnya, mungkin saja kita bisa melihat kehilangan kecepatan dalam keadaan tertentu, meski mungkin akan berubah seiring perkembangan proyek. Paul Bakaus, Developer Advokat untuk Chrome dan Open Web di Google, mengatakan dalam sebuah presentasi tentang AMP:

"Tentu saja, jika Anda membangun situs Anda sendiri, dan Anda tahu apa yang Anda lakukan dan ini bagus sekali cepat dan segalanya, AMP mungkin tidak membuat situs Anda lebih baik, benar.  Lebih jelasnya, itu mungkin tidak membuat situs Anda lebih baik ".

Apa sebenarnya AMP, adalah kumpulan teknik pengoptimalan yang relatif rumit yang digabungkan untuk kenyamanan, dengan cara yang Anda tidak perlu memikirkan semua bagian yang bergerak di balik semuanya. Ini memberi Anda seperangkat peraturan yang ketat, dan jika Anda mengikutinya, Anda akan memiliki situs yang lebih cepat daripada yang tidak dioptimalkan, atau tidak dioptimalkan pada tingkat yang sama.

Namun pada saat yang sama, jika Anda lebih suka menggunakan setiap elemen alur kerja pengoptimalan Anda, Anda sebenarnya bisa mengumpulkan teknik yang sebanding Anda tanpa menggunakan AMP sama sekali. Menggunakan AMP, setidaknya untuk saat ini, tidak penting - namun mengetahui bagaimana mengoptimalkan ke tingkat yang setara mungkin akan segera terjadi.

Mari menggali lebih dalam tentang apa itu AMP, bagaimana cara kerjanya, dan melihat beberapa hasil tes kecepatan, maka kita akan meninjau kembali pertanyaan "Apakah akan membuat situs saya lebih cepat?" di akhir artikel.

Apakah AMP untuk Pengembang

AMP secara resmi digambarkan sebagai kombinasi dari tiga hal: AMP HTML, AMP JS dan AMP CDN. Hal ini tentu saja benar, namun dari perspektif pengembang, saya merasakan tiga hal yang paling sesuai bagi Anda saat mengkode adalah:

1. Aturan praktik terbaik AMP untuk pengkodean
2. Elemen HTML khusus AMP
3. Validator AMP untuk memastikan Anda menerapkan dua di atas

Singkatnya, Anda akan mulai membuat dokumen AMP cukup banyak dengan menyalin dan menempelkan kode yang akan Anda temukan di halaman contoh di dokumentasi AMP. Dari situ, Anda mulai mengisi halaman Anda menggunakan tiga item dalam daftar ini, yang semuanya didukung oleh AMP HTML dan AMP JS.

Catatan: AMP CDP dapat digunakan secara otomatis dan gratis oleh pengguna AMP, namun mungkin Anda bisa melakukannya dengan sama baiknya menggunakan CDN lain seperti CloudFlare. Karena ini, dan faktanya CDN bukan bagian dari proses pengkodean, saya telah meninggalkannya dari daftar tiga aspek terpenting AMP untuk pengembang.

Izinkan saya meringkas masing-masing dari ketiganya.

1. AMP’s Rules untuk CSS, HTML dan JS

traight off the bat, ada peraturan saat bekerja dengan AMP yang akan membantu mengoptimalkan halaman mana pun, jadi mereka layak untuk mengetahui apakah Anda menggunakan AMP atau tidak. Mereka cukup ketat, dan ada beberapa hal yang mungkin Anda biasakan yang Anda mungkin tidak perlu lakukan, jadi bersiaplah untuk coding untuk terasa sedikit canggung

Misalnya, semua CSS harus terdapat inline di head section, terbungkus tag <style amp-custom>...</style> ... - jadi tidak ada lagi yang menautkan ke stylesheet eksternal manapun. Anda tidak mungkin ingin menulis CSS Anda langsung ke dokumen HTML Anda, jadi Anda harus mempertimbangkan untuk menggunakan sesuatu seperti  Jade includes  atau memiliki output PHP dari inline stylesheet Anda.

CSS Anda juga bisa tidak membutuhkan lebih dari 50kb. Untuk menjelaskannya, standar CSS Bootstrap yang minim, tanpa tema, adalah 121kb. Sebuah tema akan menambahkan kira-kira 23kb membawanya ke total 144kb, hampir tiga kali jumlah yang diijinkan. Jadi Anda harus benar di atas menggunakan kode styling dengan sangat efisien.

Di atas itu ada penyeleksi CSS terlarang, seperti * misalnya, jadi tidak akan ada lagi penggunaan  * { box-sizing: border-box } t untuk mengontrol jarak di seluruh situs Anda. Dengan cara yang sama ada elemen HTML terlarang, seperti  base, frame, embed  dan beberapa lainnya. Dukungan untuk forms saat ini sedang dalam pengembangan, jadi untuk sementara juga tidak ada yang menggunakan elemen  form  atau elemen masukan lain.

Anda  dapat memuat font web eksternal, namun hanya dari Google Font atau Fonts.com melalui  https://fonts.googleapis.com  dan  https://fast.fonts.net  masing-masing.

Untuk ikhtisar lengkap tentang apa yang dapat dan tidak dapat Anda lakukan di CSS dan HTML Anda, lihat Spesifikasi AMP HTML.

"Yang besar" dalam peraturan AMP adalah bahwa JavaScript khusus yang diizinkan sama sekali. ika Anda terbiasa menggunakan kekuatan JavaScript respon menu Anda, atau hal lain, Anda kurang beruntung dan harus menemukan cara lain. Namun ini seimbang sampai tingkat tertentu melalui kehadiran komponen built-in AMP seperti lightbox dan carousel, antara lain, yang membawa kita ke bagian selanjutnya: elemen kustom.

2. Custom HTML Elements

AMP mencakup satu set elemen HTML kustom yang terfokus pada media yang masing-masing diawali dengan  amp-. Ada komponen untuk mengganti beberapa elemen HTML standar, dan tambahan yang menambahkan fungsionalitas yang biasanya Anda perlukan ditambahkan JavaScript untuk diajukan.

Tag standar  img, video, audio dan iframe  diganti dengan  amp-img, amp-video, amp-audio dan amp-iframe .

Ada juga sejumlah elemen yang dirancang untuk menyematkan konten pihak ketiga, seperti  amp-ad, amp-analytics, amp-pinterest, amp-twitter and amp-youtube.

Dan akhirnya ada yang akan saya gambarkan sebagai fitur penambahan elemen seperti  amp-lightbox, amp-carouseland amp-anim.

Untuk pemeriksaan menyeluruh lengkap,  spesifikasi komponen AMP HTML .

Elemen kustom AMP ada untuk melakukan dua hal utama:

1. Pastikan mengoptimalkan kode
2. Memfasilitasi prioritas dan optimalisasi pemuatan

Saya sebutkan sebelumnya tiga aspek yang paling penting dari AMP untuk pengembang adalah aturan praktik terbaiknya, elemen khusus dan validator untuk menerapkan semuanya. Dengan pemikiran ini, mengingat kemungkinan untuk mengikuti peraturan praktik terbaik apakah Anda menggunakan AMP atau tidak, saya merasa penentu besar apakah Anda harus menggunakan AMP adalah sejauh mana situs Anda akan menggunakan elemen khusus yang disediakannya.

Jika Anda merasa situs Anda bisa menggunakannya sering, kemungkinan AMP akan membantu Anda dengan pemuatan media yang cepat dan efisien.

Jika Anda merasa situs Anda hanya akan menggunakannya secara hemat, hasil Anda mungkin sama baiknya meninggalkan AMP dari gambar dan menerapkan peraturan praktik terbaik tanpa itu.

Salah satu aspek menyeimbangkan apakah AMP akan memberi Anda perbaikan adalah kenyataan JavaScript yang dibutuhkan untuk menjalankannya adalah 44kb. Jadi harus ada cukup media di halaman Anda sehingga AMP mengkoordinasikan pemuatan efisien akan menghasilkan penambahan 44kb, dan kemudian memberi Anda keunggulan di luar itu. Beberapa elemen khusus, seperti Twitter dan YouTube, memerlukan skrip tambahan untuk dimuat juga.

Dalam pengujian saya, beban JavaScript AMP di sekitar 779ms - 932 ms pada koneksi 3G simulasi sebesar 750kbs, skrip Twitter dimuat di sekitar 367ms - 468ms dan YouTube pada 318ms - 386ms.

Pentingnya Elemen amp-ad 

Salah satu alasan utama mengapa proyek AMP ada adalah memberi penerbit cara untuk memonetisasi situs mereka melalui iklan yang tidak terlalu lambat dan menjengkelkan bagi pengunjung.

Proyek AMP mencoba untuk menghilangkan pengalaman seperti mencapai situs web dan menunggu lima detik hanya untuk iklan layar penuh untuk memblokir jalan Anda menuju sebuah artikel. Atau mencoba membaca beberapa teks dan hampir tidak dapat melihat apapun karena spanduk raksasa berukuran empat per lima dari ruang yang tersedia.

Namun, mereka ingin menyingkirkan jenis masalah ini sambil memastikan penerbit masih dapat memperoleh cukup uang dari iklan mereka untuk mendukung bisnis mereka. Di sinilah elemen  amp-ad  muncul.

Tag  <amp-ad>...</amp-ad> terlihat aneh sejak awal, namun sebenarnya adalah cara yang terpadu dan performant untuk menampilkan iklan dari daftar padat penyedia utama:

• A9
• Adform
• AdReactor
• AdSense
• AdTech
• Dot and Media
• Doubleclick
• Flite
• plista
• Smart AdServer
• Yieldmo
• Revcontent

Jika tampilan iklan adalah bagian utama dari situs Anda, AMP layak untuk dicoba hanya untuk elemen  amp-ad  saja.

Untuk informasi lebih lanjut tentang cara menggunakannya kunjungi:  https://www.ampproject.org/docs/reference/amp-ad.html

3. Validator

Validator AMP ada untuk memastikan Anda mematuhi peraturan AMP. Ini akan memberi tahu Anda jika Anda menulis kode yang tidak sesuai dengan praktik terbaik, dan jika Anda menggunakan elemen asli yang harus diganti dengan elemen khusus.

Ketika Anda mulai mengerjakan halaman AMP, menggunakan validator adalah masalah hanya menambahkan  #development=1 ke akhir URL pratinjau Anda lalu menonton konsol di Alat Pengembang Chrome.

Jika Anda melakukan sesuatu yang salah, validator akan memberi tahu Anda.

Terutama mengingat bahwa pengkodean untuk AMP mungkin memerlukan beberapa penyesuaian, ada baiknya menjaga agar validator ini tetap terbuka sepanjang waktu sehingga Anda dapat mengatasi masalah saat mereka muncul.

Bagaimana Kecepatan yang Dihasilkan AMP

Ringkasan terbaik tentang spesifikasi teknis metode optimasi AMP dapat ditemukan di blog resmi. Namun, saya berjanji kepada Anda sebuah bahasa Inggris yang sederhana, jadi inilah:

Kode yang Tidak Ada Disana

Potongan besar tentang bagaimana halaman AMP lebih cepat adalah semua kode yang tidak ada di sana.

Anda tidak memiliki lebih dari 50kb CSS, dan kode itu tidak memerlukan permintaan  http  sendiri untuk dimuat.  Anda tidak memiliki JavaScript Anda sendiri, yang pada gilirannya berarti Anda tidak memiliki barang seperti JS powered modals, tabs, tooltips, alerts dan sebagainya. Dan di atas semua itu, Anda tidak memiliki kode untuk lima penyedia iklan yang berbeda dan tiga layanan analisis yang berbeda. Dan di atas semua itu, Anda tidak memiliki kode untuk lima penyedia iklan yang berbeda dan tiga layanan analisis yang berbeda.

Tidak adanya semua elemen ini memberi Anda keuntungan secara langsung.  Kode yang sama sekali tidak ada memiliki waktu pemuatan nol. Tentu saja Anda tidak memerlukan AMP untuk meninggalkan kode, jadi ada sesuatu yang perlu diingat apakah Anda memutuskan untuk menggunakan AMP atau tidak

Prioritas dan Optomasi Pemuatan

Kami telah menyentuh elemen khusus AMP dan faktanya mereka memfasilitasi prioritas dan pengoptimalan pemuatan.

Cara ini terjadi dalam praktiknya adalah ketika Anda membuka halaman AMP, media terlihat di layar, (diposisikan di bagian atas atau lebih rendah dari halaman web dan sangat terlihat atau tidak terlihat tanpa menggulir ke bawah halaman), akan dimuat terlebih dulu sehingga Anda dapat mulai melihat, lalu media yang tersisa akan dimuat setelah itu. Ada juga kasus di mana halaman mungkin dimuat sebelum pengguna menavigasi ke sana, sehingga sepertinya memuat langsung.

Ini semua terjadi melalui beberapa teknik yang berbeda, termasuk hal-hal seperti  lazy loading, prerendering, preconnecting dan prefetching. Anda sebenarnya bisa menerapkan metode ini sendiri jika Anda memilih untuk tidak menggunakan AMP. Dalam  artikel di blog AMP  yang saya sebutkan di atas, tertulis:

"Setiap halaman web dapat memiliki pengoptimalan ini, namun halaman AMP tidak dapat memilikinya. Sementara artikel ini adalah tentang pengoptimalan di AMP, mungkin juga berguna sebagai semacam daftar yang akan dilakukan untuk mengoptimalkan situs web non-AMP. "

Jadi jika tidak ada yang lain, lihatlah cara AMP menangani pemuatan untuk mendapatkan ide baru tentang apa yang dapat Anda lakukan untuk situs Anda sendiri.

Efisiensi Tata Letak

Semua media yang ditambahkan ke halaman AMP harus memiliki karakter tinggi dan lebar yang ditentukan. Ini berarti bahwa meskipun masih memungkinkan untuk memiliki elemen yang dapat diubah ukurannya dan responsif, AMP akan tahu bagaimana harus meletakkan halaman sebelum media tersebut dimuat. Ini mencegah harus menunggu sampai gambar dimuat, lalu menghitung ulang tata letak halaman, menghemat waktu render dalam proses.

Beberapa Uji Kecepatan

ika Anda telah mengikuti desas-desus tentang AMP, Anda pasti pernah mendengar Google membagikan hasil tesnya  peningkatan kecepatan hingga 85%   dengan halaman mitra awal. interest melakukan tes baru-baru ini dan menemukan bahwa “halaman AMP memuat empat kali lebih cepat dan menggunakan data delapan kali lebih sedikit daripada halaman yang dioptimalkan untuk seluler tradisional”.

Ini adalah beberapa nomor yang cukup signifikan, jadi saya ingin tahu persis apa yang ada di balik perbedaan kecepatan ini. Seperti yang saya sebutkan sebelumnya, pertanyaan besarnya adalah "lebih cepat dari apa?"

Untuk mengetahui saya mulai dari awal dengan  starter page code  yang disediakan oleh dokumen AMP, dan halaman setara yang dibuat dalam HTML biasa.  Saya ingin melihat apa yang akan terjadi saat menambahkan konten ke satu halaman dengan cara AMP, dan ke yang lain dengan cara yang umum.

Dalam setiap tes ini, saya menggunakan Chrome Developer Tools untuk meniru iPhone 6 dengan koneksi 3G "reguler" 750kb/s. es Google sendiri menggunakan pendekatan yang sama dengan "koneksi 3G simulasi dan perangkat Nexus 5 yang disimulasikan ".

Saya mengulangi tes beberapa kali untuk menyingkirkan kejadian tersendat secara acak yang menyebabkan pemuatan yang tertunda. Dalam hasil, saya juga selalu menunjukkan waktu muat terendah di setiap pengujian. Pengujian menggunakan metode page refresh " Empty Cache and Hard Reload " sehingga mensimulasikan pembukaan pada konten untuk pertama kalinya.

Tes 1: Gambar Tunggal

Pertama, saya mulai dasar, termasuk gambar tunggal 500kb (dari  Unsplash) pada setiap halaman.

Hasil

• AMP: 6.23 detik
• Regular: 5.48 detik

Pada tes pertama ini AMP sedikit lebih lambat, dan jika Anda melihat panel jaringan pada tangkapan layar yang dapat Anda lihat, hal itu karena perlu memuat AMP JS dan ukuran halaman HTML yang sedikit lebih besar. Ukuran fail HTML yang lebih besar disebabkan oleh persyaratan untuk beberapa CSS boilerplate untuk mencegah FOUT (flash of unstyled text) sedangkan AMP JS melakukan pemrosesannya.

Catatan: Pada tes pertama ini saya telah menunjukkan tangkapan layar dari keseluruhan halaman yang sedang diuji sehingga Anda dapat melihat pengaturan yang saya gunakan. Untuk beberapa tes berikutnya aku hanya menggambarkan apa yang saya lakukan dan tunjukkan panel jaringan karena kalau tidak akan terlalu banyak gambar besar untuk menempatkan Anda melalui loading.

Tes 2: Dua Gambar

Saya tahu idenya adalah AMP akan mulai muncul saat media ditambahkan. Dengan demikian saya mulai melakukannya di tes kedua, menambahkan gambar 500kb lagi.

Hasil

• AMP: 11.14 detik
• Regular: 10.44 detik

Sekali lagi, dalam tes ini AMP datang sedikit lebih lambat sekitar margin yang sama, untuk alasan yang sama.

Tes 3: Lima Gambar

Dalam pengujian sejauh ini markup ekstra dan JS telah menyebabkan AMP tertinggal sedikit, tapi sekarang saatnya untuk melihat dampak prioritas pemuatan AMP, dimana konten di bawah satu kelompok memiliki muatan yang ditangguhkan. Kali ini, saya menambahkan tiga gambar 500kb lagi, sehingga jumlahnya menjadi lima.

Hasil

• AMP: 16.14 detik
• Regular: 26.08 detik

Di sini kita melihat AMP lebih maju dengan selisih yang cukup besar. Jika Anda melihat secara dekat grafik jaringan untuk pemuatan AMP, Anda dapat melihatnya memuat tiga gambar pertama dalam 16,14 detik dan kemudian memungkinkan pengguna untuk mulai melihat. Ini memuat dua gambar yang tersisa setelah itu, yang dapat Anda lihat terjadi antara kira-kira tanda 22 dan 34 detik.

Dalam versi reguler di sisi lain, kelima gambar harus dimuat sekaligus, yang membutuhkan waktu 26,08 detik.

Tes 4: Lima Gambar dengan Page Scrolling

Dalam tes ini, saya ingin melihat bagaimana AMP dibandingkan jika halaman itu digulir saat pemuatan, sesuatu yang sering dilakukan pengunjung yang tajam dari waktu ke waktu.

Hasil

• AMP: 26.87 detik
• Regular: 26.09 detik

Dalam tes ini penggulir mencegah konten yang diidentifikasi seperti di bawah kelompok, yang membeli waktu muat kembali ke tempat yang sama dengan versi regulernya. Versi reguler, seperti yang diharapkan, memiliki waktu buka tidak berubah dengan menggulir saat memuat.

Tes 5: Lima Gambar dengan Lazy Load Script

Karena kecepatan keuntungan AMP dalam "Test 2" berasal dari lazy loading technique, saya ingin melihat bagaimana hal itu akan bersaing dengan skrip yang sebanding. Untuk menguji ini, saya memasukkan plugin  jQuery dan  Lazy Load , keduanya diperkecil, ke dalam versi HTML biasa, dan mengatur Lazy Load agar berjalan pada pengaturan default.

Hasil

• AMP: 16.14 detik
• Regular: 6.59 detik

Seperti yang diharapkan, kecepatan pemuatan AMP sama seperti pada "Test 2". Halaman biasa namun turun dari 26,08 detik menjadi 6,59 detik dengan skrip JQuery Lazy Load.

Penting untuk dicatat di sini, bagaimanapun, bahwa pada pengaturan default jQuery Lazy Load hanya berlaku pada gambar pertama, yang terlihat di area pandang.  AMP di sisi lain juga memuat dua gambar berikutnya yang menurutnya akan Anda lihat.

Tes 6: Perubahan Lazy Load Threshold

Untuk membuat perbandingan lebih banyak lagi, saya ingin memastikan bahwa JQuery Lazy Load menarik tiga gambar pertama, sama seperti AMP. Jadi saya mengubah pengaturan  threshold  untuk naskah menjadi  1400, yang berarti setiap gambar 1400px di luar area pandang juga akan dimuat, sehingga membuatnya memuat tiga gambar pertama.

Hasil

• AMP: 16.14 detik
• Regular: 16.51 detik

Di sini, dengan kedua halaman memuat tiga gambar, AMP mundur lagi dengan margin kecil.

Memuat jumlah gambar yang sama membawa keduanya pada satu garis yang sama secara kasar, yang menurut saya salah satu pendekatan tidak harus dilakukan dengan lebih baik daripada yang lain, namun pilihan jQuery lebih dapat dikonfigurasi, sementara AMP otomatis dan bebas tangan.

Tes 7: Twitter dan YouTube Embeds

Dalam tes ini saya ingin melihat bagaimana elemen khusus  amp-twitter dan amp-youtube  bernada out of the box dibandingkan dengan kode embed asli untuk setiap layanan. Saya menyematkan video dan tweet di setiap halaman, menggunakan setiap metode.

Hasil

• AMP: 11.22 detik
• Regular: 9.56 detik

Dalam tes ini, elemen khusus AMP keluar sedikit lebih lambat daripada menggunakan kode embed asli. Namun yang tidak saya lakukan dalam tes ini adalah menumpuk beberapa video dan tweet di atas satu sama lain untuk melihat bagaimana load prioritization mojo AMP memberikan efek.

Dengan gambar, kami melihat keuntungan hanya sekali, ada cukup konten di laman yang diprioritaskan memuat bantuan, jadi kemungkinan hal yang sama akan terjadi dengan video YouTube dan Tweet.

Tes 8: AMP CDN vs GitHub

Hal berikutnya yang ingin saya coba adalah melihat potensi keuntungan potensial dari halaman dengan lima gambar yang saya gunakan di "Test 3" yang menggunakan AMP CDN.

Jika Anda ingin menguji halaman AMP yang online untuk melihat bagaimana kelanjutannya menggunakan CDN, cukup tambahkan  cdn.ampproject.org/c/  sebelum URL-nya,  cdn.ampproject/c/s/  jika memuat https.  Sebagai contoh:

• http://myampsite.com → http://cdn.ampproject.org/c/myampsite.com
• https://myampsite.com → https://cdn.ampproject.org/c/s/myampsite.com

https://myampsite.com → https://cdn.ampproject.org/c/s/myampsite.comCara kerja CDN dalam praktiknya adalah versi reguler dari sebuah halaman akan menyertakan tautan ke versi AMP di head section. Google akan mengikuti hipertaut itu, dan saat mengenali halaman baru sebagai situs AMP akan menyimpannya di AMP CDN secara otomatis.

Saat menguji AMP CDN untuk diri Anda sendiri, pastikan untuk membolehkan pemuatan lebih lama saat pertama kali berjalan melalui cache, kemudian periksa waktu muat setelah itu.

Saya memasukkan halaman percobaan saya ke halaman hosting GitHub, lalu saya memasukkan sebuah versi ke dalam AMP CDN. Waktu muat komparatif, masih dengan koneksi 3G iPhone simulasi, adalah sebagai berikut.

Hasil

• AMP via CDN: 16.71 detik
• AMP via GitHub: 16.50 detik

Kedua hasil pada dasarnya sama, dengan halaman GitHub yang menghasilkan seperlima detik lebih cepat.

Tes 9: AMP CDN vs. Personal Host

Saya tidak yakin apakah GitHub mungkin melakukan semacam voodoo untuk membuatnya menyajikan halaman secepat AMP CDN, jadi tes berikutnya yang saya lakukan adalah membandingkannya dengan hosting pribadi saya sendiri, yang saya tahu pasti tidak ada keluar dari optimasi kecepatan pemuatan biasa.

Hasil

• AMP via CDN: 17.28 detik
• AMP via Personal Host: 16.33 detik

Hosting pribadi saya, mengejutkan, melayani halaman secepat CDN. Dalam tes ini CDN benar-benar turun sedikit hingga lebih dari tujuh belas detik.

Sayangnya saya tidak bisa membuat tes dimana AMP CDN menyajikan halaman lebih cepat. Namun, hidup saya di Australia dan berada di luar ibu kota mungkin ada kaitannya dengan hal itu.  Hasil Anda mungkin berbeda.

Tes 10: The Guardian Pre dan Post AMP

Dalam semua tes sejauh ini saya menggunakan halaman dengan hampir tidak ada CSS, hanya konten mentahnya. Tapi bukan itu cara kita merancang situs, bukan? Kita bekerja keras untuk menyempurnakan styling dan tata letak, kami menggunakan beberapa splash JavaScript untuk menambahkan fitur, dan tidak semua yang biasa, kami mungkin cenderung menggunakan lebih banyak kode daripada yang mutlak diperlukan.

Selain itu, menjalankan beberapa tes dengan konten yang sangat mendasar di tempat tidak sama dengan menguji situs lengkap dengan konten dunia nyata. Dalam konteks ini tes sebenarnya, bisa dibilang, berasal dari pengujian situs live pra dan pasca pengoptimalan AMP.

Jadi itulah yang saya lakukan selanjutnya, dimulai dengan sebuah artikel dari The Guardian. Pertama saya menguji versi HTML biasa dari artikel tersebut, dan kemudian versi AMP dari artikel yang sama persis.

Hasil

• Pra AMP: 5.05 detik
• Post AMP: 3.87 detik

Di sini kita mulai melihat peningkatan yang signifikan antara pra dan pasca versi AMP, memotong 1,18 detik dari waktu buka. Itu adalah peningkatan 23% yang cukup padat!

Tes 11: BBC News Pre dan Post AMP

Pada tes berikutnya, yang terakhir saya akan bicarakan, saya membandingkan versi default artikel BBC dengan versi AMP-nya. Seperti tes pada The Guardian, artikel yang sama persis diuji di masing-masing formatnya.

Hasil

• Pre AMP: 5.05 detik
• Post AMP: 3.87 detik

Oke jadi sekarang kita sedang berbicara. Kenaikan kecepatan sangat besar. Dari 20,44 detik menjadi 2,74 detik bahkan sedikit di atas peningkatan 85% yang dilaporkan dari tes AMP awal. Ini sebenarnya merupakan perbaikan 86%.

Perhatikan baik-baik tangkapan layar, khususnya bagan yang menggambarkan pemuatan setiap sumber daya individual dengan bilah horizontal hijau / merah / biru. Jumlah sumber daya yang dimuat dalam versi pre AMP adalah pisang. Bandingkan dengan bagan di versi post AMP, di mana jumlah sumber daya telah diperintahkan untuk masuk. Tak heran pengoptimalan mampu menciptakan peningkatan yang begitu besar.

Di sini, dua pertanyaan muncul dalam pikiran.

Satu, bisakah tingkat optimalisasi ini dibuat tanpa AMP? Ya, saya pikir itu mungkin bisa.

Dua, apakah tingkat optimalisasi ini dibuat tanpa AMP? Tidak, kemungkinan besar itu mungkin tidak akan terjadi.

Di luar pengujian yang terkontrol, dalam organisasi nyata, pengembang mungkin ingin mengoptimalkan site produksi namun mungkin tidak dapat didorong kembali dari rekan kerja yang perlu fokus pada monetisasi dan analisis. Kedua belah pihak mencoba untuk melakukan pekerjaan mereka, dan mereka mungkin tidak dapat mencapai kesamaan.

Di situlah AMP bertujuan untuk melangkah masuk dan menjembatani kesenjangan. Mereka menciptakan kerangka optimasi yang ketat yang harus dipatuhi jika Anda menginginkan tanda persetujuan AMP, yang membuat para pengembang senang. Tapi mereka juga menyediakan monetisasi terpadu, analisis dan kemungkinan pemaparan yang lebih besar di Google, yang membuat orang bertanggung jawab atas arus pendapatan bahagia.

Jika Anda adalah pengembang yang menemukan diri Anda dalam situasi ini, hasil ini menunjukkan bahwa AMP mungkin sesuai dengan perintah dokter.

Jadi Sekarang, Akankah AMP Membuat Situs Saya Lebih Cepat?

Kami telah banyak membahas artikel ini, semua dengan tujuan untuk mengetahui apakah di penghujung hari, AMP akan membuat situs Anda lebih cepat. Jawabannya, tampaknya, tidak hanya bergantung pada pertimbangan teknis dari situs Anda, tetapi juga pada kebutuhan praktis dari bisnis yang didukung oleh situs tersebut.

Jika Anda membuat semua keputusan tentang bagaimana situs Anda dibangun, AMP dapat membuat situs Anda lebih cepat jika:

• Anda menggunakan media yang cukup untuk mendapatkan keuntungan dari proses pemuatan yang optimal.
  
• Anda lebih memilih AMP memandu proses pengoptimalan Anda daripada menanganinya secara manual.

Pada saat yang sama, jika dalam keputusan Anda membuat kekuatan untuk mengoptimalkan situs Anda, Anda bisa mendapatkan hasil yang sama baiknya atau mungkin lebih baik dengan menggunakan metode pengoptimalan Anda sendiri, selama mereka berada pada tingkat yang sebanding dengan yang AMP lakukan

Jika Anda tidak bisa membuat semua keputusan tentang bagaimana situs Anda dibangun, AMP dapat membuat situs Anda lebih cepat jika:

• Ini memungkinkan Anda meyakinkan kolega Anda untuk menyetujui penerapannya, sehingga memberi Anda kemampuan untuk menerapkan pengoptimalan yang Anda tidak akan mendapatkan lampu hijau untuk yang lain.

Saya pikir intinya harus jelas adalah bahwa AMP sendiri tidak cepat - itulah cara yang salah untuk mengutarakannya.

AMP memberikan Anda sebuah metode untuk membuat situs Anda cepat

Anda tidak perlu menggunakan metode itu, tapi jika Anda menginginkan pendekatan yang mudah atau yang akan diterima oleh rekan kerja Anda, AMP mungkin pilihan yang tepat untuk Anda.

Penutup

AMP masih merupakan proyek yang sangat baru, jadi ada baiknya tetap mengamatinya dari dekat saat berkembang. Apa artinya peringkat mesin pencari Anda bisa berubah sewaktu-waktu, begitu juga persyaratan penggunaan AMP, atau kinerjanya.

Dalam tes yang saya jalankan AMP sedikit lebih lambat dalam keadaan tertentu, namun seiring berjalannya proyek, saya yakin ini akan menjadi lebih efisien dan kami mungkin melihat hasil ini menjadi tidak relevan. Pada saat yang sama, di luar tes terkontrol, jelas bahwa di situs live utama yang menerapkan optimasi AMP adalah sarana untuk pencapaian kinerja yang sangat besar.

Saya merasa bahwa apakah Anda memutuskan untuk benar-benar menggunakan AMP atau tidak, setiap orang setidaknya harus memperhatikannya dengan sangat dekat. Ini adalah sumber ide yang berpotensi besar bagi pengembang cara mereka dapat meningkatkan optimalisasi situs mereka, jika tidak ada yang lain.

Dengan peluncuran baru halaman AMP ke dalam hasil pencarian Google, akan sangat menarik untuk terus mencari umpan balik dari para pengadopsi awal AMP. Alasan saya mengatakan ini adalah bisa jadi berspekulasi mereka hanya akan terus menggunakan AMP jika hasilnya retensi lalu lintas lebih besar dan pendapatan. Apa yang terjadi dalam hal ini mungkin adalah membuat atau menghancurkan AMP.

Sampai saat itu, mungkin fakta kunci  terbesar dari kemunculan AMP adalah bahwa mengoptimalkan situs ke tingkat tertinggi mungkin akan menjadi semakin penting. Hari-hari dari stylesheet yang membengkak dan JavaScript yang berlebihan, belum lagi iklan sombong, mungkin segera berada jauh di belakang kami sebagai intro situs animasi Flash.

Dan itu adalah sesuatu yang bisa kita semua senangi.

Hipertautan Terkait:

• Introducing the Accelerated Mobile Pages Project Google official blog
• www.ampproject.org
• AMP Project on Github
• AMP WordPress plugin
• Accelerated Mobile Pages ( AMP ) for WordPress on Envato Market