Semua yang Perlu Anda Ketahui Tentang Google Accelerated Mobile Pages

Pada Mei 2015, Facebook meluncurkan platform penerbitan dalam aplikasi barunya, Artikel Instan. Sebulan kemudian, Apple menyatakan bahwa pengalaman Kios lama (pada dasarnya folder mewah yang penuh dengan aplikasi berita) akan diganti di iOS 9 dengan platform pengumpulan dan penemuan berita baru yang disebut Apple News.

Bacaan lebih lanjut tentang Smashing:

• Kinerja yang Dirasakan
• Preload: Apa gunanya?
• Bersiap Untuk HTTP/2
• Peningkatan Progresif
• AMP Web Progresif

Empat bulan kemudian, giliran Google untuk mengumumkan rencananya sendiri, yang agak terlambat tetapi tidak kalah ambisius, untuk merevolusi konsumsi berita seluler dengan solusi berbasis web sumber terbuka yang disebut Accelerated Mobile Pages, atau AMP. Hanya dalam beberapa bulan, kami telah melihat ketenangan relatif dari penerbitan digital seluler meletus menjadi perang platform skala penuh lainnya ketika Facebook, Apple, dan sekarang Google bersaing untuk loyalitas penerbit dan perhatian pembaca.

Sementara Facebook dan Apple memiliki awal yang signifikan di Google, ada banyak alasan untuk percaya bahwa AMP akan mengejar ketinggalan dengan cepat (dan bahkan bisa melampaui salah satu atau kedua pesaingnya). Jika Anda seorang pengembang atau penerbit yang perlu mengetahui alasan, apa, dan bagaimana Accelerated Mobile Pages Google secepat dan seefisien mungkin, Anda berada di tempat yang tepat.

Tapi Apa Masalahnya?

Sebelum kita membahas solusi, ada baiknya meluangkan waktu sejenak untuk mengeksplorasi masalahnya. Jika Anda banyak membaca di perangkat seluler, kemungkinan besar Anda sudah terlalu sadar bahwa berinteraksi dengan konten berbasis web di ponsel atau tablet berkisar dari hampir tidak dapat diterima hingga mengerikan. Laman sering dimuat dengan lambat, dirender tidak menentu, dan berperilaku tidak terduga karena dua alasan utama:

• campur tangan pihak ketiga . Iklan dan teknik pelacakan terkait tidak hanya menambahkan permintaan massal dan tambahan ke perangkat dengan bandwidth dan CPU yang sudah dibatasi, tetapi halaman sering kali berperilaku seolah-olah mereka kerasukan saat mengalami beberapa panggilan document.write() . The New York Times baru-baru ini melakukan pengujian yang menunjukkan penurunan signifikan dalam ukuran halaman dan peningkatan masa pakai baterai setelah pemasangan pemblokir konten iOS.
• kerusakan jaminan dari desain responsif . Meskipun sebagian besar situs web yang dirancang secara responsif terlihat bagus di semua ukuran layar, situs web tersebut sering kali memuat banyak beban situs web desktop saat dilihat di perangkat seluler. Ketika Paul Irish melakukan audit kinerja Reddit, dia menemukan bahwa banyak overhead dapat ditelusuri kembali ke aset yang disebut SnooIcon, maskot Reddit yang diberikan dalam SVG sehingga dapat dianimasikan (oleh perpustakaan pihak ketiga, artinya lebih banyak overhead) saat mouseover — bukan situasi di mana aset sering kali berada di perangkat seluler.

Masukkan Artikel Instan Facebook, Apple News, dan Halaman Seluler yang Dipercepat — penyelamat kami dari dunia di mana, menurut Facebook (PDF, 3,4 MB), waktu pemuatan rata-rata artikel di perangkat seluler adalah 8 detik. Meskipun menyebut 8 detik sebagai keabadian jelas merupakan hiperbola, mengingat bahwa Anda dapat menikmati video Vine kedua Anda dalam jangka waktu tersebut, mungkin adil untuk mengatakan bahwa, menurut standar saat ini, ini setidaknya satu kalpa.

Demo singkat Artikel Instan Facebook, Berita Apple, dan Halaman Seluler yang Dipercepat. Perhatikan bahwa Artikel Instan Facebook dan Apple News adalah pengalaman dalam aplikasi, sedangkan AMP sepenuhnya berbasis browser.

Apa Perbedaan AMP?

Beberapa konteks tentang bagaimana AMP berbeda dari Artikel Instan Facebook dan Apple News akan memperjelas beberapa keputusan yang dibuat Google untuk inisiatif penerbitan digital barunya.

Artikel Instan Facebook dan Apple News memiliki beberapa karakteristik yang sama:

• pengalaman dalam aplikasi . Pembaca mengakses Artikel Instan Facebook melalui Facebook di perangkat seluler, dan Apple News adalah aplikasi mandiri yang hadir dengan iOS 9. Saat ini tidak ada platform yang memungkinkan pengguna untuk melihat artikel dalam format khusus mereka di luar aplikasi masing-masing. Anggap keduanya sebagai penyegaran RSS khusus aplikasi.
• didorong oleh sindikasi . Sementara Artikel Instan Facebook dan Apple News menggunakan format sindikasi yang sangat berbeda (Format Berita Apple berbasis JSON, dan Markup Artikel Instan kurang lebih HTML dibungkus dalam umpan RSS), mereka didasarkan pada prinsip yang sama: Membujuk CMS Anda untuk menghasilkan format sindikasi yang diperlukan, dan Facebook atau Apple News akan menyeruputnya, menguraikannya, dan menjadikannya indah dan cepat melalui penyaji yang disesuaikan dan dioptimalkan.
• berorientasi pada pengalaman . Meskipun Artikel Instan Facebook dan Apple News sama-sama berfokus pada kinerja, keduanya sama-sama peduli untuk membuat artikel terlihat dan terasa modern. Kedua platform memiliki komponen yang memungkinkan interaksi yang apik dan mulus yang biasanya kita kaitkan dengan pengalaman membaca yang dibuat dengan tangan.

