Core Web Vitals ialah field metrics untuk loading, interaction responsiveness dan visual stability. Ia memberi shared measurement bagi sebahagian user experience, tetapi green report tidak menggantikan relevant content, accessible journey, crawlability atau business outcome.
CrUX dan first-party RUM menunjukkan apa yang dialami eligible visitors. DevAlat dan repeatable lab test mengenal pasti element, interaction, resource atau task di sebaliknya. Lighthouse 100 bukan objektif.
Kenali tiga metric dan threshold semasa
Nilai 75th percentile page visits secara berasingan bagi Mobile dan Desktop. Lebih rendah lebih baik untuk semua metric. LCP dan INP ialah nilai masa; CLS ialah unitless visual-stability score.
INP menggantikan First Input Delay (FID) sebagai Core Web Vital pada 12 Mac 2024, dan Chrome performance tools menamatkan support FID kemudian pada tahun itu. Total Blocking Time dalam Lighthouse ialah lab diagnostic yang berguna, bukan pengganti field INP.
| Metric | Good | Needs improvement | Poor | Pengalaman yang diukur |
|---|---|---|---|---|
| LCP | ≤ 2.5 saat | > 2.5 hingga 4 saat | > 4 saat | Bila likely main content kelihatan |
| INP | ≤ 200 milliseconds | > 200 hingga 500 ms | > 500 ms | Responsiveness merentas qualifying interactions |
| CLS | ≤ 0.1 | > 0.1 hingga 0.25 | > 0.25 | Unexpected visual movement sepanjang visit |
Fahami bagaimana assessment pass atau fail
Page atau origin pass apabila nilai 75th-percentile LCP, INP dan CLS semuanya “good”. Dalam PageSpeed Insights, aggregation dengan data INP tidak mencukupi boleh pass apabila LCP dan CLS good; jika LCP atau CLS tidak cukup data, assessment tidak dapat dibuat.
Search Console memberikan status URL group berdasarkan Core Web Vital yang paling lemah. “No data” bukan pass atau fail—sample CrUX tidak cukup untuk assessment itu.
| Situasi | Assessment | Maksud |
|---|---|---|
| Semua tiga metric good | Pass | Sekurang-kurangnya 75% measured visits memenuhi setiap threshold |
| Satu metric needs improvement | Tidak pass | Baiki dimensi experience itu |
| Satu metric poor | Poor group/status | Prioritikan affected representative journeys |
| INP tidak cukup; LCP dan CLS good | Boleh pass dalam PSI | Qualifying interactions tidak cukup untuk INP |
| LCP atau CLS tidak cukup | Cannot assess | Gunakan RUM/lab; jangan panggil pass |
| Tiada CrUX data | Unknown | Selalunya eligible traffic tidak cukup, bukan bukti laju |
Letakkan Core Web Vitals dalam page experience dan Cari
Google menyatakan ranking systems menggunakan Core Web Vitals, tetapi tiada satu page-experience signal. Relevance kekal utama dan perfect report tidak menjamin top ranking. HTTPS, Mobile presentation, intrusive interstitial, distracting ads dan pemisahan main content masih membentuk experience.
Gunakan Core Web Vitals untuk membaiki important journey dan friction, bukan membuang semua feature. Ukur sama ada perubahan juga menjaga accessibility, task completion dan conversion quality.
| Claim | Kedudukan tepat |
|---|---|
| “CWV menjamin ranking” | Salah; ia satu set signal antara banyak signal |
| “CWV tidak penting jika content rank” | Salah; poor experience mengurangkan user value dan boleh mempengaruhi Cari outcome |
| “Hanya green URL usable” | Salah; threshold bukan diagnosis UX lengkap |
| “Page experience ialah satu score” | Salah; Google menerangkan banyak aspek, page-specific dan beberapa site-wide assessments |
Gunakan setiap evidence layer untuk soalan yang betul
| Evidence | Soalan terbaik | Source | Limit utama |
|---|---|---|---|
| CrUX field data | Apa dialami eligible Chrome users? | PSI, Search Console, CrUX API/History/BigQuery | Aggregated sample dengan eligibility/segmentation limit |
| First-party RUM | Route, element, interaction, context dan release mana regress? | web-vitals library atau RUM platform | Perlu governance, sampling, privacy dan analysis |
| Lab load test | Apa block reproducible navigation? | Lighthouse dan PSI lab | Satu simulated load; lemah untuk post-load behavior |
| Interactive trace | Task, handler, layout atau paint mana lambat? | Chrome DevAlat Performance | Manual conditions mungkin berbeza |
| Delivery evidence | Adakah server/CDN/asset berubah? | Server-Timing, CDN dan app logs | Bukan complete visual experience |
| Business analytics | Adakah journey lebih cepat bantu outcome? | Analytics dan conversions | Correlation perlu release/cohort control |
Fahami apa yang CrUX termasuk dan tidak termasuk
CrUX menggabungkan pengalaman eligible Chrome users pada supported Desktop dan Android Chrome. Chrome iOS, Android WebView, Chromium browser lain dan pengguna yang tidak memenuhi setting criteria tidak termasuk. Page/origin juga mesti publicly discoverable dan sufficiently popular.
Jadi CrUX ialah representative evidence, bukan census semua visitors. Query parameter dan fragment dibuang dalam page-level aggregation, manakala SPA soft navigation mempunyai platform-measurement limit. Lengkapkan soalan low-traffic atau segmented dengan first-party RUM.
| Ciri CrUX | Kesan operasi |
|---|---|
| 28-day rolling aggregation | Release bercampur dengan sehingga 27 hari data lama dan berubah beransur |
| API/PSI updated daily | Data baru bukan independent 28-day test |
| URL dan origin level | Origin fallback boleh menutup slow/fast Template |
| Eligible Chrome sample | Jangan generalize kepada semua browser/audience |
| Popularity threshold | Page baru/low traffic mungkin tiada field data |
| Privacy filtering/fuzzing | Gunakan distribution/trend, bukan infer traffic volume |
Baca PageSpeed Insights dan Search Console dengan betul
PageSpeed Insights menggabungkan CrUX 28 hari dengan Lighthouse lab run yang baru. Sahkan field section “This URL” atau “Origin”; scope itu boleh memberi cerita berbeza. Search Console mengumpulkan URL dengan similar experience dan direka untuk group diagnosis, bukan exact score setiap URL.
Group status Search Console mengikuti metric paling lemah. Buka representative examples, banding PSI URL dengan origin data dan verify Template sebenar sebelum apply satu fix ke semua page.
- Pisahkan Mobile dan Desktop.
- Rekod collection dates, URL/origin scope dan group.
- Jangan compare Search Console group terus dengan satu Lighthouse run.
- Sahkan URL tested cukup page-level CrUX data.
- Semak distribution tiga-tiga metric, bukan overall label sahaja.
- Simpan Template, release version dan representative URL.
- Gunakan CrUX History/RUM untuk trend, bukan screenshot.
- Anggap “No data” sebagai unknown.
Tentukan affected unit sebelum ubah code
Report URL sering cuma contoh shared Header, Hero, Artikel Template, Product Gallery, Form atau Consent Layer. Reproduce lebih satu URL dan segment mengikut Template, Device, Navigation Type dan important user state.
Baiki satu image pada satu URL tidak berkesan apabila CMS rule menghasilkan masalah sama pada ratusan page. Sebaliknya, jangan rewrite global component kerana satu personalized page ialah outlier.
| Pattern | Likely unit | Perbandingan pertama |
|---|---|---|
| Metric sama dalam satu Template | Template markup atau shared asset rule | Tiga representative URLs |
| Issue merentas kebanyakan page | Header, font, consent, analytics atau CDN | Laman Utama, article, service dan form |
| Hanya repeat visit lambat | Cache, service worker atau client state | Cold vs warm navigation |
| Hanya post-login flow | Application route/state | Anonymous vs authenticated RUM |
| Hanya satu geography | CDN, origin distance atau third party | Region/network cohort |
| Hanya release baru | Changed bundle/component/backend | Version dan deployment annotation |
Diagnose LCP melalui empat subpart
LCP mengukur bila largest eligible content element dalam initial viewport dipaint. Candidate boleh berbeza mengikut viewport, content dan user, jadi capture actual element—jangan anggap setiap page ialah Hero Image.
Setiap LCP boleh dibahagi kepada Time to First Byte, resource load delay, resource load duration dan element render delay. Baiki subpart terbesar yang dibuktikan; compress image tidak membantu jika late discovery atau client rendering ialah punca.
| LCP subpart | Evidence | Punca biasa | Response fokus |
|---|---|---|---|
| TTFB | Document response mula lewat | Origin work, redirects, cache miss, network distance | Cache HTML, kurangkan backend, buang redirect, suitable CDN |
| Resource load delay | LCP request bermula lama selepas TTFB | CSS background, JS injection, lazy load, parser block | Initial HTML, buang lazy load, priority/preload bila terbukti |
| Resource load duration | Request mengambil masa panjang | Image/font terlalu besar atau slow asset host | Responsive size, compression, modern format, cache/delivery |
| Element render delay | Resource tiba tetapi paint lewat | Blocking CSS/font, hydration, animation, hidden state | Kurangkan blocking work dan render content lebih awal |
Apply LCP fix tanpa mencipta masalah baru
Untuk image LCP, sediakan crawlable src/srcset dalam initial HTML, minta dimensions tepat dan jangan lazy-load. fetchpriority="high" atau preload boleh membantu genuinely critical late-discovered resource, tetapi preload banyak file bersaing untuk bandwidth.
Untuk text LCP, inspect font dan CSS delivery. TTFB lebih pantas juga memberi setiap discovered resource permulaan lebih awal. Rujuk panduan Image SEO untuk responsive image dan intrinsic dimensions.
- Rekod LCP element dan empat subparts.
- Test cold/warm cache.
- Letak primary resource dalam initial document jika boleh.
- Jangan lazy-load LCP image.
- Serve dimension sesuai rendered size dan DPR.
- Preload hanya identified critical resource.
- Pastikan text visible semasa font load.
- Check Mobile viewport, bukan Desktop sahaja.
- Retest redirects, CDN cache dan third-party Hero.
Diagnose INP sepanjang visit
INP melihat qualifying Click, Tap dan Keyboard interaction sepanjang page visit dan melaporkan high-latency interaction, biasanya yang paling lama dengan satu outlier allowance bagi page yang banyak interactions. Page tanpa qualifying interaction tiada INP value.
Interaction latency mempunyai input delay sebelum callback, processing duration event callbacks, dan presentation delay sehingga next frame. Diagnose slow part serta target; first click pantas tidak membuktikan seluruh experience responsive.
| INP part | Apa melambatkan | Evidence | Response biasa |
|---|---|---|---|
| Input delay | Existing long task, script evaluation, timer atau overlapping work | Interaction trace dan load state | Kurangkan startup JS, split/yield work, kawal recurring task |
| Processing duration | Heavy event callback atau synchronous calculation | Event timing dan call stack | Kurangkan handler work, move/defer noncritical work |
| Presentation delay | Large DOM update, style/layout/paint atau framework render | Rendering selepas callback | Update smaller region, kurangkan DOM/layout/animation cost |
| Iframe interaction | Widget ada main thread tetapi berkongsi constrained device | Frame target/provider trace jika boleh | Delay, replace, isolate atau renegotiate vendor |
Test interaction yang benar-benar digunakan
Lighthouse load audit tidak menemui semua slow Menu, Cari, Filter, Checkout, Form Validation atau Chat interaction. Gunakan field attribution untuk mengenal pasti slow target/type, kemudian reproduce pada constrained hardware dengan DevAlat Performance.
Pecahkan long task dan yield selepas urgent UI update supaya browser boleh paint; defer Analytics, Save, Spellcheck atau kerja kedua. Elak render DOM besar selepas action kecil. Lihat juga panduan JavaScript SEO.
- Buka/tutup Navigation, Mega Menu dan Dialog.
- Taip Cari dan apply Filter.
- Expand FAQ atau Accordion.
- Validate dan submit Lead/Checkout Form.
- Accept/reject Consent.
- Buka WhatsApp, Chat atau Embed.
- Test interaction ketika startup.
- Gunakan low/mid-tier Mobile conditions.
- Rekod target, type, load state dan tiga INP subparts.
Diagnose CLS sepanjang page lifetime
CLS ialah unitless score berdasarkan berapa banyak visible content bergerak dan sejauh mana. Ia menggunakan worst session window dengan one-second gap dan five-second cap—bukan setakat sebelum load event.
Sesetengah movement dalam 500 ms selepas qualifying input boleh dianggap expected. Tatal dan hover bukan qualifying input, jadi shift semasa scroll/hover masih boleh dikira. CrUX boleh include user-visible iframe shifts yang page JavaScript RUM tidak sentiasa nampak.
| CLS source | Mengapa shift | Evidence |
|---|---|---|
| Image/video tanpa dimensions | Browser tahu size selepas layout | Layout Shift track + attributes |
| Ad/embed/widget | Late creative guna unknown/different height | Field target, slot lifecycle, provider timing |
| Injected banner/content | Block baru muncul di atas content | Post-load dan scroll flow |
| Web font | Fallback/final font metrics berbeza | Font waterfall dan text shift |
| Animation/transition | Layout properties ubah geometry | DevAlat rendering/animation trace |
| Back/forward atau long-lived page | Later state terlepas load-only test | RUM, pageshow dan full journey |
Reserve ruang dan kawal late content untuk CLS
Berikan image/video intrinsic width/height atau aspect-ratio tepat. Reserve realistic space untuk ads/embed, dan tentukan empty slot collapse sebelum—bukan selepas—surrounding content stabil.
Gunakan metric-compatible fallback font atau font-display, dan animate dengan transform/opacity apabila sesuai. Consent/promotion boleh overlay tanpa menolak content, tetapi mesti accessible dan tidak menutup main task.
- Load setiap Template pada Mobile/Desktop widths.
- Tatal lazy images, ads dan embeds.
- Buka Menu, Accordion, Filter dan validation error.
- Trigger Consent, Promotion, Chat dan locale UI.
- Test font pada cold cache/slow network.
- Gunakan Back/Forward navigation.
- Check hover dan responsive breakpoints.
- Capture shifted element dan element yang menyebabkan shift.
Anggap third-party code sebagai product decision
Tag manager, ads, consent, chat, heatmap, A/B tool, social embed dan video player boleh menjejaskan semua metric. Third party boleh melambatkan LCP request, mengambil main thread semasa interaction atau resize container tanpa ruang.
Inventory owner, purpose, load rule, data destination dan performance cost. Load selepas consent/intent bila sesuai, reserve space dan remove duplicate tags. Jika feature mahal masih diperlukan, document tradeoff; jangan sembunyikan dengan score-only workaround.
| Keputusan | Soalan |
|---|---|
| Keep | Adakah ia menyokong measured user/business outcome? |
| Delay | Boleh load selepas consent, idle, viewport proximity atau intent? |
| Restrict | Boleh run hanya pada Template yang perlu? |
| Replace | Adakah lighter provider/static preview cukup? |
| Remove | Adakah unused, duplicate, expired atau ownerless? |
| Monitor | Boleh observe version, load failure dan CWV attribution? |
Baiki platform rule, bukan generated page sahaja
Dalam WordPress/page builder, punca biasa termasuk oversized source image, multiple optimization plugins, uncached HTML, global animation, font variants, slider Hero, plugin JS, duplicated analytics dan DOM-heavy Component. Mulakan dengan responsible Template, Theme atau Plugin setting; jangan stack plugin sebelum tahu punca.
Pada custom site, jadikan Route data, image Component default, code splitting, hydration boundary, CSS delivery dan CDN caching sebagai shared rules. Selepas fix, test updates, forms, analytics, accessibility dan SEO output.
| Symptom | Tempat platform untuk inspect |
|---|---|
| Hero besar pada setiap page | Media pipeline dan responsive image Component |
| Slow uncached response | Page cache, origin, database dan CDN |
| Poor INP selepas consent | Tag manager, CMP callbacks dan vendor scripts |
| CLS pada semua Card | Shared dimensions dan skeleton Component |
| Staging laju, production lambat | Ads, analytics, CDN, personalization dan consent |
| Baik hanya bila plugin disabled | Plugin function dan alternative—bukan blind disable kekal |
Gunakan first-party RUM apabila aggregate tidak cukup
Library web-vitals mengumpul LCP, INP dan CLS hampir selaras dengan Google tooling; attribution build boleh merekod debug target dan subparts. Capture route/Template, metric ID, value, rating, navigation type, release version dan privacy-safe component label.
Hantar pada lifecycle point sesuai dan jangan bergantung pada unload/beforeunload. Sampling, consent, retention dan minimization mesti ikut privacy obligation. RUM/CrUX boleh berbeza kerana population, iframe, browser API, SPA attribution dan aggregation.
| RUM field | Sebab | Privacy/control |
|---|---|---|
| Template/route group | Cari shared failures | Normalized path; buang personal parameters |
| Release version | Asing cached/new code | Non-personal build ID |
| Metric value/rating/id | Aggregate/deduplicate | Elak session identity tanpa sebab |
| Attribution target | Cari LCP/INP/CLS component | Safe label, bukan user text |
| Navigation/device context | Jelaskan cold, bfcache, constrained journey | Coarse dimensions sahaja |
| Business event link | Ukur task outcome | Governed analytics dan consent |
Prioritikan performance sebagai keputusan business dan accessibility
Mulakan Poor sebelum Needs Improvement, Mobile sebelum Desktop apabila audience/issue di sana, high-value journey sebelum rare archive, dan shared Template cause sebelum isolated URL. Ambil kira slow device, assistive technology dan network yang disembunyikan oleh average.
Performance budget ialah release guardrail, bukan janji byte count sama dengan experience. Tetapkan limit pada proven cause—Hero bytes, third-party execution, route JS atau layout shifts—serta kekalkan UX, accessibility dan conversion gate.
| Priority signal | Lebih tinggi apabila |
|---|---|
| Status/severity | Poor, recurrent dan banyak visits |
| Template reach | Satu punca menjejaskan banyak indexable/transactional URLs |
| Journey value | Lead, signup, purchase, reading atau support |
| Audience risk | Mobile, constrained device atau key region |
| Change confidence | Trace menunjukkan controllable root cause |
| Regression risk | Fix boleh staged, measured dan rolled back |
Jalankan field-to-fix workflow yang repeatable
Simpan evidence, owner, risk dan retest dalam workflow audit SEO. Performance perlu jadi governed release discipline, bukan occasional plugin cleanup.
- Pilih metric, device, date range dan affected group.
- Sahkan URL/origin CrUX scope dan sample limits.
- Map examples kepada Templates dan journeys.
- Gunakan RUM attribution/field evidence jika ada.
- Reproduce route dan interaction dalam matched lab.
- Kenal pasti element, target, shift dan metric subparts.
- Trace server, network, asset, CSS, JS atau third-party cause.
- Pilih smallest coherent change dan success guardrails.
- Implement staging dengan release version.
- Regression-test content, accessibility, analytics dan conversion.
- Deploy berperingkat jika risiko perlu.
- Monitor lab/RUM dahulu, kemudian tunggu CrUX window sebelum close.
Gunakan release QA yang melindungi lebih daripada green score
| Gate | Pass condition | Evidence |
|---|---|---|
| Content | Main answer, media dan CTA masih berguna | Visual/content review |
| Accessibility | Keyboard, focus, labels, motion, contrast usable | Manual + automated checks |
| SEO delivery | Status, Canonical, metadata, links, image, schema betul | Build/crawl samples |
| Analytics | Consent, pageview, conversion tidak duplicate/hilang | Debug + production events |
| Performance | Target subpart baik tanpa Vital lain regress | Matched trace + RUM canary |
| Resilience | Slow API, third party, cache miss/error masih usable | Failure-path tests |
| Rollback | Previous version/config boleh restore | Release record + owner |
Ukur perubahan tanpa overclaim causality
Annotate release dan compare Device, Template, Navigation Type serta business cohort sama. Lab/RUM boleh confirm mekanisme segera; CrUX/Search Console berubah perlahan kerana 28-day window masih ada pre-release visits.
Sambungkan performance ke workflow measurement SEO: track CWV distribution, affected URLs, impressions, engagement dan qualified conversion. Design/content/campaign/ranking change serentak mengehadkan simple causal claim.
| Tempoh | Evidence | Keputusan |
|---|---|---|
| Sebelum release | Baseline distribution, trace dan business metric | Define target + rollback threshold |
| Minit/jam | Synthetic checks, errors, canary RUM | Catch breakage/regression |
| Hari | Versioned RUM ikut Template/device | Confirm user root-cause improvement |
| Sehingga/selepas 28 hari | CrUX, PSI dan Search Console trend | Verify aggregate response |
| Ongoing | Performance budget + release monitoring | Prevent recurrence |
Mitos Core Web Vitals
- “Lighthouse 100 bermaksud semua user mendapat fast experience.”
- “PSI field dan lab numbers patut sama.”
- “No CrUX data bermaksud page laju.”
- “Search Console memberi exact score setiap URL.”
- “Satu optimized example fix seluruh URL group.”
- “Compress Hero sentiasa fix LCP.”
- “Total Blocking Time sama dengan INP.”
- “CLS tamat apabila page load selesai.”
- “Semua shift selepas click dikecualikan.”
- “Performance plugin boleh kenal pasti semua root cause.”
- “Remove JavaScript automatik improve business journey.”
- “Pass CWV menjamin ranking atau conversion.”
Soalan lazim
Apakah Core Web Vitals pada 2026?
Largest Contentful Paint, Interaction to Next Paint dan Cumulative Layout Shift kekal sebagai tiga metric semasa untuk loading, responsiveness dan visual stability.
Adakah Core Web Vitals ranking factor?
Google menyatakan ranking systems menggunakan Core Web Vitals, tetapi tiada single page-experience signal dan strong score tidak menjamin top ranking.
Mengapa PSI menunjukkan dua set nombor?
Field section menggunakan aggregated CrUX 28 hari; lab section ialah Lighthouse simulation baru untuk diagnosis.
Mengapa Search Console berbeza daripada PSI?
Search Console menggunakan similar URL groups dan worst metric untuk status. PSI biasanya satu URL jika data cukup, jika tidak origin.
Berapa lama fix muncul?
Lab dan RUM boleh berubah segera. CrUX ialah rolling 28-day aggregate, jadi old/new experiences bercampur sehingga window bergerak.
Adakah setiap page perlukan CrUX data?
Tidak. New/low-traffic page mungkin tidak eligible. Gunakan representative Templates, RUM dan lab tanpa menganggap “No data” pass.
Adakah LCP sentiasa Hero Image?
Tidak. Ia boleh image atau text dan berubah mengikut viewport/user. Capture actual candidate dan subparts.
Mengapa INP poor walaupun page load pantas?
INP mengukur interactions sepanjang visit. Startup task, Menu, Form, Filter, DOM update dan Widget boleh lambat selepas page kelihatan siap.
Mengapa field CLS lebih buruk daripada Lighthouse?
Real users scroll, buka UI dan melihat Ads, Font, Embed serta long-lived state yang load-only test tidak exercise. CrUX juga boleh observe sesetengah iframe shift.
Patutkah buang useful feature untuk pass?
Hanya selepas menilai user/business value. Kurangkan, delay, isolate atau replace actual cost dahulu, kemudian ukur performance dan task outcome.
Rujukan rasmi
- Google Cari Central: Core Web Vitals and Hasil carian
- Google Cari Central: page experience in Cari
- Google Search Console Bantuan: Core Web Vitals report
- Google PageSpeed Insights: field and lab data
- web.dev: how Core Web Vitals thresholds are defined
- web.dev: Web Vitals measurement and tools
- web.dev: getting started with Web Vitals measurement
- web.dev: why lab and field data differ
- web.dev: debug performance in the field
- web.dev: optimize Largest Contentful Paint
- web.dev: optimize Time to First Byte
- web.dev: optimize Interaction to Next Paint
- web.dev: INP replaced FID as a Core Web Vital
- web.dev: diagnose slow interactions in the lab
- web.dev: find slow interactions in field data
- web.dev: optimize Cumulative Layout Shift
- web.dev: field measurement best practices
- Chrome DevAlat: Performance panel reference
- Chrome UX Report: methodology and eligibility
- Chrome UX Report: tools, cadence and granularity
Kongsikan template, PageSpeed result dan recent releases. Jack boleh asingkan server, image, CSS, JavaScript dan third-party cause.
Evolusi Ranking Google: Daripada PageRank ke Modern Cari Systems2 September 2026
Kandungan AI dan SEO Google: Apa Dibenarkan, Apa Dianggap Spam dan Cara Publish2 September 2026
Google Florida Update 2003: Fakta, Teori dan Lesson SEO2 September 2026