Cara cek kecepatan website dan 7 langkah mempercepatnya

Cara cek kecepatan website yang paling langsung adalah membuka PageSpeed Insights (tab baru), menempelkan URL halaman, menekan tombol analisis, lalu membaca tab Mobile lebih dulu. Gratis, tanpa mendaftar, dan selesai di bawah tiga menit.

Yang sulit bukan membukanya. Yang sulit adalah memutuskan apa yang dikerjakan setelah angkanya keluar merah. Sebagian besar panduan berbahasa Indonesia berhenti sebagai daftar alat: PageSpeed Insights, GTmetrix, Pingdom, selesai. Padahal nasib halaman Anda ditentukan oleh empat angka di dalam laporan itu, dan oleh urutan perbaikan mana yang dikerjakan lebih dulu.

Artikel ini dibagi dua. Bagian pertama mengajari Anda membaca laporan hasil cara cek kecepatan website tadi, termasuk kenapa hasil Desktop sering membuat orang merasa aman padahal tidak. Bagian kedua berisi tujuh perbaikan yang sudah diurutkan dari yang paling berdampak ke yang paling kecil, dengan catatan mana yang bisa Anda kerjakan sendiri dan mana yang perlu developer. Penutupnya satu standar berangka yang bisa Anda tagihkan ke vendor mana pun, termasuk ke kami.

Cara cek kecepatan website dalam tiga menit

Urutannya begini, dan tidak ada langkah yang boleh dilewati:

1. Buka pagespeed.web.dev (tab baru).
2. Tempel URL halaman yang ingin diukur. Bukan hanya beranda. Ukur juga halaman yang paling banyak dibuka pengunjung, biasanya halaman layanan, halaman produk, atau landing page iklan.
3. Tekan tombol analisis, lalu tunggu sekitar 20 sampai 40 detik.
4. Setelah hasil muncul, klik tab Mobile. Itu tab pertama yang harus Anda baca, bukan Desktop.
5. Catat empat angka: skor performa, LCP, INP, dan CLS. Abaikan dulu seluruh daftar rekomendasi di bawahnya.
6. Ulangi tesnya tiga kali dengan jeda beberapa menit, lalu pakai angka tengahnya.

Langkah keenam itu yang kerap dilewati, dan yang biasanya bikin ribut antara pemilik usaha dan developer. Dokumentasi Lighthouse menyatakan terus terang bahwa banyak variasi skor bukan berasal dari Lighthouse: yang berubah biasanya kondisi di sekitarnya, seperti rute internet, tes A/B di situs Anda sendiri, iklan yang berbeda tiap muat, perangkat uji yang berbeda, sampai ekstensi browser. Satu kali pengukuran bukan bukti apa apa, ke arah baik maupun buruk.

Dari pengalaman kami, percakapan "kemarin skornya 72 kok sekarang 61" hampir selalu selesai begitu kedua pihak sepakat memakai angka tengah dari tiga tes, pada halaman yang sama, di jam yang kurang lebih sama. Biayanya nol rupiah, dan itu menghemat berjam jam perdebatan yang tidak memperbaiki apa pun.

Kenapa hasil desktop sering menipu

Kesalahan paling umum saat orang mencari cara cek kecepatan website terjadi di detik terakhir: mereka membukanya di laptop, melihat skor Desktop 96 berwarna hijau, lalu menutup tabnya dengan lega. Tab Mobile di sebelahnya mungkin 43.

Ada dua alasan kenapa angka mobile yang lebih penting.

Pertama, itu versi yang dipakai Google. Dokumentasi Google Search menyebut bahwa Google memakai versi mobile dari konten sebuah situs, yang dirayapi dengan agen smartphone, untuk pengindeksan dan pemeringkatan. Kalimat lanjutannya lebih keras lagi: hanya konten yang tampil di situs mobile yang dipakai untuk pengindeksan.

