Resize Observer

Intersection Observer diluncurkan dalam iOS 12.2 berkat Engineer Google Ali Juma. Ini adalah JavaScript API baru untuk memantau perubahan di titik temu elemen target dengan elemen ancestor atau dengan viewport dokumen tingkat atas secara tidak bersamaan.

Resize Observer adalah API serupa  yang kami implementasikan awal tahun ini di bawah tanda preferensi. JavaScript API ini memungkinkan developer Web untuk secara tidak bersamaan mengamati kapan suatu elemen diubah ukurannya, apa pun sebabnya. Ini tersedia di iOS 13 beta dan tanda preferensi yang sesuai telah diaktifkan secara default di trunk, jadi kami berharap fitur ini tersedia di rilis iOS 13.

Scroll

Apple mengambil alih tugas yang kami mulai tahun lalu untuk membuat <iframe> elemen dapat di-scroll dan perilaku ini sekarang diaktifkan secara default di versi iOS 13 terbaru. Perbaikan bug lain yang melibatkan elemen-elemen yang dapat di-scroll tersedia untuk scroll-snap-align, scrollability setelah resize indikator find-in-page setelah scroll serta untuk berbagai regresi iOS 13 yang terkait dengan scroll flickering dan jittering.

Peningkatan telah diimplementasikan untuk parameter ScrollIntoViewOptions API scroll. Dukungan untuk penyelarasan scroll logis diluncurkan di iOS 13. Kami juga melanjutkan upaya kami untuk mendukung parameter IDL scroll-behavior serta properti CSS dan kami berharap untuk menyelesaikannya di semester berikutnya. Saat mengerjakan ini, kami juga mendeteksi dan memperbaiki bug Chrome yang terkait dengan metode scrollIntoView(), termasuk kasus-kasus ketika terdapat scrollbar atau ketika scroller menggunakan mode penulisan non-default.

Masalah browser interoperability yang lama untuk pengguna terkait dengan nilai scrollLeft, scrollTop, dan API sejenis yang tidak konsisten dan salah satu pencapaian penting kami adalah memastikan perilaku standar yang lebih reliabel ketika mengatur atau mendapatkan koordinat scroll. Kami memperkenalkan opsi untuk membuat Chrome menggunakan nilai standar dalam mode penulisan non-default dan berencana meluncurkannya, setelah memastikan bahwa itu tidak akan menyebabkan kerusakan serius. Demikian pula, Apple memutuskan untuk mengaktifkan perubahan 2018 kami ke scroller viewport pada semua port WebKit.

Selain perbaikan bug rutin, kami mulai menerapkan fitur scroll menarik lainnya, termasuk kustomisasi overscroll dan overscroll-behavior yang merupakan API yang kuat bagi developer web untuk mengontrol apa yang terjadi ketika scroller mencapai batas-batasnya. Kami mengharapkan lebih banyak kemajuan tahun depan.

Resource Loading

Tujuan menarik yang lain adalah untuk memberikan lebih banyak kekuatan kepada pembuat Web untuk mengontrol loading behaviour. Secara khusus, ini memungkinkan kemampuan untuk mengontrol privasi dan mengoptimalkan tata letak halaman.

Atribut referrerpolicy telah diterapkan untuk menentukan berapa banyak informasi perujuk yang harus dimasukkan dalam permintaan yang terkait dengan loading resources elemen HTML. Ini hanya diterapkan untuk elemen <iframe> dan <script> serta tersedia di iOS 13 di bawah experimental feature flag. Kami akan terus berbicara dengan Apple untuk melihat kapan ini bisa diaktifkan secara default atau diterapkan untuk elemen lain.

Atribut imagesrcset dan imagesizes pada <link rel=preload> juga telah diterapkan dan tersedia di iOS 13 di bawah experimental feature flag. Atribut ini memberikan kemungkinan untuk melakukan preload gambar responsif yang diwakili oleh elemen <img> dengan atribut srcset serta ukuran yang relevan dan mengoptimalkan pemilihan ukuran yang sesuai untuk perangkat pengguna.

Kami juga mulai mengirimkan patch untuk mendukung atribut lazyload pada elemen <img> dan <iframe>. Atribut ini memungkinkan pembuat Web untuk mengindikasikan bila memuat konten elemen dengan lazyload adalah ide yang bagus (mis. jika mereka tidak terlihat di viewport sampai pengguna melakukan scroll ke situ) atau bila konten mereka harus segera dimuat. Petunjuk ini sangat membantu browser untuk mengoptimalkan pemuatan sumber daya.

Yang terakhir, kami membuat dukungan eksperimental untuk atribut intrinsic size di WebKit. Proposal ini dimaksudkan guna membantu browser untuk menentukan rasio aspek atau ukuran gambar sebelum isinya benar-benar dimuat, untuk menghindari perubahan posisi post-load tambahan. Proposal ini telah digantikan oleh pendekatan berbasis CSS murni yang menangani kasus penggunaan yang sama. Eksperimen kami bermanfaat untuk diskusi antara vendor browser serta CSS WG, dan kami berencana untuk menulis ulang patch untuk mengimplementasikan pendekatan berbasis CSS di WebKit.