Sebaliknya, Accelerated Mobile Pages memiliki fokus yang berbeda:

• pengalaman berbasis web . Dokumen AMP dirancang untuk dirender di browser atau di WebViews.
• dokumen atom . Meskipun dokumen AMP divalidasi, diuraikan, dan dirender sebagian oleh waktu proses AMP (lebih banyak lagi di bawah), dokumen tersebut adalah dokumen lengkap dan independen yang hidup di server web Anda sendiri (dan, secara opsional, dalam cache CDN), bukan kumpulan metadata yang pada suatu saat akan diubah menjadi artikel dan dirender dalam aplikasi.
• berorientasi pada kinerja . AMP jauh lebih peduli dengan kinerja dokumen AMP daripada estetika atau pola interaksi. Itu tidak berarti bahwa dokumen AMP secara inheren sederhana (mereka bisa semenarik Artikel Instan Facebook atau artikel Apple News dengan gaya yang tepat), tetapi runtime jauh lebih peduli dengan membuat artikel dirender dengan cepat daripada dengan memberikan efek visual yang mewah seperti hal-hal kecil yang gila.

Apa Itu AMP Tepatnya?

Cukup berfilsafat dan melambaikan tangan tingkat tinggi. Mari kita masuk ke spesifik. Meskipun memahami Artikel Instan Facebook dan Apple News cukup mudah (mereka pada dasarnya adalah agregator berita mewah dengan perender khusus yang dibangun di atas format sindikasi berpemilik), AMP adalah outlier. Ini sedikit lebih sulit untuk dipahami, karena dua alasan:

• Tidak ada model sederhana untuk membandingkannya. Ketika RSS masih baru, kita semua mengagumi kekuatannya, menulis banyak artikel dan posting blog tentang potensi gangguannya, menyatakan halaman beranda mati (lagi), dan kemudian mulai melupakan semuanya. Artikel Instan Facebook dan Apple News pada dasarnya adalah RSS reboot, kecuali bahwa mereka menghilangkan semua ketidaknyamanan standar, dan masing-masing hanya berfungsi dalam satu aplikasi.
• AMP bukan klien. . Sementara Artikel Instan Facebook, Apple News, dan AMP memiliki beberapa elemen yang sama, seperti format sindikasi eksklusif dan perender khusus, AMP adalah satu-satunya tanpa klien khusus (selain browser). Lebih dari saudara-saudaranya, AMP adalah seperangkat spesifikasi, konvensi, dan teknologi yang dapat digabungkan menjadi solusi, bukan solusi ujung-ke-ujung (penerbit-ke-pembaca) itu sendiri.

Sekarang setelah kita tahu bahwa AMP adalah kumpulan bahan, bukan kue yang dipanggang sepenuhnya, mari kita lihat apa saja komponen individual tersebut:

• HTML-AMP,
• waktu proses AMP,
• cache AMP.

HTML AMP

Dokumen AMP ditulis dalam HTML, tetapi bukan sembarang HTML. Beberapa tag dilarang, sementara beberapa tag baru diperkenalkan (sebagian untuk menggantikan yang dilarang dan sebagian untuk merangkum fungsionalitas interaktif). Anda dapat menganggap AMP HTML seperti apa HTML jika dirancang hanya dengan mempertimbangkan kinerja seluler (berlawanan dengan diperkenalkan 14 tahun penuh sebelum pengenalan iPhone).

Karena AMP HTML dirancang untuk kinerja yang optimal, untuk memahami dan menghargai nilainya, kita perlu memahami masalah yang dipecahkannya. Berikut adalah tiga hal terbesar yang mengganggu pemuatan dan rendering halaman web di perangkat seluler:

• ukuran muatan . Desain web responsif telah membantu kami dengan baik karena memungkinkan kami membangun satu situs web untuk setiap perangkat dan layar di luar sana. Tapi itu juga terkadang berarti mengirimkan muatan ukuran desktop (HTML, JavaScript, CSS, dan aset) ke perangkat seluler dengan bandwidth dan CPU yang sangat terbatas. (Mereka yang menganggap ponsel mereka sebagai komputer desktop kecil memberi terlalu banyak kredit untuk perangkat keras seluler. iPhone 6s Anda memiliki 2 GB RAM, sementara laptop Anda mungkin memiliki 8 atau 16.)
• pemuatan sumber daya . Sumber daya tidak selalu dimuat dalam urutan optimal, yang berarti bandwidth, CPU, dan RAM sering kali didedikasikan untuk aset yang bahkan mungkin tidak pernah dilihat pengguna. Selain itu, sumber daya sering kali tidak menyatakan lebar dan tingginya (terutama saat ditayangkan melalui jaringan iklan atau disuntikkan melalui panggilan document.write() ), yang tidak hanya menyebabkan laman mengubah ukurannya sendiri karena dimensi sumber daya ditentukan dengan malas, tetapi juga memicu yang tidak perlu dan perhitungan ulang tata letak yang mahal. Itulah yang menyebabkan halaman web melompat-lompat seperti anak kucing yang mengejar laser saat mereka bermanifestasi dengan sangat lamban.
• eksekusi JavaScript . Saya tidak akan membahas topik kinerja JavaScript di sini, tetapi situs web modern sering kali menumpuknya hingga megabita, dan meskipun mungkin dijalankan tanpa latensi yang terlihat di komputer desktop, seluler masih merupakan lingkungan yang sangat berbeda, menurut saya. kita semua bisa setuju, JavaScript sebaiknya dijaga agar tetap minimum.