Kedua, mode Mobile mensimulasikan perangkat dan jaringan yang jauh lebih lemah dari laptop Anda. Prosesornya dilambatkan dan jaringannya ditahan, sehingga gambar besar dan skrip berat yang tidak terasa di laptop berubah menjadi detik detik yang nyata. Skor Desktop yang hijau sering kali hanya membuktikan bahwa laptop Anda kencang.

Ini bukan masalah teoretis di pasar jasa website Indonesia. Saat menyusun riset pembanding untuk situs ini, kami menarik HTML dari 16 halaman vendor jasa website pada 20 September 2026. Pengukurannya sederhana, satu kali ambil HTML saja tanpa gambar, CSS, atau JavaScript, jadi ini bukan Lighthouse dan bukan Core Web Vitals lapangan. Meski begitu hasilnya sudah terlihat kasar: satu vendor butuh sekitar 2,8 detik hanya untuk mengirim HTML, satu lagi sekitar 1,3 detik, dan satu halaman harga memuat ratusan gambar sekaligus di satu halaman. Satu situs bahkan mengembalikan error server dua kali berturut turut padahal peringkatnya ada di halaman pertama.

Artinya sebagian penjual website belum lulus ujian yang mereka jual sendiri. Anda berhak menguji calon vendor dengan alat yang sama sebelum transfer.

Empat metrik yang benar benar penting

Laporan PageSpeed Insights panjang dan mudah membuat orang tenggelam. Padahal seluruh gunanya cara cek kecepatan website hanya berhenti di empat baris di bawah ini, dan itu yang perlu Anda hafal. Tiga yang pertama adalah Core Web Vitals, dan ambang batasnya diambil dari dokumentasi resmi web.dev.

Tabel ini lebih lebar dari layar. Geser ke samping untuk melihat seluruh kolom.

Ketiga Core Web Vitals diukur pada persentil ke-75 dari kunjungan, dipisah antara mobile dan desktop. Artinya bukan rata rata pengunjung yang dihitung, melainkan pengalaman pengunjung yang paling sial di antara tiga per empat yang tercepat. Ini penting dipahami sebelum Anda berdebat soal "di HP saya cepat kok".

LCP, angka yang paling layak diperjuangkan

Largest Contentful Paint mengukur kapan elemen terbesar di layar pertama selesai dirender. Di website usaha, elemen itu hampir selalu gambar hero atau judul besar di bagian paling atas. Batas baiknya 2,5 detik.

Yang membuat LCP layak diprioritaskan adalah komposisinya sudah dipetakan orang lain. Panduan optimasi LCP di web.dev menyebut pembagian tipikalnya: sekitar 40 persen waktu habis di TTFB, sekitar 40 persen di durasi memuat sumber daya LCP itu sendiri, lalu masing masing di bawah 10 persen untuk jeda mulai memuat dan jeda render. Artinya kalau LCP Anda buruk, tersangkanya hanya dua: server lambat membalas, atau gambar hero Anda kegedean. Anda tidak perlu menebak nebak.

INP, metrik yang menggantikan FID

Interaction to Next Paint mengukur jeda antara pengunjung mengetuk sesuatu dan layar benar benar berubah. Batas baiknya 200 milidetik. INP menjadi Core Web Vital yang stabil pada 2024, menggantikan FID yang lama.

Penyebabnya hampir selalu JavaScript yang menahan main thread, entah dari skrip pihak ketiga yang dimuat saat halaman dibuka atau dari tugas panjang yang tidak dipecah. Panduan web.dev menyarankan memecah pekerjaan di dalam callback menjadi beberapa tugas terpisah supaya browser sempat menggambar ulang layar.

Bagian ini praktis tidak bisa dikerjakan pemilik usaha, dan memang tidak perlu. Yang perlu Anda lakukan cuma satu: berhenti menambah plugin chat, popup, pelacak, dan widget ulasan tanpa mengukur ulang sesudahnya.

CLS, paling murah diperbaiki dan paling sering diabaikan

Cumulative Layout Shift mengukur seberapa sering isi halaman melompat sendiri. Ini metrik yang paling mudah diperbaiki sekaligus kerap ditinggalkan, karena angkanya tidak terlihat dramatis di laporan.

