Derfor flytter jeg wordpress projekter til PerfGrid

Skal lige starte med at sige at der er reklamer i dette indlæg, jeg bruger selv PerfGrid til alle mine egne løsninger. Også Kim-tetzlaff.dk ligger hos PerfGrid.

Når jeg optimerer hjemmesider ser jeg konstant på hvad det er der gør at hjemmesider bliver langsomme. Jeg har gennem mere end 25 år arbejdet hands-on med hastighedsoptimering, og den vej igennem fået den erfaring jeg har i dag. Men de sidste par år har jeg set et mønster som går igen på rigtig mange af de hjemmesider jeg optimerer. Det kan både være fordi at hjemmesider bliver mere og mere avancerede, men også fordi der er virkelig mange webhosts at vælge imellem.

Hvad enten du går efter en billig hosting til din hjemmeside, eller du mere går efter den service og support der er, så har jeg fundet den som jeg mener gør det bedste stykke arbejde

Når jeg flytter tunge wordpress løsninger til PerfGrid (tidligere Hosting4Real), bliver TTFB og generel responstid typisk tre til ti gange hurtigere, allerede før jeg begynder at optimere noget som helst på selve sitet.

Det her er min forklaring på hvorfor – og hvornår det giver mening at gøre det samme med din egen hjemmeside eller webshop.

Hosting kan ødelægge selv den bedste hastighedsoptimering

Når en hjemmeside er langsom, starter jeg som udgangspunkt næsten altid med den klassiske hastighedsoptimering. Det anbefaler jeg også de fleste at gøre, fordi mange hjemmesider faktisk kan komme til at køre fornuftigt på selv lidt træge servere, når der først er ryddet ordentligt op.

Typisk handler det om ting som:

• at fjerne eller udskifte tunge plugins
• at komprimere og strukturere billeder bedre
• at slå cache rigtigt til
• at få styr på css, javascript og unødvendige kald

For rigtig mange sites er det nok til, at de eksisterende servere kan følge med, og så er der ingen grund til at flytte alt over på en ny platform.

Men oftere og oftere møder jeg løsninger, der ligger på dyre webhoteller eller såkaldt specialiseret wordpress hosting, som alligevel ikke kan trække hjemmesiden. Her er TTFB høj, backend føles tung, og hver ekstra optimeringsrunde giver mindre udbytte, fordi serveren i sig selv er flaskehalsen.

I de tilfælde giver det ikke mening at blive ved med at finpudse frontend oven på en server, der ikke kan følge med. Der anbefaler jeg at flytte til PerfGrid og deres Grid løsning, og først derefter bruge tid på den dybe optimering af selve wordpress delen.

Hvem PerfGrid er – og hvorfor jeg anbefaler dem

PerfGrid, som tidligere hed Hosting4Real, er et lille, specialiseret hostingmiljø. De forsøger ikke at være alt for alle. I stedet fokuserer de på:

• høj performance
• stabilitet under pres
• teknisk sparring med udviklere og bureauer

Kombinationen jeg især lægger mærke til:

• moderne hardware med NVMe lager og hurtige AMD cpu’er
• LiteSpeed webserver som standard
• integreret Valkey/Redis til objektcache
• deres egen Photon Optimizer, der kombinerer cdn og billedoptimering
• et enkelt kontrolpanel uden cpanel bloat

Man skriver endda med folk i supporten, der selv har arbejdet praktisk med performance i mange år. Det betyder, at man kan tale om cache strategi, php versioner og konkrete problemer – ikke kun om hvordan man nulstiller en adgangskode. Jeg bruger selv PerfGrid til alle mine løsninger og kim-tetzlaff.dk ligger også der. Derfor er der ingen tom snak, bare for at få nogle kliks 🙂

De har 2 hostingmiljøer, den ene er den jeg snakker om her, og er deres Grid løsning. Men de har også en cPanel løsning, som er lidt langsommere, omend den også er hurtig, så er Grid løsningen til de tungere hjemmesider.

Du kan læse mere om deres løsninger her:

I dag flytter jeg oftere og oftere først – og optimerer bagefter

