Bagaimanakah Anda Mendiagnosis dan Menambah Baik Core Web Vitals yang Lemah?

Pernyataan Masalah dan Konteks Berkenaan

Satu halaman produk e-dagang mempunyai data lapangan mudah alih 28 hari dengan p75 LCP sebanyak 4.1 saat, INP sebanyak 320 milisaat, dan CLS sebanyak 0.06. Desktop lulus ketiga-tiga metrik. Larian Lighthouse tempatan oleh pembangun melaporkan LCP sebanyak 1.8 saat, TBT sebanyak 80 milisaat, dan CLS sebanyak 0.01. Terangkan cara anda menyelaraskan percanggahan ini, mencari punca utama LCP dan INP, menyusun urutan pembaikan, dan membuktikan bahawa perubahan yang digunakan telah menambah baik pengalaman pengguna sebenar.

Gunakan ambang "baik" Core Web Vitals semasa: kira persentil ke-75 secara berasingan untuk mudah alih dan desktop, dengan LCP pada atau di bawah 2.5 saat, INP pada atau di bawah 200 milisaat, dan CLS pada atau di bawah 0.1. Angka-angka ini adalah andaian temu duga, bukan ukuran daripada mana-mana syarikat sebenar. Matlamatnya bukan untuk membaca senarai semak pengoptimuman secara hafalan. Matlamatnya adalah untuk menghubungkan taburan pengguna, komponen metrik, kerja pelayar, dan pengesahan ke dalam satu rantaian diagnostik yang boleh dibuktikan salah (falsifiable).

Soalan ini sesuai untuk temu duga frontend kanan, prestasi web, dan full-stack. Calon perlu memahami laluan air terjun rangkaian (network waterfalls), benang utama (main thread), dan reka letak (layout), di samping menyedari bahawa satu larian Lighthouse tidak boleh mengatasi data pengguna sebenar dan bahawa TBT bukanlah INP.

Perkara yang Dinilai oleh Penemu Duga

Pertama, bolehkah calon menormalkan bukti sebelum bertindak? Jawapan yang mantap menentukan sama ada data lapangan mewakili satu URL, kumpulan URL, atau keseluruhan domain asal (origin), kemudian membahagikannya mengikut mudah alih berbanding desktop, templat laluan, tahap peranti, rangkaian, geografi, dan versi keluaran. Jawapan yang lemah menyatakan masalah itu tidak wujud semata-mata kerana skor Lighthouse tempatan berwarna hijau.

Kedua, bolehkah calon memetakan setiap metrik kepada kekangan prestasi (bottleneck) yang berbeza? LCP mengambil kira masa kandungan utama muncul. INP merangkumi kelewatan penuh daripada interaksi sehingga bingkai rendering seterusnya. CLS merangkumi pergerakan visual yang tidak dijangka. Ia berkongsi beberapa kos benang utama dan kos rendering, tetapi "mengurangkan saiz bundle" tidak dapat menjelaskan setiap kegagalan.

Ketiga, bolehkah calon mengatribusikan kependaman (latency)? LCP boleh dipecahkan kepada TTFB, kelewatan pemuatan sumber (resource load delay), tempoh pemuatan sumber (resource load duration), dan kelewatan rendering elemen (element render delay). Kependaman satu interaksi boleh dipecahkan kepada kelewatan input (input delay), tempoh pemprosesan (processing duration), dan kelewatan persembahan (presentation delay). Pembaikan harus menyasarkan komponen yang tidak normal dan bukannya item rawak daripada senarai semak prestasi.

Keempat, bolehkah calon menggunakan alat lapangan dan makmal dengan betul? RUM dan CrUX mengenal pasti perkara yang dialami oleh pengguna sebenar. DevTools, Lighthouse, dan senario peranti terkekang yang boleh dihasilkan semula membantu menjelaskan puncanya. Tanpa input pengguna sebenar, Lighthouse tidak dapat mengukur INP; isyarat makmal seperti TBT adalah bantuan diagnostik.