Kesimpulan

Kolaborasi antara AMP project dan Igalia untuk memajukan Platform Web telah sangat berhasil. Ada beberapa tugas yang tertunda dan ide-ide baru yang harus dikerjakan sehingga kami menantikan untuk melanjutkan kerja keras ini tahun depan!


Catatan Editor: Postingan berikut ditulis oleh David Vogelpohl, VP of Web Strategy di WP Engine. WP Engine adalah platform pengalaman digital untuk WordPress.



Dalam dunia pengembangan web, kami sering menggunakan fitur untuk otomatisasi, membaca buku tentang efisiensi project, dan menerapkan berbagai teknik untuk menghadirkan inovasi dengan laju yang semakin cepat. Meskipun kita sering bertanya pada diri sendiri, “Bagaimana kita bisa menjadi pemancing yang lebih baik?” Banyak dari kita yang jarang bertanya pada diri sendiri “Bagaimana kita bisa memperlengkapi penjual dan pembuat konten dengan fitur yang mereka butuhkan untuk memancing sendiri?”.
Artikel ini menceritakan kisah tentang bagaimana dan mengapa WP Engine berinvestasi dalam memanfaatkan AMP untuk membantu developer membuat pengalaman yang berkinerja tinggi, indah, dan kaya fitur yang SANGAT DISUKAI pembuat konten.

Mengapa WP Engine peduli dengan efisiensi desain & pengembangan?

Pada pertengahan tahun 2018, WP Engine membeli Genesis, framework tema untuk WordPress dan plugin Atomic Blocks sebagai bagian dari strategi kami untuk memberikan solusi pengembangan dan desain yang intuitif dan andal. Atomic Blocks adalah plugin WordPress yang mencakup library komponen situs pra-desain yang dapat dikonfigurasi yang disebut “blok” dan pengaturan blok yang disebut “layout” yang memudahkan pembuat situs mendesain dan menerapkan pengalaman baru.
Pengguna Atomic Blocks sekarang bisa memanfaatkan kekuatan pembangunan halaman berbasis komponen sembari menciptakan pengalaman yang 100% tervalidasi AMP.
Ini sering dicapai dengan Genesis dan Atomic Blocks dengan memanfaatkan editor berbasis blok baru di WordPress yang diberi kode “Gutenberg” selama rilisnya ke WordPress #core pada akhir tahun 2018.
Pengguna bisa mendesain blok WordPress dengan berbagai model (Genesis membantu hal ini); menyediakan kontrol desain terkonfigurasi agar sesuai dengan branding, pra-muat blok dengan konten, dan mengintegrasikan blok dengan software atau sistem lain yang dapat diperluas.
Berikut adalah contoh editor blok yang digunakan dengan Atomic Blocks.
Berikut adalah contoh tema StudioPress yang menggunakan pendekatan blok-modular ini, sangat mudah dikonfigurasi oleh pembuat konten, diupdate untuk menggunakan AMP, dan mendapatkan skor luar biasa 95 pada Google Page Speed Insights (naik dari skor 54 pra-AMP). Pengguna Genesis juga bisa membuat tema khusus mereka sendiri. Berikut adalah contoh situs AMP menggunakan tema Genesis yang dibuat khusus. Terlepas dari pilihan tema pra-desain atau khusus, berkat AMP, pelanggan kami bisa membangun situs yang cepat menjadi semakin cepat dibandingkan sebelumnya!

Mengapa WP Engine memutuskan untuk menambahkan dukungan AMP ke Genesis & Atomic Blocks?

