Core Web Vitals i Umbraco: så mäter den här sajten grönt

Betygen

De flesta Umbraco-sajter missar inte Core Web Vitals för att Umbraco är långsamt. De missar dem för att ingen gjorde prestanda till ett beslut under uppstarten – det blev städarbete tre månader efter lansering, inklämt mellan kundens önskemål.

KindbergCo.com körs på KindbergCo Umbraco Platform med minimala avvikelser från grundbygget. Så i stället för att prata om prestanda i det abstrakta – här är vad PageSpeed Insights faktiskt rapporterar, testat 24 augusti 2026 (Lighthouse labbdata).

Desktop

• Performance: 100
• Accessibility: 100
• Best Practices: 100
• SEO: 100
• Agentic Browsing: 2/2
• First Contentful Paint: 0,4 s
• Largest Contentful Paint: 0,7 s
• Total Blocking Time: 10 ms
• Cumulative Layout Shift: 0,004
• Speed Index: 0,5 s

Mobil

• Performance: 91
• Accessibility: 100
• Best Practices: 100
• SEO: 100
• Agentic Browsing: 2/2
• First Contentful Paint: 1,7 s
• Largest Contentful Paint: 3,3 s
• Total Blocking Time: 0 ms
• Cumulative Layout Shift: 0,004
• Speed Index: 2,8 s

Desktop är rent över hela linjen. Mobil är starkt men inte perfekt – mer om det nedan, för att låtsas något annat skulle motverka hela poängen med ett inlägg om ärlig mätning.

En sak till värd att säga rakt ut: det här är labbdata, inte fältdata. PageSpeed Insights visar just nu ingen Chrome UX Report-data för den här sajten – det verkliga användardataset som Google faktiskt använder för Core Web Vitals som rankingsignal. Det är normalt för en sajt med lägre trafik; CrUX behöver en viss volym riktiga Chrome-besök innan den rapporterar något. Labbresultat från Lighthouse är rätt verktyg för tekniska beslut under utveckling. De är inte samma sak som att sajten “klarar Googles Core Web Vitals-bedömning”, vilket kräver fältdata.

Vad “grönt” faktiskt betyder här

De tre mätvärden Google räknar som Core Web Vitals är LCP (laddning), INP (interaktivitet – Total Blocking Time är den närmaste labbproxyn) och CLS (visuell stabilitet). På mobil är två av tre i praktiken perfekta: CLS är 0,004, och TBT på 0 ms ligger klart inom det “bra” intervallet. Det som fortfarande ligger i gult är LCP, på 3,3 sekunder mot Googles tröskel på 2,5 sekunder för “bra”.

Det är det ärliga resultatet: layoutstabilitet och interaktivitet är lösta. Laddningshastighet på mobilnät är bra, men inte grönt ännu. Båda fakta väger tyngre än ett enskilt rubriktal.

Vad som faktiskt ligger bakom de här siffrorna

Inget av det här är slumpmässigt, och inget är magi. Det är en specifik uppsättning implementationsbeslut som är inbyggda i plattformen innan en enda sida kundinnehåll finns.

• Caching och statiska cache-headers. Distribuerade caching-mönster och cache-headers för statiska filer gör att upprepade anrop inte räknar om eller hämtar på nytt det som inte har ändrats. Det förklarar merparten av varför Speed Index på desktop är 0,5 sekunder.

• Separerad, minifierad CSS och JavaScript. Plattformen skickar inte en enda monolitisk bundle till varje sida. CSS och JS delas upp, minifieras och laddas utifrån vad en given sida och dess block faktiskt behöver.

• Dynamisk skriptladdning per block. Ett block som behöver en slider (SplideJS) eller interaktivt beteende (AlpineJS) laddar sina egna skript. En sida utan det blocket betalar inte för det. Det är den direkta förklaringen till att Total Blocking Time är försumbart på båda enhetstyperna – 10 ms desktop, 0 ms mobil.

• Responsiv bildhantering. Bilder levereras i den storlek som behövs för sitt sammanhang i stället för en enda överdimensionerad originalfil som skalas ner i webbläsaren. Det är också den mest sannolika spaken kvar att dra i för LCP på mobil.

• Semantisk markup och strukturerade rubriker. De ligger bakom 100 i Accessibility och 100 i Best Practices, och är en del av varför det här inte handlar om att fuska till ett Lighthouse-tal.

• SEO-grundarbete. Canonical-URL:er, sitemap-generering, robots.txt-hantering och metadatafält är plattformens standard – en kort SEO-insats på den här sidan tog den från 92 till 100.

Accessibility och Best Practices landar på 100 både på mobil och desktop. De är inte nätverksberoende på samma sätt som laddningshastighet – de är en funktion av markup och kod, så de försämras inte av en långsammare uppkoppling på samma sätt som LCP.

PageSpeed Insights sätter numera också betyg i en femte kategori: Agentic Browsing, Googles mått på hur väl en sida fungerar för AI-agenter snarare än mänskliga besökare. KindbergCo.com får 2/2 på både desktop och mobil – och det kostar ingenting extra, eftersom kontrollerna bakom det (ett korrekt uppbyggt accessibility-träd, layoutstabilitet) är samma semantiska markup och CLS-disciplin som redan beskrivits ovan. Det är inget separat initiativ. Det är samma beslut som betalar sig två gånger.

Där det fortfarande inte är grönt: LCP på mobil

3,3 sekunder mot ett mål på 2,5 sekunder är en verklig lucka, inte ett avrundningsfel. Largest Contentful Paint är nästan alltid rendertiden för det största synliga elementet – oftast en hero-bild eller ett stort textblock ovanför vikningen – under simulerade förhållanden för mellanklass-mobilnät och CPU. LCP på desktop för samma sida är 0,7 sekunder, vilket visar att det inte är ett problem med serverns svarstid; det är ett problem med bandbredd och bildstorlek specifikt för begränsade uppkopplingar.

Plattformen ger verktygen för att stänga den luckan – responsiv bildhantering, dynamisk laddning, caching – men plattformen kan inte bestämma hur stor en hero-bild en redaktör laddar upp, eller vilken sida som får mest uppmärksamhet. Det är den ärliga gränsen mellan vad en grund löser som standard och vad som fortfarande beror på det specifika bygget.

Varför det spelar roll om ni utvärderar plattformen

Varenda siffra ovan är en biprodukt av beslut som togs en gång, på plattformsnivå, i stället för att omprövas i varje projekt: hur CSS och JS buntas, hur bilder levereras, hur cache-headers sätts, hur markup struktureras. Det är det verkliga värdet – inte ett enskilt smickrande Lighthouse-tal, utan hundratals timmars sådana beslut redan fattade, testade och i drift i produktion på kindbergco.com.

Att starta ett nytt Umbraco-bygge från en tom installation innebär att ta alla de besluten igen, under en deadline. Att starta från KindbergCo-plattformen innebär att prestanda är ett utgångsläge, inte en brandkårsutryckning. Vill ni veta hur er egen Umbraco-sajt faktiskt mäter, hör av er via formuläret nedan.