Analisis Seluler di PageSpeed Insights

PageSpeed Insights menganalisis laman untuk melihat apakah laman mengikuti saran kami agar dapat dirender dalam waktu kurang dari satu detik di jaringan seluler. Penelitian menunjukkan bawah penundaan apa pun yang lebih dari satu detik akan menyebabkan pengguna kehilangan fokus, sehingga tercipta pengalaman buruk. Tujuan kami adalah membuat pengguna terus terlibat dengan laman dan memberikan pengalaman optimal, terlepas dari perangkat maupun jenis jaringannya.

Tidak mudah untuk memenuhi jatah waktu satu detik. Untungnya, tidak harus seluruh halaman yang dirender dalam jatah waktu ini. Sebagai gantinya, kami harus memberikan dan merender konten paruh atas (PA) dalam waktu kurang dari satu detik, sehingga memungkinkan pengguna mulai berinteraksi dengan laman secepat mungkin. Lalu, selagi pengguna mencerna laman pertama konten, seluruh laman sisanya dapat diberikan secara progresif di latar belakang.

Beradaptasi dengan jaringan seluler berlatensi tinggi

Memenuhi kriteria PA satu detik di perangkat seluler memberikan tantangan unik yang tidak ada pada jaringan lainnya. Pengguna dapat mengakses situs Anda melalui berbagai macam jaringan 2G, 3G, dan 4G. Latensi jaringan jauh lebih tinggi dibandingkan sambungan berkabel, dan memakan porsi signifikan dari jatah 1000 milidetik (md) kami untuk merender konten PA:

  • 200-300 md waktu perjalanan bolak balik untuk jaringan 3G
  • 50-100 md waktu perjalanan bolak balik untuk jaringan 4G

3G adalah jenis jaringan yang dominan di seluruh dunia, dan selagi penyebaran 4G sedang dalam proses di dunia, sebaiknya tetap pertimbangkan bahwa kebanyakan pengguna akan mengakses laman Anda dengan jaringan 3G. Karenanya, kami harus berasumsi bahwa, rata-rata, tiap permintaan jaringan akan membutuhkan waktu 200 milidetik.

Dengan mempertimbangkan hal tersebut, mari kita bekerja dengan mundur ke belakang. Jika kita melihat urutan komunikasi umumnya antara browser dan server, 600 md dari waktu tersebut telah digunakan oleh overhead jaringan: pencarian DNS untuk menyelesaikan nama hosting (misalnya google.com) menjadi alamat IP, perjalanan pulang pergi jaringan untuk melakukan hubungan TCP, dan terakhir perjalanan pulang pergi jaringan penuh untuk mengirim permintaan HTTP. Semua ini hanya menyisakan 400 md untuk kami!

Memberikan pengalaman perenderan di bawah satu detik

Setelah dikurangi latensi jaringan, kami hanya memiliki 400 md dalam jatah, dan masih banyak yang harus dilakukan: server harus merender tanggapan, kode aplikasi pihak klien harus diterapkan, dan browser harus menata letak dan merender konten. Dengan mempertimbangkan hal itu, kriteria berikut akan membantu kami tetap dalam jatah tersebut:

(1) Server harus merender tanggapan (<200 md)
Waktu tanggapan server adalah waktu yang dibutuhkan oleh server untuk mengembalikan HTML awal, dikurangi waktu transportasi jaringan. Karena waktu kami hanya sedikit, waktu ini harus dipertahankan seminimum mungkin - idealnya dalam 200 milidetik, dan sebaiknya malah lebih sedikit!
(2) Jumlah pengalihan harus diminimalkan
Pengalihan HTTP tambahan dapat menambahkan satu atau dua perjalanan pulang pergi jaringan tambahan (dua jika pencarian DNS tambahan diperlukan), menimbulkan ratusan milidetik latensi tambahan pada jaringan 3G. Karenanya, kami amat mendorong webmaster untuk meminimalkan jumlahnya, dan idealnya menghilangkan seluruh pengalihan - ini penting terutama untuk dokumen HTML (hindari pengalihan "m dot" jika mungkin).
(3) Jumlah perjalanan pulang pergi untuk perenderan pertama harus diminimalkan

