Ipinaliwanag ang Core Web Vitals: LCP, INP at CLS sa payak na paliwanag

Ang Core Web Vitals ay hindi personality test para sa iyong website

Madalas ituring ang Core Web Vitals na parang misteryosong scorecard. Nakakakuha ng pulang numero ang isang page, may magpo-post ng screenshot sa Slack, at magsisimulang magtalo ang team tungkol sa mga framework ng JavaScript.

Hindi iyon gaanong kapaki-pakinabang.

Mas simple ang mas magandang paraan ng pag-iisip tungkol sa Core Web Vitals: tatlong sukat ito kung nararamdaman bang magagamit ang isang page ng totoong tao sa totoong device. Hindi nito nasasaklaw ang bawat aspekto ng performance, accessibility o kalidad. Pero nahuhuli nito ang tatlong karaniwang pinagmumulan ng inis:

• Masyadong matagal lumitaw ang pangunahing content.
• Mabagal tumugon ang page kapag may gustong gawin ang user.
• Gumagalaw o tumatalon ang layout habang nagbabasa o nagta-tap ang user.

Iyon ang tatlong Core Web Vitals: LCP, INP at CLS.

Ginagamit sila ng Google bilang bahagi ng page experience signals nito, pero hindi ang SEO angle ang pinakamagandang dahilan para pagtuunan ito. Mas magandang dahilan na ang mabagal, magalaw at hindi tumutugong mga page ay nagsasayang ng oras ng users. Karaniwan ding mas mahina ang conversion, mas mahirap suportahan, at mas mabilis maluma ang mga ito.

Ang tatlong metric sa tig-iisang pangungusap

Bago pumasok sa detalye, narito ang payak na bersyon:

• LCP, o Largest Contentful Paint, sumusukat kung gaano katagal bago mag-load ang pangunahing nakikitang content.
• INP, o Interaction to Next Paint, sumusukat kung gaano kabilis tumugon ang page sa mga interaction ng user sa buong pagbisita.
• CLS, o Cumulative Layout Shift, sumusukat kung gaano kalaki ang hindi inaasahang paggalaw ng page.

Ang karaniwang mga threshold ay:

| Metric | Mabuti | Kailangan ng pagpapahusay | Mahina | |---|---:|---:|---:| | LCP | 2.5s o mas mabilis | 2.5s–4.0s | Higit sa 4.0s | | INP | 200ms o mas mabilis | 200ms–500ms | Higit sa 500ms | | CLS | 0.1 o mas mababa | 0.1–0.25 | Higit sa 0.25 |

Karaniwang sinusuri ang mga numerong ito sa 75th percentile ng mga totoong pagbisita ng user. Mahalaga iyon. Hindi mo sinusubukang gumawa ng isang perpektong lab run. Sinusubukan mong gawing maganda ang karanasan para sa karamihan ng users, kabilang ang mga taong nasa mas mababagal na phone at mas magulong network.

Kung nakatitig ka sa isang automated report at hindi sigurado kung saan magsisimula, nakatutulong na paghiwalayin ang diagnosis sa panic. May hiwalay kaming gabay kung paano magbasa ng Lighthouse report nang hindi nagpapanic, na tumatalakay sa workflow na iyon nang mas detalyado.

LCP: kailan nararamdamang loaded na ang page?

Sinusukat ng Largest Contentful Paint ang render time ng pinakamalaking nakikitang content element sa viewport. Sa praktika, madalas itong:

• isang hero image,
• isang malaking heading,
• isang featured article image,
• isang product image,
• isang malaking bloke ng text.

Hindi tinatanong ng LCP kung kailan natapos mag-load ang bawat script, tracking pixel at below-the-fold image. Ang tanong nito ay: kailan naging visible ang pangunahing bagay na pinuntahan ng user para makita?

Dahil dito, mas makataong metric ang LCP kaysa sa makalumang “page load time”. Maaaring technically late matapos mag-load ang isang page pero mabilis pa rin ang pakiramdam kung mabilis lumitaw ang pangunahing content. Totoo rin ang kabaligtaran: maaaring mag-fire ang load event ng isang page habang blangko, malabo o naka-block pa rin ng render delay ang hero area.

Karaniwang sanhi ng mahinang LCP

Karamihan ng masasamang problema sa LCP ay nagmumula sa ilang mahuhulaang lugar:

1. Mabagal na server response

Kung late dumating ang HTML document, late rin magsisimula ang lahat ng iba pa.

1. Render-blocking CSS o JavaScript

Nasa browser na ang content pero hindi pa nito ito maipinta.

1. Hindi na-optimize na hero images

Masyadong malaki ang pinakamalaking element, mali ang format, hindi nabigyan ng priority, o aksidenteng na-load lazily.

1. Web fonts na nagpapaliban sa text rendering

Maaaring ang malaking heading ang LCP element, at maaaring maantala o biswal na mabago ito ng font loading.

1. Mga delay sa client-side rendering

Kung kailangan ng page ng malaking JavaScript bundle bago ito makapagpakita ng makabuluhang content, naghihirap ang LCP.

Paano pagbutihin ang LCP

Magsimula sa aktuwal na LCP element. Huwag mag-optimize ng kung anu-anong asset hangga’t hindi mo alam kung ano ang sinusukat ng browser.

Kasama sa praktikal na mga ayos ang:

• Ihatid ang HTML nang mabilis: mag-cache kung angkop, bawasan ang backend work, iwasan ang mababagal na redirect.
• I-optimize ang LCP image: gamitin ang tamang dimensions, compression at format.
• Huwag i-lazy-load ang above-the-fold hero image.
• Gamitin ang fetchpriority="high" nang maingat para sa pangunahing image kapag ito talaga ang priority.
• I-inline ang critical CSS kung makabuluhan nitong nababawasan ang render delay.
• Bawasan ang JavaScript na kailangan bago ang unang makabuluhang render.
• Gamitin ang font-display: swap o ibang sinadyang font strategy.

Madalas na salarin ang mga image at font. Para sa mga image, hindi lang “maliit na file ay mabuti” ang trade-off. Mahalaga ang pagpili ng format, encoding effort at browser support, kaya mayroon kaming praktikal na decision tree para sa kung kailan mas mahusay ang AVIF kaysa WebP at kung kailan hindi. Para sa mga page na maraming type, ang web fonts ay isa pa rin sa pinakamadaling performance wins dahil maraming site ang nagpapadala ng mas maraming font file kaysa sa ginagamit nila.

INP: tumutugon ba ang page kapag hinawakan?

Sinusukat ng Interaction to Next Paint ang responsiveness. Mas partikular, tinitingnan nito ang delay sa pagitan ng user interaction at ng susunod na visual update matapos maproseso ng browser ang interaction na iyon.

Kasama sa interactions ang mga bagay tulad ng:

• pag-click ng button,
• pag-tap ng menu,
• pagpili ng checkbox,
• pag-type sa form field,
• pagbukas ng accordion.

Pinalitan ng INP ang First Input Delay bilang Core Web Vital noong 2024. Magandang pagbabago iyon. Tiningnan lang ng First Input Delay ang unang interaction. Mas malawak ang INP: isinasaalang-alang nito ang interactions sa buong pagbisita sa page at nire-report ang isang high-latency interaction bilang score ng responsiveness ng page.

Sa payak na salita: nahuhuli ng INP ang mga page na mukhang loaded pero pakiramdam ay stuck.

Malamang nakagamit ka na ng ganitong page. Mukha itong handa na. Tina-tap mo ang menu. Walang nangyayari sa loob ng kalahating segundo. Tina-tap mo ulit. Pagkatapos, dalawang bagay ang sabay na nangyayari. Problema iyon sa INP.

Karaniwang sanhi ng mahinang INP

Karaniwang main-thread problem ang INP. Gustong tumugon ng browser, pero nakaharang ang JavaScript, rendering work o layout calculation.