Panduan web.dev menyebut penyebab tersering: gambar tanpa dimensi, iklan dan iframe tanpa ruang yang dipesan lebih dulu, konten yang disuntikkan belakangan, dan web font. Solusinya pun sederhana. Selalu pasang atribut width dan height pada gambar serta video, atau pesan ruangnya lewat CSS aspect-ratio. Untuk font, muat font kritis sedini mungkin dengan <link rel=preload>.

Menurut kami inilah metrik yang paling merugikan penjualan meski skornya terlihat sepele. Pengunjung yang salah pencet karena tombol bergeser tidak akan melapor ke Anda. Dia cuma menutup tab.

Skor performa, angka ringkasan dan bukan tujuan akhir

Skor performa adalah rata rata tertimbang dari beberapa metrik lab. Pada Lighthouse 10, bobotnya adalah Total Blocking Time 30 persen, Largest Contentful Paint 25 persen, Cumulative Layout Shift 25 persen, First Contentful Paint 10 persen, dan Speed Index 10 persen. Rentang warnanya: 0 sampai 49 merah, 50 sampai 89 oranye, 90 sampai 100 hijau.

Dokumentasi Lighthouse sendiri menyebut bahwa mencapai skor 100 sangat menantang dan bukan sesuatu yang diharapkan. Jujur saja, mengejar 100 adalah cara paling mahal untuk membeli rasa puas. Halaman dengan skor 91, LCP 1,9 detik, dan CLS 0,02 melayani pengunjung lebih baik daripada halaman berskor 99 yang tombolnya nyangkut setengah detik setiap diklik.

Data lab dan data lapangan, kenapa kotak atas sering kosong

Hasil cara cek kecepatan website di PageSpeed Insights punya dua lapis, dan banyak orang menyangka lapisan atas hilang karena alatnya rusak.

Lapisan atas adalah data lapangan, diambil dari Chrome UX Report, yaitu kumpulan pengukuran anonim dari pengunjung sungguhan. Lapisan bawah adalah data lab, yaitu satu kali simulasi di mesin Google dengan perangkat dan jaringan yang ditahan.

Dokumentasi CrUX menjelaskan syarat masuknya: halaman harus bisa ditemukan publik, dan harus cukup populer, yaitu punya jumlah pengunjung minimum. Angka pastinya sengaja tidak diumumkan Google. Konsekuensinya penting untuk usaha kecil: website yang baru tayang atau masih sepi memang tidak akan punya data lapangan, dan itu bukan kesalahan siapa pun.

Laporan Core Web Vitals di Google Search Console bekerja dengan aturan yang sama. Bantuan resminya menyebut datanya berasal dari CrUX, mengukur 28 hari terakhir, dan bila sebuah grup URL tidak punya data minimum maka URL itu dihilangkan dari laporan.

Jadi kalau Search Console Anda menampilkan "No data available", jangan panik dan jangan membayar siapa pun untuk memperbaikinya. Pakai data lab untuk memperbaiki halaman sekarang, lalu tunggu trafiknya tumbuh sampai data lapangan muncul sendiri.

Cara mengecek kecepatan website dengan alat selain PageSpeed Insights

Satu alat sebetulnya cukup untuk mengambil keputusan, tapi ada saatnya Anda butuh sudut pandang lain. Ini yang kami pakai, dan untuk apa masing masing.

Tabel ini lebih lebar dari layar. Geser ke samping untuk melihat seluruh kolom.

Ada satu hal yang perlu diluruskan soal GTmetrix, karena masih sering salah dikutip di artikel berbahasa Indonesia. GTmetrix berpindah ke Lighthouse pada November 2020 dan mengganti skor PageSpeed serta YSlow lamanya dengan GTmetrix Grade, Performance, dan Structure. Tab Timings serta tab PageSpeed dan YSlow yang lama digantikan tab Performance dan Structure.

