Hurtigere WordPress: billeder, CSS og JavaScript

Hvad måler Google: Core Web Vitals

Google måler brugeroplevelsen med tre tal, og de er et godt udgangspunkt for at prioritere:

Grænseværdierne kommer fra Googles dokumentation på web.dev. De måles på rigtige besøgende, så en side kan score fint på din egen computer og stadig være langsom for kunder på mobil.

Billeder: det største og letteste sted at starte

På forsider er billeder typisk den største del af det, der skal hentes¹, og derfor giver billedoptimering ofte mest for mindst arbejde. Start med formatet. WebP og AVIF giver markant mindre filer end JPEG og PNG ved samme kvalitet², alle moderne browsere understøtter dem, og WordPress kan håndtere begge, hvis serveren kan. Et optimeringsplugin eller dit CDN kan konvertere eksisterende billeder og sende det bedste format til hver browser.

Dernæst størrelsen. Et billede på 4.000 pixels i bredden, der vises i 800, spilder båndbredde. WordPress laver selv flere størrelser af hvert billede og lader browseren vælge den mindste, der passer, men kun hvis temaet bruger WordPress’ egne billedfunktioner. Upload aldrig billeder direkte fra kameraet.

Lazy loading er den tredje brik: WordPress venter med at hente billeder længere nede, til de er ved at komme ind på skærmen. Det er godt, men ikke for det øverste billede. Hero- eller produktbilledet øverst er typisk sidens LCP-element og skal hentes med det samme, gerne med høj prioritet. WordPress forsøger selv at gøre det rigtigt, men sidebyggere og temaer kan ødelægge det, så tjek det i browserens udviklerværktøjer. Og sørg for, at alle billeder har mål, så der er reserveret plads til dem, og teksten ikke hopper, når de kommer.

CSS: få siden vist, før alt er hentet

Browseren viser ingenting, før alle stylesheets i <head> er hentet og læst. Mange WordPress-sider indlæser CSS fra temaet, sidebyggeren og hvert eneste plugin på alle sider, også der, hvor pluginet slet ikke bruges.

Critical CSS

Critical CSS er den lille del af din CSS, der skal til for at vise det, man ser uden at scrolle. Den lægges direkte i <head>, mens resten hentes uden at blokere, så siden kan vises med det samme. Den genereres næsten altid af et værktøj eller et performanceplugin, fordi den er forskellig fra skabelon til skabelon. Test grundigt bagefter: forkert critical CSS giver et kort glimt af ustylet indhold.

Indlæs kun det, siden bruger

Den største gevinst er ofte at fjerne CSS, der ikke bruges. Et kontaktformular-plugin behøver ikke sit stylesheet på produktsiderne. Nogle plugins kan slå det fra selv, ellers kan et asset-manager-plugin fjerne filer per side, eller du kan gøre det i temaet:

add_action( 'wp_enqueue_scripts', function () {
    // Kun på kontaktsiden
    if ( ! is_page( 'kontakt' ) ) {
        wp_dequeue_style( 'contact-form-7' );
    }
}, 20 );

Minificering er næsten altid en fordel, men at samle alt i én stor fil er det ikke længere. Med HTTP/2 kan browseren hente mange filer parallelt, og en kæmpe fil skal hentes igen, hver gang en lille del ændrer sig. Læs mere om, hvad HTTP/3 ændrer for din sides hastighed.

JavaScript: mindre, senere og kun hvor det skal bruges

JavaScript er dyrere end billeder byte for byte, fordi browseren ikke kun skal hente det, men også fortolke og køre det (på engelsk), og mens den gør det, kan siden ikke reagere på klik (på engelsk). Tung JavaScript er derfor en typisk årsag til en dårlig INP. Er du ikke udvikler, så start med vores introduktion: JavaScript forklaret for hjemmesideejere.

Async og defer

Et almindeligt script i <head> stopper browseren, indtil det er hentet og kørt. Med defer hentes scriptet i baggrunden og køres først, når HTML’en er læst, i den rækkefølge scriptene står. Det er det sikre valg for de fleste scripts. Med async køres scriptet, så snart det er hentet, uanset rækkefølge, hvilket passer til selvstændige scripts som analyseværktøjer. Siden WordPress 6.3 kan du angive strategien direkte, og WordPress sørger selv for, at et script ikke bliver udskudt, hvis et andet script afhænger af det:

wp_enqueue_script(
    'mit-tema',
    get_theme_file_uri( 'assets/js/tema.js' ),
    array(),
    '1.0.0',
    array( 'strategy' => 'defer', 'in_footer' => true )
);

Indlæs kun scripts, hvor de bruges

Ligesom med CSS er den største gevinst at undgå scripts, der ikke bruges på siden. Brug wp_enqueue_script betinget med funktioner som is_product() eller has_block(), og fjern plugins’ scripts med wp_dequeue_script, hvor de ikke er nødvendige. Gå dine plugins igennem: hvert plugin, der tilføjer JavaScript til alle sider, koster lidt på hver eneste sidevisning.

Tredjepartsscripts

Chatbokse, sociale widgets, heatmaps og annoncescripts kan være blandt de tungeste scripts på en side, og du har ingen kontrol over dem. Spørg for hvert, om det er nødvendigt, og om det kan vente, til siden er vist eller brugeren interagerer. Nogle performanceplugins kan udskyde bestemte scripts, til brugeren scroller eller klikker.

Særligt for webshops

WooCommerce og dets udvidelser tilføjer scripts til kurv, variationer, betaling og sporing. Tjek, hvilke der indlæses på sider, hvor ingen handler, som blogindlæg, og vær forsigtig med at udskyde scripts i kurv og kasse. Test hele købsforløbet efter hver ændring.

Fonte

Hver vægt og stil af en webfont er en fil, der skal hentes, så hold det nede på et par vægte. Host fontene selv, så browseren ikke skal oprette en ekstra forbindelse, brug font-display: swap, så teksten vises med det samme, og preload kun de fonte, der bruges øverst på siden. En reservefont i samme størrelse forhindrer, at teksten hopper, når webfonten kommer.

Sådan måler du, om det virker

PageSpeed Insights viser både en laboratorietest og, hvis siden har nok trafik, Core Web Vitals fra rigtige brugere, og Search Console viser dem for hele sitet grupperet efter sidetype. Vil du se præcis, hvilke filer der hentes, og hvad der blokerer, er fanerne Network og Performance i browserens udviklerværktøjer det bedste sted. Mål før og efter hver ændring, test på mobil med begrænset forbindelse, og lav én ændring ad gangen, så du ved, hvad der hjalp.

Den rækkefølge vi ville gøre det i

1. Mål siden, og find LCP-elementet og de tungeste filer.
2. Optimer billeder: format, størrelse og lazy loading, men ikke på LCP-billedet.
3. Fjern CSS og JavaScript fra sider, hvor de ikke bruges, og fjern plugins, du ikke har brug for.
4. Sæt defer på dine egne scripts, og udskyd tredjepartsscripts.
5. Tilføj critical CSS, og test alle sidetyper.
6. Ryd op i fontene.
7. Mål igen, og gentag.

Ofte stillede spørgsmål

Hvorfor er min side langsom, selv om jeg har hurtig hosting?

Hosting afgør kun, hvor hurtigt serveren svarer. Skal browseren derefter hente flere megabyte billeder og køre tung JavaScript, bliver siden langsom alligevel.

Kan optimering ødelægge noget?

Ja. Udskudt JavaScript og forkert critical CSS er de typiske årsager til menuer, der ikke virker, og indhold, der blinker. Test efter hver ændring, og for en webshop altid hele vejen gennem kurv og betaling.

Vil du have hjælp?

Vi måler, finder flaskehalsene og retter dem i både front end, server og database, så din webshop bliver hurtig, uden at noget går i stykker. Få din webshop gjort hurtigere.

1. HTTP Archive, Web Almanac 2024, kapitlet Page Weight (på engelsk): den typiske forside på desktop henter 1.054 kB billeder og 613 kB JavaScript. På undersider er det omvendt, med 442 kB billeder og 627 kB JavaScript. ↩︎
2. Google, An image format for the Web (på engelsk): WebP uden tab er 26 % mindre end PNG, og WebP med tab er 25–34 % mindre end tilsvarende JPEG ved samme kvalitet. ↩︎