Dengan mempertimbangkan keinginan brand tertentu untuk mengadopsi AMP dan fakta bahwa agensi kami dan pelanggan developer merasa bahwa mereka tidak mendapatkan dukungan produk dari kami atau bahkan produk lain di ekosistem WordPress, kami merasa sangat perlu untuk mendukung mereka ketika membangun dengan AMP.
Tentu saja, sesuai dengan misi kami yaitu menyediakan developer dengan fitur yang mempermudah penciptaan pengalaman yang sangat disukai pembuat konten, kami harus melakukannya dengan cara yang tidak hanya mudah bagi developer untuk menciptakan pengalaman itu, tetapi juga untuk melakukannya dengan cara yang memungkinkan pembuat konten tidak perlu terlalu memikirkan kompatibilitas AMP saat membuat halaman landing atau web yang perlu mereka buat.
Pembuat konten SANGAT SUKA menciptakan pengalaman yang kompatibel dengan AMP untuk brand mereka.
Menambahkan fitur baru atau dukungan untuk standar tertentu seperti AMP adalah permintaan yang tidak mudah bagi fitur pengembangan dan desain populer seperti Genesis atau Atomic Block. Terdapat pertimbangan terhadap >600 ribu situs yang menggunakan produk-produk itu dan banyak developer di seluruh dunia yang mengandalkan produk-produk tersebut sebagai bagian dari alur kerja harian mereka.
Seperti Anda semua, kami sangat berhati-hati setiap kali kami mempertimbangkan untuk menambahkan sesuatu yang baru pada produk kami. Ketika berhubungan dengan dukungan AMP, kami memulainya dengan memperhatikan sinyal dari pelanggan tentang seberapa sering mereka menggunakan AMP, apa yang mereka sukai, dan apa yang tidak mereka sukai dari AMP.
Masukan yang kami terima sedikit tipikal dari apa yang diharapkan dari banyak audience developer web sehubungan dengan AMP. Sebagian besar mengatakan tidak pernah membangun situs dengan AMP dan mengklaim bahwa pelanggan downline mereka jarang meminta situs AMP. Artinya, banyak yang mengakui bahwa mereka memang memiliki pelanggan tertentu (khususnya dalam publikasi) yang meminta situs AMP dan bahwa permintaan tersebut sering kali berdasarkan keinginan untuk mendapatkan kinerja dan visibilitas penelusuran/sosial yang lebih baik dalam berbagai platform.
Kami kemudian bertanya, “Untuk pelanggan yang mengejar strategi AMP, fitur atau teknik apa yang Anda gunakan untuk memenuhi permintaan tersebut?” Jawabannya agak mengejutkan. Tanggapan luar biasanya adalah, “Kami tidak memilikinya!”

Bagaimana kami melakukan pendekatan dukungan AMP dalam Genesis & Atomic Blocks

Google dan kontributor lainnya merilis plugin AMP untuk WordPress pada tahun 2019. Plugin ini mengaktifkan banyak kemampuan kunci AMP untuk situs WordPress dan dioptimalkan untuk tema inti WordPress. Tema inti adalah tema yang disertakan dengan WordPress; meskipun demikian, sebagian besar situs WordPress didukung oleh tema khusus yang dibuat oleh developer atau tema premium yang dibuat oleh perusahaan seperti WP Engine.
Tema khusus dan tema premium (dibuat dengan Genesis atau lainnya) mengharuskan developer tema tersebut untuk mengoptimalkan kode mereka untuk memastikan kompatibilitas AMP bahkan ketika menggunakan plugin AMP untuk WordPress. Misalnya, beberapa tema premium WP Engine memasukkan elemen yang tidak kompatibel dengan AMP, sehingga setiap pengguna tema tersebut akan mengalami kegagalan ketika validasi AMP.
Selain itu, plugin yang menggerakkan pengalaman front end seperti plugin Atomic Blocks kami juga harus memastikan kode mereka dioptimalkan untuk memastikan validasi AMP 100%.
Plugin AMP untuk WordPress menangani banyak tugas dalam membuat situs WordPress mendukung AMP; meskipun demikian, beberapa aspek situs mungkin memerlukan pekerjaan tambahan seperti yang digambarkan di atas.
Karena persyaratan ini, kami memulai misi untuk menambahkan kemampuan ke Genesis bagi developer untuk membuat tema khusus dengan validasi AMP 100%, mengupdate tema premium kunci untuk kompatibilitas AMP, dan mengganti elemen Atomic Blocks yang tidak lulus validasi AMP.
Membangun tema AMP khusus dengan Genesis
Dalam rilis Genesis 3.0, kami menambahkan kemampuan yang memungkinkan developer untuk lebih mudah membuat tema khusus yang 100% tervalidasi AMP.
Membuat tema yang 100% tervalidasi AMP dengan Genesis dimulai dengan menginstal plugin AMP untuk WordPress. Tim kontributor pada plugin AMP melakukan tugas yang luar biasa, sehingga developer tema Genesis mendapatkan banyak keuntungan hanya dengan menjalankan plugin ini.
Berikut adalah screenshot dari apa yang dilihat pengguna WordPress saat menggunakan plugin AMP.
Dua keuntungan utama dalam dunia Genesis yang terkait dengan plugin AMP adalah fakta bahwa ia secara otomatis mengubah markup ke HTML AMP dan menangani CSS tree shaking untuk membantu developer tema selalu dalam batas CSS 50KB.
Artinya, Genesis itu sendiri dan tentu saja banyak tema yang dibuat dengan Genesis memiliki atau sudah memiliki dependensi Javascript yang tentu saja akan menyebabkan situs atau halaman tertentu gagal divalidasi. Terkait dengan Genesis itu sendiri (vs. “tema turunan” yang dibangun dengan Genesis), beberapa area kunci dari dependensi JavaScript adalah model sistem menu Genesis (khususnya “Superfish”), JavaScript yang terkait dengan komentar thread, dan skrip yang terkait dengan link lewati.
Di Genesis 3.0 kami mengganti dependensi ini atau menjadikannya opsional / nonaktif ketika berjalan dengan AMP.
Beberapa keuntungan bagi developer Genesis adalah bahwa tema turunan tidak perlu lagi menyertakan skrip responsive-menus.js atau melakukan pekerjaan apa pun untuk memprosesnya. Genesis sekarang menyertakan skrip ini dan menangani semua pekerjaan pemrosesannya, bila Anda menggunakan esponsive menus API yang baru.
Hasilnya adalah sekarang membangun tema yang 100% tervalidasi AMP dengan framework Genesis lebih mudah dilakukan daripada sebelumnya. Dengan menggunakan kemampuan ini, kami bisa dengan mudah mengupdate dua tema turunan premium agar kompatibel dengan AMP dan banyak tema turunan khusus lainnya dalam ekosistem Genesis juga telah diupdate atau dibuat dengan kompatibilitas AMP.
Sejak peluncuran Genesis 3.0, respons komunitas sangat positif dengan banyak developer yang tidak hanya mengadopsi AMP sebagai bagian dari situs yang mereka bangun, tetapi juga berbagi pengetahuan dan pengalaman mereka dengan orang lain seperti yang bisa dilihat dalam postingan sangat bagus ini yang berjudul “Building a Native AMP WordPress Site”.