Jadi kalau Anda menemukan panduan yang masih menyuruh mengejar "YSlow Score A", panduan itu berumur lebih dari lima tahun. Dan karena GTmetrix kini memakai mesin yang sama dengan PageSpeed Insights, menjalankan keduanya lalu memilih angka yang lebih enak dilihat sama saja dengan membohongi diri sendiri.

Cara mempercepat website, tujuh langkah diurutkan dari yang paling berdampak

Urutan di bawah ini bukan selera. Urutannya mengikuti komposisi LCP dan bobot skor Lighthouse yang sudah dibahas di atas: gambar dan server memegang porsi terbesar, sedangkan hal hal kecil yang sering disebut duluan di panduan lain justru duduk di bawah.

Tabel ini lebih lebar dari layar. Geser ke samping untuk melihat seluruh kolom.

1. Kecilkan dan konversi gambar

Ini hampir selalu langkah dengan hasil terbesar per jam kerja, sekaligus langkah yang paling mudah dikerjakan sendiri oleh pemilik usaha tanpa menyentuh kode. Audit Lighthouse bernama "Serve images in modern formats" menyebut AVIF dan WebP punya karakter kompresi serta kualitas yang lebih unggul dibanding JPEG dan PNG, sehingga memuat lebih cepat dan memakan lebih sedikit kuota seluler. Lighthouse hanya melaporkan gambar yang potensi penghematannya di atas 8 KiB, jadi kalau gambar Anda muncul di daftar itu, penghematannya memang nyata.

Praktiknya: jangan mengunggah foto langsung dari kamera ponsel. Foto 4 MB yang ditampilkan selebar 800 piksel tetap diunduh utuh oleh pengunjung, termasuk pengunjung yang sedang memakai kuota. Ubah ukurannya dulu sesuai lebar tampilnya, lalu simpan sebagai WebP.

2. Pasang dimensi gambar dan pesan ruang iklan

Tambahkan atribut width dan height pada setiap gambar dan video, atau pesan ruangnya dengan CSS aspect-ratio. Untuk iklan, embed, dan iframe, pesan ruangnya lewat min-height atau aspect-ratio.

Pekerjaannya biasanya selesai dalam satu jam dan langsung terlihat di CLS. Ini perbaikan termurah di seluruh daftar, dan umumnya ditunda justru karena tidak menaikkan angka besar di laporan.

3. Prioritaskan gambar hero, tunda sisanya

Gambar paling atas harus ditemukan browser sedini mungkin. Panduan LCP web.dev menyarankan memastikan sumber daya LCP bisa ditemukan di markup HTML awal, dan memberinya fetchpriority="high".

Sebaliknya, gambar yang berada di bawah layar pertama diberi loading="lazy". Tapi hati hati di sini, karena ini kesalahan yang paling sering kami temukan saat mengaudit website orang lain. Dokumentasi web.dev menulis tegas: jangan melakukan lazy load pada gambar yang kemungkinan besar berada di dalam viewport saat halaman dimuat, terutama gambar LCP. Memasang loading="lazy" ke semua gambar sekaligus, hero termasuk, justru memperlambat LCP. Plugin "optimasi gambar" sekali klik sering melakukan persis itu, lalu pemiliknya bingung kenapa skornya malah turun.

4. Kurangi skrip pihak ketiga

Setiap widget chat, popup diskon, peta, pemutar video, pelacak iklan, dan bukti sosial adalah JavaScript milik orang lain yang berjalan di halaman Anda. Total Blocking Time punya bobot 30 persen di skor Lighthouse, tertinggi dari semua metrik, dan skrip pihak ketiga adalah penyumbangnya yang paling sering.

Langkah yang kami sarankan ke klien: catat semua skrip pihak ketiga di halaman utama, lalu tanyakan satu per satu, "kapan terakhir ini menghasilkan penjualan". Yang tidak bisa dijawab, cabut. Ukur ulang sesudahnya. Ini keputusan bisnis, bukan keputusan teknis, jadi Anda yang memegang palunya.