Kelima, bolehkah calon membuktikan penambahbaikan dan bukan sekadar menunjukkan pelaksanaan perubahan (deployment)? Selepas keluaran, bandingkan taburan RUM yang setara (like-for-like) mengikut versi atau kohort pelancaran, semak pagar kawalan (guardrails) ralat dan perniagaan, kemudian biarkan data lapangan 28 hari terkumpul mengesahkan perubahan tersebut. Satu snapshot, min yang lebih rendah, atau satu telefon yang lebih pantas tidak membuktikan bahawa p75 telah lulus.

Soalan untuk Dijelaskan Sebelum Menjawab

• Apakah skop data lapangan? Keputusan URL, kumpulan URL, dan domain asal boleh berbeza. Jika 4.1 saat itu milik domain asal, halaman produk tersebut belum lagi terbukti sebagai puncanya. Jika ia milik templat produk, bahagikan lagi trafik templat tersebut.
• Peranti, rangkaian, dan rantau manakah yang menyumbang sampel mudah alih? Kegagalan yang terhad kepada peranti kelas rendah atau satu rantau memerlukan pembiakan semula dan keutamaan yang berbeza. Menggabungkan mudah alih dan desktop akan menyembunyikan masalah.
• Bilakah metrik mengalami kemerosotan (regressed)? Penjajaran dengan sesuatu keluaran, skrip pihak ketiga, saluran paip imej, atau perubahan campuran trafik akan mengecilkan hipotesis. Nilai 28 hari terkumpul tidak mendedahkan kesan segera satu-satu keluaran secara tepat.
• Apakah elemen LCP sebenar dan interaksi INP yang perlahan? Imej utama (hero image), teks tajuk, dan bekas yang dirender oleh klien memerlukan pembaikan yang berbeza. Butang tambah ke troli, pemilihan varian, dan input carian juga menggunakan laluan benang utama yang berbeza.
• Bagaimanakah Lighthouse dijalankan? Pengekangan (throttling) peranti dan rangkaian, cache, pengesahan, data halaman, dan perjalanan yang diuji harus menyerupai populasi yang perlahan. Satu pemuatan sejuk (cold load) pada komputer riba yang pantas tidak mewakili taburan mudah alih.
• Lapisan manakah yang boleh diubah oleh pasukan? Pasukan khusus frontend masih perlu mengukur TTFB tetapi tidak boleh berpura-pura boleh membaiki domain asal secara langsung. Jika CDN, pemaparan pelayan (server rendering), dan perkhidmatan imej berada dalam skop, rancangan boleh merangkumi keseluruhan laluan kritikal.
• Apakah yang mentakrifkan keluaran yang berjaya? Di sini, ketiga-tiga metrik p75 mudah alih mesti berada dalam keadaan baik sementara kadar ralat, penukaran (conversion), dan kebolehcapaian kekal selamat. Melukis imej utama yang salah lebih awal atau menyekat interaksi kritikal bukanlah satu kejayaan.

Jawapan 30 Saat

"Saya akan terlebih dahulu mengesahkan sama ada 4.1 saat dan 320 milisaat adalah data lapangan peringkat URL atau peringkat origin mudah alih, kemudian membahagikannya mengikut templat laluan, peranti, rangkaian, dan keluaran. TBT Lighthouse bukan INP, jadi keputusan tempatan tidak boleh mengenepikan masalah pengguna sebenar. Saya akan menggunakan RUM untuk mengenal pasti elemen LCP sebenar dan interaksi paling perlahan, kemudian merekodkan surihan rangkaian dan Prestasi pada peranti yang setanding. Saya akan memecahkan LCP kepada TTFB, penemuan, muat turun, dan rendering, serta memecahkan INP kepada input, pemprosesan peristiwa, dan persembahan bingkai seterusnya. CLS sudah pun lulus pada 0.06, jadi ia menjadi pagar kawalan regresi dan bukannya pelaburan pertama. Akhir sekali, saya akan melancarkannya secara berperingkat, membandingkan p75 RUM dan pagar kawalan yang setara, serta menunggu tetingkap CrUX 28 hari untuk mengesahkannya."