Pengoptimalan AMP editor blok WordPress dengan Atomic Blocks

Sama seperti tema khusus yang mengharuskan developer untuk mengoptimalkan kodenya untuk AMP, plugin yang mengontrol pengalaman front end juga harus melakukan hal yang sama. Dalam kasus kami, plugin Atomic Blocks memberikan pengalaman yang kaya bagi pembuat situs untuk menggunakan komponen situs yang disebut “blok” untuk menciptakan pengalaman baru terlepas dari tema yang mereka gunakan.
Membuat Atomic Blocks kompatibel dengan AMP sebenarnya merupakan pekerjaan yang mudah karena hanya beberapa elemen dari blok tersebut yang tidak tervalidasi AMP. Bagi saya, ini adalah contoh bagus tentang seberapa banyak fitur pengembangan dan desain bawaan yang bisa langsung kompatibel dengan AMP tanpa memerlukan refactor komplet.
Dalam kasus Atomic Blocks, kami bisa melakukan refactor bagian-bagian blok dan layout yang diaktifkan plugin agar kompatibel dengan AMP. Pekerjaannya sangat ringan, kami bisa mengerjakannya hanya dalam sekali sprint!
Dalam contoh di bawah ini, Anda bisa melihat betapa mudahnya bagi pembuat konten untuk membuat pengalaman AMP yang indah, berkinerja, dan fungsional tanpa menyadari bahwa pengalaman tersebut sudah 100% tervalidasi AMP.

Inilah jenis pengalaman mulus yang memberikan nilai tambah besar bagi tim marketing dan membantu menuntaskan roadmap dan halaman landing yang kompleks dari tugas-tugas yang harus diselesaikan tim developer. Dengan cara ini, brand bisa memanfaatkan kekuatan AMP sembari menciptakan pengalaman baru dalam hitungan jam vs. hari atau minggu.

Masa depan AMP untuk produk pengembangan dan desain WP Engine

Untuk framework tema Genesis, tim engineering kami terus mengikuti evolusi AMP untuk memastikan bahwa pelanggan kami dibekali dengan kemampuan terbaru dalam tema yang mereka bangun dengan Genesis. Kami juga berencana memperluas dukungan AMP di seluruh inventori tema Genesis premium sehingga pelanggan memiliki lebih banyak pilihan ketika memanfaatkan tema premium dan AMP.
Untuk plugin Atomic Blocks (yang juga digunakan dalam tema AMP premium), kami melanjutkan pendekatan 100% validasi AMP sehingga pengguna Atomic Blocks bisa menikmati set fitur lengkap Atomic Blocks dalam konteks AMP.
Meskipun kami menyadari bahwa beberapa pelanggan atau brand downline yang mereka layani mungkin tidak memilih untuk menerapkan strategi yang berfokus pada AMP, penting bagi kami bahwa ketika mereka melakukannya, kami mempersenjatai mereka dengan fitur yang memungkinkan tim developer untuk dapat menciptakan pengalaman yang indah, berkinerja, dan fungsional yang SANGAT DISUKAI pembuat konten.
Ditulis oleh David Vogelpohl, VP of Web Strategy di WP Engine


Sejak kami mengumumkan pratinjau developer AMP stories kami berfokus untuk memastikan format ini menjadi cara yang mudah dan menarik bagi penayang untuk membuat konten visual di web. Sangat menyenangkan melihat eksperimen dan arah yang diambil oleh beberapa penguji awal dengan produk ini.
Tentu saja ada banyak orang yang meminta kami untuk berbagi pembelajaran awal tentang cerita AMP – apa yang berhasil, apa yang tidak – jadi kami mencoba untuk menyusun ringkasan praktik terbaik dengan cepat di sini:

Kualitas Cerita

1) AMP stories adalah – cerita, yang ditujukan untuk mengomunikasikan pesan, menjelaskan situasi, suatu kejadian, seseorang, atau konsep. Penayang harus menceritakan kisah-kisah penting yang layak dibaca yang kaya secara visual dan berbagi informasi yang relevan dalam pengiring teks mereka. Kami telah melihat cerita-cerita visual yang dibuat dalam berbagai kategori konten, dari olahraga, resep, berita utama hingga hiburan. Beberapa hal yang harus dihindari:

• AMP storiesyang hanya merupakan slideshow gambar atau dihasilkan secara otomatis sering kali tidak memiliki konten inti yang diharapkan dan dicari pengguna saat memilih apa yang ingin dibaca.
• AMP stories harus lengkap, artikel mandiri; mereka harus masuk akal dan berguna bagi pengguna tanpa mengharuskan pengguna mengklik link lain.

Lihat contoh cerita AMP dari Washington Post, Mic.com dan FIFA (ditampilkan di atas).

2) Kualitas Aset Adalah Penting : Kami melihat interaksi pengguna yang jauh lebih baik ketika aset yang tepat dipilih dan diformat dengan benar untuk AMP stories sehingga pengguna merasa menjadi bagian dari pengalaman tersebut. Di luar relevansi, ini artinya gambar dan video memiliki resolusi tinggi, berorientasi potret, dan selayar penuh karena membuat pengalaman lebih imersif, indah, dan menarik bagi pengguna. Meskipun kami tahu bahwa memanfaatkan aset yang ada bisa mempercepat pembuatan cerita, harap perhatikan bahwa aset yang dipilih harus menyatu dengan pengalaman tersebut dan pas dengan dimensi perangkat yang digunakan untuk melihatnya.

3) Lebih Dari Sekadar Gambar Diam: Beberapa AMP stories yang paling menarik menggabungkan video singkat atau efek Ken Burns untuk melibatkan pengguna secara mendalam. Saat menggunakan video, lihat dokumentasi video kami di AMPproject.org, termasuk tips ini:

• Praktik terbaik adalah menggunakan 720p, yang pada rasio aspek 3:4 memiliki lebar 720px dan tinggi 960px: Over-indexing pada video resolusi tinggi tidak semestinya memperlambat waktu pemuatan cerita untuk kualitas yang berkurang.
• Jika menggunakan audio, harap perhatikan bahwa cerita AMP bisa berdiri sendiri dengan audio yang dimatikan, mengingat bahwa beberapa kasus penggunaan terjadi ketika pengguna sedang bepergian dan mungkin tidak ingin mengaktifkan audio. Untuk alasan ini framework AMP mendukung teks, serta kemampuan untuk menentukan apakah video berisi audio melalui atribut `noaudio`.

Mem-build Audience & Memonetisasinya

4) “Jika AMP stories yang sangat bagus dibuat tetapi tidak ada yang melihatnya, apakah itu ada?” Karena AMP stories bersifat self-canonical, kualitas dan relevansi (di seluruh web) berasal dari Cerita AMP itu sendiri. Seperti halaman lainnya, sinyal-sinyal ini penting agar dapat ditayangkan oleh platform seperti Google Penelusuran. Penayang harus mempromosikan AMP stories kepada pengguna di halaman beranda dan situs mereka sendiri, melalui saluran sosial, dan mekanisme promosi standar lainnya. Penayang berita harus mempertimbangkan penautan dari peta situs Google Berita.
5) Visibilitas & Pengindeksan: Ada sejumlah hal yang ingin dilakukan oleh penayang untuk memastikan bahwaAMP stories – meskipun mungkin condong ke visual – memiliki metadata dan struktur teks yang diperlukan untuk memastikan Google bisa menemukan dan memahami AMP stories:

• Buat semua teks bisa di-crawl: Gunakan overlay teks, daripada menyisipkan judul atau teks pengiring langsung ke dalam gambar atau video.
• Terapkan markup data terstruktur: Seperti AMP, penayang harus menyertakan data terstruktur yang tepat selain metadata khusus Cerita AMP. Perhatikan bahwa ada persyaratan ukuran yang unik untuk thumbnail utama dan gambar logo penayang khusus untuk dokumen Cerita AMP.

6) Bereksperimen dengan monetisasi: Meskipun baru beberapa bulan sejak kami membagikan dokumentasi publik di github untuk Single Page Ads di AMP stories, kami mulai melihat adopsi awal dari format yang memanfaatkan aset gambar dan video ini. Kami juga melihat eksperimen dengan real estat iklan untuk menjalankan eksperimen bagi produk mereka sendiri dan untuk podcast, newsletter, dll.