I mange projekter kan jeg se allerede inden første egentlige optimeringsrunde, at hostingmiljøet er hovedproblemet.

Typiske tegn som jeg ser er:

• navigation i backend tager flere sekunder pr. klik
• ordrelister, produktoversigter og brugeroversigter loader langsomt
• TTFB på centrale sider ligger på fem til ti sekunder
• udviklerværktøjer og gtmetrix viser lange ventetider på selve html dokumentet og på admin ajax kald

Hvis jeg begynder at optimere sådan et site på den gamle server, bruger jeg uforholdsmæssigt meget tid på at vente på svar. Både jeg og kunden betaler i praksis prisen for en langsom server.

Derfor gør jeg ofte noget andet:

1. Jeg tager en komplet kopi af sitet.
2. Jeg lægger det på en PerfGrid server på et testdomæne, fx dev.ditdomæne.dk.
3. Jeg slår al cache fra og lader være med at optimere noget som helst.
4. Jeg tester gammel og ny server direkte op imod hinanden på de samme sider og flows.

Det giver et ret ærligt billede af, hvad vi vinder kun ved at skifte server. Først derefter beslutter jeg, hvor meget klassisk optimering der giver mening.

Case: micronordic.com – tre til ti gange hurtigere alene ved serverskift

Micronordic.com er en stor multisproget WooCommerce webshop med WPML, Elementor og en række større plugins ovenpå. Det er den type løsning, der stiller tydelige krav til hosting, både på frontend og i backend.

Udgangspunktet på den gamle server

På den gamle server, som var hos DigitalOcean og en ret kraftig server, lå TTFB på de vigtigste sider generelt mellem fem og ti sekunder. Det gjaldt både forsiden, centrale produktkategorier og andre tunge produktsider. Det kan selvfølgelig være mange ting, store plugins, dårlig kode osv. Men da jeg havde gennemgået koden, og set på tema osv. var det ikke der problemet lå.

Når TTFB ligger deroppe, og det ikke er flaskehals i kode eller plugins, betyder det i praksis at:

• serveren er presset og kan ikke følge med, når man klikker rundt
• oplevelsen bliver langsommere jo mere man navigerer, fordi hver ny side starter med flere sekunders ventetid
• backend føles tung, og almindeligt arbejde i WooCommerce bliver trægt

Selv en simpel handling som læg i kurv tog ofte to sekunder eller mere, og ajax kald til mini kurv og andre funktioner lå tydeligt for højt.

PageSpeed Insights viste pæne tal på desktop for forsiden, men mobilresultaterne og den faktiske oplevelse stemte bedre overens med virkeligheden:

• mobilscore under 50
• Largest Contentful Paint omkring 14 sekunder
• et speed index der lignede det man oplevede som bruger 10+ sekunder

Gtmetrix bekræftede det samme: fuld indlæsningstid omkring ti sekunder, lange ventetider på html dokumentet og flere tunge admin ajax kald, dette er fx for forsiden.

Kopien til PerfGrid – uden cache og uden optimering

For at se hvor meget hostingmiljøet betød, lavede jeg en 1:1 kopi af shoppen til en testserver hos PerfGrid på et subdomæne. Den gamle server kørte videre på det normale domæne, så vi kunne sammenligne direkte.

På PerfGrid lod jeg opsætningen stå helt rå:

• Cache og optimerings plugin var deaktiveret
• Redis og objektcache var ikke sat op endnu
• tema, plugins, content og konfiguration var uændret

Det var en bevidst ren servertest, for at vi kunne se og mærke forskellen, før vi eventuelt flyttede til den nye server.

Allerede i den tilstand faldt TTFB på de samme typer sider til under ét sekund, og generelle sideloads lå under ét sekund uden nogen form for caching.

• læg i kurv gik fra over to sekunder til langt under ét sekund
• mini kurv og andre ajax kald blev flere gange hurtigere
• checkout oplevedes som normalt hurtigt i stedet for tungt
• Backend blev betydeligt hurtigere og ikke træg at arbejde i

PageSpeed viste det samme billede:

• fuld indlæsningstid faldt fra omkring ti sekunder til cirka to sekunder
• mobil LCP faldt markant
• desktop blev mere stabil, total blocking time faldt til tæt på nul
• ventetiden på html dokumentet og de vigtigste ajax kald blev reduceret markant

Alt sammen med en 1:1 kopi – uden cache og uden frontendoptimering.

Optimeringen efter flytningen

Da sitet først lå stabilt på PerfGrid og var flyttet endeligt til hoveddomænet, begyndte jeg på den egentlige frontend og wordpress optimering. Her vandt vi yderligere hastighed ved blandt andet:

• at rydde op og optimere i css
• at komprimere og strukturere billeder bedre
• at reducere antallet af ajax kald og optimere de kald, der skulle blive
• at gennemgå og optimere WPML konfigurationen
• at sætte LiteSpeed cache rigtigt op til netop den løsning
• at finjustere plugins og andre dele af opsætningen

Kunden har bagefter fortalt, at de aldrig før har oplevet sitet så hurtigt – hverken frontend eller backend. Forskellen kan mærkes både i daglig drift og i kundernes oplevelse.

Konklusionen på micronordic casen

Når en multisproget WooCommerce webshop med WPML, Elementor og flere store plugins:

• går fra fem til ti sekunders TTFB til under ét sekund
• får fuld indlæsningstid reduceret fra omkring ti sekunder til cirka to sekunder
• oplever at læg i kurv går fra over to sekunder til langt under ét sekund

kun ved at skifte server, før der overhovedet er optimeret på frontend, er det ret tydeligt, at hostingmiljøet har været hovedproblemet. Dette er ikke et enkeltstående tilfælde, det samme er set med flere andre kunder som har fået flyttet deres hjemmesider til PerfGrid, som blandt andet Body-sds.dk, Mummum.dk, plantekoeb.dk mf.

Derefter giver det selvfølgelig mening at tage den klassiske optimeringsrunde oven på en hurtig og stabil server. Som du nok lagde mærke til var der fx mange AJAX kald, alt for mange set i forhold til at der kun er en kurv. Det er kombinationen af server og optimering, der til sidst gør løsningen markant hurtigere over hele linjen.

Men hvad med deres Core Web Vitals og CrUX data? jo den er blevet betydeligt bedre, og ser nu ud sådan: NB! Flytningen skete lige før den blev grøn

Og her på mobilen alene:

Hvad PerfGrid teknisk gør anderledes

Set udefra handler det “bare” om hurtige servere. I praksis er det flere konkrete valg, der tilsammen gør forskellen.

Lad os starte med manden bag, Lucas, som gennem mange år har snakket om hastighed, næste lige så længe som jeg. Det bærer hans serverløsninger også præg af. Han er en person som ved meget om hastighed både på serverniveau og han har også en god sjat viden om de løsninger om køre på hans servere, fx WordPress mf.

Det der gør den store forskel på hans servere er at al bloat er fjernet, altså alt det som man reelt ikke har brug for, er der ikke. Og det gør i sig selv serveren betydeligt hurtigere. Og så er der selvfølgelig hardware osv.

LiteSpeed webserver
LiteSpeed håndterer php, statiske filer og cache på en anden måde end klassisk Apache. Det giver hurtigere svar under load og spiller tæt sammen med LiteSpeed cache for wordpress, som jeg ofte bruger ovenpå PerfGrids miljø.

NVMe lager og moderne cpu’er
Disk og cpu betyder mere end de fleste tror, især på travle webshops og medlemsløsninger. NVMe og nyere AMD cpu’er gør, at database og php ikke står i kø.

Valkey og Redis til objektcache
Med korrekt opsat objektcache kan wordpress og WooCommerce genbruge tunge databaseopslag i stedet for at genskabe dem på hver eneste sideindlæsning.

Photon Optimizer og cdn
Deres egen løsning til billedoptimering og caching sørger for, at billeder og statiske filer bliver leveret hurtigt og effektivt, uden at jeg skal opbygge en sær løsning til hver enkelt kunde.

Et panel uden bloat
Grid panelet er enkelt at arbejde i, uden unødvendige menuer og funktioner. Det lyder banalt, men det gør daglig drift hurtigere og mindre fejlbehæftet.

