Kort svar: Find først det element, browseren faktisk registrerer som LCP på den berørte side og enhed. Del derefter tiden op i TTFB, ventetid før ressourcen opdages, downloadtid og ventetid før rendering. Et hero-billede skal ofte være synligt i den oprindelige HTML og ikke lazy-loades, men preload kun den dokumenterede LCP-ressource. Genmål samme URL og kontrollér samtidig funktion og layout.
Largest Contentful Paint måler, hvornår det største relevante element i viewporten er blevet vist. For de fleste brugere bør LCP ligge på højst 2,5 sekunder ved 75-percentilen. Tallet er dog kun begyndelsen: du kan ikke vælge den rigtige rettelse, før du ved, hvilket element og hvilken del af kæden der er langsom.
På desktop kan LCP være et stort hero-billede. På mobil kan samme billede være skjult, så en overskrift eller et andet billede bliver LCP. Test derfor den konkrete URL og viewport – ikke bare temaets designintention.
Kontrolramme: WordPress 7.1, PHP 8.4.23, FlyingPress 5.6.5 og Chrome 151 udgør versionsgrundlaget pr. 28. august 2026. Et screenshot fra Article Lab eller en anden syntetisk stagingfixture viser kun en kontrolleret mekanisme; det er ikke CrUX-, Lighthouse- eller produktionsbevis. Mærk derfor egne observationer med URL, dato, mobil/desktop og felt- eller labkilde.
På denne side
Feltdata viser rigtige brugeres oplevelse på tværs af en periode. Se om problemet findes for hele origin eller en bestemt URL-type, og om det især rammer mobil. En labtest kan derefter reproducere den langsomme kæde med et kontrolleret netværk og CPU.
Hvis feltdata er dårlige, men én lokal test er god, er problemet ikke nødvendigvis løst. Forskellen kan skyldes cache, geografi, enhed, samtykketilstand eller en sjælden skabelon. Dokumentér begge datatyper og marker tydeligt, hvad de repræsenterer.
Åbn browserens performanceværktøj og optag en fuld genindlæsning. Vælg LCP-hændelsen, og kontrollér det tilknyttede DOM-element. Gem:
Antag ikke, at det visuelt største element i designfilen også er browserens LCP. Et baggrundsbillede, en video eller en senere indsættelse kan ændre kandidaten.
En brugbar LCP-diagnose består af:
For et tekstbaseret LCP kan der ikke være en separat billeddownload, men font, CSS og JavaScript kan stadig holde renderingen tilbage.
| Dominerende led | Typisk undersøgelse | Undgå som første gæt |
|---|---|---|
| Høj TTFB | Cache HIT/MISS, origin, PHP og database | At preload flere frontendfiler |
| Lang resource load delay | HTML-opdagelse, lazy load, CSS-baggrund, JS-injektion | At komprimere et allerede lille billede |
| Lang downloadtid | Billeddimension, format, CDN/overførsel | At ændre JavaScript-delay |
| Lang render delay | Kritisk CSS, font, JS, animation og skjulte tilstande | At preload billedet igen |
Forestil dig to mobilmålinger med LCP omkring fire sekunder. I den første kommer HTML sent: TTFB fylder 2,2 sekunder, billedet opdages straks derefter, og både download og rendering er korte. Her skal cache/origin undersøges. En billedpreload kan højst flytte en lille del, fordi browseren ikke kan opdage markup før HTML'en er ankommet.
I den anden måling er TTFB 300 millisekunder, men billedrequesten starter først efter 2,4 sekunder. View Source viser, at heroen ikke findes som et almindeligt billede; et script indsætter den efter initialisering. Her er den rigtige første test at gøre ressourcen synlig i den oprindelige markup på staging. Eftermålingen skal vise tidligere requeststart. Hvis kun filstørrelsen er ændret, men requesten stadig starter sent, er den dominerende fejl ikke løst.
Tallene er illustrative, men metoden er den samme på en virkelig side: peg på den største underdel, vælg én ændring, og kontroller at netop den del flytter sig. Et samlet før/efter-tal uden underdele kan ikke forklare årsagen.
Sæt også et stopkriterium. Hvis en preload giver dobbelt billedrequest, hvis mobilen vælger en større kandidat end før, eller hvis CLS stiger, ruller du ændringen tilbage. Prøv derefter den mere grundlæggende løsning: direkte HTML-opdagelse, korrekte dimensioner eller fjernet renderforsinkelse. Det beskytter siden mod at samle flere prioritetshints, som konkurrerer uden at løse den målte flaskehals.
Browseren kan ikke opdage et element i HTML, før HTML ankommer. Sammenlign kold og varm anonym request samt cacheheader. Hvis kun første request er langsom, skal origin-generering og cacheopvarmning undersøges. Hvis et dokumenteret cache HIT stadig er langsomt, ligger tiden måske i proxy, edge eller netværk.
Følg TTFB-guiden i stedet for at kompensere med frontend-preloads. En tidlig billedrequest kan ikke hente de sekunder tilbage, der allerede blev tabt før HTML.
Et LCP-billede bør normalt være tilgængeligt direkte i den oprindelige HTML som et korrekt <img> eller <picture> med brugbar src/srcset. Browseren opdager det senere, hvis:
background-image;Undtag kun det dokumenterede LCP-billede fra lazy load. Kontroller i Network, at requesten nu starter tidligere og ikke blot får et andet filnavn.
Preload kan hjælpe, hvis den kritiske ressource ellers opdages sent, men browseren skal have samme kandidat, srcset-logik og crossorigin-forhold som den reelle request. En forkert preload kan hente en desktopfil på mobil eller hente samme billede to gange.
Brug preload eller høj fetch-prioritet på det dokumenterede LCP-billede, ikke på alle billeder over folden. Kontrollér bagefter, at requesten er tidligere, ikke duplikeret og faktisk ender som LCP.
Kontrollér det leverede billedes faktiske pixelmål mod visningen. Et 3000-pixel billede er sjældent nødvendigt i en smal mobilhero. Brug responsive kandidater, et passende moderne format og en kvalitetsindstilling, der bevarer motivets detaljer.
Gem:
srcset-kandidat ved hver viewport;Optimér ikke kun filstørrelsen. Hvis et forkert beskåret billede kræver CSS-zoom, kan den visuelle kvalitet og layoutstabilitet blive dårligere.
Hvis ressourcen er færdighentet længe før LCP, så undersøg hvad der holder elementet skjult eller uformateret:
Deaktivér én kandidat på staging og gentag sporet. Hvis en animationsforsinkelse skaber LCP, så vis hovedindholdet uden ventetid eller brug en transform/opacity-effekt, der ikke blokerer den første meningsfulde visning.
Find hvor LCP-elementet ejes: tema, featured image, buildersektion, global blok eller et plugin. Ret det native element, så responsive billeder, dimensioner og lazy-load-undtagelse følger med ved redigering. Undgå en global kode-snippet, hvis problemet kun findes på én skabelon.
Efter ændringen skal du åbne flere sider med samme template. En global hero-komponent kan have forskellige billeder og tekstlængder, som ændrer LCP-kandidaten.
Hvis kun én landingsside har et sent billede, så ret det konkrete native billede eller dets indstillinger. Hvis alle sider med samme hero-skabelon har samme opdagelsesforsinkelse, hører rettelsen sandsynligvis til den globale komponent. Før du ændrer den, skal du kontrollere mindst én kort overskrift, én lang overskrift og én side med et andet billedformat.
Et godt før/efter-notat kan se sådan ud:
Hvis kandidaten efter rettelsen bliver en tekstoverskrift, er det ikke automatisk en fejl. Notér kandidatskiftet og analyser den nye kæde; sammenlign ikke underdelene som om elementet var det samme.
Rettelsen er dokumenteret, når:
Hvis LCP-elementet skifter efter rettelsen, skal det nye element analyseres. Det er muligt at forbedre det første element og blot afsløre den næste flaskehals.
Ved regression gendanner du den tidligere lazy-load-, preload-, font- eller builderindstilling og rydder kun den berørte URL/assetcache. Kontrollér, at den oprindelige requestkæde og rendering er tilbage.
Kontakt hosting, hvis den dominerende del er dokumenteret TTFB/origin. Kontakt tema-/builderudvikleren med et minimalt eksempel, hvis elementet først kan opdages via en låst script- eller CSS-struktur. Hostious WordPress-support kan hjælpe med at koble trace, HTML og assetkæde.
Gem performance trace, HAR, HTML-kilde, LCP-selector, response headers og de rå tider for alle fire underdele. Navngiv materialet med testprofil og cachetilstand, og fjern cookies, tokens og interne stier.
Under 2,5 sekunder for 75 % af besøgene i feltdata. Mellem 2,5 og 4 er ‘needs improvement’, og over 4 sekunder koster både placeringer og konverteringer.
I PageSpeed Insights under diagnosen ‘Largest Contentful Paint element’ – eller i DevTools’ Performance-panel. Det er tit hero-billedet eller H1-blokken; ret DET element frem for at optimere alt.
Kun når elementet opdages for sent. Er problemet TTFB eller downloadstørrelse, flytter preload intet. Mål hvilket af de fire led der fylder – og sæt ind præcis dér.