Rabu, 9 November 2016
Progressive Web App (PWA) memanfaatkan teknologi baru untuk menghadirkan situs seluler dan aplikasi native terbaik kepada pengguna, dan aplikasi ini adalah salah satu ide baru yang paling menarik di web. Namun, agar memiliki dampak nyata, Progressive Web App harus dapat diindeks dan ditautkan. Setiap rekomendasi yang disajikan dalam artikel ini merupakan praktik terbaik yang sudah ada guna meningkatkan potensi untuk diindeks, terlepas dari apakah Anda mem-build Progressive Web App atau situs statis sederhana. Meskipun demikian, kami telah menyusun praktik terbaik ini sebagai checklist untuk memandu Anda:
Membuat Konten Anda Dapat Di-crawl
Mengapa demikian? Secara historis, situs akan selalu membuat atau merender HTML di server. Hal ini merupakan cara paling sederhana untuk memastikan apakah konten Anda ditautkan secara langsung. Aplikasi web memopulerkan konsep rendering sisi klien, di mana konten diperbarui secara dinamis di halaman selagi pengguna bernavigasi, tanpa harus memuat ulang halaman.
Pendekatan modernnya adalah rendering hybrid. Dalam pendekatan ini, rendering sisi server digunakan saat pengguna bernavigasi langsung ke URL dan rendering sisi klien digunakan setelah pemuatan halaman awal untuk konten asinkron dan permintaan navigasi selanjutnya.
Sampel PWA sisi server kami mendemonstrasikan rendering sisi server murni, sedangkan sampel PWA hybrid kami mendemonstrasikan pendekatan gabungan.
Jika Anda belum memahami terminologi rendering sisi server dan sisi klien, lihat artikel tentang rendering sisi klien dan sisi server, serta rendering sisi server di react dan node.js.
Praktik terbaik:
Gunakan rendering sisi server atau hybrid sehingga pengguna menerima konten dalam payload awal permintaan web mereka.
Selalu pastikan URL Anda dapat diakses satu per satu:
https://www.example.com/product/25/
URL di atas harus merupakan deep link ke resource tersebut.
Jika Anda tidak dapat mendukung rendering sisi server atau hybrid untuk Progressive Web App dan Anda memutuskan untuk menggunakan rendering sisi klien, sebaiknya gunakan "alat Fetch as Google" di Google Search Console untuk memverifikasi bahwa konten Anda berhasil dirender untuk crawler Penelusuran kami.
Jangan mengalihkan pengguna yang mengakses deep link kembali ke halaman beranda aplikasi web Anda.
Selain itu, sebaiknya hindari menayangkan laman kesalahan kepada pengguna sebagai ganti tautan dalam.
Memberikan URL yang Bersih
Mengapa demikian? ID fragmen (#user/24601/ atau #!user/24601/) adalah
solusi efektif bagi browser untuk konten baru AJAX dari server, tanpa memuat ulang halaman.
Desain ini dikenal sebagai rendering sisi klien.
Namun, sintaksis ID fragmen tidak kompatibel dengan beberapa alat web, framework, dan protokol seperti protokol Open Graph Facebook.
History API memungkinkan
kami memperbarui URL tanpa ID fragmen sembari tetap mengambil resource secara asinkron sehingga dapat
menghindari pemuatan ulang halaman. Tindakan ini akan menguntungkan keduanya. Skema crawling AJAX
(dengan URL fragmennya yang di-escape/#!) dulu merupakan hal yang wajar, tetapi
sekarang tidak direkomendasikan lagi.
Sampel PWA sisi klien dan PWA hybrid kami mendemonstrasikan History API.
Praktik terbaik:
Berikan URL yang bersih tanpa ID fragmen (# atau #!), misalnya:
https://www.example.com/product/25/
Jika menggunakan rendering sisi klien atau hybrid, pastikan untuk mendukung navigasi browser dengan History API.
Hindari:
Penggunaan struktur URL #! untuk mendorong URL unik tidak disarankan:
https://www.example.com/#!product/25/
Cara ini diperkenalkan sebagai solusi sebelum adanya History API dan dianggap sebagai pola yang terpisah
dari struktur URL # murni.
Penggunaan struktur URL # tanpa simbol ! yang menyertainya
tidak didukung:
https://www.example.com/#product/25/
Struktur URL ini sudah menjadi konsep di web dan terkait dengan deep linking ke konten di halaman tertentu.
Menentukan URL Kanonis
Mengapa demikian? Cara terbaik agar tidak menimbulkan kebingungan pengindeksan jika konten yang sama tersedia di beberapa URL (baik di domain yang sama atau berbeda), adalah dengan menandai satu halaman sebagai kanonis, dan membuat semua halaman lain yang menggandakan konten tersebut agar merujuk ke halaman itu.
Praktik terbaik:
Sertakan tag berikut di semua halaman yang mencerminkan bagian konten tertentu:
<link rel="canonical" href="https://www.example.com/your-url/" />
Jika Anda mendukung Accelerated Mobile Pages, pastikan Anda juga menggunakan petunjuk rel="amphtml"
yang serupa.
Hindari:
Hindari menggandakan konten dengan sengaja di beberapa URL dan tidak menggunakan
elemen link rel="canonical".
Misalnya, elemen link rel="canonical" dapat mengurangi ambiguitas untuk URL dengan
parameter pelacakan.
Hindari membuat referensi kanonis yang bertentangan di antara halaman Anda.
Desain untuk Beberapa Perangkat
Mengapa demikian? Pastikan semua pengguna mendapat pengalaman terbaik saat melihat situs Anda, apa pun perangkat yang digunakan.
Jadikan desain situs Anda responsif —font, margin, padding, tombol, dan desain umum situs harus diskalakan secara dinamis berdasarkan resolusi layar dan area pandang perangkat.
Gambar kecil yang ditingkatkan skalanya untuk perangkat desktop atau tablet akan memberikan pengalaman yang buruk. Sebaliknya, gambar dengan resolusi super tinggi memerlukan waktu lama untuk didownload di ponsel dan dapat memengaruhi performa scroll di seluler.
Baca selengkapnya tentang UX untuk PWA.
Praktik terbaik:
Gunakan
atribut srcset
untuk mengambil gambar beresolusi berbeda bagi layar berkepadatan berbeda guna menghindari mendownload
gambar yang lebih besar dari yang dapat ditampilkan di layar perangkat.
Skalakan ukuran font dan tinggi baris untuk memastikan teks Anda mudah dibaca apa pun ukuran perangkatnya. Demikian pula, pastikan padding dan margin elemen juga diskalakan dengan semestinya.
Uji berbagai resolusi layar menggunakan fitur Mode Perangkat Chrome Developer Tools dan Alat Uji untuk Mobile-Friendly.
Jangan tampilkan konten yang berbeda kepada pengguna dari yang Anda tampilkan ke Google. Jika Anda menggunakan pengalihan atau deteksi agen pengguna (alias sniffing browser atau penayangan dinamis) untuk mengubah desain situs Anda untuk perangkat yang berbeda, pastikan bahwa kontennya tetap sama.
Gunakan alat "Fetch as Google" di Search Console untuk memverifikasi bahwa konten yang diambil oleh Google cocok dengan konten yang dilihat pengguna.
Untuk alasan kegunaan, hindari menggunakan font berukuran tetap.
Mengembangkan Secara Iteratif
Mengapa demikian? Salah satu cara paling aman untuk menambahkan fitur ke aplikasi web adalah melakukan perubahan secara iteratif. Jika menambahkan fitur satu per satu, Anda dapat mengamati dampak dari setiap perubahan.
Selain itu, banyak developer cenderung melihat progressive web app mereka sebagai peluang untuk memperbaiki situs seluler secara bersamaan, yakni dengan mengembangkan aplikasi web baru dalam lingkungan terpisah dan menggantinya dengan situs seluler yang ada saat sudah siap.
Saat mengembangkan fitur secara iteratif, coba pisahkan perubahan menjadi beberapa bagian. Misalnya, jika Anda ingin beralih dari rendering sisi server ke rendering hybrid, lakukan iterasi tunggal daripada menggabungkan dengan fitur lain.
Kedua pendekatan ini memiliki keunggulan dan kekurangan masing-masing. Dengan iterasi, kompleksitas terkait potensi pengindeksan penelusuran dapat berkurang karena transisi yang berkelanjutan. Namun, iterasi dapat memperlambat proses pengembangan dan kemungkinan membuat perbaikan menjadi kurang inovatif jika pengembangan tidak dimulai dari awal.
Dalam kedua kasus tersebut, bagian terpenting yang perlu diperhatikan adalah URL kanonis dan konfigurasi robots.txt situs Anda.
Praktik terbaik:
Lakukan iterasi di situs Anda secara bertahap dengan menambahkan fitur baru satu per satu.
Misalnya, jika belum mendukung HTTPS, mulailah dengan migrasi ke situs yang aman.
Hindari:
Jika Anda telah mengembangkan progressive web app di lingkungan terpisah, jangan meluncurkannya tanpa memeriksa apakah link rel-canonical dan robots.txt telah disiapkan dengan tepat.
Pastikan link rel-canonical mengarah ke situs sebenarnya, dan konfigurasi robots.txt memungkinkan crawler meng-crawl situs baru Anda.
Anda mungkin ingin mencegah crawler mengindeks situs yang masih dalam pengembangan sebelum diluncurkan, tetapi jangan lupa untuk berhenti memblokir crawler dari mengakses situs baru Anda setelah diluncurkan.
Menggunakan Progressive Enhancement
Mengapa demikian? Jika memungkinkan, sebaiknya deteksi fitur browser sebelum menggunakannya. Deteksi fitur juga lebih baik daripada menguji browser yang Anda yakini mendukung fitur tertentu.
Sebelumnya, praktik buruk yang umum dilakukan adalah mengaktifkan atau menonaktifkan fitur dengan menguji browser mana yang digunakan oleh pengguna. Namun, karena fitur di browser terus berkembang, teknik ini sangat tidak disarankan.
Pekerja Layanan merupakan teknologi yang relatif baru dan penting untuk tidak merusak kompatibilitas dalam mengejar kemajuan—ini adalah contoh waktu penggunaan progressive enhancement yang sempurna.
Praktik terbaik:
Sebelum mendaftarkan Pekerja Layanan, periksa ketersediaan API-nya:
if ('serviceWorker' in navigator) {
...
Gunakan metode deteksi per API untuk semua fitur situs Anda.
Jangan pernah menggunakan agen pengguna browser untuk mengaktifkan atau menonaktifkan fitur di aplikasi web Anda. Selalu periksa apakah API fitur tersedia dan lakukan degradasi halus jika tidak tersedia.
Hindari memperbarui atau meluncurkan situs tanpa mengujinya di beberapa browser. Periksa analisis situs untuk mempelajari browser mana yang paling populer di kalangan basis pengguna Anda.
Menguji dengan Search Console
Mengapa demikian? Anda harus memahami cara Google Penelusuran melihat konten situs. Anda dapat menggunakan Search Console untuk mengambil setiap URL dari situs Anda dan memahami cara Google Penelusuran melihat URL tersebut menggunakan fitur "Crawl > Fetch as Google". Search Console akan memproses JavaScript dan merender halaman ketika opsi tersebut dipilih; jika tidak, hanya respons HTML mentah yang akan ditampilkan.
Google Search Console juga menganalisis konten di halaman Anda dalam berbagai cara, termasuk mendeteksi kehadiran Data Terstruktur, Kartu Informasi, Sitelink, dan Accelerated Mobile Pages.
Praktik terbaik:
Pantau situs Anda menggunakan Search Console dan jelajahi fiturnya, termasuk Fetch as Google.
Berikan peta situs melalui Crawl > Peta Situs di Search Console. Tindakan ini mungkin merupakan cara yang efektif untuk memastikan Google Penelusuran mengetahui semua halaman situs Anda.
Menganotasi dengan data terstruktur Schema.org
Mengapa demikian? Data terstruktur Schema.org adalah
kosakata fleksibel untuk merangkum bagian terpenting dari halaman Anda sebagai data yang dapat diproses oleh
mesin. Hal ini bisa jadi sama umumnya dengan mengatakan bahwa sebuah halaman adalah NewsArticle,
atau sama detailnya dengan menjelaskan lokasi, nama band, tempat konser, dan vendor tiket untuk band yang menggelar tur, atau
merangkum bahan dan cara memasak resep.
Penggunaan metadata ini mungkin tidak berlaku untuk setiap halaman di aplikasi web Anda, tetapi tindakan ini disarankan apabila sesuai. Google mengekstraknya setelah halaman dirender.
Terdapat berbagai jenis data, termasuk NewsArticle, Recipe, dan
Product. Anda juga dapat mempelajari semua
jenis data yang didukung di sini.
Praktik terbaik:
Gunakan Alat Pengujian Data Terstruktur untuk memverifikasi bahwa metadata Schema.org Anda sudah benar.
Periksa apakah data yang Anda berikan muncul dan tidak ada error.
Hindari menggunakan jenis data yang tidak cocok dengan konten halaman Anda yang sebenarnya. Misalnya, jangan gunakan
Recipe untuk Kaus yang Anda jual. Gunakan Product sebagai gantinya.
Menganotasi dengan Open Graph & Kartu Twitter
Mengapa demikian? Selain metadata Schema.org, menambahkan dukungan bagi protokol Open Graph Facebook dan kartu informasi Twitter juga akan membantu.
Format metadata ini meningkatkan pengalaman pengguna ketika konten Anda dibagikan di jaringan sosial yang sesuai.
Jika situs atau aplikasi web Anda yang ada menggunakan format ini, pastikan situs atau aplikasi web tersebut juga disertakan dalam progressive web app untuk viralitas yang optimal.
Praktik terbaik:
Uji markup Open Graph Anda dengan Facebook Object Debugger Tool.
Pelajari format metadata Twitter.
Jangan lupa untuk menyertakan format ini jika situs Anda yang ada mendukung format tersebut.
Menguji dengan Beberapa Browser
Mengapa demikian? Dari sudut pandang pengguna, jelas bahwa situs harus memiliki perilaku yang sama di semua browser. Meskipun pengalaman mungkin disesuaikan dengan ukuran layar yang berbeda, kami berharap situs seluler berfungsi dengan cara yang sama di perangkat yang ukurannya serupa, baik di ponsel iPhone atau Android.
Meski web dapat dianggap terfragmentasi karena jumlah browser yang digunakan di seluruh dunia, variasi dan persaingan inilah yang membuat web menjadi platform yang inovatif. Untungnya, standar web saat ini sudah semakin maju dan alat modern memungkinkan developer membuat situs yang kaya dan kompatibel lintas browser dengan percaya diri.
Praktik terbaik:
Gunakan alat pengujian lintas browser seperti BrowserStack.com, Browserling.com, atau BrowserShots.org untuk memastikan PWA Anda kompatibel lintas browser.
Mengukur Performa Pemuatan Halaman
Mengapa demikian? Semakin cepat pemuatan situs untuk pengguna, semakin baik pengalaman yang didapatkan. Mengoptimalkan page speed merupakan fokus umum dalam pengembangan web, tetapi terkadang saat mengembangkan versi situs yang baru, pengoptimalan yang dibutuhkan tidak dianggap sebagai prioritas utama.
Untuk hasil terbaik, saat mengembangkan progressive web app, sebaiknya Anda mengukur performa kecepatan pemuatan halaman dan melakukan pengoptimalan sebelum meluncurkan situs.
Praktik terbaik:
Gunakan alat seperti PageSpeed Insights dan Pengujian Halaman Web untuk mengukur performa pemuatan halaman situs Anda. Meskipun Googlebot sedikit lebih lambat dalam rendering, riset menunjukkan bahwa 40% konsumen akan meninggalkan halaman yang waktu pemuatannya lebih dari tiga detik.
Baca selengkapnya tentang rekomendasi performa halaman web kami dan jalur rendering yang penting di sini.
Hindari melakukan pengoptimalan pascapeluncuran. Jika konten situs Anda dimuat dengan cepat sebelum bermigrasi ke progressive web app yang baru, penting bagi Anda untuk tidak menurunkan tingkat pengoptimalan.
Semoga checklist di atas berguna dan memberikan panduan yang tepat untuk membantu Anda mengembangkan Progressive Web App dengan mempertimbangkan potensi untuk diindeks.
Saat memulai, pastikan Anda memeriksa sampel Progressive Web App dengan potensi untuk diindeks yang mendemonstrasikan rendering sisi server, sisi klien, dan hybrid. Seperti biasa, jika ada pertanyaan, hubungi kami di Forum Webmaster.