Analisis Mendalam Langkah demi Langkah

Langkah 1: Terangkan cara keputusan lapangan dan makmal kedua-duanya boleh menjadi betul

Dua puluh lapan hari data lapangan menggabungkan peranti pengguna sebenar, rangkaian, keadaan cache, kitaran hayat halaman, dan interaksi. p75 LCP mudah alih sebanyak 4.1 saat meletakkan kira-kira satu perempat lawatan berkaitan yang paling perlahan pada 4.1 saat atau lebih teruk. Ini tidak bermakna satu "telefon biasa" mengambil masa tepat 4.1 saat. Data desktop yang lulus mencadangkan bahawa kegagalan mungkin tertumpu pada CPU yang terkekang, rangkaian mudah alih, templat mudah alih, atau perjalanan pengguna mudah alih.

Lighthouse tempatan ialah eksperimen terkawal. Ia boleh diulang dan berguna untuk laluan air terjun serta pengesanan regresi, tetapi ia mewakili satu konfigurasi peranti dan rangkaian sahaja. Tanpa input pengguna, Lighthouse tidak boleh menghasilkan INP secara langsung. TBT sebanyak 80 milisaat ialah isyarat makmal mengenai penyekatan benang utama. Sesuatu halaman mungkin mempunyai TBT permulaan yang rendah tetapi menjalankan tugas 300 milisaat apabila pengguna membuka pemilih varian. Perkara sebaliknya juga mungkin: TBT makmal yang tinggi mungkin berlaku pada masa beberapa pengguna sebenar sahaja yang berinteraksi.

Mula-mula, sahkan dalam PageSpeed Insights atau platform data sama ada keputusan itu adalah data URL, origin, atau kumpulan URL, dan periksa mudah alih serta desktop secara berasingan. Kemudian gunakan RUM pihak pertama untuk membahagikan mengikut templat halaman, tahap peranti, jenis sambungan berkesan, geografi, jenis navigasi, dan keluaran aplikasi. Setiap dimensi memerlukan sampel yang mencukupi dan sempadan privasi yang wajar. Diagnosis prestasi tidak mewajarkan pengumpulan rentetan pertanyaan (query strings) lengkap, teks yang ditaip, atau identiti pengguna.

Langkah 2: Bina RUM yang mengatribusikan masalah dan bukannya sekadar melaporkan skor

Pelaksanaan minimum boleh melaporkan ketiga-tiga metrik melalui web-vitals. Kod berikut adalah sama dalam semua lapan versi bahasa:

import { onCLS, onINP, onLCP } from 'web-vitals';

function sendToAnalytics(metric) {
  const body = JSON.stringify({
    name: metric.name,
    value: metric.value,
    id: metric.id,
    rating: metric.rating,
    route: location.pathname,
  });

  (navigator.sendBeacon && navigator.sendBeacon('/rum', body)) ||
    fetch('/rum', { body, method: 'POST', keepalive: true });
}

onCLS(sendToAnalytics);
onINP(sendToAnalytics);
onLCP(sendToAnalytics);

Contoh ini menggunakan location.pathname untuk kebolehbacaan. Kod pengeluaran harus memetakannya kepada templat laluan berkardinaliti rendah seperti /products/:id dan melampirkan versi keluaran, tahap peranti, serta medan atribusi yang diperlukan. Jangan hantar parameter pertanyaan, teks DOM, atau maklumat pengenalan pengguna. metric.id membantu membezakan peristiwa metrik untuk satu lawatan halaman, tetapi perkhidmatan penerima masih memerlukan peraturan persampelan dan pelaporan pendua yang jelas.

Menyimpan name dan value sahaja tidak mencukupi untuk membaiki regresi. LCP memerlukan elemen dan empat komponen masa. INP memerlukan sasaran interaksi dan tiga komponen masa. CLS memerlukan elemen yang beralih dan fasa kitaran hayat. Gunakan binaan atribusi atau produk RUM sedia ada untuk menambah medan tersebut. Pada masa pengagregatan, kira persentil daripada metrik akhir setiap navigasi. Jangan kira p75 untuk setiap komponen secara bebas dan menambahkannya: pemerhatian persentil tersebut boleh datang daripada lawatan yang berbeza.

