facebook

Tak for din besked!

Vi har modtaget din besked og vil vende tilbage hurtigst muligt.

Menu
Kontakt os:
+45 71 74 28 28

Hastighedsoptimering af hjemmeside

Her er en liste med alle de mulige optimeringer som kan foretages på en hjemmeside for at øge hastigheden.

Udgivet:

Hvad er hastighedsoptimering?

Det handler om at få hastigheden på hjemmesiden helt i vejret. Desto hurtigere at hele indholdet kan leveres til brugeren desto større er chancen for at de bliver på siden og navigere rundt på flere sider. Når man hastighedsoptimere sørger man for at dette indhold leveres så hurtigt som overhovedet muligt.

Hvis brugeren ikke får vist indholdet med det samme risikere man at de trykker tilbage og besøger konkurrenten.

Her er samlet de optimeringer som er allerbedst at udføre.

Tilføj cache headers på resource filer

css, js, font, woff, jpg, png, wmf, mpg, html osv. er eksempler på statiske filer der bør have cache control headers. Css filer som opdateres regelmæssigt kan have en leve tid på 7 dage og billeder som aldrig opdatere kan have på 90 dage.

læs her hvordan cache control opsættes og få et færdigt copy and paste eksemepel.

Forklaring på .htaccess og hvad den bruges til

Aktiver https og udnyt muligheden for http2

http2 er version 2 af http protokollen og er bred understøttet blandt alle browsere idag. http2 giver rigtig god mulighed for at hastigsoptimere levering af resourcer. Filer kan bla. leveres parallelt og så er protokollen bare hurtigere.

Test din side her for at se forskellen

Tving website til https

Sikre een https version af siden

Håndter 404 fejl korrekt

Send ikke 404 trafik til forsiden, det belaster unødvendigt serveren. Opret istedet en dedikeret 404 side til at håndterer fejlen og i bedste fald en statisk html side.

Billede stier som ikke fungere kan også sendes til et 404 billede.

Aktiver gzip encoding på serveren og komprimer filer

Som standard er en server typisk ikke opsat til at komprimer data når det sendes fra serveren. En alm. html fil kan komprimeres 2-10x og der er derfor 2-10x mindre data at sende. Det er på bekostning af cpu resourcer men det er godt givet ud.

Statisk cache af filer istedet for dynamisk rendering

Istedet for at compile hver side ved hvert request så skal siden laves som statisk og leveres til brugeren som vil speede det gevaldigt op. Det betyder at hver gang der tilgåes f.eks. forsiden så bliver data hentet fra databasen, behandlet via koden og så leveret til brugeren. For en dårligt optimeret siden kan dette tage 1-10 sek. hvorimod en statisk version kan leveres på 0,2 sek.

Statisk cache kan bygges på mange måder f.eks. igennem w3 total cache på Wordpress, en varnish cache foran serveren eller nginx cache.

Benyt CDN på statiske filer

Statiske filer såsom billeder, js og css filer kan med fordel lægges på et cdn netværk. Et cdn netværk består af servere overalt i verden som hjælper med at levere den statiske fil så tæt på brugeren som muligt. Derudover er serverne optimeret til kun at gøre netop dette.

Stackpath er eksempel på et godt cdn netværk.

Alternativt til cdn kan man benytte en nginx server på samme webserver til at levere statiske filer for at optimere levering og reducere belastning af egen server.

Minimer mængden af html kode som der leveres i response

HTML kan trimmes for whitespace da det ikke har nogen effekt på designet. Det samme gælder for skjulte tegn som newlines og return carrige. Disse tegn er derfor helt overflødige for browseren. Kør html igennem et filter lige før aflevering fra serveren.

Redirects ved http og https med og uden www

Hjemmesiden skal kun have een version af url adressen.

Eks.:

https://www.indexed.dk/

alle andre som:

https://indexed.dk

http://indexed.dk

http://www.indexed.dk

skal alle lede til den primære adresse. Når denne redirect opsætte skal den via 1 redirect tage en hvilken som helst af de andre versioner og lede direkte til den primære. Der skal ikke benyttes flere redirects på først at sende fra http til https og derefter videre til www versionen.