5. Perbaiki TTFB lewat cache dan hosting

TTFB adalah waktu sampai byte pertama diterima browser. Panduan web.dev menyebut kebanyakan situs sebaiknya punya TTFB 0,8 detik atau kurang, dan menandai di atas 1,8 detik sebagai buruk. Penyumbangnya termasuk redirect, pencarian DNS, negosiasi koneksi dan TLS, serta kecepatan server membalas.

Karena TTFB memakan sekitar 40 persen dari LCP, perbaikan di sini memang berdampak. Tapi perhatikan urutannya: cek angkanya dulu. Kalau TTFB Anda sudah 0,4 detik, pindah hosting tidak akan mengubah apa pun kecuali tagihan bulanan. Keluhan soal lambat yang kami temukan di forum pemilik website Indonesia pun bercampur antara urusan server dan urusan halaman, seperti komentar ini di r/indonesia:

"idk men, saya sudah nyerah ama hosting server, saya uda pakai VPS saja, hosting di indonesia lebih lambat loadingnya daripada VPS di Digital Ocean server singapur."

Keluhan seperti ini valid, tapi hanya menyentuh satu lapisan dari empat. Pindah server tanpa mengecilkan gambar adalah memindahkan masalah, bukan menyelesaikannya.

6. Rapikan pemuatan font

Web font menyumbang ke CLS lewat pergantian font yang mengubah tinggi baris, dan menyumbang ke LCP bila judul besar Anda menunggu font selesai diunduh. Panduan CLS web.dev menyarankan memuat font kritis sedini mungkin dengan <link rel=preload>, memastikan font cadangan yang dipakai memang mirip, dan mempertimbangkan font-display: optional supaya tidak terjadi tata letak ulang.

Perbaikan tercepat justru sering berupa pengurangan. Dua keluarga font dengan dua ketebalan masing masing sudah cukup untuk hampir semua website usaha.

7. Pecah tugas JavaScript yang panjang

Langkah terakhir ini murni pekerjaan developer, dan biasanya baru perlu bila INP Anda masih buruk setelah enam langkah sebelumnya beres. Panduan INP web.dev menyarankan memecah pekerjaan di dalam callback menjadi beberapa tugas terpisah, mengecilkan ukuran DOM, menghindari layout thrashing, dan memakai CSS content-visibility untuk menunda render bagian yang belum terlihat.

Kami menaruhnya di posisi tujuh bukan karena tidak penting, tetapi karena biayanya paling tinggi per satuan perbaikan. Membayar developer untuk merombak JavaScript sementara gambar hero Anda masih 3 MB adalah urutan yang terbalik.

Cara optimasi website yang sering disarankan tapi dampaknya kecil

Sekarang bagian yang jarang ditulis orang: saran populer yang menurut kami tidak layak jadi prioritas.

• Minify CSS dan JavaScript sebagai langkah pertama. Penghematannya biasanya puluhan kilobyte, sementara satu foto yang tidak dikompres bisa memakan beberapa megabyte. Kerjakan, tapi jangan didahulukan.
• Mengejar skor 100. Dokumentasi Lighthouse sendiri menyebutnya sangat menantang dan bukan sesuatu yang diharapkan. Setelah 90, biaya per poin naik tajam sementara manfaat bagi pengunjung mendatar.
• Mencabut plugin membabi buta. Yang menahan halaman adalah plugin yang memuat skrip di setiap halaman, bukan jumlah plugin. Ukur dulu, baru cabut.
• Memasang CDN untuk audiens yang seluruhnya di satu kota. CDN membantu bila pengunjung Anda tersebar jauh. Kalau seluruh pembeli Anda ada di Yogyakarta dan server Anda di Jakarta, keuntungannya tipis.
• Percaya satu angka dari satu kali tes. Sudah dibahas di atas, tapi layak diulang karena ini sumber salah paham paling mahal antara klien dan vendor.

Satu lagi yang perlu diletakkan pada tempatnya. Google menyatakan Core Web Vitals dipakai oleh sistem peringkatnya, tetapi di halaman yang sama juga menegaskan tidak ada satu sinyal tunggal, dan bahwa Google Search selalu berusaha menampilkan konten paling relevan meski pengalaman halamannya kurang baik. Kecepatan membantu ketika kualitas kontennya seimbang. Kecepatan tidak menyelamatkan halaman yang tidak menjawab apa yang dicari orang.

Standar serah terima berangka yang bisa Anda tagihkan

Cara cek kecepatan website di atas baru benar benar berguna kalau Anda memakainya sebagai alat tawar, bukan sekadar bacaan.

Saat menyusun pembanding harga untuk situs ini, kami membuka 18 halaman harga vendor jasa website Indonesia pada 20 September 2026. Sampelnya kualitatif dan kami tidak mengubahnya menjadi persentase. Yang kami catat: janji kecepatan di halaman halaman itu umumnya berbentuk kata sifat seperti "cepat", "SEO friendly", atau "mobile friendly", bukan angka yang bisa dicek pembeli setelah situsnya jadi.

Kalimat berikut bisa Anda tempel ke percakapan WhatsApp dengan vendor mana pun sebelum transfer:

Saat serah terima, halaman yang Anda bangun harus mencapai skor PageSpeed Insights mode Mobile 90 ke atas dengan LCP 2,5 detik atau kurang, dan tautan laporannya dikirim ke saya.

Tiga hal membuat kalimat itu bekerja. Angkanya berasal dari alat milik Google, bukan alat milik vendor. Modenya disebut eksplisit, sehingga tidak bisa dijawab dengan skor Desktop. Dan buktinya berupa tautan laporan yang bisa Anda buka ulang sendiri kapan saja.

Itu juga jaminan yang menempel di setiap paket pembuatan website kami: PageSpeed Insights mobile 90 ke atas dan LCP 2,5 detik atau kurang saat serah terima, pada halaman yang kami bangun, dengan tautan laporan dikirim. Kalau Anda sedang menyiapkan halaman untuk iklan berbayar, syarat ini bahkan lebih penting daripada di halaman biasa, karena setiap detik tambahan dibayar dengan biaya klik. Kami menuliskannya sebagai bagian dari paket landing page siap iklan, bukan sebagai bonus.

Menjaga kecepatan setelah situs tayang

Kecepatan bukan kondisi permanen. Halaman yang lolos 92 saat serah terima bisa turun ke angka 60an dalam enam bulan tanpa ada yang sengaja merusaknya. Penyebabnya berulang dan membosankan: gambar baru diunggah tanpa dikompres, plugin chat dipasang saat ada promo, satu pixel iklan ditambahkan, lalu satu lagi.

Karena itu jadikan cara cek kecepatan website ini pemeriksaan terjadwal, jangan menunggu ada yang mengeluh. Sebulan sekali sudah cukup untuk website usaha: ukur beranda dan dua halaman yang paling banyak dibuka, catat keempat angkanya di satu spreadsheet, lalu bandingkan dengan bulan lalu. Yang Anda cari bukan angka sempurna, melainkan tren yang menurun.

Kalau Anda tidak ingin mengurusnya sendiri, pemeriksaan bulanan ini termasuk dalam paket maintenance website kami pada tingkat Jaga Plus seharga Rp950.000 per bulan, yang mencakup cek PageSpeed bulanan berikut perbaikannya bila skornya turun. Paket Jaga seharga Rp350.000 per bulan sengaja tidak memasukkannya, dan itu ditulis terbuka di halaman harga supaya Anda tidak merasa tertipu belakangan.

Satu hal lagi sebelum situs baru Anda tayang. Kecepatan hanyalah satu dari beberapa urusan teknis yang wajib beres sebelum serah terima. Urutan pemeriksaan lengkapnya kami tulis terpisah di checklist teknis sebelum serah terima, dan sebaiknya Anda jalankan bersamaan dengan pengukuran kecepatan ini.

Kesimpulan