Hvornår PerfGrid er det rigtige valg – og hvornår du kan lade være

PerfGrid er ikke svaret på alt, og det er heller ikke altid nødvendigt at skifte.

Jeg peger typisk på PerfGrid, når:

• du driver en WooCommerce shop, hvor omsætning og konverteringer er vigtige
• du har et medlemsunivers, kursusplatform eller anden løsning med mange loggede brugere
• du oplever langsom backend og høj TTFB, selv efter rimelig oprydning og optimering
• du gerne vil have en host, der kan tale teknik og performance og ikke kun standard support

Der hvor jeg også har set en fordel, er hvis du fx er hos Simply med flere webhoteller kørende, så kan det betale sig at flytte sine sites til PerfGrid, fordi de er billigere og du kan have flere hjemmesider på samme server.

Jeg er mere afslappet omkring hostvalg, når:

• der er tale om et lille informationssite med få besøgende
• performance ikke er afgørende, og budgettet er meget begrænset

Men i det øjeblik hastighed, stabilitet og seo har reel forretningsmæssig betydning, bliver servervalget en del af selve hastighedsoptimeringen – ikke bare en linje på fakturaen.

Sådan kan en flytning til PerfGrid foregå

Når jeg hjælper med at flytte et site til PerfGrid, foregår det typisk sådan her:

1. Analyse af nuværende setup
   Jeg måler TTFB, kigger på PageSpeed, gtmetrix, backend hastighed og gennemgår hostingen.
2. Testflytning til PerfGrid
   Sitet kopieres til en PerfGrid server på et testdomæne. Cache slås fra, så vi får en ren baseline for serverens ydeevne.
3. Sammenligning
   Vi sammenligner gammel og ny server på de samme sider og flows: forside, vigtige kategorier, produkter, login, checkout, backend osv.
4. Endelig flytning
   Hvis tallene taler for sig selv, flytter vi domænet, får dns på plads, sætter Redis op og sikrer en kontrolleret overgang.
5. Efterfølgende optimering
   Når serveren ikke længere holder sitet tilbage, går jeg i gang med den dybe optimering: css, billeder, ajax, WPML, cache og resten af det tekniske.

Hvad du kan gøre som næste skridt

Hvis du er i tvivl om din nuværende host er en flaskehals, er et godt første skridt at få en ærlig analyse af hastigheden:

• mål TTFB på de vigtigste sider
• kig på mobilresultaterne i PageSpeed, ikke kun en flot desktopscore
• se på fuld indlæsningstid og ajax kald i udviklerværktøjer eller gtmetrix

Har du brug for hjælp til at vurdere, om PerfGrid og deres Grid løsning er det rigtige valg for din hjemmeside eller webshop, kan jeg både hjælpe med analysen, testflytningen og den efterfølgende optimering.

Værktøjer jeg har brugt til test

Jeg bruger til dagligt mange værktøjer når jeg tester en hjemmeside. Den vigtigste er og bliver browseren, der kan man faktisk se det meste og man kan teste på alle leder og kanter, også i backend. Jeg bruger Chrome browseren, og ofte kigger jeg i netværk, performance, coverage og performance monitor. Det giver en helt del data der kan bruges i optimeringen.

Derudover bruger jeg også Google Pagespeed Insights som er god overfor kunden, der kan de se et fremskridt, de kan få nogle tal de kan forstå osv. Men den er også god til at se hvilke frontend optimeringer der skal laves. Dog skal man stadig huske at det er det der kaldes en LAB test, det er altså ikke en rigtig hastighedsanalyse af din hjemmeside. Til det har de deres CrUX som viser den målte hastighed ude hos brugerne.

Og så har jeg brugt GT metrix til at teste løbende, fordi det især kan give et billede af hvordan det går over tid.

Du kan læse mere om PerfGrid her:
Som fortalt tidligere, jeg har selv alle mine hjemmesider liggende hos perfgrid, og har flere kunder der er flyttet til perfgrid, med samme resultat. Hurtigere hjemmeside allerede før eventuel optimering af hjemmesiden. Og det bedste af det hele, Perfgrid er billigere end de fleste store hostingudbydere.