Die doelwit om LCP-tyd onder 2 sekondes te kry, vereis deurslaggewende aksies: 'n vinnige bedienerreaksie, die korrekte identifisering van die bladsy se grootste sigbare element, die kompressie en prioritisering van die heldebeeld, die vermindering van onnodige CSS- en JavaScript-lading, die gebruik van kasstelsels en 'n CDN, die optimalisering van lettertipes, en die meting van veranderinge met werklike gebruikersdata. Largest Contentful Paint meet hoe lank dit neem vir die grootste teksblok, prent, videoplagkaat of agtergrondprent wat op die gebruiker se skerm sigbaar is, om te laai. Volgens Google is 'n goeie LCP-waarde onder 2,5 sekondes; maar vir mededingende SEO, hoë omskakelingskoerse en 'n gladder gebruikerservaring is onder 2 sekondes 'n praktiese en haalbare teiken.
In hierdie gids hanteer ons die LCP-probleem nie bloot as 'n tegniese tellingverbetering nie, maar as 'n prestasieprojek wat die werklike gebruikerservaring beïnvloed. Ons fokus spesifiek op die stappe wat in die praktyk die beste resultate lewer, soos hosting-infrastruktuur, TTFB, beeldoptimalisering, weergawe-blokkerende hulpbronne, WordPress-inproppe, CDN- en kaslae. As jou webwerf stadig laai, 'n LCP-waarskuwing in jou PageSpeed Insights-verslag kry, of ranglys- en omskakelingsverlies op mobiele verkeer ervaar, kan jy meetbare winste behaal deur die kontrolelys hieronder stap vir stap toe te pas.
Wat is LCP en Hoekom Mik Ons Vir Onder 2 Sekondes?
LCP is een van die Core Web Vitals-maatstawwe en meet hoe vinnig die hoofinhoud van die bladsy aan die gebruiker verskyn. FCP (First Contentful Paint) volg die oomblik wanneer die eerste inhoud verskyn, INP volg interaksievertraging, en CLS volg visuele stabiliteit. LCP fokus op die laai-oomblik van die groot inhoud waarop die gebruiker werklik wag. Op 'n produkbladsy is dit gewoonlik die produkprent, op 'n blogplasing die omslagprent of hoofopskrifarea, en op 'n tuisblad die groot banier.
Google definieer die goeie LCP-drempel as 2,5 sekondes. Maar hierdie limiet verteenwoordig slegs 'n ervaring wat nie problematies is nie. In die SEO-standaarde van 2026, veral met mobiele-eerste indeksering, KI-gedrewe soekresultate, 'n hoogs mededingende SERP-struktuur en gebruikers se geduld in gedagte, is onder 2 sekondes 'n veiliger prestasiedoelwit. In e-handel, SaaS, korporatiewe webwerwe en inhoudswebwerwe kan selfs 'n vertraging van 1 sekonde die weieringkoers verhoog en omskakelings soos vormvoltooiing, byvoeging tot mandjie of kwotasieversoeke verminder.
LCP-verbetering is ook belangrik vir handelsmerkpersepsie, nie net vir soekenjins nie. As 'n gebruiker die bladsy oopmaak en 'n leë skerm, 'n laat prent of 'n springende uitleg sien, mag hulle die werf as onbetroubaar beskou. Daarom is vinnige hosting-keuse Hostragons Webhosting, die verskaffing van 'n veilige en moderne konneksie met SSL SSL sertifikate, en die bou van handelsmerkvertroue met die regte domeinnaam Domeinnavraag alles deel van die prestasiewerk.
Meet Jou LCP-Waarde Korrek: Laboratorium- vs Werklike Gebruikersdata
Voordat jy met optimalisering begin, moet jy die huidige stand van sake korrek meet. PageSpeed Insights, Lighthouse, Chrome DevTools, WebPageTest en die Google Search Console Core Web Vitals-verslag is die gereedskap wat die meeste gebruik word. Dit is egter nie korrek om die resultate van hierdie gereedskap op dieselfde manier te interpreteer nie. Lighthouse produseer laboratoriumdata; dit toets onder spesifieke toestel-, netwerk- en simulasietoestande. CrUX en Search Console wys egter werklike gebruikersdata. In die proses om LCP-tyd onder 2 sekondes te kry, moet jy albei datatipes saam gebruik.
Sleutelwaardes om tydens meting te monitor
- LCP-element: Watter prent, teks of blok word as die LCP op die bladsy gemerk?
- TTFB: Wat is die bediener se tyd om die eerste greep te stuur? Die ideale doelwit vir die meeste bladsye is tussen 200-500 ms.
- Weergawevertraging: Hoekom teken die blaaier die element laat, selfs al het die hulpbron aangekom?
- Hulpbronlaaivertraging: Hoe laat begin die versoek vir die LCP-element?
- Hulpbronlaaiduur: Veroorsaak die lêergrootte of netwerkvertraging 'n probleem terwyl die LCP-hulpbron afgelaai word?
Byvoorbeeld, as die LCP-element in 'n WordPress-blogplasing 'n WebP-omslagprent van 320 KB is, is die probleem gewoonlik hanteerbaar. Maar as dieselfde prent 'n 2,8 MB JPEG is en nie verskyn voordat CSS-lêers gelaai is nie, kan LCP maklik tot 4-5 sekondes styg. In 'n ander voorbeeld, as die lêergrootte klein is, maar TTFB 1,4 sekondes is, lê die probleem meer by hosting, databasenavrae of 'n gebrek aan kas, eerder as by die prent.
Die Mees Algemene Oorsake van LCP-Probleme
'n LCP-probleem bestaan gewoonlik nie uit 'n enkele oorsaak nie, maar uit 'n ketting van vertragings. Die bediener reageer laat, die HTML kom laat aan, kritieke CSS blokkeer weergawe, die LCP-prent word laat ontdek, JavaScript beset die hoofverwerkingsdraad, en lettertipe-verandering vertraag die inhoud. Daarom is dit nie altyd genoeg om net een inprop te installeer of 'n prent te komprimeer nie.
| Probleemarea | Simptoom | Prioriteitsoplossing | Verwagte impak |
|---|---|---|---|
| Stadige hosting of hoë TTFB | Eerste reaksie bo 800 ms | LiteSpeed, NVMe, PHP-opdatering, bedienerkas | Hoog |
| Groot heldebeeld | LCP-element bo 1 MB | WebP/AVIF, korrekte grootte, preload | Hoog |
| Weergawe-blokkerende CSS | Inhoud verskyn nie voor CSS klaar is nie | Kritieke CSS, skoonmaak van ongebruikte CSS | Hoog |
| Oormatige JavaScript | Hoofdraad besig, laat weergawe | Defer, delay, kode-verdeling | Medium-hoog |
| Ongeoptimaliseerde lettertipe | Teks verskyn laat | Font-display swap, preload, plaaslike lettertipe | Medium |
| Gebrek aan CDN en kas | Stadige laai op afgeleë liggings | CDN, blaaierkas, edge-kas | Medium-hoog |
Jy kan hierdie tabel as 'n prioriteitskaart beskou. Die eerste doelwit is om die stap te vind wat die grootste vertraging in die LCP-ketting veroorsaak. As TTFB hoog is, moet die bediener- en kaskant opgelos word voor beeldoptimalisering. As TTFB goed is, maar die LCP-prent laai laat, moet die formaat, grootte en prioriteit van die prent aangespreek word.
1. Verminder Bedienerreaksietyd
Die grondslag van LCP-optimalisering is 'n vinnige bedienerreaksie. As die HTML-dokument laat aankom, ontdek die blaaier ook die CSS-, JS- en beeldhulpbronne laat. Daarom is die eerste stap vir LCP-verbetering op werwe met 'n hoë TTFB-waarde om die hosting-infrastruktuur te ondersoek. As gedeelde hosting-hulpbronne onvoldoende is, SVE-limiete gereeld vol is, of databasisreaksies verleng word, sal bladsy-optimalisering 'n beperkte effek hê.
Uitvoerbare kontroles aan die hostingkant
- Skuif die PHP-weergawe na 'n huidige en stabiele weergawe. Ou PHP-weergawes kan aansienlike traagheid in WordPress en moderne CMS-strukture veroorsaak.
- Kontroleer prestasiekenmerke soos NVMe-skyf, LiteSpeed- of NGINX-gebaseerde struktuur, HTTP/2- of HTTP/3-ondersteuning.
- Kies die bedienerligging naby jou hoofteikengehoor. Vir 'n werf wat op Suid-Afrika gefokus is, verminder 'n plaaslike of naasliggende streekligging die vertraging.
- Maak databasistabelle skoon, verwyder onnodige hersienings en tydelike data.
- Oorweeg VPS, wolkbediener of skaalbare hostingplanne vir werwe met hoë verkeer VPS-bediener.
As 'n praktiese doelwit, probeer om die TTFB-waarde tot 200-400 ms op rekenaar te verminder, en so ver as moontlik onder 500 ms op mobiel. Natuurlik kan hierdie doelwit verander op dinamiese, gepersonaliseerde of databasis-intensiewe bladsye. Maar op blog-, korporatiewe en kategoriebladsye is hierdie waardes haalbaar met 'n goed gekonfigureerde kas.
2. Identifiseer en Prioritiseer die LCP-Element
Optimalisering sonder om die LCP-element te ken, is op raaiwerk gebaseer. Jy kan die LCP-element in die Chrome DevTools Performance-paneel of in die PageSpeed Insights-verslag sien. Hierdie element is meestal die omslagprent, skyfievertoning, groot opskrifblok of videoplagkaat aan die bokant van die bladsy. Sodra die LCP-element geïdentifiseer is, moet jy die blaaier laat weet dat hierdie hulpbron belangrik is.
Aanbevole benadering vir die heldebeeld
- Laat die LCP-prent uit van lui laai. Die hoofprent aan die bokant van die skerm moet nie lui gelaai word nie.
- Definieer die prent so vroeg as moontlik in die HTML. Heldeprente wat as CSS-agtergrond gegee word, word soms later ontdek.
- Gebruik preload en hoë fetch-prioriteit in gepaste situasies.
- Bied verskillende groottes vir mobiel en rekenaar aan. Moenie 'n 1920 px prent na 'n 390 px wye mobiele skerm stuur nie.
- Spesifiseer prentafmetings met width en height. Dit verminder ook die CLS-risiko.
Byvoorbeeld, as die LCP-element op jou tuisblad 'n banier van 1600x900 piksels is, maak dit 'n groot verskil om 'n WebP-weergawe van 720 px breed op mobiel te bedien. Na kompressie kan die prent daal van 1,5 MB na die reeks van 180-250 KB. Hierdie enkele verandering kan die mobiele LCP-waarde met meer as 1 sekonde verbeter.
3. Optimaliseer Prente met WebP of AVIF
Prente is die mees algemene oorsaak van LCP-probleme. Veral op WordPress-werwe kan die oorspronklike resolusie van 'n opgelaaide prent baie groot wees, en selfs al vertoon die tema hierdie prent klein op die skerm, moet die blaaier steeds die groot lêer aflaai. Daarom is dit nodig om die prent nie net te komprimeer nie, maar ook in die regte grootte te bedien.
Kontrolelys vir beeldoptimalisering
- Skakel JPEG- en PNG-lêers om na WebP- of AVIF-formaat waar moontlik.
- Komprimeer omslagprente tot 'n vlak waar kwaliteitverlies aanvaarbaar is. Gewoonlik lewer 'n kwaliteitreeks van 70-85 persent goeie resultate.
- Gebruik responsiewe beeldstruktuur. Danksy die srcset-logika word verskillende groottes na verskillende skerms gestuur.
- Maak onnodige EXIF- en metadata-inligting skoon.
- Gebruik SVG vir ikone waar moontlik; maar vereenvoudig ook onnodig komplekse SVG-lêers.
In 'n tipiese scenario wat ons op 'n inhoudswerf gedoen het, was die gemiddelde blog-omslagprent 1,2 MB, maar na WebP-omskakeling en korrekte hergrootte het dit tot 180 KB gedaal. As die LCP-prent hierdie omslagprent is, word aansienlike spoedwins behaal, veral op 4G mobiele verbindings. Hierdie wins verbeter nie net die PageSpeed-telling nie, maar ook die gebruiker se aanvanklike persepsie.
4. Verminder Weergawe-Blokkerende CSS-Lêers
Wanneer die blaaier die HTML-dokument ontvang, het dit CSS-reëls nodig om die bladsy te teken. Groot, onverdeelde en ongebruikte CSS-lêers kan die verskyning van die LCP-element vertraag. Veral voorafgeboude temas en bladsybouers kan baie stylblaaie laai wat nie op 'n enkele bladsy benodig word nie.
Wat om aan die CSS-kant te doen
- Genereer kritieke CSS en laai die nodige style vir die bokant van die skerm vroeg.
- Maak ongebruikte CSS-kode skoon of laai dit per bladsy.
- Verklein CSS-lêers, maar moenie net met minify tevrede wees nie; die werklike wins is om onnodige kode te verminder.
- Verhoed dat derdeparty-inprop CSS-lêers op alle bladsye laai.
- Gebruik slegs die nodige komponente van jou tema; bevraagteken groot skyfievertonings, animasies en ikoonpakkette.
Die punt om hier op te let, is om nie die visuele integriteit van die bladsy te versteur terwyl kritieke CSS gegenereer word nie. Verkeerd gekonfigureerde kritieke CSS kan veroorsaak dat 'n gebreekte ontwerp aanvanklik verskyn of CLS toeneem. Daarom moet mobiele en rekenaartoetse afsonderlik na elke verandering gedoen word.
5. Kry JavaScript-Lading Onder Beheer
JavaScript kan LCP op twee maniere beïnvloed. Eerstens kan JS-lêers die weergaweproses blokkeer. Tweedens kan dit die hoofverwerkingsdraad vir 'n lang tyd beset, wat die blaaier vertraag om die LCP-element te teken. Veral naspoorkodes, regstreekse ondersteuningsnutsmiddels, advertensieskripte, A/B-toetsnutsmiddels en sosiale media-wiggies kan prestasie aansienlik verlaag.
Toepaslike taktieke vir JavaScript
- Stel nie-kritieke skripte uit met defer of async.
- Laat derdeparty-skripte wat nie vir die eerste skerm nodig is nie, eers na gebruikerinteraksie loop.
- Deaktiveer onnodige JS-lêers van bladsybouer-inproppe per bladsy.
- Gebruik kode-verdeling en module-gebaseerde laai om lang take te verminder.
- Toets die impak van analise-, pixel- en geselsie-skripte een vir een.
Byvoorbeeld, as 'n korporatiewe webwerf se tuisblad gelyktydig 'n skyfievertoning, animasiebiblioteek, kaart-inbedding, regstreekse ondersteuning, en drie verskillende naspoorkodes laat loop, word dit moeilik om die LCP-doelwit te bereik. Sommige van hierdie nutsmiddels mag nodig wees vir omskakeling; maar dit is nie noodsaaklik dat almal tydens die aanvanklike laai loop nie. Prestasie-optimalisering gaan oor prioritisering sonder om die besigheidsdoelwit te benadeel.
6. Versnel Lettertipes en Behoud Tekssigbaarheid

Op baie bladsye is die LCP-element nie 'n prent nie, maar 'n groot opskrif of teksblok. In hierdie geval kan die laat laai van web-lettertipes die LCP-waarde direk beïnvloed. Die oproep van baie gewigte en style van eksterne lettertipe-verskaffers veroorsaak vertraging, veral op mobiel.
Voorstelle vir lettertipe-optimalisering
- Laai slegs die lettertipe-gewigte wat gebruik word. Kontroleer of jy werklik al die 300, 400, 500, 600, 700 en kursiewe variasies nodig het.
- Gebruik font-display swap om te verhoed dat teks onsigbaar bly.
- Preload kritieke lettertipes, maar vermy onnodige preload-gebruik.
- Bedien lettertipes vanaf die plaaslike bediener waar moontlik.
- Die keuse van stelsel-lettertipes is in sommige projekte die vinnigste en eenvoudigste oplossing.
Al lyk die vermindering van lettertip-lêers klein, is die impak groot as die LCP 'n tekselement is. Boonop is lettertipes ook effektief op CLS. Met die laai van verskillende lettertipes kan die tekswydte verander en die bladsy-uitleg verskuif. Daarom moet prestasie en visuele ontwerp saam geëvalueer word.
7. Konfigureer Kas- en CDN-Lae Korrek
Kasstelsels verbeter LCP-prestasie aansienlik vir herhaalde besoeke en statiese inhoud. Bladsykas, objekkas, blaaierkas en CDN-kas is verskillende lae. Die doel van almal is om dieselfde inhoud vinniger te bedien in plaas daarvan om dit herhaaldelik te genereer of van 'n verafgeleë bediener af te haal.
Op WordPress-werwe, wanneer LiteSpeed Cache, Redis-objekkas, blaaierkas en CDN-integrasie saam gebruik word, versnel die HTML-produksietyd en statiese lêeraflewering. In korporatiewe of pasgemaakte sagtewareprojekte moet toepassingsvlakkas, databasisnavraagoptimalisering en 'n edge-kasstrategie beplan word. As jou verkeer van verskillende streke en lande af kom, word CDN-gebruik selfs belangriker CDN en Webwerf Spoed Gids.
Punte om op te let in kaskonfigurasie
- Stel 'n lang kasduur vir statiese lêers en gebruik lêerweergawe-bepaling.
- Stel HTML-kasreëls versigtig in dinamiese areas soos lidmaatskap, mandjie of persoonlike panele.
- Evalueer beeldoptimalisering, Brotli-kompressie en HTTP/3-ondersteuning op die CDN.
- Beplan die kas-uitveeproses volgens jou publikasievloei.
- As verskillende kas vir mobiel en rekenaar benodig word, toets dat geen verkeerde inhoud bedien word nie.
8. Spesiale LCP-Verbeteringsplan Vir WordPress-Werwe
WordPress kan vinnig wees as dit korrek gekonfigureer is; maar onbeheerde tema- en inpropgebruik verhoog die LCP-waarde. Die mees algemene fout wat ons op WordPress-werwe sien, is om die prestasieprobleem slegs met 'n kas-inprop te probeer oplos. Terwyl temakeuse, aantal inproppe, beelddissipline en hostinggehalte saam hanteer moet word wordpress-hosting.
Stap-vir-stap WordPress-kontrolelys
- Gebruik 'n ligte en opgedateerde tema. Kies 'n behoefte-gefokusde tema in plaas van 'n té funksie-ryke tema.
- Verwyder onnodige inproppe. Selfs passiewe inproppe kan 'n sekuriteits- en bestuursrisiko skep.
- As jy 'n bladsybouer gebruik, verminder die las van globale wiggies en animasies.
- Hergrootte omslagprente voordat jy dit oplaai.
- Konfigureer bladsykas, CSS/JS-optimalisering en beeldoptimalisering versigtig in LiteSpeed of 'n soortgelyke kas-inprop.
- Maak databasis-hersienings, gemorskommentaar, transients en konsepte periodiek skoon.
Op 'n voorbeeld-blogbladsy kan die LCP by die eerste meting 4,1 sekondes wees. As TTFB 900 ms is, die omslagprent 1,8 MB is en die tema CSS-lêer 450 KB is, is die oplossingsvolgorde duidelik: verlaag eers TTFB met hosting en kas, maak dan die omslagprent WebP en responsief, en verminder laastens ongebruikte CSS. Aan die einde van hierdie werk is dit 'n realistiese doelwit dat die LCP-waarde tot die band van 1,7-2,1 sekondes daal.
9. Doen Aparte Optimalisering Vir Mobiele LCP
Mobiele gebruikers het gewoonlik laer verwerkingskrag en wisselende konneksiegehalte. Daarom kan 'n LCP-waarde wat goed lyk op rekenaar, swak wees op mobiel. Aangesien die gewig van mobiele ervaring hoog is in Google se assesserings, moet jy jou toetse beslis in 'n mobiele scenario doen.
In mobiele optimalisering veroorsaak groot prente en swaar JavaScript-las meer probleme. As jy outomatiese video, 'n groot skyfievertoning, intense animasie en eksterne ingebedde inhoud op die eerste skerm gebruik, word die LCP-doelwit moeilik. 'n Eenvoudige helde-area, duidelike opskrif, geoptimaliseerde prent en vinnige bedienerreaksie lewer gewoonlik beter resultate op mobiel.
Vinnige winste vir mobiel
- Gebruik 'n enkele, geoptimaliseerde heldeprent in plaas van 'n skyfievertoning.
- Wys 'n saamgeperste plakkaatprent in plaas daarvan om video op die eerste skerm te speel.
- Moet glad nie onnodige rekenaarkomponente op mobiel laai nie, in plaas daarvan om hulle net met CSS weg te steek.
- Definieer srcset geskik vir mobiele breekpunte vir prente.
- Begin derdeparty-skripte eers na die aanvanklike laai.
10. Toets en Monitor Veranderinge Stap Vir Stap
Een van die grootste foute in LCP-optimalisering is om te veel veranderinge gelyktydig te maak en nie te kan verstaan watter stap gewerk het nie. Vir meetbare vordering, neem aantekeninge voor en na elke verandering. PageSpeed Insights, WebPageTest filmstrook-aansig en Chrome DevTools prestasie-opname is nuttig in hierdie proses.
Die aanbevole toetsvloei is soos volg: Kies eers 3-5 kritieke URL's soos die tuisblad, die blogplasing met die meeste verkeer, 'n kategoriebladsy en 'n omskakelingsbladsy. Noteer die huidige LCP, TTFB, LCP-element, totale bladsygrootte en aantal versoeke vir elke URL. Pas dan eers bediener/kas, dan beeld, dan CSS/JS, dan lettertipe-verbeterings toe. Her-toets dieselfde URL's na elke fase. Laastens, wag vir die Google Search Console Core Web Vitals-verslag om op te dateer; werklike gebruikersdata word binne 'n paar weke meer betekenisvol.
Doelwitkontrolelys Vir LCP Onder 2 Sekondes
- Verminder die TTFB-waarde so ver moontlik onder 500 ms.
- Identifiseer die LCP-element definitief en verseker dat dit vroeg op die bladsy laai.
- Bedien die heldebeeld in WebP- of AVIF-formaat, in die korrekte grootte.
- Laat prente op die eerste skerm uit van lui laai.
- Gebruik kritieke CSS, verminder ongebruikte CSS- en JS-lêers.
- Vertraag onnodige derdeparty-skripte.
- Verminder die aantal lettertipes en gewigte, gebruik font-display swap.
- Konfigureer bladsykas, blaaierkas, objekkas en CDN-lae.
- Doen mobiele toets apart en volg werklike gebruikersdata.
- Skep 'n permanente prestasiestandaard deur elke verandering afsonderlik te meet.
Afsluiting
Om LCP-tyd onder 2 sekondes te kry, is nie 'n eenmalige inprop-instelling nie; dit is 'n holistiese werk wat bestaan uit hosting, hulpbronprioriteit, beelddissipline, CSS/JS-bestuur, kas en meetprosesse. Die vinnigste resultaat kom gewoonlik van die stappe om TTFB te verlaag, die LCP-prent te optimaliseer en weergawe-blokkerende hulpbronne te verminder. Vir blywende sukses moet jy prestasie deel maak van jou publikasieproses.
As jou werf se infrastruktuur jou prestasiedoelwitte beperk, kan jy begin met vinniger hosting, die regte bedienerligging en veilige SSL-konfigurasie. Jy kan 'n stewiger fondament vir LCP en algehele gebruikerservaring bou deur die geskikte hosting-opsies vir jou webwerf by Hostragons te ondersoek Hostragons Hosting Pakkette.
Gereelde Vrae
Wat moet die LCP-waarde wees?
Google beskou 'n LCP-waarde onder 2,5 sekondes as goed. Maar vir mededingende SEO en 'n beter gebruikerservaring is onder 2 sekondes 'n sterk doelwit. Veral in mobiele verkeer kan hierdie doelwit omskakelingskoerse positief beïnvloed.
Wat beïnvloed LCP-tyd die meeste?
Die mees algemene invloede is stadige bedienerreaksie, groot heldebeeld, weergawe-blokkerende CSS, swaar JavaScript, laat-laaiende lettertipes en 'n gebrek aan kas. Om te verstaan watter faktor dominant is, moet die LCP-element met PageSpeed Insights en DevTools ondersoek word.
Sal CDN-gebruik die LCP-waarde verlaag?
Ja, veral as gebruikers ver van die bedienerligging af is, kan 'n CDN statiese lêers vanaf nader eindpunte bedien en laaityd verminder. As TTFB, beeldgrootte en weergawe-blokkerende hulpbronne egter in 'n slegte toestand is, is 'n CDN alleen dalk nie genoeg nie.
Wat moet die eerste stap vir LCP-optimalisering in WordPress wees?
Die eerste stap is om die LCP-element en TTFB-waarde te bepaal. Daarna moet die hosting- en kaskonfigurasie nagegaan word, die omslag- of heldeprent geoptimaliseer word, en onnodige tema- en inproplas verminder word.
Is lui laai goed vir LCP?
Lui laai is voordelig vir prente wat onder die vou is. Maar die toepassing van lui laai op die eerste skerm se prent, wat die LCP-element is, is gewoonlik nadelig, want die blaaier laai hierdie belangrike hulpbron laat. Die LCP-prent moet met prioriteit gelaai word.