Kasama sa tipikal na mga sanhi ang:

• malalaking JavaScript bundle,
• magastos na event handler,
• hydration work sa client-rendered apps,
• third-party scripts na nakikipag-agawan sa main thread,
• mahahabang task pagkatapos ng page load,
• komplikadong DOM updates na na-trigger ng maliliit na interaction,
• layout thrashing, kung saan paulit-ulit na nagbabasa at nagsusulat ng layout values ang code.

Maaaring mag-ambag ang marketing tags, analytics, chat widgets at consent banners. Hindi nito ibig sabihing “alisin ang lahat”. Ibig sabihin, may gastos ang bawat script sa page, at madalas na sa interaction latency nakikita ang gastos na iyon.

Paano pagbutihin ang INP

Ang pagpapabuti ng INP ay hindi tungkol sa isang mahiwagang attribute; mas tungkol ito sa pagbabawas ng main-thread contention.

Kasama sa kapaki-pakinabang na mga paraan ang:

• Hatiin ang mahahabang JavaScript task sa mas maliliit na bahagi.
• I-defer ang hindi mahalagang work hanggang magamit na ang page.
• Alisin ang hindi ginagamit na JavaScript sa halip na i-minify lamang ito.
• Panatilihing maliit at predictable ang event handlers.
• Iwasang i-render muli ang malalaking bahagi ng interface para sa maliliit na state change.
• Gumamit ng CSS para sa simpleng visual states kung maaari.
• I-audit ang third-party scripts at i-load lamang ang mga ito kung saan kailangan.

Tingnan din ang interaction design. Ang button na nagbibigay ng agarang visual feedback ay maaaring maramdaman na mas responsive, kahit mas matagal ang follow-up work. Hindi iyon kapalit ng performance, pero bahagi ito ng mahusay na interface engineering. Nag-o-overlap dito ang aming checklist para sa accessible web buttons: nakatutulong ang malinaw na states, tamang semantics at predictable na behaviour sa users at browsers.

CLS: nananatili ba ang page kung saan inaasahan ng user?

Sinusukat ng Cumulative Layout Shift ang hindi inaasahang paggalaw ng mga visible element. Kung nagsisimulang magbasa ang user ng isang paragraph at may ad, image o banner na nag-load sa itaas nito, na nagtutulak sa text pababa, nag-aambag iyon sa CLS.

Hindi sinusukat sa segundo ang CLS. Isa itong score batay sa kung gaano karaming content ang gumalaw at kung gaano kalayo ito gumalaw. Mas mababa ay mas mabuti.

Ang mahalagang salita ay hindi inaasahan. Karaniwang hindi binibilang sa parehong paraan ang mga layout change na dulot ng user action. Kung may nag-tap ng “show more” at lumawak ang content, inaasahan iyon. Kung lumitaw ang newsletter banner sa itaas pagkalipas ng tatlong segundo at itinulak pababa ang lahat, hindi iyon inaasahan.

Karaniwang sanhi ng mahinang CLS

Madalas ordinaryo ang mga failure sa CLS:

• images na walang width at height attributes,
• ads o embeds na walang nakareserbang espasyo,
• cookie banners na inilalagay sa itaas ng content,
• web fonts na nagsu-swap in gamit ang ibang metrics,
• late-loading promotional bars,
• dynamically injected content malapit sa itaas ng page.

Karaniwang solusyon ang magreserba ng espasyo bago dumating ang content. Dapat malaman ng browser ang hugis ng page sa pinakamaagang panahon.

Paano pagbutihin ang CLS

Magsimula sa mga visible shift. Manood ng recording o gumamit ng browser tooling para tukuyin kung aling elements ang gumagalaw.

Pagkatapos, ilapat ang mga boring na ayos:

• Magdagdag ng explicit na width at height attributes sa images.
• Gumamit ng CSS aspect-ratio para sa responsive media containers.
• Magreserba ng fixed o minimum space para sa ads, embeds at iframes.
• Iwasang mag-inject ng banners sa itaas ng umiiral na content pagkatapos ng load.
• Pumili ng font fallbacks na may katulad na metrics sa final font.
• Iwasan ang animations na nagpapabago ng layout properties tulad ng top, left, width o height; mas piliin ang transforms.

Isa ang CLS sa ilang performance metrics kung saan mas nananalo ang disiplina kaysa talino. Kung may stable boxes ang page, malamang na maganda ang score nito.

Parehong kapaki-pakinabang ang field data at lab data, pero magkaibang tanong ang sinasagot nila

Karaniwang pinagmumulan ng kalituhan na magkakaiba ang numerong ipinapakita ng iba’t ibang tool. Normal iyon.

Ang field data ay nagmumula sa totoong users. Sinasalamin nito ang aktuwal na devices, networks, locations at browser conditions. Halimbawa ng field data ang Chrome User Experience Report ng Google.

Ang lab data ay nagmumula sa controlled test environment. Pamilyar na halimbawa ang Lighthouse. Repeatable ito at kapaki-pakinabang sa debugging, pero hindi ito kapareho ng lived experience ng iyong users.

Gamitin ang field data para magpasya kung may totoong problema ang users. Gamitin ang lab data para i-reproduce at i-debug ang problemang iyon.

Tandaan din na karaniwang tinatasa ang Core Web Vitals per URL o URL group, hindi bilang isang abstract na property ng iyong brand. Maaaring may ibang-ibang bottleneck ang iyong home page, blog article, pricing page at checkout.

Isang makatuwirang pagkakasunod-sunod ng trabaho

Kung mahina ang lahat ng tatlong metric, nakatutuksong magsimula sa lahat ng lugar. Labanan iyon.

Isang praktikal na order ay:

1. Ayusin muna ang obvious na CLS

Ang kulang na image dimensions at unstable banners ay madalas quick wins.

1. Pagbutihin ang LCP para sa mahahalagang template

Magpokus sa mga page na mahalaga: product pages, landing pages, articles, sign-up flows.

1. Imbestigahan ang INP gamit ang totoong interactions

I-click ang mga bagay na aktuwal na kini-click ng users. Menus, filters, forms at checkout controls ay madalas magpakita ng higit pa kaysa initial load trace.

1. I-audit ang third-party scripts

Panatilihin ang mga nagbibigay-katwiran sa kanilang gastos. Alisin o i-delay ang mga hindi.

1. Magtakda ng performance budget

Kung walang budget, kumukupas ang performance improvements. Tahimik na babawiin ng bagong scripts, images at design components ang trabaho.

Ang mahalagang punto: huwag mag-optimize para sa badge. Mag-optimize para sa user journey. Ang maliit na improvement sa score sa low-traffic page ay maaaring mas hindi mahalaga kaysa sa bahagyang hindi perpekto pero mas mabilis na checkout interaction.

<!-- tool-cta:start -->

💡 Subukan ito: Dahil karaniwang problema sa larawan ang LCP, paliitin ang iyong hero asset gamit ang Image Compressor bilang una at madaling panalo.

<!-- tool-cta:end -->

Ang hindi sinasabi sa iyo ng Core Web Vitals

Kapaki-pakinabang ang Core Web Vitals, pero hindi kumpleto.

Hindi nito sinasabi kung maganda ang iyong content. Hindi nito sinasabi kung may saysay ang iyong navigation. Hindi nito ginagarantiya ang accessibility. Hindi nito sinusukat ang privacy, security, trust, readability o kung nasasagot ba ng page ang tanong ng user.

Hindi rin nito pinapalitan ang judgment. Maaaring pumasa ang isang page sa Core Web Vitals at hindi pa rin kaaya-aya. Maaaring hindi maabot ng isang complex application ang threshold habang responsable pa rin ang pagkaka-engineer nito para sa mga constraint nito.

Ituring ang LCP, INP at CLS bilang smoke alarms. Kapag tumunog ang mga ito, mag-imbestiga. Kapag tahimik sila, ipagpatuloy ang pag-maintain ng gusali.