AMP
ID
English Deutsch Français العربية Español Italiano 日本語 한국어 Português Русский Türkçe 中文 Polski Tiếng việt

Mengoptimalkan halaman AMP Anda yang dikelola pihak lain (hosted)

Panduan ini menyediakan kiat dan panduan untuk para webmaster (master web) tentang cara mengoptimalkan situs web AMP mereka yang dikelola pihak lain.

Bukankah AMP distandarkan cepat?

Runtime AMP dioptimalkan untuk kecepatan dan jika halaman AMP Anda disajikan oleh sebuah cache AMP, halaman tersebut dioptimalkan sepenuhnya dan menawarkan kinerja pemuatan tertinggi. Contohnya: jika pengguna Anda datang ke halaman AMP Anda dari Google Search di perangkat seluler, sebagai standar, halaman akan disajikan oleh cache AMP.

Namun, halaman AMP tidak selalu disajikan dari cache AMP. Sebuah situs web mungkin memutuskan untuk memperlihatkan halaman AMP dari servernya sendiri untuk sumber lalu lintas lain. Contoh penggunaan yang paling sering adalah situ yang dibuat sepenuhnya dalam AMP, seperti tasty.co, di mana pengguna langsung ke situsnya. Sumber lalu lintas lain adalah Twitter, yang memulai penautan ke halaman AMP, bukannya menyampaikan versi seluler standar. Ini berarti bahwa jika seorang pengguna mengeklik suatu tautan di salah satu dari aplikasi seluler Twitter, tautan tersebut membuka versi AMP halaman Anda di asal Anda sendiri (jika tersedia).

Sebagai konsekuensinya, Anda tidak selalu dapat memastikan bahwa halaman AMP Anda hanya disajikan dari cache AMP. Untuk kasus ini, di mana Anda menyajikan halaman AMP dari server Anda sendiri, penting untuk memastikan bahwa halaman AMP Anda menawarkan kinerja pemuatan yang optimal.

Halaman AMP distandarkan untuk memuat dengan cepat, tetapi ada beberapa pengoptimalan kinerja tambahan yang dapat Anda terapkan untuk membantu browser memuat halaman AMP jauh lebih cepat. Panduan ini menjelaskan beberapa pengoptimalan yang sebaiknya Anda pertimbangkan jika menayangkan halaman AMP. Namun, sebelum Anda mulai membaca panduan ini, pastikan bahwa Anda telah mencakup semua praktik terbaik kinerja web dasar. Secara khusus, pengoptimalan gambar mempunyai dampak besar pada kinerja pemuatan.

Contohnya, dengan menerapkan teknik-teknik pengoptimalan berikut ini:

Templat "The Scenic" memuat dua detik lebih cepat pada koneksi 3G.

Jika Anda ingin melewati detailnya, kunjungi penghasil Boilerplate AMP, yang dapat Anda gunakan untuk menghasilkan halaman AMP yang dioptimalkan secara kustom.

Mengoptimalkan pemuatan Runtime AMP

Walaupun AMP sudah cukup ketat tentang markah mana yang diizinkan di bagian <head>, masih ada ruang untuk pengoptimalan. Kuncinya adalah untuk membuat struktur bagian <head> sedemikian rupa sehingga semua skrip pemblokir render/pemuatan dan font kustom dimuat secepat mungkin.

Berikut ini adalah urutan yang disarankan untuk bagian <head> di halaman AMP:

<!doctype html>
<html ⚡ lang="en">
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width">
    <meta name="description" content="This is the AMP Boilerplate.">
    <link rel="preload" as="script" href="https://cdn.ampproject.org/v0.js">
    <link rel="preload" as="script" href="https://cdn.ampproject.org/v0/amp-experiment-0.1.js">
    <link rel="preconnect dns-prefetch" href="https://fonts.gstatic.com/" crossorigin>
    <script async src="https://cdn.ampproject.org/v0.js"></script>
    <script async custom-element="amp-experiment" src="https://cdn.ampproject.org/v0/amp-experiment-0.1.js"></script>
    <!-- Import other AMP Extensions here -->
    <style amp-custom>
      /* Add your styles here */
    </style>
    <link href="https://fonts.googleapis.com/css?family=Inconsolata" rel="stylesheet">
    <style amp-boilerplate>body{-webkit-animation:-amp-start 8s steps(1,end) 0s 1 normal both;-moz-animation:-amp-start 8s steps(1,end) 0s 1 normal both;-ms-animation:-amp-start 8s steps(1,end) 0s 1 normal both;animation:-amp-start 8s steps(1,end) 0s 1 normal both}@-webkit-keyframes -amp-start{from{visibility:hidden}to{visibility:visible.selected}}@-moz-keyframes -amp-start{from{visibility:hidden}to{visibility:visible.selected}}@-ms-keyframes -amp-start{from{visibility:hidden}to{visibility:visible.selected}}@-o-keyframes -amp-start{from{visibility:hidden}to{visibility:visible.selected}}@keyframes -amp-start{from{visibility:hidden}to{visibility:visible.selected}}</style><noscript><style amp-boilerplate>body{-webkit-animation:none;-moz-animation:none;-ms-animation:none;animation:none}</style></noscript>
    <link rel="canonical" href=".">
    <title>My AMP Page</title>
  </head>
  <body>
    <h1>Hello World</h1>
  </body>
</html>

Mari kita bahas langkah demi langkah:

  1. Tag pertama harus tag meta charset, diikuti oleh tag meta yang tersisa.

  2. Selanjutnya, muat terlebih dahulu tag v0.js <script> runtime AMP dengan <link as=script href=https://cdn.ampproject.org/v0.js rel=preload>. Runtime AMP harus mulai mengunduh sesegera mungkin karena boilerplate AMP menyembunyikan dokumen melalui body { visibility:hidden } hingga runtime AMP telah dimuat. Memuat runtime AMP terlebih dahulu menjadi isyarat bagi browser untuk mengunduh skrip tersebut dengan prioritas yang lebih tinggi. Kunjungi perenderan sisi server untuk belajar cara menghindari hal ini.

  3. Jika halaman Anda menyertakan ekstensi penunda perenderan (cth., amp-experiment, amp-dynamic-css-classes, amp-story), muat terlebih dahulu ekstensi tersebut karena mereka dibutuhkan oleh runtime AMP untuk merender halaman.

<link as="script" rel="preload" href="https://cdn.ampproject.org/v0/amp-custom-css-0.1.js">
<link as="script" rel="preload" href="https://cdn.ampproject.org/v0/amp-experiment-0.1.js">
<link as="script" rel="preload" href="https://cdn.ampproject.org/v0/story-1.0.js">
  1. Gunakan preconnect untuk mempercepat koneksi ke asal lain di mana URL sumber daya lengkapnya tidak diketahui sebelumnya, contoh: saat menggunakan Google Fonts:
<link rel="preconnect dns-prefetch" href="https://fonts.gstatic.com/" crossorigin>
  1. Muat runtime AMP:
<script async src="https://cdn.ampproject.org/v0.js"></script>
  1. Tentukan tag <script> untuk ekstensi penunda perenderan (cth.: amp-experiment amp-dynamic-css-classes, dan amp-story).
  2. Tentukan tag <script> untuk ekstensi yang tersisa (cth.: amp-bind ...). Ekstensi ini tidak menunda perenderan, dan oleh karena itu, tidak boleh dimuat sebelumnya karena dapat menghabiskan bandwidth penting untuk perenderan awal.
  3. Tentukan gaya kustom apa pun dengan menggunakan tag <style amp-custom>.
  4. Tambahkan tag lain yang diizinkan di bagian <head>. Secara khusus, font eksternal apa pun harus yang paling lama bertahan karena mereka menghalangi perenderan.
  5. Terakhir, tentukan kode boilerplate AMP. Dengan memasukkan kode boilerplate terakhir, ini mencegah gaya kustom secara tidak sengaja menimpa aturan CSS boilerplate.

Cache AMP melakukan semua pengoptimalan ini secara otomatis (dan beberapa lagi). Anda dapat menggunakan alat Pengoptimal AMP untuk secara otomatis melakukan pengoptimalan ini di asal Anda sendiri.

Pramuat gambar hero