DNS prefetch

Når der inkluderes eksterne script på siden skal browseren undersøge og resolve et domæne til en ip for at kunne hente denne resource. Via dns prefetch i header kan man angive og få browseren til at gøre dette som noget af det første og ikke når ressource filen senere skal hentes.

Korrekt og optimalt billede format

Det mest benyttede format er jpg og understøttet af alle browsere. Ønsker man at reducere fil størrelsen findes der formater som webp som kan gøre dette mere optimalt og drastisk reducere størrelsen. Ulempen er dog at Safari endnu ikke har denne understøttelse og måske aldrig får det.

Derfor bør man implementere webp til de browsere som understøtte dette med fallback til jpg for dem som ikke gør. Ulempen her er igen at dette vil kræve yderligere cpu og storage ressourcer til at genkomprimere billeder som vil ligge dobbelt på serveren.

Korrekte dimensioner for billeder

Det har stor betydning hvor meget billeder fylder da det er afgørende for en mobil med mindre god net forbindelse. En typisk fejl er at vise et billede som eks. har en pixel bredden på 2000 men at mobil skærmen kun kan vise maks 500 og det giver en overflødige billede størrelse på 1500 pixel. Billedevisning skal derfor være responsiv og tilbyde browseren flere versioner i forskellige størrelser og så kan browseren vælge den størrelse som passer bedst til den angivene enhed.

[Læs hvorledes dette implementeres](How To Create Responsive Images)

Minify af CSS og JS ressource filer

Komprimering (minify) af css og js ressource filer reducere den mængde data der skal overføres. Minify vil fjerne overflødige tegn som space og newlines. Minify af js kan også omdøbe metoder og variable navne i filerne så de er kortere men også uforstålige.

Sammensmeltning af css og js filer

Istedet for at browseren skal hente 10 css filer kan de sammensmeltes så der kun skal hentes een. Der er fordele og ulemper ved denne metode.

http2 protokollen understøtter parallel hentning af filer, så her er det ikke altid en fordel at sammensmelte det hele. Hvis man bruger præcis de samme filer på alle sider så kan det alligevel godt betale sig da denne ene så vil caches lokalt i browseren. Benytter man forskellige filer på forskellige sider så bør de ligge enkeltvis da browseren kan drage fordel af at cache dem enkeltvis.

Lazy load af billeder

Typisk adfærd for en browser er at hente alle billede på en side. Dette betyder store data mængder, belastning af serveren og nedprioritering af måske vigtigere ressource filer eller billeder.

Hvis man lazy loader billeder betyder det at der kun hentes de billeder der er synlige og lige under folden. Når der scrolles på siden hentes de næste billeder som skal til at blive synlige. Hvis brugeren ikke scroller for hurtigt vil dette slet ikke bemærkes.

Ved lazy load sikre man også at css og js filer i højere grad prioriteres frem for billeder.

Det er her vigtigt at der altid angives størrelse på billeder så design ikke hopper rundt ved load af de næste billeder på siden.

Defer og async af ressource filer

Elementer som ikke er en del af første skærmbillede kan med fordel placeres i bunden af siden og hentes til sidst via defer og async egenskaber på js filer.

Her er en god forklaring på forskellen

Inkluder ikke js filer som der slet ikke benyttes

Den dovne inkludere alle js filer på alle sider, det er den nemme løsning og nogen gange eneste på nogle cms systemer. Det er bare ikke optimalt. Tag stilling til hvad der inkluderes og kun inkluder det som der er behov for på den enkelte side. Det gør en verden til forskel.

Aktiver support for http3 på serveren

Selvom understøttelse ikke er fuld på alle browsere så er der fallback til http2 eller http1.1 for dem som ikke gør.

http3 er en smule hurtigere end http2 og har mindre latency.

Eksempel på http2 og http3 requests og understøttelse.

Rigsarkivet

Lad os arbejde sammen om at bygge noget stort!

Bliv en af vores samarbejdspartnere og lad os bygge fede løsninger som skaber værdi for jer og jeres kunder.

Udgivet:

Bliv kontakt af os