Langkah 3: Mendiagnosis LCP dengan empat komponen masa

Satu navigasi mudah alih perlahan yang representatif menunjukkan TTFB sebanyak 0.6 saat, kelewatan pemuatan sumber sebanyak 1.5 saat, tempoh pemuatan sumber sebanyak 0.9 saat, dan kelewatan rendering elemen sebanyak 1.3 saat, untuk jumlah LCP sebanyak 4.3 saat. Komponen-komponen ini milik navigasi yang sama, jadi ia boleh ditambah. Ia bukan empat nilai p75 yang bebas.

Dua komponen mencurigakan yang paling besar ialah kelewatan pemuatan dan kelewatan rendering. Periksa sama ada elemen utama (hero) dimasukkan hanya selepas JavaScript klien dijalankan atau tersilap dimuatkan secara malas (lazy-loaded). Untuk imej, letakkan <img> dan src atau srcset miliknya dalam HTML awal, sediakan sizes yang betul, jangan muat secara malas imej LCP di atas lipatan (above-the-fold), dan gunakan fetchpriority yang lebih tinggi hanya untuk sumber yang benar-benar kritikal. Jika CSS adalah satu-satunya laluan penemuan, nilaikan pramuat (preload) yang tepat. Mempramuat setiap imej besar menyebabkan sumber-sumber kritikal bersaing untuk mendapatkan lebar jalur.

Sebanyak 1.3 saat lagi berlalu selepas sumber selesai dimuat turun, jadi pemampatan imej selanjutnya mungkin hanya mengalihkan masa ke dalam kelewatan rendering. Periksa JavaScript segerak, pintu kawalan pemaparan klien (client-rendering gates), gaya penyekat (blocking styles), fon, dan keadaan yang menyembunyikan imej utama. Memaparkan kandungan utama yang kelihatan melalui pelayan (server-rendering), mengurangkan CSS kritikal, dan menangguhkan penghidratan (hydration) bukan kritikal boleh membantu, tetapi surihan baharu mesti menunjukkan bahawa komponen sasaran benar-benar menurun. TTFB sebanyak 0.6 saat masih wajar dipantau. Ia mempunyai keutamaan yang lebih rendah daripada kelewatan 1.5 dan 1.3 saat yang diukur dalam sampel ini; ia tidak dikecualikan secara kekal daripada pengoptimuman.

Langkah 4: Mendiagnosis INP dengan tiga komponen masa

Satu interaksi "pilih varian" perlahan yang representatif mengambil masa 350 milisaat: 140 milisaat kelewatan input, 120 milisaat pemprosesan peristiwa, dan 90 milisaat kelewatan persembahan. Ketiga-tiga komponen datang daripada satu interaksi, jadi jumlahnya adalah bermakna. p75 INP lapangan sebanyak 320 milisaat ialah agregat berasingan dan tidak boleh digantikan oleh surihan ini.

Kelewatan input bermaksud kerja lain telah menduduki benang utama apabila pengguna bertindak. Rakam surihan Prestasi yang bermula sebelum interaksi dan cari penilaian skrip, tag pihak ketiga, pemasa, atau tugas panjang penghidratan. Pecahkan kerja yang boleh diganggu kepada tugas yang lebih kecil, tangguhkan kerja bukan kritikal, dan elakkan daripada menumpukannya semasa fasa permulaan. Memendekkan pengendali klik semasa sahaja tidak membuang 140 milisaat yang dihabiskan untuk menunggu sebelum pengendali itu bermula.