Akibat cara TCP memperkirakan kapasitas sambungan (Permulaan Lambat TCP), sambungan TCP baru tidak dapat langsung menggunakan seluruh bandwidth yang tersedia antara klien dan server. Karenanya, server dapat mengirimkan hingga 10 paket TCP pada sambungan baru (~14 KB) dalam perjalanan pulang pergi pertama, lalu harus menunggu klien mengenali data ini sebelum dapat mengembangkan jendela kepadatannya dan melanjutkan untuk memberikan lebih banyak data.

Karena perilaku TCP inilah, penting untuk mengoptimalkan konten untuk meminimalkan jumlah perjalanan pulang pergi yang diperlukan untuk memberikan data yang dibutuhkan guna melakukan perenderan pertama dari laman. Idealnya, konten PA harus cukup di bawah 14 KB - ini memungkinkan browser melukis laman hanya setelah satu perjalanan pulang pergi. Selain itu, penting untuk diperhatikan bahwa batas 10 paket (IW10) adalah pembaruan terbaru atas standar TCP: Anda sebaiknya memastikan bahwa server sudah ditingkatkan versinya ke versi terbaru untuk mendapatkan manfaat dari perubahan ini. Jika tidak, batasnya kemungkinan besar 3-4 paket!

(4) Hindari pemblokiran eksternal JavaScript dan CSS dalam konten paruh atas

Sebelum browser dapat merender laman ke pengguna, browser harus menguraikan laman itu. Jika browser menemukan skrip pemblokiran eksternal atau tidak asinkron saat menguraikan laman, browser harus berhenti dan mengunduh sumber daya itu. Setiap kali hal itu dilakukan, perjalanan jaringan bertambah, sehingga menunda waktu perenderan pertama laman.

Oleh karena itu, JavaScript dan CSS yang diperlukan untuk merender bagian paruh atas harus dijadikan sebaris, dan JavaScript dan CSS yang diperlukan untuk menambahkan fungsi tambahan ke laman harus dimuat setelah konten PA telah dikirimkan.

(5) Cadangkan waktu untuk tata letak dan perenderan browser (200 md)
Proses untuk menguraikan HTML, CSS, dan menjalankan JavaScript membutuhkan waktu dan sumber daya klien! Tergantung pada kecepatan perangkat seluler, dan kerumitan laman, proses ini dapat membutuhkan waktu ratusan milidetik. Sebaiknya cadangkan 200 milidetik untuk proses tambahan browser.
(6) Optimalkan waktu perenderan dan eksekusi JavaScript
Skrip rumit dan kode yang tidak efisien dapat membutuhkan puluhan dan ratusan milidetik untuk dijalankan - gunakan alat pengembang internal dalam browser untuk membuat profil dan mengoptimalkan kode Anda. Untuk pendahuluan yang bagus, lihat kursus interaktif untuk Alat Pengembang Chrome kami.

FAQ

