Critical CSS är den lilla mängd stilkod som krävs för att rita upp det som syns direkt på skärmen, och som läggs rakt in i sidans HTML så att webbläsaren slipper vänta på en separat stilmall. Tänk dig att en besökare klickar in på din sajt via en mobil med svajig 4G. Webbläsaren laddar ner HTML-dokumentet, hittar en länk till en stor stilfil och stannar upp. Ingenting ritas ut förrän hela den filen är nere och tolkad, och under tiden ser besökaren en vit skärm. Det är precis den pausen som tekniken är till för att ta bort, och den är en central pusselbit i bredare arbete med sidhastighet och optimering. Hur snabbt sidan känns hänger i sin tur ihop med hur väl den konverterar besökare till kunder, och med vilka sökord du faktiskt syns på.
Idén är enkel: i stället för att låta en extern fil blockera all rendering plockar man ut just de regler som behövs för det första som syns, och lägger dem direkt i dokumentet. Då kan webbläsaren visa något läsbart nästan på en gång, medan övriga stilar hämtas i bakgrunden utan att hålla upp något. Samma grundprincip — flytta fram det viktigaste — går igen i en genomtänkt innehållsstrategi och i hur du optimerar en WordPress-sajt.
★ SNABBVERSIONEN
- Reglerna för innehållet ovanför vikningen läggs inline i HTML.
- Syftet är snabbare FCP, alltså kortare tid till första synliga innehåll.
- Den fullständiga stilmallen laddas asynkront och blockerar inte renderingen.
- Verktyg som Critical, WP Rocket och Jetpack kan generera urvalet automatiskt.
- Felaktigt urval ger FOUC, så testa alltid på riktiga enheter.
Vad tekniken faktiskt är
När en webbläsare bygger en sida behöver den både HTML och CSS innan den vågar rita ut något. Stilmallen räknas som en renderingsblockerande resurs: webbläsaren vill inte visa text som strax hoppar runt när stilarna anländer, så den väntar. Med en enda stor fil betyder det att allt måste hämtas och tolkas innan första pixeln ritas. Det är samma sorts flaskhals som du jagar i annat arbete med sidhastighet, och som ofta dyker upp först när du granskar en konkurrents sajt som laddar snabbare än din.
Critical CSS bryter det mönstret genom att dela stilkoden i två delar. Den kritiska delen är allt som behövs för det område som syns utan att besökaren scrollar, alltså typsnitt, färger och layouten för header och den första rubriken, och den läggs inline i <head>. Resten laddas via en länk, men på ett sätt som inte blockerar. Den här prioriteringen liknar hur du tänker när du planerar innehåll: det viktigaste först, resten sedan.
Det här hänger ihop med begreppet “above the fold”, det som ryms på skärmen innan man scrollar. Innehållet där är det enda besökaren ser i den första kritiska sekunden, så det är också det enda som verkligen behöver stilas omedelbart. Att första intrycket sätts direkt märks även i din klickfrekvens, alltså CTR, och i hur Google bedömer trovärdighet via E-E-A-T.
Vanlig CSS, alltså den fullständiga stilmallen, innehåller däremot alla regler för hela sajten, medan det kritiska urvalet bara är ett litet, sidspecifikt utdrag ur den. Skillnaden i praktiken handlar om var koden ligger och när den laddas:
- Den fullständiga mallen ligger ofta i en extern fil som måste hämtas innan rendering.
- Det kritiska urvalet ligger inline i HTML-dokumentet och är redan på plats.
- Den fullständiga mallen täcker hela sidan, även det du aldrig ser.
- Det kritiska urvalet täcker bara den synliga delen vid laddning.
- Den fullständiga mallen blockerar rendering, det inline-lagda urvalet gör det inte.
De ersätter inte varandra. Det kritiska urvalet visar sidan snabbt, sedan tar den fullständiga filen över och stilar allt det andra när man scrollar. Webbläsarens väg från HTML till färdig sida kallas den kritiska renderingsvägen, och poängen är att korta den vägen genom att ta bort ett av stoppen. Resultatet märks tydligast i FCP, First Contentful Paint, som mäter hur snabbt det första innehållet dyker upp och ingår i Core Web Vitals, alltså värden Google bryr sig om. Du kan följa de värdena över tid i Google Search Console, och de väger in i samma helhetsbild som strukturerad data och backlinks bygger upp.
Poängen är inte att ladda mindre stilkod totalt, utan att ladda rätt kod först. Allt det andra får komma när det väl behövs.
Varför det spelar roll för hastighet och SEO
En snabb sida påverkar både hur länge besökare stannar och hur Google bedömer din sajt, och långsam laddning är en av de vanligaste anledningarna till att folk lämnar innan sidan ens visats. Tekniken attackerar just den första, mest synliga delen av laddningen, men det är värt att vara ärlig med vad du faktiskt får ut av den. Hastighet är en pusselbit bland flera; den samspelar med innehållsstrategin, med hur sidan konverterar och med hur du ligger till mot konkurrenterna.
Förbättringen ligger främst i hur snabbt sidan känns, alltså FCP och den upplevda laddningstiden. Den fixar varken tung JavaScript, långsam serverrespons eller ostyrda bilder. Mätvärden som FID, First Input Delay, eller INP, som handlar om hur snabbt sidan svarar på klick och input delay, påverkas inte direkt av stilstrategin, utan styrs fortfarande av din JavaScript. Effekterna du rimligen kan vänta dig ser ut så här:
- Snabbare FCP, eftersom det första innehållet ritas utan att vänta på en extern fil.
- Lägre risk att besökaren möts av en vit skärm på långsamma nät.
- En jämnare upplevd laddning på mobil, där uppkopplingen ofta är sämre.
- Ett litet plus i Core Web Vitals, en signal bland många i Google.
Studier av användarbeteende brukar visa att de allra första sekunderna är avgörande för om någon stannar, och en snabbare sida hänger ofta ihop med bättre konvertering på sajten. En lägre tröskel att stanna kvar påverkar i sin tur ofta din CTR och hur väl sidan presterar i bredare arbete med sidhastighet. Tänk på den som ett sätt att städa undan en flaskhals, inte som en mirakelkur. En sida med flera sekunders serversvar blir inte snabb bara för att stilkoden ligger inline — då handlar det snarare om grundläggande WordPress-optimering eller serverval.
NINJA-FAKTA
Det första intrycket av hastighet sätts ofta inom den första sekunden. Om besökaren ser text och layout direkt uppfattas sidan som snabb, även om bilder längre ner fortfarande laddas. Critical CSS köper dig just den sekunden, och den sekunden märks även i hur sidan konverterar.
Vanliga missförstånd
Tekniken låter enklare än den är, och några myter ställer till det. Den första är att den skulle minska mängden stilkod som laddas. Så är det inte. Lika mycket laddas totalt, men det viktigaste flyttas fram och resten skjuts till bakgrunden. Det är samma missuppfattning som när folk tror att backlinks handlar om antal snarare än kvalitet, eller att E-E-A-T är en enskild knapp man trycker på.
En annan vanlig idé är att urvalet genereras en gång och sedan är klart. I verkligheten är det kopplat till din design. Ändrar du layouten ovanför vikningen, byter typsnitt eller flyttar en knapp, så stämmer inte längre det inline-lagda urvalet, och då måste det genereras om innan sidan börjar se konstig ut. Det är ett underhåll som hör ihop med löpande WordPress-optimering och med att du bevakar din sajt i Search Console.
VANLIG MISS
Många tror att FOUC, Flash Of Unstyled Content, alltid betyder att det kritiska urvalet är trasigt. Det är ofta tvärtom: FOUC uppstår när du laddar den vanliga stilmallen asynkront utan att lägga rätt regler inline. Saknas en viktig regel i urvalet, blinkar sidan till i ostilad form innan den riktiga koden kommer. Lösningen är inte att slopa tekniken, utan att se till att urvalet faktiskt täcker allt synligt — testa gärna i samband med ditt övriga sidhastighetsarbete.
Ett tredje missförstånd är att tekniken gör samma sak som ett CDN. Det stämmer inte. Ett CDN flyttar dina filer närmare besökaren och kortar nätverksfördröjningen, men en extern stilfil blockerar fortfarande rendering tills den hämtats. Det inline-lagda urvalet löser blockeringen, ett CDN löser avståndet, och de jobbar bäst tillsammans. Samma sak gäller strukturerad data: den löser ett annat problem än hastighet, men ingår i samma helhet.
Så gör du i praktiken
Du behöver sällan skriva ut det kritiska urvalet för hand. Det vanliga är att låta ett verktyg analysera sidan, identifiera vad som syns ovanför vikningen och plocka ut just de reglerna. Sedan läggs resultatet inline och resten laddas asynkront. Innan du börjar lönar det sig att ha koll på din nuläge via Search Console och din innehållsstrategi, så att du vet vilka sidor som är värda att snabba upp först. Grovt ser arbetsgången ut så här:
- Generera urvalet för en specifik sida med ett verktyg.
- Lägg in den genererade koden inline i sidans
<head>. - Ladda den fullständiga stilmallen asynkront så att den inte blockerar.
- Testa sidan på mobil och desktop och leta efter FOUC.
- Generera om när designen ovanför vikningen ändras.
Notera att urvalet i regel är sidspecifikt. Startsidan och en produktsida visar olika innehåll överst, så de behöver olika kritiska urval, och att återanvända startsidans urval på alla sidor är ett vanligt nybörjarfel. Det här gäller särskilt om du jobbar lokalt — en sida för SEO i Göteborg och en för SEO i Stockholm kan ha helt olika hjältesektioner överst.
Vilket verktyg som passar beror mest på plattformen. Bygger du själv finns Node-verktyget Critical, där funktionen critical.generate tar fram urvalet och fungerar fint ihop med ett byggsteg där du redan kompilerar Sass. Använder du WordPress kan du läsa mer i guiden om SEO för WordPress om hur prestanda hänger ihop med plattformen, och på WordPress slipper du i regel koden helt:
- WP Rocket genererar och lägger in urvalet automatiskt per sidtyp.
- Jetpack har en funktion för kritisk stilkod i sina prestandainställningar.
- Flera cache-plugins erbjuder samma sak som en kryssruta.
Det finns också online-baserade AI Tools och gratis generatorer som tar en URL och spottar ut ett urval, men kontrollera alltid resultatet. Automatiken är bra på enkla sidor och sämre på sidor där JavaScript ritar ut innehåll efter laddning. Det är samma nyans som gäller annan automatisering inom SEO — verktyg sparar tid, men du behöver fortfarande analysera konkurrenterna och tolka resultatet själv. Innan du publicerar lönar det sig att gå igenom en kort kontroll:
Verifiera ditt urval
Skillnaden mellan ett urval som hjälper och ett som ställer till det syns tydligt när man ställer dem mot varandra:
Bra hantering
Litet, sidspecifikt urval som täcker hela det synliga området. Den fullständiga koden laddas asynkront. Urvalet genereras om vid designändringar. Resultatet testas på riktiga enheter, gärna som en del av löpande sidhastighetsarbete.
Dålig hantering
Samma generella urval på alla sidor. Viktiga regler saknas, så sidan blinkar. Inline-kod som blivit så stor att HTML-dokumentet sväller. Inget test, bara förhoppning — precis tvärtemot hur du optimerar för konvertering.
De praktiska valen brukar landa i något av dessa lägen:
| Situation | Vad du gör |
|---|---|
| Liten sajt på WordPress | Slå på funktionen i WP Rocket eller Jetpack och testa |
| Egenbyggd sajt med byggsteg | Generera med Critical eller critical.generate, lägg inline |
| Tung sida med mycket JavaScript | Generera per sida och granska resultatet extra noga |
Vill du gräva djupare i hur laddningstid påverkar din synlighet hänger den här tekniken tätt ihop med bredare arbete för att optimera sidhastighet, och du kan följa upp effekten över tid med hjälp av Google Search Console när sidorna börjar indexeras och rankas. Jobbar du lokalt är det extra värt att snabba upp dina viktigaste landningssidor, oavsett om det gäller SEO i Umeå eller SEO i Västerås — en snabb sida hjälper dig att synas där dina kunder faktiskt söker.
Vanliga frågor
Vad är Critical CSS?
Det är den minsta mängd stilkod som behövs för att rita upp den del av sidan som syns direkt när besökaren landar, alltså innehållet ovanför vikningen. Koden läggs in rakt i sidans HTML så att webbläsaren kan visa något läsbart utan att först vänta på en separat fil. Resten av stilmallen hämtas i bakgrunden. Tekniken kortar tiden till första synliga innehåll och ger en snabbare upplevd laddning, framför allt på mobil och svaga nät.
Varför spelar det roll för SEO?
Sidhastighet påverkar hur länge folk stannar och hur Google bedömer sajten. Tekniken förbättrar främst FCP, alltså hur snabbt det första innehållet ritas upp, vilket ingår i Core Web Vitals. En snabbare sida ger ofta lägre avvisningsfrekvens och en bättre upplevelse på mobil. Det är ingen genväg till förstaplatsen, men det tar bort en av de vanligaste flaskhalsarna: att hela sidan står tom medan en stor stilmall laddas ner och tolkas.
Hur tar jag fram den?
Ett verktyg analyserar vad som syns ovanför vikningen och plockar ut just de reglerna. Node-verktyget Critical och funktionen critical.generate är vanliga val, och i WordPress sköter plugins som WP Rocket och Jetpack det automatiskt. Verktyget skapar en liten stilsträng som läggs inline i sidans head, medan den fullständiga mallen laddas asynkront efteråt. Kontrollera alltid resultatet i webbläsaren, eftersom automatiken ibland missar element på sidor med mycket JavaScript.
Kan tekniken orsaka problem?
Ja, om urvalet är felaktigt genererat. Ett vanligt problem är FOUC, alltså att sidan blinkar till i ostilad form innan den riktiga stilmallen hinner ladda, vilket händer när en viktig regel saknas inline. Inline-kod gör också HTML-dokumentet större, så på sidor med tung design kan vinsten ätas upp. Urvalet behöver dessutom uppdateras när designen ändras, annars stämmer det inte längre. Testa därför på riktiga enheter innan du publicerar.
Relaterade termer
VILL DU FÖRSTÅ MER?
Undrar du hur det funkar i praktiken för just din sajt? Hör av dig.