HTML AMP menggunakan elemen gambarnya sendiri: amp-img. Sementara amp-img mempunyai banyak keuntungan dibanding tag img HTML biasa, salah satu kerugiannya adalah runtime AMP harus dimuat sebelum pengunduhan gambar dapat dimulai. Bagi beberapa gambar, seperti gambar hero untuk halaman produk, sangat penting agar gambar dimuat secepat mungkin. Di dalam kasus ini, yang terbaik adalah memuat gambar sebelumnya untuk memastikan bahwa browser mulai mengunduh gambar sesegera mungkin dan tidak perlu menunggu hingga runtime AMP telah dimuat.

<head>
  <link rel="preload" href="/images/elephants.png" as="image">
</head>
<body>
  ...
  <amp-img width="404" height="720" layout="responsive"
           src="/images/elephants.png" alt="..." >
  </amp-img>
</body>

Namun, bagaimana jika tata letak responsif Anda membutuhkan gambar hero yang berbeda sesuai dengan lebar layar? Contohnya: gambar lebar untuk desktop dan gambar sempit untuk seluler, seperti ini:

<amp-img width="404" height="720"
    alt="..." layout="responsive"
    src="/images/elephants_narrow.png"
    media="(max-width: 415px)">
</amp-img>
<amp-img height="720"
    alt="..." layout="fixed-height"
    src="/images/elephants_wide.jpg"
    media="(min-width: 416px)">
</amp-img>

Untungnya, link rel=preload juga mendukung kueri media. Jadi, kita dapat menggunakan kueri media yang sama di dalam pernyataan kita yang telah dimuat sebelumnya, seperti ini:

<link rel="preload" as="image"
    href="/images/elephants_narrow.png"
    media="(max-width: 415px)">
<link rel="preload" as="image"
    href="/images/elephants_wide.jpg"
    media="(min-width: 416px)">

Omong-omong, pendekatan yang sama berhasil untuk gambar poster amp-video:

<link rel="preload" href="/images/poster.jpg" as="image">
...
 <amp-video width="480" height="270" src="elephant.mp4"
             poster="/images/poster.jpg"
             layout="responsive">
     ...
</amp-video>

Cukup pastikan untuk menempatkan pernyataan yang telah dimuat sebelumnya setelah pernyataan viewport karena browser memerlukan dimensi viewport untuk menentukan lebar layar:

<meta name="viewport" content="width=device-width">
...
<link rel="preload" media="(max-width: 415px)" ...>

Lakukan pemuatan sebelumnya untuk gambar penting saja, jika tidak, pengunduhan gambar dapat menguasai bandwidth yang diperlukan untuk pengunduhan penting lainnya.

Mempertimbangkan penggunaan pekerja layanan (service worker)

Karena semua browser besar mendukung pekerja layanan, mengevaluasi apakah masuk akal untuk menambahkan pekerja layanan ke situs Anda merupakan ide yang bagus.

Ada dua pola arsitektural yang berbeda yang kita ketahui akan bekerja untuk navigasi yang cukup cepat:

  • Untuk aplikasi halaman tunggal: model App Shell (di dalam konteks AMP disebut sebagai AMP-dalam-PWA). Pola ini mengharuskan pekerja layanan untuk meningkatkan dokumen AMP ke pengalaman PWA berbasis shell aplikasi.
  • Untuk aplikasi multi-halaman: streaming sumber daya komposit. Pekerja layanan menyimpan tajuk serta bagian kaki statis di cache dan menggunakan streaming untuk seketika menghasilkan tanggapan sebagian yang disimpan di cache sambil memuat konten.

Jika tidak ada dari pola ini yang digunakan dan mustahil untuk menyimpan seluruh situs di cache (hanya masuk akal untuk situs yang sangat kecil), sebuah pekerja layanan mungkin mempunyai dampak kinerja negatif. Hal terbaik di dalam hal ini adalah untuk tidak menggunakan pekerja layanan.

Namun, jika Anda ingin situs web Anda dapat diinstal dari layar utama, atau ingin menawarkan pengalaman offline, Anda harus menggunakan pekerja layanan. Di dalam hal ini, penting untuk menggunakan pramuat navigasi untuk mengurangi potensi pelambatan (Catatan: Saat ini, pramuat (preload) navigasi hanya didukung di Chrome).

Jika situs web AMP Anda menggunakan pekerja layanan, berikut ini adalah beberapa praktik terbaik:

Jika Anda mencari cara untuk memulai dengan pekerja layanan di situs AMP Anda, lihat sampel ini yang menyediakan pekerja layanan yang menerapkan semua praktik terbaik ini.

Runtime AMP disajikan dengan umur maksimal selama 50 menit untuk memastikan pembaruan tersedia dengan cepat. Untuk menghindari kemungkinan kegagalan cache browser, bagus jika menyajikan runtime AMP dari pekerja layanan.

Menyimpan di cache sebelumnya tidak hanya relevan untuk beralih dari halaman AMP di cache ke halaman non-AMP di asal Anda sendiri, namun juga untuk beralih dari halaman AMP yang di cache ke halaman AMP di asal Anda sendiri. Alasannya adalah bahwa cache AMP menulis ulang URL runtime AMP dari URL abadi ke versi rilis terbaru, contohnya:

https://cdn.ampproject.org/v0.js -> https://cdn.ampproject.org/rtv/001515617716922/v0.js.

Konsekuensinya adalah bahwa halaman AMP yang disajikan dari asal Anda tidak mendapatkan keuntungan dari penyimpanan browser di cache, dan dalam hal ini harus mengunduh (tanpa versi) runtime AMP kembali. Dengan pekerja layanan, Anda dapat menyimpan runtime AMP tanpa versi sebelumnya di cache dan mempercepat transisi. Untuk mengetahui selengkapnya tentang mengapa cache AMP mempunyai versi URL runtime AMP, bacalah dokumen ini.

Di Safari, ada perbedaan penting tentang cara pekerja layanan diterapkan -- di Safari mustahil menginstal pekerja layanan untuk asal Anda jika halaman tersebut disajikan dari sebuah cache AMP.

Mengoptimalkan font kustom

Dengan AMP, ada beberapa hal yang dapat Anda lakukan untuk mengoptimalkan pemuatan font Anda (sebagian besar dari mereka sebenarnya tidak spesifik untuk AMP):

  • Jika mungkin, gunakan font-display: opsional: Ini hanya akan menggunakan font tersebut jika sudah ada di cache, dan kembali ke font sistem jika font kustom Anda belum dimuat.
  • Optimalkan font web Anda (contohnya, sajikan font kustom dengan menggunakan WOFF2).
  • Muat font kustom terlebih dahulu:
<link rel="preload" as="font" href="/bundles/app/fonts/helveticaneue-roman-webfont.woff2" >
  • Jika Anda menggunakan Google Fonts, atau penyedia font lainnya dengan URL font yang tidak diketahui, sambungkan server font yang bersangkutan terlebih dahulu:
 <link rel="preconnect dns-prefetch" href="https://fonts.gstatic.com/" crossorigin>

Terakhir, namun tidak kalah penting, cobalah untuk meminimalkan jumlah font kustom yang Anda gunakan di halaman Anda. Jika bisa, gunakan font sistem sebagai ganti font kustom karena font sistem membuat situs web Anda cocok dengan sistem operasi pengguna, dan ini membantu menghindari memuat lebih banyak sumber daya.

Tata Letak AMP Perenderan Sisi Server

Tata Letak AMP perenderan sisi server merupakan suatu teknik yang digunakan cache AMP untuk semakin mempercepat waktu pemuatan. Dengan perenderan sisi server, boilerplate AMP dapat dihapus sehingga dokumen AMP dapat diwarnai tanpa menjalankan JavaScript runtime AMP. Contohnya: versi Penghasil Boilerplate AMP yang dirender sisi server merender dua kali lebih cepat dibanding versi AMP biasa!

Jika Anda menayangkan sebuah halaman AMP, Anda sebaiknya mempertimbangkan untuk menggunakan Pengoptimal AMP. Pengoptimal AMP membuat Anda bisa menyajikan halaman AMP yang telah dioptimalkan dari backend Anda sendiri yang menyertakan tata letak AMP perenderan sisi server. Pengoptimal AMP juga secara otomatis melakukan banyak pengoptimalan lain yang dijelaskan di dalam dokumen ini.

Pengoptimalan dasar

Tentu saja, semua dasar pengoptimalan kinerja web juga berlaku pada halaman AMP: