Published: July 31, 2024 by Lucas Rolff
Hvordan vi finder hastighedsproblemer
Som hosting udbyder har vi med tusindevis af hjemmesider at gøre. Om det er WordPress, Magento, Prestashop eller endda hjemmesider bygget i Laravel. Så er en af de ting vi oplever i vores support afdeling, at finde ud af hvorfor en given hjemmeside er langsom eller ikke virker så optimalt som den måske kunne. Om dette er for allerede eksisterende kunder, eller evt. nye kunder som ønsker at have deres hjemmesider hostet hos os. Så prøver vi så vidt muligt altid at finde ud af hvor eventuelle hastighedsproblemer eller ressourceproblemer opstår.
Når du køber webhoteller hos os. Så går vi selvfølgelig meget op i, at du så vidt muligt skal have en hurtig og optimal hjemmeside. Det gør også at vi kvit og frit oftest hjælper med at analysere din hjemmesides hastighed samt ressourceforbrug for at finde ud af hvor der er problemer.
Men hvordan gør vi egentligt dette? Det er det vi vil gå en smule over her.
Der er lidt forskellige måder hvorpå hastighed måles. Vi har to primære kategorier, den ene er "frontend" og den anden er "backend".
Frontend kan være alt lige fra store billeder, videoer, eksterne scripts så som Google Tag Manager, Facebook Pixel og lign, men også ting så som for meget javascript, som simpelthen sløver på siden når den først er leveret til brugeren. Effekten her kan være stor for besøgende med langsomme enheder så som mobiler og tablets, men også for dem der har en langsom internetforbindelse.
Backend derimod kan oftest være betydeligt mere besværligt faktisk at finde ud af hvad der går galt. Fordi det generelt set kræver du laver en form for "profiling" af koden der køres, og det er ikke altid nemt i et miljø hvor du ikke kan ændre alt for mange ting. Problemer med ens backend kan opstå ved brug af for mange dårlige plugins i WordPress som bruger en masse tid i de forskellige "filter" og "hooks" du har tilgængelige i WordPress. Det kan også være ting så som unødige databasekald, eller endda kald til eksterne systemer som gør din side pludselig bliver afhængig af hastigheden af andre servere end din egen. Gode eksempler på dette kan f.eks være hvis du bruger server-side Facebook Pixel, eller f.eks bruger en betalingsgateway som laver et API kald for hver sidevisning (Hvilket vi desværre har oplevet).
Frontend optimering
Nogle af de redskaber vi bruger til at undersøge hvordan ens frontend kan optimeres, består egentligt af relativt få redskaber.
Vi bruger Developer Tools som findes i de fleste browsere. Det kan generelt set give et relativt hurtigt indblik i lavthængende frugter som kan optimeres. Dette kan f.eks være ting som at komprimere sine billeder, eller endda levere dem som WebP eller AVIF format som ret ofte er betydeligt mindre end PNG eller JPEG.
Alle vores Grid Hosting løsninger kommer med en "Photon Optimizer" funktion som gør at vi "on the fly" kan konvertere til WebP eller AVIF baseret på hvad browseren kan understøtte. Vi gør dette på en relativt intelligent måde, så vi prøver så vidt muligt at levere det format der er mindst. Om hvorvidt det er WebP eller AVIF kommer an på en række interne parametre.
Redskaber som speedvitals.com, gtmetrix.com eller Google PageSpeed Insights kan ligeledes give indsigt i hvad der muligvis kan optimeres.
Du kan også bruge plugins så som LiteSpeed Cache til at optimere sider med, hvor der f.eks er funktioner til at lazy-load billeder (som forresten også er understøttet direkte i WordPress), det smarte ved LiteSpeed Cache er dog at det kan beregne hvad dine "above the fold" billeder er, og så undlade disse fra at blive lazy-loaded.
Du kan også bruge plugins som WP Rocket eller Flying Scripts til at optimere dine sider. Alle 3 plugins prøver at optimere sider baseret på "best practices". Dog kommer alt frontend optimering næsten altid med en del frem og tilbage for at få en side der virker optimalt. Da ikke alle optimeringer virker for alle sider. Så det er vigtigt man tester sådanne optimeringer på en test side. Dette kan du f.eks bruge vores "1-click installer" funktion til i både Grid Hosting løsninger samt vores cPanel webhotel løsninger.
En anden ting man kan prøve, er også at bruge et tema som er optimeret til faktisk at være hurtigt. Vel og mærke vi generelt set ikke er fans af Elementor temaer, så gør Elementor's eget tema "Hello Elementor" det relativt godt hvad angår hastighed.
Men vi skal huske på, at valg af for mange plugins også kan have en indflydelse på hvad der faktisk loades på siden. Ret ofte ser vi folk har en masse plugins aktive som de faktisk ikke bruger, eller reelt set ikke har brug for.
Backend optimering
Backend optimering er for os betydeligt mere interessant, fordi det er en af de steder hvor vi har en masse erfaring gennem de sidste 12 år vi har drevet hosting. Men også fordi vi har arbejdet på utroligt skalerbare løsninger.
Vi har flere redskaber til rådighed på vores systemer som gør vi kan lave en "profiling" af koden der køres på kunders sider. Nogle af disse er f.eks Blackfire.io, samt CloudLinux X-Ray, men også redskaber så som Sentry Profiling til at indsamle data over en længere periode. Funktioner som vi i samarbejde med kunden kan tilbyde, og stille analyser til rådighed for at finde ud af hvor evt. backend problemer skulle ligge.
Alle redskaber vi bruger giver forskellige resultater, nogle er tungere end andre, så hvor præcise de er, kommer lidt an på redskabet der bruges. Blackfire.io giver generelt set et godt indblik hvad der foregår, men det er også en tungere process at gøre, da vi skal lave individuelle profiling af hver enkelte forespørgsel. Men det giver mulighed for at se individuelle callgraphs og flame graphs som kan hjælpe med at identificere problemer.
CloudLinux X-Ray er en lettere process, hvor vi kan køre den for X antal forespørgsler, eller vi kan køre den for alle forespørgsler der bliver kørt i et interval. Problemet med CloudFlare X-Ray er den ikke altid er super præcis over hvad der helt reelt foregår, dette skyldes dog generelt set manglende funktioner så som såkaldte "call graphs" og "flame graphs", så til tider kan det betyde at X-Ray siger at problemet ligger ét sted, hvor det faktisk er et andet sted. Dette kommer sig også af, at i WordPress er der mange hooks og filtre som kan resultere i det er svært og finde hoved og hale i hvad der faktisk sløver ting.
Et andet redskab vi bruger ofte er Sentry Profiling, både i samarbejde med kunder, men også til udvikling af vores egne systemer så som perfgrid.com og hosting-panel.net - det hjælper os med at identificere ting som vi kan optimere på over længere sigt. Og giver os forskellige informationer omkring miljøet på det pågældende tidspunkt hvor noget er sløvt.
Sidst men ikke mindst, så findes der wp-cli profile som giver muligheden for at profile de forskellige hooks og filtre som køres i WordPress. wp-cli profile er tilgængeligt for alle kunder på alle løsninger, da vi tilbyder wp-cli som en del af vores standard pakker.
Men vi skal samtidig huske på at optimering ikke altid handler omkring langsom kode. Det kan også være at hardwaren eller konfigurationen af serveren ikke altid er det mest optimale for den pågældende side. Vi har set eksempler på hvor en af vores konkollegaer i branchen har nyere og bedre hardware end os på papiret, men det har været konfigurationen/opsætningen der simpelthen har gjort, at vi har kunne trække betydeligt mere hastighed ud af siderne. Uden overhovedet at foretage andre ændringer.
Når det så er sagt, så prøver vi altid på at bygge funktioner som gør at sider bliver hurtigere. Vi tjekker vores server konfigurationer på faste intervaller, og sørger altid for at lave optimeringer hvor end det er muligt. Og så tilbyder vi ting så som Redis Object Caching i vores Grid Hosting løsninger, da det kan gavne i form af hastighed for nogle hjemmesider.
Har du en langsom side og vil du gerne finde ud af hvorfor? Så endelig kontakt os på support@perfgrid.com, vi ser frem til at hjælpe dig så godt vi nu kan (kvit og frit).