Bagaimana dampak jaringan 4G atas kriteria seluler di atas?
Latensi perjalanan pulang pergi yang lebih rendah adalah salah satu peningkatan utama dalam jaringan 4G. Ini akan sangat membantu, dengan mengurangi waktu tambahan jaringan total, yang saat ini lebih dari 50% dari anggaran satu detik kami dalam jaringan 3G. Namun, 3G adalah jenis jaringan yang dominan di dunia, dan akan berlangsung selama bertahun-tahun - Anda harus mengoptimalkan laman dengan mempertimbangkan pengguna 3G.
Saya menggunakan pustaka JavaScript, seperti JQuery, ada saran?
Banyak pustaka JavaScript, seperti JQuery, digunakan untuk meningkatkan laman guna menambah interaktivitas, animasi, dan efek lainnya. Namun, banyak perilaku ini dapat ditambahkan dengan aman setelah konten PA dirender. Periksa pemindahan eksekusi dan pemuatan JavaScript tersebut setelah laman dimuat.
Saya menggunakan kerangka kerja JavaScript, untuk menyusun laman, ada saran?
Apabila konten laman disusun oleh JavaScript sisi klien, sebaiknya Anda memeriksa penyebarisan modul JavaScript yang relevan untuk menghindari perjalanan jaringan tambahan. Demikian pula, meningkatkan perenderan sisi server dapat meningkatkan kinerja pemuatan laman pertama secara signifikan: merender template JS pada server, menyebariskan hasil ke dalam HTML, kemudian menggunakan template sisi klien setelah aplikasi dimuat.
Bagaimana SPDY dan HTTP 2.0 akan membantu?
SPDY dan HTTP 2.0 bertujuan untuk mengurangi latensi muatan laman dengan membuat penggunaan koneksi TCP yang mendasari jadi lebih efisien (multiplexing, kompresi header, prioritas). Selanjutnya, dorongan server dapat membantu meningkatkan kinerja lebih jauh dengan menghilangkan latensi jaringan ekstra. Sebaiknya selidiki penambahan dukungan SPDY pada server Anda, dan beralih ke HTTP 2.0 setelah standarnya siap.
Bagaimana cara mengidentifikasi CSS kritis pada laman saya?
Di Alat Pengembang Chrome, buka panel Audit, dan jalankan laporan Kinerja Laman Web, dalam laporan yang dibuat, lihat Buang aturan CSS yang tidak digunakan. Atau gunakan alat, atau skrip, pihak ketiga lainnya untuk mengidentifikasi pemilih CSS mana yang diterapkan dalam tiap laman.
Dapatkah praktik terbaik ini dijadikan otomatis?
Pasti. Ada banyak produk optimalisasi kinerja web (WPO) sumber terbuka dan komersial yang dapat membantu Anda memenuhi beberapa atau seluruh kriteria di atas. Untuk solusi sumber terbuka, lihat alat optimalisasi PageSpeed.
Bagaimana cara menyesuaikan server saya untuk memenuhi kriteria tersebut?
Pertama, pastikan server Anda menjalankan versi terbaru sistem operasi. Untuk memanfaatkan ukuran jendela kepadatan TCP awal yang ditingkatkan (IW10), Anda memerlukan Linux kernel 2.6.39+. Untuk sistem operasi lain, lihat dokumentasi.
Untuk mengoptimalkan waktu tanggapan server, perintahkan kode Anda, atau gunakan solusi pengawasan aplikasi untuk mengidentifikasi kelemahan Anda - misalnya, skrip kehabisan waktu tunggu, panggilan basis data, permintaan RPC, perenderan, dll. Tujuannya adalah merender tanggapan HTML dalam 200 milidetik.
Bagaimana tentang Kebijakan Keamanan Konten?
Jika Anda menggunakan CSP, Anda mungkin perlu memperbarui kebijakan default.
Pertama, atribut CSS sebaris pada elemen HTML (misalnya, &lt p style=...&gt) harus dihindari jika mungkin, karena sering mengakibatkan duplikasi kode yang tidak perlu, dan diblokir secara default dengan CSP (dinonaktifkan melalui "unsafe inline" pada "style-src"). Jika CSP diaktifkan, CSP akan memblokir semua tag script sebaris secara default. Jika Anda memiliki JavaScript sebaris, Anda perlu memperbarui kebijakan CSP dengan nonce atau potongan skrip atau menggunakan "unsafe-inline" untuk mengaktifkan semua skrip sebaris yang perlu dijalankan. Jika Anda memiliki gaya sebaris, Anda perlu memperbarui kebijakan CSP dengan nonce atau potongan gaya atau menggunakan "unsafe-inline" untuk mengaktifkan semua pemblokiraan gaya sebaris yang perlu diproses.

Ada pertanyaan lain? Jangan ragu untuk mengajukan pertanyaan dan memberikan masukan dalam grup diskusi kami di pagespeed-insights-discuss.