Ringkasnya, cara cek kecepatan website yang benar cuma butuh empat kebiasaan: buka PageSpeed Insights, baca tab Mobile lebih dulu, catat LCP, INP, CLS, serta skor performa, lalu ulangi tiga kali sebelum menyimpulkan apa pun.

Setelah itu, kerjakan perbaikan sesuai urutannya. Gambar dan dimensi gambar lebih dulu, karena murah dan berdampak besar. Skrip pihak ketiga berikutnya, karena itu keputusan Anda dan bukan keputusan developer. Server serta JavaScript belakangan, karena mahal dan sering dipakai untuk menghindari pekerjaan yang lebih membosankan tapi lebih berguna.

Dan saat Anda memesan website baru, minta angkanya ditulis di awal. Vendor yang serius akan setuju tanpa berdebat, karena mereka memang mengukurnya. Vendor yang menghindar sudah memberi Anda jawaban.

Kalau Anda ingin website Anda diperiksa dan diperbaiki dengan standar yang sama, kirim URL Anda lewat WhatsApp (membuka WhatsApp di tab baru) dan kami balas dengan hasil pengukuran plus daftar perbaikan yang sudah diurutkan. Kalau Anda masih membandingkan anggaran lebih dulu, semua angkanya terbuka di halaman harga.

Sumber

• web.dev, Core Web Vitals (tab baru): ambang LCP 2,5 detik, INP 200 milidetik, CLS 0,1, pengukuran pada persentil ke-75 yang dipisah antara mobile dan desktop, serta status INP sebagai metrik stabil sejak 2024.
• Chrome for Developers, Lighthouse performance scoring (tab baru): bobot metrik Lighthouse 10, rentang warna skor, catatan bahwa skor 100 sangat menantang, dan penjelasan penyebab skor berubah ubah.
• web.dev, Optimize LCP (tab baru): komposisi LCP sekitar 40 persen TTFB dan 40 persen durasi muat sumber daya, plus saran fetchpriority="high".
• web.dev, Optimize INP (tab baru): ambang 200 milidetik, memecah tugas panjang, ukuran DOM, dan content-visibility.
• web.dev, Optimize CLS (tab baru): dimensi gambar, ruang untuk iklan dan iframe, serta penanganan web font.
• web.dev, Time to First Byte (tab baru): ambang baik 0,8 detik, buruk di atas 1,8 detik, dan daftar penyumbangnya.
• web.dev, Browser-level image lazy loading (tab baru): peringatan agar tidak melakukan lazy load pada gambar di viewport awal dan gambar LCP.
• Chrome for Developers, Serve images in modern formats (tab baru): keunggulan kompresi AVIF dan WebP serta ambang pelaporan 8 KiB.
• Chrome for Developers, CrUX methodology (tab baru): syarat halaman masuk dataset dan ambang popularitas yang tidak diumumkan.
• Bantuan Google Search Console, laporan Core Web Vitals (tab baru): sumber data CrUX, jendela 28 hari, dan perlakuan URL yang datanya kurang.
• Google Search Central, mobile-first indexing (tab baru): Google memakai versi mobile untuk pengindeksan dan pemeringkatan.
• Google Search Central, page experience (tab baru): Core Web Vitals dipakai sistem peringkat, tidak ada sinyal tunggal, dan relevansi tetap didahulukan.
• GTmetrix, Welcome to the new GTmetrix powered by Lighthouse (tab baru): perpindahan ke Lighthouse pada November 2020 dan penggantian tab PageSpeed serta YSlow.
• PageSpeed Insights (tab baru): alat pengukuran yang dipakai sepanjang artikel ini.
• Pengukuran HTML kami sendiri terhadap 16 halaman vendor jasa website Indonesia pada 20 September 2026. Satu kali pengambilan HTML saja tanpa gambar, CSS, atau JavaScript, jadi angkanya indikasi kasar dan bukan hasil Lighthouse.
• Kutipan pengguna diambil dari utas r/indonesia, "[ASK] How to make a website for dummies" (tab baru).