Tempoh pemprosesan adalah milik fungsi panggil balik (event callbacks). Masukkan status yang dipilih atau maklum balas pemuatan ke dalam bingkai seterusnya sebelum analisis inventori, penyegaran cadangan, atau pengelogan; buang pengiraan pendua dan sempitkan kemas kini keadaan. Untuk kelewatan persembahan, periksa kemas kini DOM yang besar, reka letak segerak paksaan (forced synchronous layout), dan thrashing reka letak. Kumpulkan pembacaan dan penulisan DOM serta kurangkan kawasan yang mesti disusun atur dan dilukis untuk interaksi ini. Ubah satu kekangan yang diukur pada satu-satu masa dan ulangi perjalanan yang sama untuk membandingkan ketiga-tiga komponen.

Langkah 5: Jadikan CLS yang sudah baik sebagai pagar kawalan regresi

CLS sebanyak 0.06 adalah di bawah 0.1, jadi ia tidak sepatutnya mengatasi LCP dan INP yang gagal. Ia masih memerlukan perlindungan kerana pemuatan imej utama yang lebih awal, komponen imej gantian, atau maklum balas interaksi baharu boleh memperkenalkan anjakan reka letak. Berikan imej dan video width, height, atau aspect-ratio yang stabil; tempah ruang untuk iklan, cadangan, dan kandungan tak segerak; serta kawal perbezaan saiz antara fon web dan fon sandaran (fallback).

Jurang antara CLS makmal sebanyak 0.01 dan CLS lapangan sebanyak 0.06 ialah bukti yang berguna. Larian Lighthouse lalai terutamanya merangkumi pemuatan, manakala pengguna sebenar mungkin melihat anjakan selepas pemuatan semasa menatal, membuka komponen, atau memastikan halaman panjang kekal aktif. Gunakan atribusi RUM dan trek Layout Shifts DevTools untuk menghasilkan semula perjalanan tersebut. Anjakan reka letak di dalam iframe rentas-asal (cross-origin) mungkin muncul dalam CrUX tetapi tidak dapat diatribusikan sepenuhnya melalui Web API halaman teratas, jadi periksa kandungan terbenam apabila percanggahan itu muncul.

Langkah 6: Susun perubahan mengikut bukti dan lancarkan secara berperingkat

Jangan cipta projek "imej" dan "JavaScript" yang berasingan serta mengubah segala-galanya secara serentak. Surihan semasa mencadangkan bahawa penemuan elemen utama sebelah klien yang tertangguh dan tugas panjang permulaan mungkin meningkatkan kedua-dua kelewatan pemuatan/rendering LCP dan kelewatan input INP. Kumpulan pertama boleh menguji satu hipotesis yang dikongsi: jadikan elemen utama boleh ditemui dalam HTML awal dan tangguhkan JavaScript yang tidak diperlukan oleh skrin pertama. Perubahan kekal kecil, tuntutan sebab-akibat kekal boleh diuji, dan kedua-dua metrik yang gagal mungkin bertambah baik.

Tulis isyarat yang dijangkakan untuk setiap perubahan. Kebolehtemuan imej utama sepatutnya mengurangkan kelewatan pemuatan sumber. Mengurangkan tugas panjang permulaan sepatutnya merendahkan kelewatan rendering LCP, kelewatan input INP, dan TBT makmal. Jika komponen yang sepadan tidak bergerak, jangan berikan kredit kepada pembaikan tersebut untuk perubahan skor yang berlaku secara kebetulan. Kualiti imej, kadar ralat, masa sehingga halaman boleh digunakan, penukaran, dan kebolehcapaian ialah pagar kawalan supaya angka prestasi tidak dapat menyembunyikan kemerosotan produk.

Lancarkan kepada kohort trafik sambil mengekalkan versi lama yang setanding atau garis dasar serentak. Bandingkan laluan yang sama, populasi mudah alih, dan versi keluaran sambil menyemak bahawa campuran trafik tidak beralih secara ketara. Apabila sesuatu pelaksanaan bertindih dengan perubahan trafik, garis masa sebelum dan selepas menunjukkan korelasi, bukan sebab-akibat secara automatik.

Langkah 7: Selesaikan isu dengan tiga lapisan bukti

