Developers.Google.com/Speed/Pagespeed/Insights
PageSpeed Insights
 |
| PageSpeed Insights Pengukur Kecepatan |
PageSpeed Insights - pengukur kinerja laman blog/ Website untuk perangkat seluler atau perangkat desktop. Alat ini mengambil URL dua kali, yang satu untuk tampilan pengguna seluler, dan yang satunya untuk tampilan pengguna desktop.
Nilai PageSpeed berkisar antara 0 sampai 100 poin. Semakin tinggi skor semakin baik, dan skor 85 atau lebih menunjukkan bahwa laman bekerja dengan baik. Harap diperhatikan bahwa PageSpeed Insights terus disempurnakan, sehingga skor akan berubah saat kami menambahkan aturan baru atau meningkatkan analisis pada tampilan desktop ataupun tampilan handphone..
Namun, karena kinerja sambungan jaringan sangat bervariasi, PageSpeed Insights hanya mempertimbangkan aspek kinerja laman blog/website yang tidak terkait dengan jaringan atau konfigurasi server dan struktur HTML laman, dan penggunaan sumber daya eksternalnya seperti gambar, JavaScript, dan CSS. Menerapkan saran seharusnya akan meningkatkan kinerja laman secara relatif. Akan tetapi, keseluruhan kinerja laman masih akan tergantung pada sambungan jaringan pengguna.
Setiap saran dinilai dengan indikator prioritas untuk menunjukkan tingkat kepentingan blog/website.
Cek PageSpeed Insight
PageSpeed Insights menganalisa suatu halaman untuk melihat halaman render di bawah kedua di jaringan seluler dan desktop. Penelitian telah menunjukkan bahwa keterlambatan lebih dari satu detik akan menyebabkan pengguna untuk mengganggu aliran pemikiran mereka, menciptakan pengalaman buruk. Tujuan kami adalah untuk menjaga pengguna terlibat dengan halaman dan memberikan pengalaman yang optimal, terlepas dari perangkat atau jenis jaringan.
Tentang PageSpeed Insights
menunjukkan tingkat kepentingannya:
| Ikon | Nama | Deskripsi |
|---|---|---|
 | tanda seru merah | Memperbaiki hal ini akan memberi dampak signifikan pada kinerja laman. |
 | tanda seru kuning | Pertimbangkan untuk memperbaiki hal ini jika tidak memerlukan kerja yang berat. |
 | tanda centang hijau | Tidak ditemukan masalah yang signifikan. Bagus! |