Fitur & Pengembangan

7) Uji lebih awal dan sering. Ada fitur layanan mandiri yang tersedia (situs Pengujian AMP dan Situs Pengujian Validasi AMP Google) sehingga penayang bisa menguji AMP storiessebelum mendorongnya ke web dan mengidentifikasi serta mengatasi error. Selain itu, penayang bisa menguji markup data terstruktur di sini. Komunitas AMP stories berharap fitur ini semakin kuat dari waktu ke waktu dan menantikan masukan agar fitur ini semakin bermanfaat.
8) Jadikan Itu Sebagai Milik Anda!: Seperti AMP, AMP stories adalah project open source dan keberhasilannya akan bergantung pada kontribusi penayang dan mitra di seluruh dunia yang memberikan masukan, permintaan fungsionalitas, dan bahkan kode itu sendiri. Dukungan teks dan subtitel ditambahkan ke project oleh organisasi yang menginginkan dukungan untuk fitur tersebut, tetapi membutuhkannya dengan cepat.  Dengan sedikit panduan dari tim AMP, mereka mengimplementasikan fitur tersebut, membuatnya tersedia untuk semua orang di sini.  Jika Anda memiliki pertanyaan atau ide, jangan ragu untuk menghubungi kami melalui saluran yang tepat di sini.

Kami gembira bisa terus bekerja sama dengan mitra untuk mengembangkan format ini dan berharap dapat mendengar – dan melihat! – dari Anda.
Ingin lebih banyak sumber daya?

• Pengantar untuk Mem-build AMP stories
• Praktik terbaik Cerita AMP
• Persyaratan AMP untuk Google Penelusuran
• Revisi Spesifikasi Ekstensi AMP stories

Ditulis oleh Lisa Lehman, AMP story Partnerships, Google



Model tata kelola baru dan terbuka untuk AMP

Dalam entri blog terpisah, kami mendiskusikan maksud kami untuk beralih ke model tata kelola baru untuk AMP Project.

AMP Linker

Untuk browser yang membatasi akses cookie pihak ketiga, AMP Linker adalah cara baru untuk menjaga sesi pengguna tetap sinkron. Lihat entri blog pemberitahuan kami untuk detail dan cara penerapannya di halaman Anda.

“Scroll tanpa batas” dengan amp-next-page

<amp-next-page> (sekarang tersedia sebagai versi eksperimen) mendukung apa yang disebut dengan “scroll tanpa batas” artikel. Developer bisa menetapkan hingga tiga URL yang akan dimuat ketika pengguna sampai ke kedalaman-scroll yang sudah ditetapkan dalam halaman, dan dokumen tersebut akan memuat dengan mulus secara berurutan.

Animasi tilt-bound dengan amp-orientation-observer

<amp-orientation-observer>, yang mendukung sinkronisasi tingkat-rendah antara orientasi perangkat dan bingkai pengguna dalam animasi yang diberikan, sekarang sudah diluncurkan. Dengan ini, Anda bisa membuat berbagai efek, seperti menggeser latar belakang halaman dengan halus, panning gambar, atau melanjutkan gerak animasi dengan memiringkan perangkat. Anda bahkan bisa membuat ruang 3D berlapis dengan menggeser beberapa komponen overlay dari suatu adegan dengan kecepatan yang berbeda.

Membandingkan gambar dengan amp-image-slider

<amp-image-slider> memberi pengguna kemampuan untuk membandingkan dua gambar sebagai overlay. Ini sangat berguna untuk perbandingan foto “sebelum dan sesudah”. Baca selengkapnya tentang komponen tersebut di entri blog terbaru kami.

Dukungan AMP Story Ads dengan Google Ad Manager (Beta)

Google Ad Manager sekarang mendukung pengiriman iklan yang terjual langsung oleh penayang ke AMP Stories yang mereka hasilkan. Anda bisa membaca selengkapnya tentang hal tersebut di sini.

Terbaik dari yang lain

• Kami meluncurkan beberapa komponen baru:
  • <amp-pan-zoom>, mendukung pan dan zoom konten interaktif inline. Komponen ini membantu pengguna pada berbagai kasus penggunaan, seperti memeriksa detail gambar produk, atau memilih kursi dalam denah kursi interaktif.
  • <amp-date-picker>, mendukung masukan tanggal dan rentang tanggal ke dalam formulir. Komponen ini sebelumnya diluncurkan sebagai eksperimen, dan sekarang tersedia secara umum. Detail selengkapnya di sini.
  • <amp-date-countdown>, menampilkan hitung mundur dinamis ke tanggal dan waktu tertentu.
  • <amp-google-document-embed> menampilkan file dokumen seperti dokumen Word, spreadsheet Excel, dan PDF secara inline di halaman AMP.