Lapisan pertama ialah pagar kawalan makmal pra-penggabungan (pre-merge): tetapkan profil mudah alih yang terkekang, keadaan cache, dan interaksi kritikal, kemudian rekodkan LCP, TBT, CLS, laluan air terjun rangkaian, dan surihan Prestasi. Ini menangkap regresi yang jelas tetapi tidak menggantikan INP sebenar.

Lapisan kedua ialah RUM pasca-keluaran. Semak saiz sampel, persampelan yang stabil, dan penyahduplikasian peristiwa metrik, kemudian bandingkan p75 LCP, INP, dan CLS untuk templat produk mudah alih bersama-sama komponennya dan pagar kawalan produk. RUM jangka pendek boleh mendedahkan arah tuju dengan cepat. Jika sampel tidak mencukupi, laporkan keyakinan yang tidak mencukupi daripada mendakwa bahawa semua pengguna telah lulus.

Lapisan ketiga ialah pengesahan 28 hari terkumpul dalam CrUX atau Search Console. Lawatan lama meninggalkan tetingkap secara beransur-ansur, jadi metrik tidak melompat ke keadaan mantap baharunya pada hari pelaksanaan. Lulus bermakna mudah alih dan desktop secara berasingan memenuhi ketiga-tiga sasaran p75: LCP ≤ 2.5 saat, INP ≤ 200 milisaat, dan CLS ≤ 0.1. Membaiki LCP tidak boleh menolak CLS daripada 0.06 melepasi ambangnya. Rekodkan kriteria pemulihan (rollback) dan sebarang segmen perlahan yang tinggal supaya kelulusan secara agregat tidak menyembunyikan masalah peranti kelas rendah.

Contoh Jawapan Berkualiti Tinggi

"Saya tidak akan menggunakan keputusan Lighthouse tempatan yang hijau untuk mengenepikan data lapangan mudah alih. Mula-mula saya akan menentukan sama ada 4.1 saat itu milik URL butiran produk, kumpulan URL, atau origin, kemudian membahagikan mudah alih mengikut peranti, rangkaian, rantau, dan versi keluaran. p75 selama 28 hari ialah taburan, bukan satu peranti, dan TBT Lighthouse bukan INP.

Saya akan menambah atribusi RUM untuk mengenal pasti elemen LCP sebenar dan interaksi paling perlahan, kemudian menangkap surihan pada peranti yang setanding. Andaikan satu navigasi perlahan mempunyai komponen LCP sebanyak 0.6, 1.5, 0.9, dan 1.3 saat. Saya akan menangani kelewatan penemuan 1.5 saat dan kelewatan rendering 1.3 saat terlebih dahulu: letakkan imej utama dalam HTML awal, buang pemuatan malas di atas lipatan, dan kurangkan kerja klien yang menyekat lukisannya. Memampatkan imej yang telah pun dimuat turun bukanlah langkah pertama saya.

Untuk INP, saya akan membahagikan interaksi yang perlahan kepada kelewatan input, pemprosesan, dan persembahan. Jika komponen tersebut adalah 140, 120, dan 90 milisaat, saya akan mencari kerja permulaan yang menduduki benang utama sebelum interaksi terlebih dahulu, kemudian memendekkan fungsi panggil balik dan mengurangkan reka letak serta lukisan untuk kemas kini tersebut. CLS sudah pun lulus pada 0.06, jadi dimensi imej dan ruang letak kandungan tak segerak kekal sebagai pengawal regresi.

Saya akan melancarkan kepada kohort kecil, memerlukan setiap perubahan menggerakkan komponen masa yang diramalkan, dan membandingkan versi dengan RUM yang setara serta pagar kawalan produk. Belanjawan prestasi makmal menghalang regresi pra-penggabungan, RUM memberikan isyarat pengguna sebenar yang pantas, dan tetingkap CrUX 28 hari menyediakan pengesahan muktamad. Saya menutup isu ini hanya apabila p75 LCP, INP, dan CLS mudah alih semuanya mencapai 2.5 saat, 200 milisaat, dan 0.1 tanpa menurunkan kadar ralat, penukaran, atau kekebolehcapaian."

Kesilapan Lazim

• Mengenepikan data lapangan kerana Lighthouse tempatan lulus → Kedua-dua set data merangkumi pengguna, tetingkap masa, dan interaksi yang berbeza → Normalkan URL, peranti, rangkaian, versi keluaran, dan skop metrik terlebih dahulu.
• Membaca TBT 80 milisaat sebagai INP 80 milisaat → Lighthouse tidak boleh mengukur INP tanpa interaksi sebenar → Gunakan INP lapangan untuk impak dan TBT serta surihan interaksi untuk diagnosis.
• Hanya melihat pada min keseluruhan laman web → Purata menyembunyikan ekor mudah alih dan templat yang gagal → Kira p75 secara berasingan untuk mudah alih dan desktop, kemudian bahagikan kumpulan yang mempunyai sampel mencukupi.
• Memampatkan imej sebaik sahaja LCP perlahan → Kelewatan penemuan atau rendering mungkin mendominasi → Pecahkan LCP kepada empat komponen dan ubah komponen yang tidak normal.
• Mempramuat setiap sumber di atas lipatan → Sumber yang kononnya kritikal bersaing sesama sendiri → Tingkatkan keutamaan hanya untuk sumber LCP yang disahkan dan semak semula laluan air terjun.
• Hanya mengoptimumkan panggil balik klik → Tugas panjang sebelum panggil balik dan reka letak selepasnya masih menyumbang masa → Periksa input, pemprosesan, dan persembahan secara berasingan.
• Mengutamakan pengurangan CLS daripada 0.06 kepada 0.02 → Usaha diberikan kepada metrik yang sudah lulus sementara LCP dan INP masih gagal → Kekalkan CLS sebagai pagar kawalan dan utamakan metrik yang melebihi ambang.
• Menambah empat nilai p75 komponen → Setiap persentil mungkin datang daripada lawatan yang berbeza → Tambah komponen hanya dalam satu navigasi yang sama; kira persentil metrik akhir pada masa pengagregatan.
• Mendakwa kejayaan apabila RUM menurun pada hari pelaksanaan → Saiz sampel, campuran trafik, dan tetingkap 28 hari belum stabil → Bandingkan kohort pelancaran, periksa pagar kawalan, dan tunggu pengesahan lapangan terkumpul.

Soalan Susulan dan Maklum Balas

Susulan 1: Mengapakah LCP lapangan lemah sedangkan beberapa telefon ujian tidak dapat menghasilkannya semula?

Semak sama ada nilai lapangan adalah untuk URL atau origin, sama ada templat halaman dikumpulkan dengan betul, dan geografi, rangkaian, jenis navigasi, atau keluaran manakah yang mengandungi sampel perlahan. Jika peranti ujian terlepas ekor taburan sebenar, ambil label persekitaran berkardinaliti rendah daripada navigasi RUM yang perlahan dan bina semula keadaan CPU, rangkaian, cache, dan pengesahan yang setanding. Jika ia masih tidak dapat dihasilkan semula, kekalkan bukti atribusi dalam talian. Menjalankan ujian berulang kali pada peranti pantas tidak dapat melenyapkan masalah tersebut.

Susulan 2: Hanya satu segmen Android kelas rendah gagal INP, manakala p75 global lulus. Patutkah anda membaikinya?

Sahkan trafik segmen tersebut, kepentingan perniagaan, dan kebolehpercayaan sampel. Ambang global yang lulus menerangkan taburan agregat, bukan setiap kohort penting. Jika tahap peranti tersebut mengandungi ramai pengguna berbayar atau INPnya jauh melebihi 500 milisaat, tentukan SLO segmen dan selesaikan masalah tersebut. Jika sampelnya kecil, tingkatkan kebolehmerhatian (observability) terlebih dahulu. Menjadikan setiap segmen kecil sebagai pintu kawalan keluaran yang ketat akan membiarkan hingar persampelan menyekat keluaran.