Mengingat tiga hambatan ini untuk pengalaman web yang lancar di perangkat seluler, AMP HTML terutama ada untuk tiga tujuan:

• mendorong singkatnya . Dokumen AMP bukan versi situs web desktop yang responsif. Meskipun dokumen AMP dapat (dan biasanya) responsif, dokumen tersebut responsif dalam konteks seluler. Dengan kata lain, daripada satu halaman yang benar-benar berfungsi di mana saja (desktop dan seluler), dokumen AMP dirancang khusus untuk berfungsi dengan baik di seluruh perangkat seluler.
• mengontrol pemuatan sumber daya eksternal . Waktu proses AMP mengontrol pemuatan sumber daya eksternal untuk memastikan bahwa prosesnya sangat efisien, menghasilkan konten yang muncul di layar pengguna secepat dan secerdas mungkin.
• merangkum fungsionalitas interaktif . Meskipun dokumen AMP cenderung langsung ke bisnis menyajikan pembaca dengan pengalaman membaca langsung, itu tidak berarti mereka tidak bisa modern dan interaktif. Waktu proses AMP menyediakan fungsionalitas yang dienkapsulasi melalui JavaScript yang sangat dioptimalkan, sehingga pengembang tidak mengambil risiko menghambat kinerja dengan menulis sendiri.

Tag HTML AMP

Di bawah ini adalah daftar tag yang dilarang habis-habisan di AMP HTML:

• script Ini jelas salah satu yang besar. Saya akan memberikan detail lebih lanjut tentang posisi AMP di JavaScript di bawah ini; untuk saat ini, anggap saja bahwa satu-satunya tag script yang akan Anda miliki di dokumen AMP adalah yang memuat waktu proses AMP dan, secara opsional, tag untuk data tertaut berbasis JSON.
• base Tag base tampaknya dilarang karena sangat berhati-hati, dan mungkin akan masuk daftar putih jika komunitas mengeluh. (Dugaan saya adalah bahwa tidak ada yang benar-benar peduli dengan satu atau lain cara.)
• frame dan frameset . Lagi pula, penggunaan real estat seluler tidak terlalu bagus, jadi baguslah.
• object , param , applet dan embed Sayangnya, dokumen AMP Anda tidak akan berisi applet Flash atau Java. (Itu sarkasme, kalau-kalau itu tidak sepenuhnya jelas.)
• form dan elemen input (dengan pengecualian tag button ) Dukungan form pada akhirnya akan diimplementasikan sebagai komponen yang dienkapsulasi karena penggunaannya terbatas tanpa skrip.

Sekarang, berikut adalah daftar tag yang menggantikan rekan HTML-nya untuk mengoptimalkan pemuatan sumber daya dan menerapkan praktik keamanan terbaik:

