De seneste år har vi set folk i marketing sætte indlæsningshastighed øverst i ethvert optimeringsforløb. I 2017 begyndte Google at fremhæve hvor vigtig indlæsningshastighed er, og hvad den ville komme til at betyde for placeringerne, men det var først i sommeren 2018, at Google gjorde det officielt.
I artiklen her vil vi gerne hjælpe dig i gang med selv at optimere og forbedre indlæsningshastigheden på dit website. Som i ethvert optimeringsforløb er der en teknisk side, der kan blive kompliceret. Hos SEO Alive vil vi gerne, at du selv kan føre det ud i livet, når vi skriver den slags artikler, selvom nogle af handlingerne kræver et mere teknisk niveau. Men helt ærligt: lad os ikke gå amok i at jagte scoren i de værktøjer, vi bruger til at auditere vores sites WPO.
Optimeringen afhænger i høj grad af, hvordan skabelonen er designet, og ikke alle skabeloner giver den samme performance. Det er vigtigt at have med.
Så er det nu!
Hvad er WPO?
Web Performance Optimization, som vi kalder WPO, er ganske enkelt optimering af de forskellige processer, der har betydning for, hvordan et website loader.
Hvordan måler du et websites indlæsningshastighed?
Der findes masser af værktøjer til at måle indlæsningshastighed. De mest populære er:
Før du går i gang med en audit, er det vigtigt at have med, at indlæsningshastigheden er forskellig fra bruger til bruger. Forskellige variabler kan påvirke, hvordan hastigheden føles for en bruger i Cuenca i forhold til en i Ottawa.
Derfor anbefaler vi, at du frem for at arbejde med indlæsningstider i sekunder holder fokus på at optimere:
›
Websitets vægt (MB)
›
Kald
›
Serverens svartid
Forbedrer vi de 3 områder, bliver indlæsningshastigheden bedre, uanset hvor brugeren befinder sig.
Vi går ned i hvert område og ser gennem de forskellige værktøjer, hvordan vi kan arbejde med dem for at løfte performance på hver eneste URL. Hvorfor siger jeg hver eneste URL? Fordi jeg — selvom det virker indlysende — har set mange tilfælde, hvor kun tallene for forsiden blev vurderet, og alle sider på et site loader selvfølgelig ikke de samme ressourcer.
Google Developer Tools
Før vi går i gang, vil jeg forklare nogle af de muligheder, Google giver gennem sine udviklerværktøjer. Det værktøj er et af de vigtigste til at analysere, hvordan et website virker. Højreklik på den side, browseren har åben, og der dukker et panel op med forskellige muligheder. Vi går til Inspect (Ctrl + Shift + I).
Når værktøjet er åbent, går vi til NETWORK øverst. Trykker vi ENTER igen i browseren, viser værktøjet indlæsningen af de forskellige ressourcer.
indlæsningstid i Googles udviklerværktøjer
Nederst på billedet kan vi se de tal, der interesserer os, når vi vil have et samlet billede af, hvordan sitet loader.
Går vi videre ned i panelet fra toppen og ser på kolonnerne, har vi:
›
Name: ressourcens navn.
›
Status: ressourcens svarkode (200, 301, 404...)
›
Type: ressourcens type (script, font, png, jpg, stylesheet...)
›
Initiator: hvilken ressource udløser kaldet.
›
Time: hvor lang tid kaldet tog.
›
Waterfall: en grafisk fremstilling af en ressources indlæsningstider.
Højreklikker vi øverst, kan vi lægge kolonner med de oplysninger til og fra.
tilføje og fjerne informationselementer i network
At slå ekstra informationselementer til som Domain, Scheme eller Cookies kan i bestemte tilfælde hjælpe os med at finde ressourcer, der giver os problemer, men her holder vi os til dem, der er slået til på forhånd.
Der er én ting, som jeg — selvom den er meget interessant — kun lige strejfer, så vi har den med. Forbindelseshastigheden, især på mobil, er en helt central del af, hvordan et site loader. Fra værktøjet her kan vi simulere langsommere hastigheder som 3G på mobil.
simulere en langsom overførselshastighed
Hvordan finder du en URL's vægt, og hvordan skærer du den ned?
Vægten, om det så er i megabyte eller kilobyte, er en af hovedgrundene til, at en URL er lang tid om at loade. Derfor starter vi med at gå ned i den del, for den lægger sporet ud til en god optimering af vores site.
De følgende tal kommer fra værktøjet ovenfor, GTMETRIX, og hører til et website, jeg er ved at gå i gang med at optimere.
tal for et websites vægt
Vi holder fokus på tallene i højre kolonne, den der handler om (Page Details), nærmere bestemt Total Page Size.
Ved første øjekast ligger sitets vægt et godt stykke over gennemsnittet, men husk, at det afgørende ikke er sitets samlede vægt, men hvor lang tid den vægt er om at loade, for der findes noget, der hedder Lazy Load — en funktion, der udskyder indlæsningen, til brugeren har brug for ressourcen. Det vender vi tilbage til.
Vi kan også finde oplysningerne i udviklerværktøjerne, i det panel vi så på ovenfor, og som jeg lige minder om igen.
indlæsningstid i Googles udviklerværktøjer
Kigger du nederst, ligger både de 7.5 MB og de 215 kald meget tæt på de tal, GTMETRIX melder. Det er vigtigt, at du ved, hvor GTMETRIX henter sine oplysninger, hvis du en dag vil bruge et andet værktøj.
Lad os nu se, hvad der vejer så meget, og hvordan vi retter op på det.
Waterfall-visningen giver et visuelt billede af, hvordan ressourcerne loader, med ressourcens URL, status, domæne og kolonnen Size. Klikker vi på den sidste kolonne, bliver vægtene sorteret fra størst til mindst og fra mindst til størst.
analyse af indlæsningen gennem waterfall
Ser vi på vægtene, kan vi konstatere — som i de fleste tilfælde — at billederne i høj grad står bag URL'ens store vægt.
Der findes ingen formel specifikation for, hvor meget et billede højst må veje, men vi anbefaler ikke mere end 100 KB, og har du muligheden (og det har du, hvis du bruger Photoshop), så sæt billederne til at loade progressivt som JPG, og undgå PNG, når du ikke har brug for en alfakanal (gennemsigtighed).
Skærer vi ned på billedernes vægt, løfter vi sitets indlæsning markant, og der findes flere værktøjer, du kan bruge. Selv optimerer jeg i Photoshop, men der er interessante muligheder online:
Både GTMetrix og Googles værktøj lader os se ressourcerne efter type, altså kun billeder, scripts, CSS...
Det er nyttigt til et bredere blik på, hvor vi skal sætte ind. På den her URL står billederne for 4 MB ud af 7.2 MB, så en stor del af vægtproblemet ligger der. Alligevel er der andre ressourcer, der falder i øjnene som ekstremt tunge for deres type, som en CSS-fil på over 700 KB og et script på over 300 KB.
Her vil jeg gerne slå fast, at når vi laver en optimering af indlæsningshastighed (WPO), støder vi ind i bestemte problemer, som godt nok har løsninger, men som ikke er inden for vores rækkevidde at gøre noget ved.
I det her tilfælde ser vi en meget stor CSS-fil. Har designeren lavet en CSS på over 700 KB, bliver det svært at optimere netop den fil.
Hvad kan vi gøre for at skære ned på vægten af de filer?
Minificering (CSS, JS og HTML)
Minificering er en proces, der skal skære ned på filernes vægt ved at fjerne unødvendige data som kommentarer, mellemrum, gentaget kode og ubrugt kode. Der findes mange værktøjer til processen, bortset fra delen med ubrugt kode, som er sværere at optimere og ville kræve, at man gik manuelt ind i filen (noget jeg ikke anbefaler).
Heldigvis taler vi om WordPress, og som alle ved, er det meget sjældent i WordPress ikke at finde et plugin, der klarer den opgave.
Selv kan jeg godt lide at bruge et helt gratis et, Autoptimize, og et betalt, WP Rocket.
I artiklen her vil jeg ikke så meget forklare, hvordan de plugins virker, som hvordan man udfører opgaverne med optimering. For bruger vi andre plugins, har de også de muligheder, og det bedste er at forstå, hvad vi laver.
Minificering med WP Rocket
Den del er ikke svær. Vi går bare ind på fanen med filoptimering og sætter flueben i feltet minify HTML. I WP Rocket bliver den mulighed gentaget nedenfor for CSS- og JS-filer. Jeg anbefaler alligevel, at du slår feltet til og tester. Gentag muligheden én ad gangen, for går noget galt, er det lettere at finde ud af hvad.
minificer html med wp rocket
Før vi tjekker effekten af minificeringen, skal vi rydde cachen, ellers ser vi ikke resultatet af den opdaterede HTML.
Hvordan rydder du browserens cache?
Den slags plugins kommer med muligheder for at rydde cachen, som vi kan se øverst.
ryd cachen med wp rocket
En anden vej er gennem browseren, når Google Developer Tools er slået til (Ctrl + Shift + I).
Højreklik på pilen »genindlæs siden«, og vælg »empty cache and hard reload«.
rydning af cachen fra Chrome-browseren
Minificering med Autoptimize
I Autoptimize er det optimize-handlingen, der står for minificeringen, med den særhed, at den giver mulighed for at beholde HTML-kommentarer. De kommentarer bliver som regel lagt ind af udviklere for at gemme information, der kan være nyttig i fremtiden.
minificer html med autoptimize
For at tjekke, at optimeringen har haft effekt, går vi ind i URL'ens kildekode og bør se noget i retning af det her:
eksempel på minificeret html
Koden bliver ulæselig, men den virker på samme måde.
De muligheder gentager sig på samme måde i WP Rocket og Autoptimize for CSS- og JS-filer. Som jeg nævnte tidligere, anbefaler jeg ikke at optimere det hele på én gang, men 1 for 1. De plugins gemmer kopier af de minificerede filer, så det er muligt at gå tilbage til originalen ved at fjerne fluebenet i det tilhørende felt.
For at skære endnu mere af sidens vægt har vi 2 muligheder mere:
›
Fjern eller skær ned på plugins, der lægger CSS eller JS til indlæsningen.
›
Fjern eller trim ubrugt kode i CSS-filen.
De 2 muligheder er mere komplekse og kræver mere viden, for du skal være forsigtig og sikre dig, at der ikke er kald fra andre sider til den del, du fjerner.
Det er ikke altid muligt at fjerne plugins på grund af det, de leverer, men nogle plugins er bedre optimeret end andre, altså færre kald og lettere JS. Så i det vidunderlige WordPress-økosystem findes der næsten altid et alternativ.
Indlæsningstid vs. svartid
Nu er det tid til at tale om kald, svartid og indlæsningstid. Her skal vi nævne en helt central del af processen: serveren. Optimering af serveren ligger som regel uden for vores hænder, så det er vigtigt at vælge en effektiv løsning.
Men lad os tage det skridt for skridt.
Hvad er et kald?
Et kald, eller HTTP Request, er et opkald fra klienten til serveren om at få en bestemt ressource. Kald kan ramme forskellige servere.
Kald kan være enten HTTP eller HTTPS. Ser vi på strukturen i et kald, kan vi analysere, hvor forsinkelsen i tid opstår.
Analyse af tiden i et HTTP-kald
strukturen i et HTTP-kald
Lad os bryde ned, hvad vi ser i det tidsdiagram.
›
Kaldet er startet, men blokeret eller sat i kø: Varer blokeringen længe, kan det skyldes flere ting: kald med højere prioritet eller mange kald til den samme kilde.
›
DNS Lookup: browseren er ved at finde kaldets IP-adresse.
›
Connecting: den tid, det tager at få forbindelse til serveren for at afvikle kaldet. Er tiden høj, kan det tyde på problemer med netværket, fejl i forbindelsen eller en overbelastet server.
›
Sending: kaldet om ressourcen bliver sendt.
›
Waiting: det er den tid, serveren er om at afvikle et kald og sende et svar; er den lang, er der et problem på serveren.
›
Receiving: modtagelse af ressourcen.
Et HTTPS-kald lægger endnu et trin til, og det ser du her.
analyse af et HTTPS-kald
De to skærmbilleder hører til to forskellige sites, et uoptimeret (HTTP Request) og et optimeret (HTTPS Request).
Ser du godt efter og sammenligner, ligger den største forskel i ventetiden. I de tilfælde skal du analysere serveren nærmere.
Kald til serveren: hvordan skærer vi ned på dem?
Som vi har set, hænger antallet af kald tæt sammen med indlæsningstiden, så færre kald ville forbedre en URL's indlæsningstider. Sund fornuft spiller en rolle i optimeringsforløbet, og det gør det også at vide, om en ressource reelt er nyttig for brugeren eller vores forretning. Det er her, vi siger farvel til bestemte ressourcer, der ikke bidrager med noget, men det er ikke mig, der skal afgøre det.
Vi har alligevel muligheder for at forbedre kaldene, selvom de handlinger ikke giver et kæmpe udslag på sitets indlæsning. Jeg gentager mig selv: det bedste er at fjerne ressourcer, der ikke bidrager med noget.
Kombiner CSS og JS
En anden populær handling, når man optimerer en webside, er at kombinere CSS- og JS-ressourcer, men hvad betyder det?
Målet med at kombinere er at skære ned på antallet af kald på bekostning af større filer. At kombinere vil sige at samle de forskellige CSS- eller JS-ressourcer i én.
Er svartiderne lange, kan det være en fordel at kombinere. Er sendetiderne meget langsomme, er en anden teknik måske bedre.
Det ideelle er at kombinere og samtidig have en god server, så vi vinder på begge sider.
Kombinering af ressourcer med WP Rocket og Autoptimize
At kombinere med de plugins er lige så enkelt som før. Vi sætter bare flueben i det tilhørende felt.
kombiner css i wp rocket
I WP Rocket er mulighederne for at kombinere CSS og JS de samme; panelerne er stort set identiske. Som vi ser på billedet, er der et felt til at lægge stien ind til de filer, vi ikke vil kombinere.
Autoptimize giver flere muligheder for at arbejde med CSS og skære ned på kaldene. I den mulighed, jeg markerer, kombinerer den og advarer dig om, hvad det kan betyde, men i sidste ende er det altid relativt.
I den første del af artiklen her ville jeg forklare, hvad bestemte grundlæggende handlinger går ud på — dem vi ser i stort set alle plugins til WPO-optimering — men der er stadig meget, vi kan gøre for at forbedre både kald og indlæsningstider.
Opsætning af cache
Optimering af cachen er uden tvivl en af de handlinger, hvor vi mærker de største forbedringer i, hvordan et site loader. I den her artikel om SEO til WordPress forklarede jeg, hvordan cachen virker. Jeg vil opfordre dig til at kigge forbi og få styr på, hvordan den fungerer.
Autoptimize og WP Rocket laver handlinger med cachen, men WP Rocket giver dig et par muligheder mere. Det er værd at bemærke, at plugins har gjort den optimering enklere: du har knap nok et par valg, og processen er hurtig og smertefri.
sæt wp rocket op
Som du ser, lader WP Rocket dig arbejde med 4 ting:
›
Slå cache til for mobile enheder.
›
Gemme filer for sig til mobile enheder.
›
Slå cache til for brugere, der er logget ind.
›
Angive tidspunktet for rydning af cachen.
Det afhænger af det enkelte projekt, hvilken mulighed du skal vælge, men med alt det i baghovedet er mit råd:
›
Cache på mobil altid, for selvom de fleste sites er responsive, er der indhold, du måske har på mobil, men ikke på desktop.
›
Filer for sig.
›
Ingen cache for brugere, der er logget ind, mest fordi jeg ikke vil have cache, når jeg sidder og retter.
›
Cachetid, som afhænger af, hvor mange ændringer du laver på dit site. Er det et nyhedssite med daglige opdateringer, så kort; er det indhold, der ikke bliver opdateret så tit, så længere.
Lazyload
Funktionen lazyload hjælper med at vise ressourcer (billeder og iframes), når brugeren har brug for dem — altså loader browseren ikke de ressourcer, før brugeren scroller ned til dem. Funktionen er bygget ind i mange plugins og er endda sat op på forhånd i nogle WordPress-temaer. Fra Chrome version 76 og frem findes den endda indbygget i browseren.
Det vil sige, at browseren allerede tolker billedets lazy loading, når du lægger attributten loading="lazy" ind, men det er selvfølgelig ikke alle browsere, der tolker det, så jeg anbefaler, at du bliver ved med at bruge pluginnet. Her er en video hentet fra web.dev, der viser et eksempel på, hvad lazy loading af billeder går ud på.
Optimering af iframes
Bruger vi iframes til at indlejre indhold fra andre sites, har vi to handlinger, vi kan bruge til at forbedre vores indlæsning.
›
Lazy loading via funktionen lazyload
›
Eller at erstatte iframen med et billede, indtil brugeren klikker på det.
Både den første og den anden mulighed kan slås til gennem — endnu en gang — vores foretrukne plugin WP Rocket.
Udskudt indlæsning af JS-filer med Defer eller Async
JS-filer er en af synderne bag det, hastighedsaudits kalder render blocking af en side. Det sker, når browseren midt i renderingen stopper op for at hente en JS-fil og køre den. Målet med WPO-optimering er at levere information til brugeren så hurtigt som muligt, og derfor bliver det regnet for blokerende, for der bliver ikke renderet noget, før den hentede JS bliver kørt.
Derfor bliver den slags typisk markeret i auditten. Bruger vi plugins eller temaer fra tredjepart, der ikke er godt optimeret, kan vi have JS, der blokerer renderingen, fordi den for eksempel ligger i headeren.
I de tilfælde bør vi bruge to attributter, der bliver lagt ind i koden, der kalder JS'en: Defer og Async. For at de attributter virker, skal scriptsene være eksterne.
Hos SEO Alive bruger vi pluginnet Pre Party Resource Hints, hvor du kan vælge, hvilke filer og hvilken indlæsningsmetode du vil bruge. En perle!
Hvad er forskellen på Defer og Async?
Selvom begge attributter har et lignende mål — at forhindre, at JS'en stopper tolkningen af DOM-HTML'en — er der en markant forskel på dem.
Med attributten Async bliver ressourcen hentet, uden at indlæsningen af HTML'en stopper, men når den er hentet, bliver indlæsningen af HTML'en sat på pause for at køre JS'en; med attributten defer bliver ressourcen også hentet parallelt med indlæsningen af HTML'en, men den kører, når indlæsningen er færdig, så scriptet blokerer ikke.
På det punkt er der forskel på WP Rocket og Autoptimize. WP Rocket gør valgene meget lettere for dig og går semi-automatisk til værks for at holde JS fra at blokere renderingen; i Autoptimize kan du derimod kun slå Async til og fra.
I Autoptimize har vi under fanen extra den mulighed for at lægge de JS-filer ind, vi vil loade med Async, men for at få mere fleksibilitet anbefaler de et andet supplerende plugin, »Async Javascript«.
async-indlæsning autoptimize
Med det plugin kan vi arbejde med både Defer og Async, og det giver endda muligheder med ét klik, så det bliver lettere. Det gode ved pluginnet er, at vi kan arbejde med scripts og holde dem ude, vi mener skal holdes ude. I WP Rocket skal vi derimod stole på det, pluginnet gør, men det gør det godt.
Muligheden ligger på den samme fane med filoptimering.
attributten defer wp rocket
Hvad er et CDN, og hvordan kan det hjælpe os?
Et CDN er det, man kalder et content delivery network. CDN'et står for at gemme en del af informationen og ressourcerne for at lette serverens belastning for de ressourcer og svare bedre på indlæsningen. CDN'er har også en funktion med geografiske kopier, så ressourcen ligger klar flere steder og bliver leveret til brugeren, uanset hvor vedkommende går på fra. Den slags service bliver som regel brugt til tunge filer som billeder og videoer.
At tegne den service er vigtigt, når vi har sites med meget trafik, men den bør ikke afvises til sites med lidt trafik.
Andre handlinger, der giver os lidt mere
Som afslutning på artiklen har vi 3 forbedringer mere, som ganske vist ikke giver store udslag i indlæsningstiderne, men som hjælper os med at skære ned på antallet af kald, og det er jo det, vi vil.
Optimering af skrifttyper
Optimering af skrifttyper kan gøres gennem plugins eller manuelt ved at redigere og optimere CSS'en. Det ideelle ville være kun at kalde den skrifttype, du skal bruge, og ikke — som det sker i mange tilfælde — hente en fil med alle Google Fonts.
Autoptimize har en mulighed for at arbejde med skrifttyper.
optimer skrifttyper med autoptimize
Det er svært at sige, hvilken mulighed du skal vælge, uden at se projektet, for jeg ved ikke, hvilken skrifttype din skabelon bruger, og hvornår den loader, så det bedste er at teste og se resultatet.
Som du ser, har vi lige efter mulighederne for Google Fonts »Remove Emoji«, som sparer os et kald til serveren. Funktionen er ganske enkelt at lave de symboler, der står for emojis, om til ikonet.
emojis wp rocket
WP Rocket lader os også slå de emojis fra og giver desuden mulighed for at forhindre, at indhold bliver indlejret på tredjeparters sites.
I sidste ende er der mange handlinger, der kan løfte et sites indlæsningshastighed. Det er ikke altid muligt at gå i dybden med at optimere hver eneste ressource, for det afhænger af, hvilken type forretning det er, og hvad den har brug for.
Jeg håber, at guiden til WPO-optimering er til nytte, og at du kan bruge den i dine egne projekter eller for dine kunder.
Jeg har brugt de sidste 10+ år fuldstændig opslugt af SEO — og helt ærligt: jeg ville ikke have det anderledes.
Min karriere rykkede et niveau op, da jeg arbejdede som senior SEO-specialist for Chess.com — et af de 100 mest besøgte websites på hele internettet. At arbejde i den skala, på tværs af millioner af sider, snesevis af sprog og en af de mest konkurrenceprægede SERP'er der findes, lærte mig ting, som intet kursus og ingen certificering kunne have lært mig. Den erfaring ændrede mit syn på, hvordan rigtig godt SEO ser ud — og den blev fundamentet for alt, hvad jeg har bygget siden.
Ud af det grundlagde jeg SEO Alive — et bureau for brands, der mener det alvorligt med organisk vækst. Vi er ikke her for at sælge dashboards og månedsrapporter. Vi er her for at bygge strategier, der rent faktisk flytter noget, og vi kombinerer det bedste fra klassisk SEO med den spændende nye verden inden for Generative Engine Optimization (GEO) — så dit brand ikke kun dukker op i Googles blå links, men også inde i de AI-genererede svar, som ChatGPT, Perplexity og Google AI Overviews leverer til millioner af mennesker hver eneste dag.
Og fordi jeg ikke kunne finde et værktøj, der håndterede begge verdener ordentligt, byggede jeg selv et — SEOcrawl AI, en enterprise-platform til SEO-intelligens, der samler placeringer, tekniske audits, backlink-overvågning, crawl-sundhed og tracking af brandets synlighed i AI ét sted. Det er den platform, jeg altid ønskede fandtes.
