En langsom hjemmeside kan skyldes et billede på 4 MB.
Det kan også være serveren, der bruger to sekunder på at svare. Et script fra et statistikværktøj. Et plugin, der laver alt for meget arbejde. En databaseforespørgsel, der burde tage 20 millisekunder, men tager halvandet sekund.
Eller lidt af det hele.
Når nogen fortæller mig, at deres hjemmeside er langsom, er mit første spørgsmål derfor normalt ikke, hvad den er bygget i.
Jeg måler den.
Ellers risikerer man at bruge en halv dag på at optimere billeder på et website, hvor problemet i virkeligheden ligger et helt andet sted.
Hvad betyder langsom?
Det er faktisk det første, man skal finde ud af.
Er det den første side, der tager lang tid om at komme frem? Er siden synlig hurtigt, men reagerer langsomt, når man klikker? Hopper indholdet rundt, mens siden loader? Er det kun produktsiderne? Kun på mobil? Kun for brugere, der ikke er logget ind?
Eller føles hele sitet bare tungt?
De symptomer kan have meget forskellige årsager.
En langsom server kan betyde, at browseren står og venter, før den overhovedet får noget at vise. Et stort billede kan betyde, at siden begynder hurtigt, men bruger lang tid på at få det vigtigste indhold på plads. For meget JavaScript kan betyde, at alt tilsyneladende er hentet, mens browseren stadig står og arbejder.
Derfor er "langsom" ikke præcist nok til at begynde at optimere efter.
Jeg begynder med målingen
Lighthouse og PageSpeed Insights er ofte fine steder at begynde.
Men jeg bruger dem som diagnoseværktøjer, ikke som facit.
Jeg vil blandt andet vide, hvor lang tid serveren er om at svare. Hvilke filer browseren henter. Hvor store de er. Hvornår det vigtigste indhold bliver synligt. Hvad der blokerer browseren undervejs. Og hvad der sker ude hos rigtige brugere.
Har sitet trafik nok, foretrækker jeg feltdata.
En laboratorietest fortæller, hvad der skete under én kontrolleret test. Feltdata fortæller, hvad der faktisk sker på telefoner, computere og netværk ude hos brugerne.
De to ting er ikke altid enige.
Billeder er stadig en klassiker
Jeg møder stadig websites, hvor et billede bliver vist i 600 pixels bredde, men browseren får tilsendt en original på 4.000 pixels.
Det er sjældent nødvendigt.
Billeder skal have fornuftige dimensioner, komprimeres ordentligt og leveres i et format, browseren kan håndtere effektivt. Og billeder længere nede på siden behøver normalt ikke blive hentet, før brugeren nærmer sig dem.
Men billedoptimering er også et godt eksempel på, hvorfor man skal måle først.
Hvis billederne allerede er rimeligt optimerede, får man ikke meget ud af at bruge tre timer på at presse yderligere 30 KB ud af dem.
Der er ingen gevinst i at optimere det forkerte problem meget grundigt.
JavaScript har en pris
Det moderne web kan utrolig meget.
Det betyder også, at vi sender utrolig meget kode ned i browseren.
Analytics. Cookie consent. Chat. Tracking. Video. Annoncer. A/B-tests. Formularværktøjer. Sociale medier. Marketing automation.
Hver enkelt integration kan være fuldstændig legitim.
Men browseren er ligeglad med organisationsdiagrammet. Den skal stadig hente og afvikle det hele.
Jeg vil derfor ofte hellere finde ud af, hvorfor et script er på siden, end spare nogle få kilobytes i en CSS-fil. Hvis ingen længere ved, hvorfor et tredjepartsscript bliver indlæst på samtlige sider, er det værd at undersøge.
Det hurtigste script er trods alt det, browseren aldrig behøver at hente.
Nogle gange ligger problemet på serveren
Man kan optimere frontend nok så meget, men hvis serveren bruger lang tid på at fremstille siden, begynder man allerede bagud.
På et WordPress-site kan årsagen eksempelvis være plugins, tunge databaseforespørgsler, eksterne API-kald eller manglende caching. På en specialbygget løsning kan problemet være en forespørgsel, der henter langt mere data end nødvendigt, eller kode, der udfører det samme arbejde igen og igen. Og nogle gange er serveren ganske enkelt underdimensioneret eller dårligt konfigureret.
Her hjælper det ikke meget at konvertere endnu et billede til WebP.
Man er nødt til at finde flaskehalsen.
Caching kan gøre en enorm forskel
Hvis en side stort set er den samme for alle besøgende, er der sjældent nogen grund til at bygge den helt forfra ved hvert eneste besøg.
Det er grundidéen i caching.
Men caching findes i flere lag. Browseren kan gemme filer. En CDN kan levere dem tættere på brugeren. Webserveren kan cache hele sider eller dele af dem. Applikationen kan gemme resultater, som ellers skulle beregnes igen. Databasen kan undgå at blive spurgt om det samme hele tiden.
Det kan gøre en meget stor forskel.
Men caching kan også ende som et plaster på en løsning, der grundlæggende laver for meget arbejde. Hvis en databaseforespørgsel tager tre sekunder, vil jeg gerne vide hvorfor – også selv om vi bagefter cacher resultatet.
Plugins er ikke langsomme. Nogle plugins er.
På WordPress ender diskussionen hurtigt med antallet af plugins.
"Vi har 37 plugins," siger kunden som regel. "Er det derfor, sitet er langsomt?"
Måske.
Men 37 fortæller mig ikke ret meget i sig selv.
Et lille plugin kan lave én simpel ting og næsten ikke kunne måles. Et andet kan indlæse scripts og styles på alle sider, lave eksterne kald og udføre en håndfuld databaseforespørgsler ved hvert besøg.
Derfor vil jeg vide, hvad de 37 plugins laver, før jeg begynder at slette dem. Det samme gælder temaer, frameworks og tredjepartsløsninger.
Mobilen er ofte dér, virkeligheden viser sig
Et website kan føles hurtigt på udviklerens MacBook med fiberforbindelse og stadig være langsomt for en stor del af brugerne.
En telefon har ikke nødvendigvis samme processorkraft. Forbindelsen er ikke nødvendigvis stabil. Og browseren kan samtidig have en hel del andet at lave.
"Det loader da hurtigt hos mig," hører jeg indimellem. Det er derfor ikke en særlig brugbar performance-måling.
Det er også en af grundene til, at jeg foretrækker feltdata, når der er nok af dem. Jeg vil hellere vide, hvad brugerne oplever, end hvor hurtigt sitet er på min egen computer.
Skal alt være grønt?
Nej.
Jeg kan godt lide grønne tal.
Men jeg ville ikke bruge timer på at flytte en Lighthouse-score fra 98 til 100, hvis brugerne allerede har en hurtig oplevelse, og tiden kunne bruges på noget vigtigere.
Det gælder også Core Web Vitals. De er nyttige, fordi de måler forskellige dele af brugeroplevelsen. Men et website skal stadig fungere uden for måleværktøjet.
Lighthouse er en diagnose, ikke en karakter.
Hvad gør man så ved en langsom hjemmeside?
Jeg ville ikke begynde med at installere endnu et performance-plugin.
Jeg ville begynde med at finde ud af, hvor tiden forsvinder.
Er serverens svartid problemet, undersøger jeg server, applikation, database og caching. Er det billederne, arbejder jeg med størrelse, format og levering. Er browseren begravet i JavaScript, finder jeg ud af, hvad der bliver kørt, hvornår det bliver kørt, og om det overhovedet behøver være der. Er det tredjepartsscripts, må man nogle gange tage en diskussion om, hvorvidt værdien af dem står mål med prisen. Og er problemet kun på bestemte sidetyper, begynder jeg dér.
Først måle. Så optimere.
Performancearbejde handler selvfølgelig om teknik. Men en stor del af arbejdet handler om prioritering. Der vil næsten altid være mere, man kan optimere. Spørgsmålet er, hvad der faktisk gør en mærkbar forskel.
Derfor begynder jeg med målingen og arbejder mig frem til årsagen, før jeg ændrer noget. Ellers risikerer man at gøre det, der er nemmest at optimere, i stedet for det, der faktisk gør hjemmesiden langsom.
Det hurtigste website er ikke nødvendigvis det med den højeste score. Det er det, der føles hurtigt for dem, der skal bruge det.
Performance & SEOJeg arbejder med performance fra måling og diagnose til billeder, caching, databaseforespørgsler, JavaScript og teknisk SEO. Målet er ikke 100 i Lighthouse. Målet er et hurtigt website, der fungerer godt for rigtige brugere.