Susulan 3: Bagaimanakah rancangan berubah jika elemen LCP ialah teks tajuk yang menggunakan fon web?

Penemuan sumber beralih daripada imej kepada fon dan gaya penyekat. Periksa bila permintaan fon ditemui, sama ada ia merentasi sambungan origin, saiz fail, font-display, dan dimensi fon sandaran, serta sama ada teks tajuk menunggu pemaparan klien. Jangan salin rancangan fetchpriority imej. Pramuat hanya fail fon yang benar-benar digunakan oleh skrin pertama, dan sahkan bahawa ini tidak menyebabkan muat turun pendua atau menggantikan sumber yang lebih kritikal.

Susulan 4: Interaksi yang perlahan berada di dalam iframe pembayaran rentas-asal (cross-origin). Apakah yang boleh dilakukan oleh halaman teratas?

INP boleh mencerminkan kependaman pengguna daripada interaksi iframe, tetapi sempadan rentas-asal mengehadkan atribusi halaman teratas. Hubungkaitkan RUM dengan versi benaman dan halaman yang mengandungi iframe tersebut, gunakan bukti prestasi daripada penyedia atau ujian yang boleh dihasilkan semula, dan bekerjasama dengan penyedia berkenaan. Halaman teratas juga boleh mengurangkan tugas panjang serentak miliknya sendiri. Tanpa tindanan panggilan (call stack) dalaman, nyatakan sempadan bukti: jangan salahkan penyedia secara automatik dan jangan dakwa bahawa kod tempatan telah membaiki iframe tersebut.

Susulan 5: Halaman mempunyai terlalu sedikit trafik untuk data CrUX peringkat URL. Bagaimanakah anda memutuskan sama ada ia lulus?

Gunakan RUM pihak pertama untuk mengumpul metrik bagi setiap lawatan dan medan persekitaran yang diperlukan, dengan melaporkan kedua-dua saiz sampel dan tetingkap masa, sementara ujian perjalanan kritikal makmal mengawal daripada regresi. Pengagregatan peringkat templat boleh meningkatkan saiz sampel hanya apabila struktur halaman dan perjalanan pengguna adalah setanding. Dengan data yang tidak mencukupi, anda mungkin membuktikan bahawa surihan yang diketahui telah bertambah baik, tetapi anda tidak boleh mendakwa status CrUX "baik" pada peringkat URL.

Susulan 6: Memaparkan elemen utama lebih awal menambah baik LCP tetapi memulakan penghidratan lebih awal dan memburukkan INP. Apakah langkah seterusnya?

Itu ialah pertukaran (trade-off) metrik yang sebenar, jadi kekalkan kedua-dua keputusan. Periksa sama ada pemaparan lebih awal benar-benar memerlukan penghidratan yang lebih awal. Selalunya kandungan visual statik boleh tiba terlebih dahulu sementara kod interaksi dimuatkan atas permintaan. Jika interaksi segera ialah keperluan perniagaan, tetapkan belanjawan di sekitar tindakan pengguna yang kritikal, pecahkan kerja benang utama, dan bandingkan LCP, INP, serta penukaran semasa pelancaran. Skor prestasi komposit tidak boleh menyembunyikan regresi INP.

Susulan 7: Dasar privasi melarang penyimpanan URL penuh dan sasaran DOM. Bolehkah RUM masih mendiagnosis isu tersebut?

Gunakan templat laluan yang telah dipratentukan, enum komponen, jenis interaksi, versi keluaran, dan tahap peranti umum. Jangan simpan ID produk, parameter pertanyaan, teks, atau pengecam pengguna. Petakan medan pada klien sebelum melapor, dan tolak nilai berkardinaliti tinggi pada pelayan. Atribusi menjadi kurang tepat, jadi pembiakan semula di makmal mesti mengisi jurang di sekitar komponen dan perjalanan yang disenaraikan. Diagnosis prestasi bukan kebenaran untuk meluaskan pengumpulan data peribadi.