• [amp-img](https://www.ampproject.org/docs/reference/amp-img.html) Mengganti tag img dan mengoptimalkan pemuatan resource dengan mempertimbangkan faktor-faktor seperti posisi viewport, resource sistem, dan konektivitas.
• [amp-video](https://www.ampproject.org/docs/reference/amp-video.html) Mengganti tag video HTML5, sehingga konten video dapat dimuat dengan lambat (dengan mempertimbangkan area pandang).
• [amp-audio](https://www.ampproject.org/docs/reference/extended/amp-audio.html) Mengganti tag audio HTML5 sehingga konten audio dapat dimuat dengan lambat (dengan mempertimbangkan area pandang).
• [amp-iframe](https://www.ampproject.org/docs/reference/extended/amp-iframe.html) Tag amp-iframe menerapkan praktik keamanan terbaik dengan melakukan hal-hal seperti konten sandbox secara default dan membatasi di mana iframe mungkin muncul untuk memastikan bahwa iframe tidak mendominasi dokumen AMP.

Terakhir, berikut adalah semua tag yang diperkenalkan AMP HTML untuk menambahkan fungsionalitas atau interaktivitas ke dokumen Anda, tanpa mengharuskan Anda menulis JavaScript:

• [amp-ad](https://www.ampproject.org/docs/reference/amp-ad.html) Tag amp-ad memungkinkan AMP runtime untuk mengelola pemuatan iklan seperti semua resource yang dimuat secara eksternal (saat ini , iklan dimuat terakhir), dan memastikan bahwa JavaScript dari jaringan iklan tidak dapat dijalankan di dalam dokumen AMP induk atau memicu penghitungan tata letak yang tidak perlu. (Selamat tinggal, document.write() !)
• [amp-analytics](https://www.ampproject.org/docs/reference/extended/amp-analytics.html) Framework mini ini mengemas data analisis dan mengirimkannya ke penyedia pihak ketiga. Mulai hari ini, dukungan AMP datang dari Adobe Analytics, Chartbeat, ClickTale, comScore, Google Analytics, Nielsen, dan Parse.ly.
• [amp-pixel](https://www.ampproject.org/docs/reference/amp-pixel.html) Ini digunakan untuk menyematkan suar web, dan mendukung token untuk mengirim beberapa variabel klien ke server.
• [amp-carousel](https://www.ampproject.org/docs/reference/extended/amp-carousel.html) Komponen yang dioptimalkan ini menampilkan gambar turunan dalam orientasi horizontal yang interaktif.
• [amp-lightbox](https://www.ampproject.org/docs/reference/extended/amp-lightbox.html) Ini memungkinkan pembaca membuka gambar dalam tampilan “lightbox” layar penuh. Ini mendukung spesifikasi gambar mini dan gambar berukuran penuh.
• [amp-anim](https://www.ampproject.org/docs/reference/extended/amp-anim.html) Ini memuat GIF animasi dan menyediakan fungsionalitas placeholder yang sangat dibutuhkan.
• [amp-font](https://www.ampproject.org/docs/reference/extended/amp-font.html) Tetapkan waktu tunggu pemuatan pada font kustom, dan tentukan font fallback jika font kustom Anda tidak dimuat dalam waktu yang ditentukan .
• [amp-fit-text](https://www.ampproject.org/docs/reference/extended/amp-fit-text.html) Teks dalam tag amp-fit-text akan otomatis diberi ukuran font yang dioptimalkan untuk ruang yang tersedia. Anggap saja sebagai respons yang sudah dikemas sebelumnya.
• [amp-list](https://www.ampproject.org/docs/reference/extended/amp-list.html) Dengan tag amp-list , Anda dapat memuat data JSON yang berulang dan dinamis, lalu merendernya menggunakan HTML templat. (Lihat tag amp-mustache di bawah.)
• [amp-mustache](https://www.ampproject.org/docs/reference/extended/amp-mustache.html) Ini mendukung rendering template HTML Moustache.
• [amp-install-serviceworker](https://www.ampproject.org/docs/reference/extended/amp-install-serviceworker.html) Jika Anda memilih untuk tidak menggunakan cache AMP (lebih lanjut tentang caching di bawah), tag amp-install-serviceworker memuat dan menginstal service worker untuk halaman saat ini. Pekerja layanan licin, tetapi menurut saya terlalu dini untuk mengandalkan mereka.
• [amp-youtube](https://www.ampproject.org/docs/reference/extended/amp-youtube.html) Bisa ditebak, ini menyematkan video YouTube dengan ID video yang ditentukan.
• [amp-twitter](https://www.ampproject.org/docs/reference/extended/amp-twitter.html) Sematkan tweet (kartu Twitter opsional).
• [amp-instagram](https://www.ampproject.org/docs/reference/extended/amp-instagram.html) Sematkan gambar Instagram.
• [amp-brightcove](https://www.ampproject.org/docs/reference/extended/amp-brightcove.html) Komponen ini memuat dan menampilkan video (dan pemutar video) dari Brightcove.
• [amp-pinterest](https://www.ampproject.org/docs/reference/extended/amp-pinterest.html) Sematkan widget Pinterest, atau tombol “Pin It”, di dokumen AMP Anda.
• [amp-vine](https://www.ampproject.org/docs/reference/extended/amp-vine.html) Sematkan video Vine yang ditentukan di dokumen AMP Anda.

Perhatikan bahwa, meskipun tag dengan awalan amp- bukanlah HTML standar, tag tersebut juga bukan hak milik. Sebaliknya, mereka adalah elemen kustom yang sah dengan implementasi JavaScript yang melakukan hal-hal seperti menerapkan praktik keamanan terbaik dan memprioritaskan pemuatan sumber daya jarak jauh (lebih lanjut tentang itu di bagian "Waktu Proses AMP" di bawah). Dengan kata lain, meskipun AMP HTML mungkin terlihat mencurigakan seperti strategi merangkul, memperluas, dan memadamkan, itu sebenarnya hanya aplikasi standar web yang cerdas dan tidak jauh berbeda dari atribut data- khusus.

Menata HTML AMP

Penataan gaya dokumen AMP dilakukan dengan CSS standar dan tidak jauh berbeda dengan gaya konten yang sudah Anda buat. Namun, perlu diingat beberapa hal:

• Semua penataan gaya harus dilakukan dengan lembar gaya sebaris — tidak ada lembar gaya yang ditautkan secara eksternal dan tidak ada gaya sebaris tingkat elemen. (Lembar gaya yang ditautkan secara eksternal akan memerlukan dokumen tambahan untuk diunduh sebelum tata letak dapat dihitung, dan gaya tingkat elemen sebaris dapat membuat dokumen membengkak.)
• Gaya dibatasi hingga 50 KB. Filosofi Google adalah bahwa 50 KB cukup untuk dokumen atau artikel yang bagus tetapi tidak cukup untuk situs web yang bagus.
• Style sheet sebaris Anda harus memiliki atribut amp-custom (yaitu <style amp-custom> ).
• Aturan @ — @font-face (lebih lanjut tentang font di bawah), @keyframes dan @media — diperbolehkan.
• Beberapa selektor memiliki batasan yang diketahui dapat menghambat kinerja, seperti pemilih universal ( * ) dan pemilih :not() .
• Qualifier !important dilarang untuk memastikan bahwa AMP runtime memiliki kata terakhir tentang ukuran elemen.
• Penataan gaya komponen AMP kustom seperti amp-carousel dilakukan dengan mengganti kelas default, seperti .amp-carousel-button-prev , atau dengan menggunakan kumpulan properti kustom CSS yang telah ditentukan sebelumnya, seperti --arrow-color .
• Semua sumber daya yang dimuat secara eksternal harus memiliki properti lebar, tinggi, dan tata letak yang ditentukan (lebih lanjut tentang tata letak di bawah) untuk meminimalkan penghitungan ulang tata letak DOM yang mahal.
• Transisi dan animasi yang dapat dipercepat GPU (dan yang tidak memicu penghitungan ulang) diizinkan. Saat ini, opacity dan transform masuk daftar putih.

Untuk detail tambahan tentang penataan gaya dokumen, lihat spesifikasi HTML AMP.

font

AMP dengan senang hati mendukung font khusus, dengan beberapa kualifikasi:

• Font harus dimuat dengan tag tautan atau aturan CSS @font-face . Dengan kata lain, Anda tidak dapat memuat font menggunakan JavaScript.
• Semua font harus disajikan melalui HTTPS.
• Penyedia font harus masuk daftar putih. Saat ini, satu-satunya penyedia yang masuk daftar putih adalah fonts.googleapis.com dan fast.fonts.net . Namun, mengingat betapa cepatnya penerbit, pengiklan, dan penyedia analitik menambahkan dukungan untuk AMP, saya menduga akan ada lebih banyak lagi yang akan segera menyusul.

tata letak

Pendekatan AMP terhadap tata letak disusun berdasarkan dua tujuan utama:

• Waktu proses harus dapat menyimpulkan ukuran semua sumber daya yang dimuat secara eksternal sebelum benar-benar dimuat, sehingga tata letak akhir dapat dihitung secepat mungkin. Setelah tata letak dihitung, artikel dapat dirender dan pembaca dapat mulai berinteraksi dengannya, meskipun iklan, gambar, audio, dan video belum selesai dimuat. (Dan, saat sumber daya tersebut dimuat, mereka akan merender dengan mulus, tanpa mengganggu pengalaman membaca dengan memperbarui tata letak dokumen.)
• Artikel AMP harus responsif. Sesuai dengan namanya “Accelerated Mobile Pages”, dokumen AMP secara khusus ditujukan untuk perangkat seluler; jadi, dalam konteks ini, "responsif" tidak termasuk resolusi desktop. Sebaliknya, dokumen AMP akan terlihat bagus di semua perangkat seluler, mulai dari peninggalan iPhone 4 kecil yang masih digunakan hingga iPad Pro yang relatif besar.

Tujuan sebelumnya terutama dicapai dengan persyaratan bahwa semua sumber daya yang dimuat secara eksternal memiliki atribut width dan height (dan lebih lanjut diberlakukan dengan membatasi skrip, yang memastikan bahwa sumber daya baru tidak dapat dimasukkan). Yang terakhir dicapai dengan kueri media standar, atribut media , atribut sizes , dan atribut layout khusus AMP.

Berikut ini adalah ikhtisar tata letak yang saat ini didukung oleh AMP:

• nodisplay Elemen awalnya tidak ditampilkan, tetapi tampilan dapat dipicu oleh tindakan pengguna. (Ini digunakan bersama dengan komponen seperti amp-lightbox .)
• fixed Elemen memiliki lebar dan tinggi yang tetap, yang berarti runtime tidak dapat menerapkan perilaku responsif apa pun.
• responsive Menurut pendapat saya, ini adalah opsi tata letak AMP yang paling berguna dan ajaib. Elemen menggunakan ruang apa pun yang dialokasikan sambil mempertahankan rasio aspeknya. (Pada dasarnya, "Jadikan hal ini terlihat bagus pada resolusi apa pun, tolong dan terima kasih.")
• fixed-height Elemen menggunakan ruang yang dialokasikan tetapi mempertahankan ketinggian tetap (skala horizontal).
• fill Elemen mengisi wadahnya tanpa memperhatikan rasio aspek. (Pikirkan width: 100% dan height: 100% .)
• container Elemen adalah sebuah container dan, oleh karena itu, membiarkan anak-anaknya (sebagai lawan dari induknya) menentukan ukurannya, persis seperti elemen div standar.

Mencapai tata letak dokumen yang fungsional dan langsung menggunakan sistem tata letak AMP relatif mudah, tetapi jika Anda mempertimbangkan semua yang didukungnya dan bagaimana nilai diterapkan ke berbagai jenis elemen, ada cukup banyak nuansa. Untuk perincian yang lebih mendetail, lihat spesifikasi tata letak AMP.

Bagaimana dengan SVG?

Didukung! SVG dasar menikmati dukungan komprehensif di browser desktop dan seluler, dan grafik tidak menjadi jauh lebih responsif daripada vektor, jadi AMP dan SVG menjadi tim yang sangat bagus. Batasan terbesarnya adalah, karena pembatasan skrip, Anda tidak akan dapat menganimasikan vektor Anda dengan JavaScript — yang, jika kami jujur, Anda mungkin tidak boleh melakukannya di seluler. Namun, jika Anda benar-benar harus menghidupkan sedikit kehidupan ke dalam SVG Anda, Anda masih dapat melakukannya menggunakan animasi CSS, sesuai dengan batasan yang sama yang diuraikan di bagian gaya di atas. Ingatlah bahwa SVG adalah bagian dari DOM, sehingga dapat ditata — dan dianimasikan — semudah elemen lainnya.

Filosofi AMP Tentang JavaScript

Kabar baik dan kabar buruk di sini. Kabar buruknya adalah Anda tidak akan menulis JavaScript apa pun untuk dokumen AMP Anda dalam waktu dekat. Tapi di satu sisi, itu juga kabar baik. Perlu diingat bahwa AMP bukanlah framework aplikasi seluler. Sebaliknya, ini adalah kerangka artikel seluler, dan karena artikel harus dioptimalkan untuk pengalaman membaca yang lancar dan lancar, sebenarnya tidak banyak kasus penggunaan yang baik untuk skrip sisi klien yang berat.

Meskipun demikian, melarang semua JavaScript selamanya tidak realistis dan sedikit kejam. Kenyataannya adalah bahwa web telah mengandalkan JavaScript untuk beberapa waktu sekarang — bahkan dalam konteks pengalaman membaca yang sederhana dan relatif hambar — untuk hal-hal seperti periklanan, analitik, dan fitur interaktif. Selain itu, salah satu hal terbaik tentang web adalah keterbukaannya dan kapasitasnya yang tampaknya tak terbatas untuk eksperimen, ekspresivitas, dan kreativitas — banyak di antaranya didukung oleh JavaScript.

Menyadari beban yang ditempatkan JavaScript sewenang-wenang, yang ditulis pengguna pada jaminan kinerja, dan keberadaan JavaScript di mana-mana dalam lingkungan web modern, tim AMP telah membuat prinsip-prinsip skrip berikut:

• Tidak ada JavaScript yang ditulis pengguna yang didukung atau diizinkan saat ini. Anda mungkin hanya memiliki dua jenis tag skrip di dokumen AMP: tag data tertaut (yang jenisnya adalah application/ld+json ) dan tag untuk menyertakan waktu proses AMP dan komponen AMP yang diperluas.
• Penulis proyek AMP telah mengantisipasi sebagian besar kebutuhan JavaScript dalam konteks konsumsi artikel seluler, sehingga AMP mendukung alternatif ( amp-pixel , termasuk font khusus dengan tag tautan atau aturan @font-face , dll.) atau menyediakan implementasi yang kompatibel dengan waktu proses AMP dan, oleh karena itu, menjamin keamanan dan performa ( amp-ad , amp-analytics , amp-carousel , dll.).
• Jika Anda benar-benar harus menggunakan JavaScript untuk sesuatu seperti fitur interaktif, Anda dapat membuat fitur tersebut secara mandiri, lalu menyertakannya dengan [amp-iframe](https://www.ampproject.org/docs/reference/extended/amp-iframe.html) . Konten yang disertakan dalam amp-iframe bahkan diizinkan berkomunikasi secara terbatas dengan dokumen induk untuk hal-hal seperti permintaan pengubahan ukuran.
• Komponen AMP adalah open source (Apache 2) dan terbuka untuk kontribusi, jadi komponen baru akan muncul seiring waktu (sebenarnya, beberapa komponen baru muncul selama penulisan dan pengeditan artikel ini, jadi saya sudah memperbarui beberapa kali). Meskipun tim AMP akan memprioritaskan komponen yang digeneralisasikan daripada fungsi khusus layanan (misalnya widget khusus untuk startup sosial Anda), tim AMP juga berkomitmen untuk menyediakan keragaman yang cukup untuk mengakomodasi rentang konten seluas mungkin.
• Akhirnya, semua kebijakan ini dapat berubah. Karena fitur browser seperti pekerja web, elemen khusus, dan shadow DOM menjadi lebih banyak didukung, opsi untuk mendukung JavaScript yang ditulis pengguna dan komponen khusus — sambil tetap menjamin keamanan dan kinerja — akan berkembang secara dramatis.

Untuk informasi selengkapnya tentang masa depan komponen AMP, lihat bagian “Komponen yang Diperluas” dari spesifikasi “Komponen HTML AMP”.

Anatomi Dokumen AMP

Sekarang setelah Anda memiliki pemahaman yang cukup kuat tentang AMP HTML, mari kita uraikan boilerplatenya.

Tentu saja, Anda akan memulai dokumen AMP dengan deklarasi doctype :

 <!doctype html>

Selanjutnya, tentukan dokumen HTML Anda sebagai AMP HTML, yang, percaya atau tidak, Anda gunakan dengan emoji tegangan tinggi sebagai atribut dalam tag html :

 <html >

Atau, jika Anda adalah orang yang suka gaya lama dan bingung dengan ide menghiasi kode Anda dengan emoji yang menggemaskan, Anda dapat menggunakan atribut amp yang jauh lebih konservatif, sebagai gantinya:

 <html amp> <!-- A good sign that you're boring! -->

Di tag head Anda, jangan lupa instruksi pengkodean karakter utf-8 :

 <meta charset="utf-8">

Dan tautkan ke versi non-AMP dokumen Anda (ditandai sebagai canonical , sehingga tidak muncul sebagai konten duplikat):

 <link rel="canonical" href="my-non-amp-index.html">

Sebaliknya, versi non-AMP Anda harus berisi referensi ke dokumen AMPlified:

 <link rel="amphtml" href="my-amp-index.html">

Karena halaman AMP ditujukan untuk perangkat seluler (dan Anda juga menginginkan rasterisasi GPU), pastikan untuk menyertakan tag meta viewport :

 <meta name="viewport" content="width=device-width,minimum-scale=1,initial-scale=1">

Baris kode berikutnya akan tampak sedikit aneh, dan memang begitu. Anda tahu bagaimana terkadang Anda melihat halaman web merender teks secara singkat sebelum font dimuat dan diterapkan, lalu berkedip dan merender kembali seperti yang diinginkan perancang? Tag di bawah ini menjaga opasitas halaman pada 0 (tidak terlihat) hingga ditata dengan benar.

 <style> body { opacity: 0 } </style> <noscript> <style> body { opacity: 1 } </style> </noscript>

Masalah dengan pendekatan ini adalah, jika AMP runtime gagal dimuat, secara teknis kemungkinan opasitas halaman tidak akan pernah berubah dari 0 menjadi 1 . Untuk mengimbangi kemungkinan seperti itu, kode di atas kemungkinan akan diubah menjadi sesuatu yang lebih dekat dengan ini:

 <style> body { animation: amp-timeout 0x 5s 1 normal forwards; } @keyframes amp-timeout { 0% {opacity: 0;} 100% {opacity: 1;} } </style>

Hal berikutnya yang harus dilakukan adalah menyertakan runtime JavaScript AMP:

 <script async src="https://cdn.ampproject.org/v0.js"></script>

Dan sertakan implementasi JavaScript untuk komponen tambahan mana pun yang Anda butuhkan:

 <script async custom-element="amp-youtube" src="https://cdn.ampproject.org/v0/amp-youtube-0.1.js"></script> <script async custom-element="amp-audio" src="https://cdn.ampproject.org/v0/amp-audio-0.1.js"></script> <script async custom-element="amp-carousel" src="https://cdn.ampproject.org/v0/amp-carousel-0.1.js"></script> <script async custom-element="amp-lightbox" src="https://cdn.ampproject.org/v0/amp-lightbox-0.1.js"></script> <script async custom-element="amp-anim" src="https://cdn.ampproject.org/v0/amp-anim-0.1.js"></script> <script async custom-element="amp-twitter" src="https://cdn.ampproject.org/v0/amp-twitter-0.1.js"></script> <!-- etc. -->

(Perhatikan penggunaan atribut async . Itu bukan opsional — semakin sedikit pemblokiran, semakin baik.)

Secara opsional, Anda dapat menaburkan sedikit data tertaut, seperti ini:

 <script type="application/ld+json"> { "@context": "https://schema.org", "@type": "NewsArticle", "headline": "Turn Your AMP up to 11!", "image": [ "img/cover-opt.jpg" ], "datePublished": "2015-01-11T08:00:00+08:00" } </script>

Sekarang mari tambahkan beberapa font, menggunakan tag link atau aturan @font-face di CSS Anda:

 <link href='https://fonts.googleapis.com/css?family=Roboto+Condensed:300,700' rel='stylesheet' type='text/css'> <link href='https://fonts.googleapis.com/css?family=Lora:400,700,400italic,700italic' rel='stylesheet' type='text/css'>

Dan kemudian kami akan membuat beberapa gaya (senilai tidak lebih dari 50 KB), dengan atribut amp-custom yang diperlukan:

 <style amp-custom>

Anda sekarang siap untuk membuat dokumen HTML yang kurang lebih standar menggunakan semua yang baru saja Anda pelajari tentang AMP HTML.

Waktu Proses AMP

Saya tidak akan menghabiskan banyak waktu di AMP runtime karena, seperti semua runtime, ini adalah kotak hitam. Itu tidak berarti bahwa waktu proses AMP tidak dapat diakses (ini adalah sumber terbuka, seperti proyek lainnya). Sebaliknya, seperti semua runtime yang baik, pengembang tidak perlu tahu persis cara kerjanya untuk memanfaatkannya, selama mereka umumnya memahami apa yang dilakukannya.

Waktu proses AMP diimplementasikan sepenuhnya dalam JavaScript dan dimulai dengan menyertakannya dalam dokumen AMP, seperti yang Anda lakukan pada file JavaScript eksternal apa pun:

 <script async src="https://cdn.ampproject.org/v0.js"></script>

Dari sana, runtime AMP terutama melakukan tiga hal:

• mengelola pemuatan dan prioritas sumber daya,
• mengimplementasikan komponen AMP,
• secara opsional, menyertakan validator waktu proses untuk HTML AMP.

Validator sangat penting untuk membuat dokumen yang sesuai dengan AMP. Itu dapat diaktifkan hanya dengan menambahkan #development=1 ke URL dokumen. Kemudian, yang harus Anda lakukan adalah membuka konsol Anda untuk melihat rapor Anda.

Kesalahan terlihat seperti ini:

Dokumen AMP yang bagus, bersih, dan patuh terlihat seperti ini:

Cache AMP (Opsional)

Dokumen AMP dapat disajikan dari server web seperti dokumen HTML lainnya, tetapi juga dapat disajikan dari cache AMP khusus. Cache opsional menggunakan beberapa teknik untuk lebih mengoptimalkan dokumen AMP:

• Referensi gambar dapat diganti dengan gambar berukuran khusus untuk viewport pemirsa.
• Gambar di paro atas dapat disejajarkan untuk menyimpan permintaan HTTP tambahan.
• Variabel CSS dapat digarisbawahi untuk mengurangi overhead sisi klien.
• Penerapan komponen AMP yang diperluas dapat dimuat sebelumnya.
• HTML dan CSS dapat diperkecil untuk mengurangi jumlah byte yang dikirim melalui kabel (atau, dalam hal ini, gelombang udara).

Siapa pun dapat menjalankan cache AMP mereka sendiri di CDN mereka sendiri, atau penerbit dapat menggunakan Google secara gratis. Mengingat bahwa Google tampaknya mengetahui satu atau dua hal tentang skalabilitas, saya menduga sebagian besar pengadopsi AMP akan dengan senang hati menerima tawaran itu. (Documentation on how to opt in to Google's cache is forthcoming, but given that Google already indexes and caches the Internet, it's a safe bet that it will revolve around your link tags and perhaps an additional meta tag.)

How Do Readers Find AMP Content?

The fact that AMP document are more or less standard HTML that will render in any modern browser is, in my opinion, a huge advantage (AMP is far more open and inclusive than Facebook Instant Articles or Apple News). But from a practical perspective, it also raises the question of how audiences will find AMP content.

If readers use Google to search from a mobile device, Google can link directly to AMP versions of articles (Google has not said that it will prioritize AMP documents over non-AMP documents, but it has said that it will use “mobile friendliness” as a mobile search signal, so you do the math). In fact, Google has indicated that it will begin sending traffic to AMP pages from Google Search on mobile as early as late February 2016. Discovery and curation engines such as Pinterest may also choose to start directing mobile traffic to AMP pages (with a few infrastructure changes). Finally, websites can redirect their own mobile traffic from responsive versions of articles to their AMP counterparts. But from my perspective, a few pieces of the puzzle are still missing.

Will other search engines direct mobile traffic to AMP articles? (Perhaps not search engines that want to do business with Apple.) Will social networking apps preload AMP documents when users post links to articles, in order to make rendering nearly instantaneous? (Probably not Facebook.) Will mobile browsers start looking for link tags with amphtml relationships? (Chrome, maybe, but probably not mobile Safari.) And will aggregators and news readers out there build specifically for lightning-fast AMP content? (Time to resurrect Google Reader!)

At this point, the answers to most of these questions are the same: to be determined.

See AMP In Action

The easiest way to see AMP in action is to check out Google's search demo. If you're the trusting type, you can watch the video and just assume it all works as well as it's depicted. If you're more the trust-but-verify type, you can go to g.co/ampdemo on your mobile device and try out some AMP pages for yourself (QR code below).

You can also check out the AMP experience through desktop Chrome using Chrome's Developer Tools. All you have to do is this:

1. Go to g.co/ampdemo in Chrome.
2. Open the Developer Tools by going to “View” → “Developer” → “Developer Tools.”
3. Go into device mode by clicking on the little phone icon in the top-left corner.
4. Pick your favorite device to emulate. (For best results, reload the page in the emulator.)

Who's Adopting AMP?

It's still relatively early days for AMP, so it's hard to tell exactly who is adopting the new format in earnest, and to what extent. That being said, I've already seen several implementations out there in the wild, and according to the AMP FAQ and AMP blog, it's being taken seriously by many major publishers (metered content and subscription access is currently under review), CMS developers, advertisers, and analytics providers. I won't list them all here because I'm sure the landscape will change almost daily, but you can keep an eye on the AMP project's home page and/or the AMP blog for news.

What Do I Think?

I'm glad you asked. My guess is that just about all publishers will eventually adopt it. If companies like BuzzFeed have taught the industry anything, it's the importance of being in as many places as possible, and that digital publishing should be a technology platform capable of getting content in front of readers wherever they are, as opposed to being a singular destination waiting for readers to come to it.

The investment required to support AMP is also relatively minimal. If a publisher already supports — or plans to support — Facebook Instant Articles and Apple News, then they might as well implement support for AMP as well. While CMS strategies vary widely across the publishing industry, most CMS' have a concept of templates and/or plugins that, once implemented, would do most of the work of converting articles into AMP HTML. (WordPress, the closest thing we have to an industry leader, already has a plugin and plans on supporting AMP for all publishers in January 2016.) And because AMP is far less proprietary than its competition (meaning that it is open source, open to contributions, based on web technologies and client-agnostic), I would expect publishers to feel more comfortable distributing their content in a format that they feel they will have more control over long-term.

The reality is that publishers will back whatever syndication formats and partners will help get their content in front of the maximum number of readers with the least amount of overhead and investment. Right now, we are in the very early stages of a new type of war that is part platform, part format and in which each party will leverage its unique strengths to maneuver itself into the best possible position. At this point, it's far too early to say which will endure and which will become the RSS of tomorrow.

Sumber daya tambahan

• “Introducing the Accelerated Mobile Pages Project, for a Faster, Open Mobile Web” Google Official Blog
• Accelerated Mobile Pages Project, official website
• Accelerated Mobile Pages, blog
• AMP HTML, GitHub
• Docs, Accelerated Mobile Pages Project
• Nigel Tufnel explaining why his amp goes to 11