• Developer sekarang bisa menyesuaikan transisi masuk dan keluar dari komponen <amp-lightbox> yang ada.
• MOAT telah meluncurkan dukungan versi beta untuk instrumentasi keterlihatan dan deteksi spam bagi iklan AMPHTML. Silakan hubungi MOAT untuk berpartisipasi dalam versi beta.
• Penyedia email bisa mengintegrasikan dengan AMP for Email menggunakan petunjuk di sini.

Fitur-fitur mendatang yang layak diperhatikan

• Pernahkah Anda ingin terus menonton video saat membaca artikel mengenai video itu, atau membaca petunjuk resep sambil menonton seseorang mempraktikkannya? Atribut “dock” di <amp-video> akan segera mendukung pengecilan video ke sudut viewport saat pengguna melakukan scroll. Developer akan dapat menyesuaikan letak dan bentuk video ditempatkan.
• <amp-video-iframe> akan segera mendukung satu set fitur yang tersedia untuk amp-video dan komponen video pihak ketiga lainnya (misalnya, fitur pengecilan video di atas) untuk video yang tersemat di dalam iframe.
• Sama seperti AMP yang sekarang memiliki <amp-next-page> untuk “scroll tanpa batas” pada dokumen, segera hadir berikutnya adalah perilaku yang sama untuk elemen halaman dalam daftar. Ini sangat berguna untuk elemen daftar scroll tanpa akhir seperti hasil penelusuran dan kartu produk.
• Input masking akan segera membantu pengguna mengisi formulir secara lebih efisien dengan menambahkan pemformatan secara otomatis seperti spasi dan karakter pengantara yang ditentukan oleh developer.
• Dukungan untuk framework persetujuan dan transparansi IAB akan segera hadir sebagai bagian dari <amp-consent> bersama dengan kemampuan untuk mengintegrasikan CMP pihak ketiga. Jika Anda adalah CMP atau penayang yang ingin berintegrasi dengan framework persetujuan IAB di halaman AMP, silakan hubungi kami di GitHub.
• Pemutar <amp-ima-video>> disempurnakan dengan fitur baru dan perbaikan bug yang meliputi penambahan tombol mute/unmute yang hilang, perbaikan kontrol tersembunyi saat memutar dan kemampuan untuk mengulang video.
• Dukungan sticky ads di desktop ketika posisi konstan di pinggir kiri atau kanan halaman

* * *
Terima kasih kepada komunitas development AMP untuk karya dan masukan Anda. Seperti biasa, mohon beri tahu kami bila ada masalah atau permintaan fitur.
Ditulis oleh Eric Lindley, Product Manager, AMP Project at Google


Pada tahun 2016, layanan perbandingan asuransi mobil Australia Greenslips.com.au, memulai desain ulang situsnya. Setelah melihat framework web yang mampu memenuhi kebutuhannya, mereka memilih untuk mem-build kembali situs webnya dengan AMP. Ini memungkinkan tim developer mereka mempertahankan basis kode tunggal yang memastikan pengalaman hebat dan cepat di desktop dan seluler. Sejak meluncurkan situs “AMP-pertama” mereka awal tahun ini, Greenslips.com.au telah melihat peningkatan 12-15% (tergantung perangkat) dalam tingkat konversi di atas peningkatan kecepatan yang diharapkan sebesar 15%.

Greenslips.com.au tidak sendirian Kami telah melihat banyak contoh bisnis terkini dalam bidang publikasi dan e-commerce meraih keberhasilan dengan menerapkan AMP di situs mereka. Pada bulan lalu, kami memublikasikan 5 studi kasus baru di AMPproject.org — dan lebih banyak lagi akan segera menyusul. Meskipun masing-masing kasus ini unik, kami berharap bahwa dengan membagikannya, bisnis dan developer bisa lebih memahami bagaimana memanfaatkan AMP dapat menguntungkan bagi situs mereka.
Penayang India seperti The Tribune dan Jagran New Media telah melihat peningkatan pendapatan pada halaman AMP, yang disambungkan dengan situs tradisional mereka. Secara khusus, Jagran New Media melihat peningkatan pendapatan 4,5 kali dari seluler, bersama dengan peningkatan traffic. Readwhere, provider CMS yang digunakan oleh The Tribune, melihat pendapatan seluler dan keterlihatan iklan yang lebih tinggi di halaman AMP mereka.

Kami juga melihat situs e-commerce mendapatkan manfaat dari kecepatan dan keuntungan pengguna yang disediakan oleh AMP. E-retailer Indonesia Tokopedia melihat peningkatan 5 kali dalam konversi dan penurunan bounce rate dari implementasi AMP mereka. Dan ketika AMP digunakan dengan solusi periklanan seperti AdWords, bisnis ini sering kali meraih keuntungan dari campaign mereka. DiscoverCarHire.com secara khusus melihat peningkatan 22% dalam kunjungan seluler dan 29% lebih banyak konversi dari perangkat seluler melalui Google Ads-nya.