Hal ini tidak mudah untuk memenuhi salah satu anggaran waktu kedua. Untungnya bagi kita, seluruh halaman tidak harus membuat anggaran ini, sebaliknya, kita harus memberikan dan merender atas flip (ATF) konten dalam kurang dari satu detik, yang memungkinkan pengguna untuk mulai berinteraksi dengan halaman secepat mungkin. Kemudian, sementara pengguna menafsirkan halaman pertama dari konten, sisa halaman dapat disampaikan secara progresif di latar belakang.
Beradaptasi dengan jaringan seluler latency tinggi
Memenuhi salah satu kriteria ATF kedua pada perangkat mobile menimbulkan tantangan yang unik yang tidak hadir di jaringan lain. Pengguna dapat mengakses situs Anda melalui berbagai jaringan 2G, 3G, dan 4G yang berbeda. latency jaringan secara signifikan lebih tinggi dari sambungan kabel, dan mengkonsumsi sebagian besar anggaran 1000 ms kami untuk membuat konten ATF:
200-300 ms jemput kali untuk jaringan 3G
50-100 ms jemput kali untuk jaringan 4G
3G adalah jenis jaringan yang dominan di seluruh dunia, dan sementara penyebaran 4G sedang berlangsung di seluruh dunia, Anda masih harus berharap bahwa mayoritas pengguna akan mengakses halaman Anda pada jaringan 3G. Untuk alasan ini, kita harus mengasumsikan bahwa setiap permintaan jaringan akan mengambil, rata-rata, 200 milidetik.
Dengan itu dalam pikiran, mari kita sekarang bekerja mundur. Jika kita melihat urutan khas komunikasi antara browser dan server, 600 ms waktu yang telah digunakan oleh jaringan overhead: lookup DNS untuk menyelesaikan nama host (misalnya google.com) ke alamat IP, jaringan jemput untuk melakukan TCP jabat tangan, dan akhirnya jemput jaringan penuh untuk mengirim permintaan HTTP. Hal ini membuat kita dengan hanya 400 ms!
Menyampaikan sub satu pengalaman render kedua
Setelah dikurangi latency jaringan, kita dibiarkan dengan hanya 400 milidetik dalam anggaran kami, dan masih banyak pekerjaan yang harus dilakukan: server harus membuat tanggapan, kode aplikasi client-side harus mengeksekusi, dan browser harus tata letak dan merender konten. Dengan itu dalam pikiran, kriteria berikut akan membantu kita tetap dalam anggaran:
1. Server harus memberikan respon (<200 ms)
waktu respon server adalah waktu yang dibutuhkan untuk server untuk mengembalikan HTML awal, anjak keluar saat jaringan transportasi. Karena kita hanya memiliki sedikit waktu, kali ini harus disimpan minimal - idealnya dalam 200 milidetik, dan lebih disukai bahkan kurang!
2. Jumlah pengalihan harus diminimalkan
pengalihan HTTP tambahan dapat menambahkan satu atau dua roundtrips jaringan tambahan (dua jika DNS lookup ekstra diperlukan), menimbulkan ratusan milidetik dari latency tambahan di jaringan 3G. Untuk alasan ini, kami sangat mendorong webmaster untuk meminimalkan jumlah, dan idealnya menghilangkan pengalihan sepenuhnya - ini sangat penting untuk dokumen HTML (menghindari "m dot" pengalihan bila memungkinkan).
3. Jumlah pulang pergi untuk membuat pertama harus diminimalkan
Karena bagaimana TCP memperkirakan kapasitas koneksi (yaitu TCP Lambat Start), koneksi TCP yang baru tidak dapat langsung menggunakan bandwidth penuh yang tersedia antara klien dan server. Karena ini, server dapat mengirim hingga 10 paket TCP pada sambungan baru (~ 14 KB) di jemput pertama, dan kemudian harus menunggu klien untuk mengakui data ini sebelum dapat tumbuh jendela kemacetan dan melanjutkan untuk memberikan lebih banyak data.
Karena perilaku TCP ini, penting untuk mengoptimalkan konten Anda untuk meminimalkan jumlah perjalanan pulang pergi yang dibutuhkan untuk memberikan data yang diperlukan untuk melakukan yang pertama membuat halaman. Idealnya, isi ATF harus cocok di bawah 14KB - ini memungkinkan browser untuk melukis halaman setelah hanya satu jemput. Juga, penting untuk dicatat bahwa 10 paket (IW10) batas adalah update terbaru untuk standar TCP: Anda harus memastikan bahwa server Anda upgrade ke versi terbaru untuk mengambil keuntungan dari perubahan ini. Jika tidak, batas kemungkinan akan 3-4 paket!
4. Hindari eksternal memblokir JavaScript dan CSS di atas konten
Sebelum browser dapat membuat halaman untuk pengguna, ia memiliki mengurai halaman. Jika menemukan script eksternal non-async atau memblokir selama parsing, itu harus berhenti dan men-download sumber daya itu. Setiap kali melakukan itu, itu adalah menambahkan perjalanan putaran jaringan, yang akan menunda waktu untuk pertama membuat halaman.
Akibatnya, JavaScript dan CSS yang dibutuhkan untuk merender di atas wilayah flip harus inline, dan JavaScript atau CSS diperlukan untuk menambahkan fungsi tambahan ke halaman harus dimuat setelah konten ATF telah disampaikan.
Sebelum browser dapat membuat halaman untuk pengguna, ia memiliki mengurai halaman. Jika menemukan script eksternal non-async atau memblokir selama parsing, itu harus berhenti dan men-download sumber daya itu. Setiap kali melakukan itu, itu adalah menambahkan perjalanan putaran jaringan, yang akan menunda waktu untuk pertama membuat halaman.
Akibatnya, JavaScript dan CSS yang dibutuhkan untuk merender di atas wilayah flip harus inline, dan JavaScript atau CSS diperlukan untuk menambahkan fungsi tambahan ke halaman harus dimuat setelah konten ATF telah disampaikan.
5. waktu cadangan untuk tata letak peramban dan rendering (200 ms)
Proses parsing HTML, CSS, dan mengeksekusi JavaScript membutuhkan waktu yang tidak responsif.
Post a Comment