Lihat studi kasus AMP baru di bawah dan berlangganan newsletter kami untuk mendapatkan update AMP Project terbaru di kotak masuk Anda.

• Greenslips.com.au – peningkatan rasio konversi 12-15%
• DiscoverCarHire.com – 29% lebih banyak konversi dari seluler
• Tokopedia – rasio konversi seluler 5 kali
• Readwhere & The Tribune – pendapatan inkremental 30%
• Jagran New Media – peningkatan pendapatan 4,5 kali
• Renovation Brands – sesi lebih lama 27%
• Superbalist – 26% peningkatan rasio konversi (diposting di Think with Google)
• Compare The Market – Penurunan 50% dalam bounce rate (diposting di Think with Google)

Apakah Anda sudah berhasil dengan AMP? Beri tahu kami dengan menghubungi di Twitter atau dengan memberikan catatan dalam formulir ini!
Ditulis oleh Matt Ludwig, AMP Project marketing lead di Google


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:

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


Catatan editor: Artikel berikut awalnya diposting di Medium oleh Vamsee Jasti, AMP Product Manager di Google. Postingan ini adalah bagian dari seri monetisasi AMP yang lebih besar.
Saya tidak habis-habisnya terpesona bahwa pengiklan mau membayar untuk tayangan iklan yang tidak pernah dilihat pengguna. Namun, begitulah sebagian besar isi default kontrak iklan. Banyak merek mengubah cara mereka menegosiasikan kontrak atau mendefinisikan ulang apa yang mereka sebut keterlihatan. Ditambah lagi, terminologi itu sendiri bisa membingungkan.

Data Loading Strategy pada amp-ad

<amp-ad width="300"
  height="250"
  type="a9"
  data-loading-strategy=1
  data-aax_size="300x250"
  data-aax_pubname="test123"
  data-aax_src="302">
</amp-ad>

Jika penayang tidak mengonfigurasi nilai ini atau nilainya ditetapkan ke ‘prefer-viewability-over-views’, maka waktu proses menyetel nilai float ke nilai default 1,25, yang merupakan nilai yang telah teruji untuk memberikan nilai keterlihatan tinggi tanpa secara drastis memengaruhi total iklan yang ditayangkan.

data-loading-strategy="prefer-viewability-over-views"

Efek Render on Idle

Terima kasih kepada Rudy Galfi dan Maggie Shiels untuk postingan ini.


“Jika tidak dapat mengukurnya, Anda tidak dapat mengelolanya.” — Peter Drucker
Oleh karena pengguna menuntut kontrol privasi yang lebih baik, maka vendor browser mulai meresponsnya dengan setelan default yang memilah cookie. Ini berarti, pendekatan tradisional yang mengandalkan cookie pihak ketiga untuk pengukuran tidak akan berfungsi di masa mendatang.
Halaman AMP sering kali ditayangkan dari AMP Cache dan kemampuan untuk mempertahankan sesi dengan menggunakan cookie pihak ketiga memungkinkan penayang untuk mengingat setelan dan preferensi pengguna bahkan ketika pengguna berpindah antara domain cache AMP dan domain penayang.

AMP Linker

AMP Linker adalah fitur baru di AMP yang membantu menjaga sesi pengguna tetap sinkron. AMP Linker bekerja dengan menandai link keluar dari cache AMP dengan parameter seperti AMP Client ID dalam parameter URL. Di sisi penerima, penyedia analytics Anda menggunakan parameter dan menuliskannya sebagai cookie pihak pertama.
Link yang ditandai tampilannya akan terlihat seperti ini
https://destination.com/checkout?_foo=1*19eaxqc*bar*V2dj…eHZKYg

Mengaktifkan AMP Linker

AMP Linker berfungsi dengan menyertakan konfigurasi untuk penyedia analytics Anda. Misalnya, jika Anda menggunakan Google Analytics Anda perlu menyertakan kode berikut:

<amp-analytics type=”googleanalytics”>
 <script type=”application/json”>
   {
     “linkers”: {
       ”enabled”: true
     }
   }
</script>
</amp-analytics>

Jika Anda sudah menggunakan Google AMP Client ID API dengan Google Analytics, tidak diperlukan pemberian tag tambahan untuk memanfaatkan kemampuan AMP Linker.
Jika Anda adalah penyedia analytics, silakan menghubungi kami untuk memanfaatkan AMP Linker.

Memandang ke depan

Kami bekerja keras untuk mendukung user journey nontradisional, tetapi penting, seperti ketika pengguna beralih dari halaman non-AMP ke halaman AMP. Ikuti terus repo kami di Github untuk mengetahui update terbaru tentang hal ini.
Selamat mengukur!
Ditulis oleh Jeff Jose, Product Manager, AMP Project at Google