Tilbud på hastighedsoptimering lige nu

10 gode råd til en hurtigere hjemmeside

  1. HTML Caching / Output Caching
  2. Skær ned på antallet af grafik filer inklusiv grafik fra de sociale medier
  3. Sammenlæg CSS filer og JavaScript filer
  4. Browser Caching
  5. Lad være med at loade de samme grafikfiler, JavaScript filer mm. Som i grunden er samme, lidt mindre eller en ældre udgave af filen.
  6. Minimer brugen af htaccess
  7. Skriv ordentlig og minifiseret kode
  8. Minimer brugen af plug-ins
  9. Se på hvordan hjemmesiden loader
  10. Test din hjemmeside i forskellige værktøjer og ressourcer

HTML Caching / Output Caching

Hjemmesider er i dag typisk lavet i et serversidescript som fx PHP eller .NET / ASP. Det betyder at, før hjemmesiden er klar til visning over for dig som bruger, skal Serveren hvor hjemmesiden ligger, lige fortolke denne serversidekode, og derefter sende din browser HTML koden, som browseren så skal fortolke for så at vise dig hjemmesiden.

På mange servere, og med mange systemer, er dette en krævende proces som kan tage alt fra 500ms – 1500ms. I nogle tilfælde helt op over 2 sekunder. Det er derfor også et sted hvor man bør starte da man kan hente så meget tid på dette punkt, og dermed gøre hjemmesiden hurtigere.

Hvad er HTML Caching / Output Caching?

I grunden kan man sige at det er lidt ligesom I gamle dage, hvor man sad og lavede helt almindelige og statiske hjemmesider. Dengang sad man og lavede en html fil pr side, fx index.html for forsiden, man uploade så denne fil til sin server, og man kunne så se hjemmesiden. Langsommeligt at arbejde med for de fleste, men det kræver utrolig lidt af en server og derfor loader det også utrolig hurtigt.

Det er selvfølgelig ikke det du skal gøre, men du skal i grunden prøve at ramme det samme resultat med din hjemmesideløsning. Altså lægge/gemme nogle HTML filer på din server, som så bliver sendt til brugeren i stedet for at serversidescriptet skal køre hver gang en bruger besøger din hjemmeside. Hvordan man når det resultat er meget forskelligt fra hjemmeside til hjemmeside, hvilket gør det umuligt at komme med den helt rigtige løsning.

[su_note note_color=”#ececec” radius=”8″]Sværhedsgrad Generelt: Kræver en del PHP viden, især om det at læse HTML’en på en hjemmeside, og gemme dem i en fil på din server, som ligger i samme struktur som URL’erne på hjemmesiden. Samtidig kæver det også kendskab til det at lave rewrites via fx htaccess.

men hvis du som udvikler bare tænker:

  1. Hvordan får jeg fat i det HTML output som bliver genereret af PHP og sendt til brugeren
  2. Hvordan gemmer jeg den på serveren, hvis ikke den allerede er gemt på serveren
  3. Hvordan henter jeg den gemte/cachede HTML fil når en bruger efterspørger en bestemt side

Sværhedsgrad WordPress: Det kræver ikke lige så meget viden at implementere denne del i WordPress, men det kræver alligevel lidt viden om htaccess, serveren og hvilke plug-ins der er gode til formålet, fx W3TC (W3 Total Cache).

Resultat: Det er meget forskelligt hvilket resultat man får ud af at implementere html caching, men en ting er sikkert at det giver typisk enormt meget, og derfor er det også en af de ting du bør implementere først.[/su_note]

Skær ned på antallet af grafik filer inklusiv grafik fra de sociale medier

Jo flere filer en bruger skal hente når de besøger din hjemmeside, jo dårligere er det. Det er sådan at når du besøger en hjemmeside, skal alle grafikfiler og billeder hentes ned på din computer, så de kan blive vist på hjemmesiden. I gennemsnit tager det mellem 15-20ms pr. fil der skal hentes, dette tal er taget ud fra tests på en række sites. Og da der typisk bliver hentet mellem 30-70 billed- og grafik filer, skal der ikke meget hovedregning til for at kunne se, at det rent faktisk kan betale sig at gå op i at have så få filer som muligt.

Hvad bør man gøre for at skære ned på antallet af grafik?

  • Se efter om der er grafik som kan erstattes af helt almindelig CSS kode, mange bruger stadig grafikfiler, selvom der rent faktisk kun er tale om en enkelt farve, fx på en baggrund. Yderligere er der også flere muligheder med CSS3 hvor man kan lave runde hjørner, skygger, gradienter mm. Dog skal man være opmærksom på at ikke alle browsere understøtter alt i CSS3, men det er bestemt værd at se på og vurdere om man skal bruge.
  • Der hvor man ikke kan erstatte det med CSS, skal du sammenlægge filerne til CSS sprites, du skal tænke dig lidt om når du gør det, både fordi selvom det er godt med så få filer som muligt, kan du fx også risikere at siden loader visuelt langsomt hvis du kun har 1 billedfil til al din grafik.
  • Kør billeder gennem smush.it, som er et komprimeringsværktøj som komprimerer filerne til det yderste uden at tabe kvalitet, bedre end Photoshops ”save for web” underligt nok.
  • Husk altid at tjekke om siden stadig loader visuelt hurtigt eller om den evt. hakker for meget.

[su_note note_color=”#ececec” radius=”8″]Sværhedsgrad Generelt: Det kræver en del kendskab til CSS og CSS3, samt kendskab til Photoshop eller et andet billedbehandlingsprogram, hvor du kan sammenlægge grafikfiler til færre filer. Derudover skal du se på din hjemmeside i en browser som fx Google Chrome, da du der har muligheden for at køre et plug-in som hedder Yslow, der kan du køre billederne igennem smush.it. Alternativt er at programmere en løsning som gør det direkte på serveren, så så kræver endnu mere.

Sværhedsgrad WordPress: Ud over ovenstående og generelle sværhedsgrad, vil du i WordPress kunne installere et plug-in som køre billeder gennem Smush.it, hvilket vil sige at du til den del ikke behøver så stor kendskab. Dog skal du have kendskab til hvad pluginet gør, da du kan ende ud i at den ikke vil som du vil.

Resultat: Hvor stort udbytte du får af dette, kommer i den grad an på hvor mange filer der var tale om fra start, men udbyttet er forholdsvis stort, så det er bestemt et sted jeg ville anbefale man gør noget ved.[/su_note]

Sammenlæg CSS filer og JavaScript filer

Ligesom med grafikfiler, er det vigtigt at du sammenlægger CSS og JavaScript filer til så få filer som muligt. Nogen gange er dette en af hver, andre gange er det lidt flere JavaScript filer. Det der i grunden bestemmer det, er hvordan hjemmesiden visuelt loader. Men start ud med at sammenlægge til 1 CSS fil og 1 JavaScript fil og tag den derfra, loader den hurtigt og uden nogen visuelle irritationer, så er det jo helt fint.

Sørg samtidig også for at CSS filen står før JavaScript filen i html koden, og placer helst JavaScript filen til aller sidst i dokumentet, altså før det afsluttende Body tag, og endnu bedre så load det asynkront så det ikke blokere for at andre filer såsom billeder bliver hentet.

Prøv yderligere også at få inline CSS og inline JavaScript med i de filer, eventuelt til sidst i filerne. Da sådan noget ikke hører hjemme i Mark-up koden (html koden), Det er kun i de tilfælde at CSS er genereret af noget JavaScript som køre, at der må være inline CSS.

[su_note note_color=”#ececec” radius=”8″]Sværhedsgrad Generelt: Det kræver noget kendskab til de forskellige JavaScript filer samt hvornår de behøver at loade. Ellers er det bare enten at lave et script som automatisk sammenlægger de forskellige filer, eller også skal du i gang med at kopiere og sætte ind. Den sidste er nemmest til en start, men kan skabe nogle problemer i forhold til når JavaScript filerne skal opdateres.

Sværhedsgrad WordPress: Sværhedsgraden er den samme, om end pluginet W3TC (W3 Total Cache), også har denne mulighed indbygget.

Resultat: Også her kommer det an på antallet af filer der var til en start, havde du kun 2 af hver før, vil det ikke give lige så meget som hvis du før have 10 af hver.[/su_note]

Browser Caching

Browser Caching, er det at man fortæller browserne at de skal gemme på filerne, og hvor lang tid de skal gemme på dem og ja hvad de ellers skal gøre i forhold til filerne. Her tænker jeg især på JavaScript, CSS og billedfiler.

Opsætter man det rigtigt, minimerer det antallet af overførsler fra serveren, og dermed også belastningen af serveren. Det betyder i grunden at når en bruger første gang besøger din hjemmeside, får browseren af vide den lige skal gemme på de her filer i dens cache, og når brugeren så skifter side, eller besøger hjemmesiden på et senere tidspunkt. Tjekker browseren lige om der er kommet en nyere version, og er der ikke det, hentes filen fra browserens cache i stedet for fra serveren.

Eksempel på brugen af browsercaching af jpg billeder (skal stå i htaccess)

AddType image/jpeg .jpg .jpeg .jpe
 ExpiresActive On
 ExpiresByType image/jpeg A31536000 #tallet er angivet i sekunder
<FilesMatch ".(jpg|jpeg|jpe)$">
 Header set Pragma "public"
 Header set Cache-Control "public, must-revalidate, proxy-revalidate"
 FileETag MTime Size
 </FilesMatch> 
 Header set Vary *

[su_note note_color=”#ececec” radius=”8″]Sværhedsgrad Generelt: Det kræver rimeligt kendskab til mime-typer samt htaccess at implementere dette. Yderligere kræver det også kendskab til hvor lang tid forskellige typer filer, bør blive gemt i browserens cache, samt hvilke situationer en fil helst ikke skal gemmes i for lang tid mm.

Sværhedsgrad WordPress: Sværhedsgraden er den samme, om end pluginet W3TC (W3 Total Cache), også har denne mulighed indbygget. Men dette er dog en meget standardiseret måde at gøre det på, hvilket ikke altid tilgodeser den enkelte WordPress hjemmeside.

Resultat: Selvom det ikke påvirker førstegangsbesøgende så meget, så kan man alligevel sige at det indirekte har en indflydelse for førstegangsbesøgende. Og en endnu større påvirkning for dem der allerede har været på din hjemmeside. Netop fordi serveren bliver belastet mindre, køre serveren også hurtigere og kan derfor behandle det der er nødvendigt, hurtigere.[/su_note]

Lad være med at loade de samme grafikfiler, JavaScript filer mm. Som i grunden er samme, lidt mindre eller en ældre udgave af filen.

Jeg ser tit når jeg optimere hjemmesiders hastighed, at der bliver loadet de samme eller næsten de samme filer flere gange. Selvom det typisk ses i Open Source løsninger som fx WordPress, fordi de forskellige plug-ins tager brug af det, og samtidig har der siddet en koder og indsat det direkte i templaten.

Men i mange andre tilfælde er det ren og skær en fejl fra udviklerens side, fordi de ikke har tænkt sig om da de lavede hjemmesiden. Et godt eksempel er Amino.dk som stadig har det problem, at de på forsiden loader 2 forskellige billeder under ”Hyperaktive Amino’er” og ”Nye ekspertblog-indlæg”, og den eneste forskel på de to er at det ene er 45x45pixel og det andet er 48x48pixel, hvilket ikke ligefrem er den helt store forskel, og dermed ville jeg mene at det næsten er den samme fil.
I stedet bør de gå ind og sige at de begge fx er 46x46pixel, da det så gør at billedet kun skal loades en gang, og samtidig er i en ordentlig størrelse. Husk på de selv samme billeder bliver også loadet i 60×60, 80×80 og 300×300 pixel.

Et andet eksempel er at mange hjemmesider loader både en gammel og en ny version af jQuery.

[su_note note_color=”#ececec” radius=”8″]Sværhedsgrad Generelt: Det kræver a du sætter dig ind i din hjemmeside og ved hvilke størrelser, hvilke filer mm. Der bliver hentet. Og derfra er det så bare at lave det om, eller bede din udvikler om at lave det om.

Sværhedsgrad WordPress: Der er ikke den store forskel fra en normal hjemmeside til en WordPress hjemmeside. Dog kan der være andre måder at gøre det på hvis det er et plug-in som laver billedstørrelserne.

Resultat: Hvor meget du kan opnå kommer helt an på hvor grelt det står til, er der mange filer som er de samme eller næsten de samme, så kan det gøre en mellemstor forskel, i Aminos tilfælde taler vi omkring 100ms, hvilket ikke er meget, men alligevel noget som jeg personligt ville forfølge og rette.[/su_note]

Minimer brugen af htaccess

Htaccess er en eller flere filer som du kan gemme på webhotellet, for at lave indstillinger på serveren, redirecte, omskrive og meget mere. Den er meget god hvis ikke der er andre alternativer til at opnå det resultat. Grunden til at man skal minimere brugen af htaccess, er fordi hver gang noget bliver efterspurgt på serveren, bliver htaccess filen læst linje for linje hver gang. Det vil sige, hurtigt skitseret, har du på din hjemmeside 70 requests, bliver htaccess filen læst 70 gange, uanset hvilken type fil der bliver efterspurgt, og står der samtidig mange linjer tager det så ekstra tid. Det siger sig selv at dette vil gøre en hjemmeside langsommere, og belaste serveren mere.

Mange systemer bruger endda også htaccess på flere niveauer, altså også nede i mapperne på serveren, hvilket betyder at når filer eller mapper i den pågældende mappe bliver læst, læses både den fil der er i mappen, men også den fil der typisk ligger i roden af sitet, og er der flere på dens vej fra mappen og tilbage til roden, bliver de også læst.

Bedre alternativer

Typisk findes der faktisk bedre alternativer og bedre brug af htaccess filen, mest fordi de fleste som laver hjemmesider, eller administrere hjemmesider, ikke har så stor kendskab til htaccess, hvilket gør at der bliver brugt det forkerte i forskellige situationer.

Et godt eksempel er at rigtig mange laver redirects ved brug af mod_rewrite (modul til Apache), hvor de i de fleste tilfælde skulle have brugt redirect eller redirectMatch som er betydeligt hurtigere og skaber færre linjer i htaccess filen.

Jeg oplevede for ikke ret lang tid siden, at der var nogen som havde lavet over 300 redirects ved brug af Rewrite i stedet for RedirectMatch, hvilket resulterede i 300+ linjer i htaccess filen. Dette kunne koges ned til 3 linjer.

De ville gerne redirecte næsten alle htm og html sider til samme mappestrukur, men uden en filendelse og med slash for enden af urlen.

Dårlig kode:

 RewriteEngine On
 RewriteRule ^gammel1.htm$ /gammel1/ [R=301,L]
 RewriteRule ^gammel2.htm$ /gammel2/ [R=301,L]
 RewriteRule ^gammel3.htm$ /gammel3/ [R=301,L]
 RewriteRule ^gammel4.htm$ /gammel4/ [R=301,L]
 RewriteRule ^gammel5.htm$ /gammel5/ [R=301,L]
 …… 
 …

Og så videre op imod 300 sider blev omdirigeret på denne måde
Yderligere var der nogle få som blev omdirigeret til forsiden og andre til en anden underside på eksakt samme måde som ovenfor.

God og omskrevet kode:

RedirectMatch 301 (underside1|underside2|underside3|underside4).(htm|html)$ http://www.domain.dk/underside/
RedirectMatch 301 (side1|side2|side3|side4).(htm|html)$ http://www.domain.dk/
RedirectMatch 301 ^(.*).(htm|html)$ http://www.domain.dk$1/

Ovenstående kode er god, både fordi den kun fylder 3 linjer, men også fordi den slet ikke bruger mod_rewrite, men derimod mod_alias, som reelt set er det man bør bruge i ovenstående tilfælde, da den er så meget hurtigere, og dermed belaster serveren mindre. Mod_rewrite er lavet til noget mere avancerede omdirigeringer og omskrivninger, mens mod_alias er lavet til omdirigeringer.

Så alt i alt tænk dig om når du bruger htaccess.

Et andet og endnu bedre alternativ er slet ikke at bruge htaccess, men i mange tilfælde kræver det at man har adgang til vHost og kan skrive det direkte i Apache Direktiverne. Det er en meget bedre løsning da det der står der kun bliver læst 1 gang.

[su_note note_color=”#ececec” radius=”8″]Sværhedsgrad Generelt: Det kræver indgående kendskab til htaccess/vHost, Apache og de forskellige moduler. Uden den kendskab, når du ikke langt og kan ikke udnytte serveren til fulde uden at det belaster alt for meget.

Sværhedsgrad WordPress: Den er lidt sværere i WordPress, forstået på den måde at WordPress og de plug-ins man kan installerer, absolut og i den grad tager brug af htaccess, og på flere niveauer endda.

Resultat: Det varierer rigtig meget. Og selvom man ikke vinder så vanvittigt meget på hjemmesidens hastighed direkte, så skal det i hvert fald være meget slemt og meget dårligt, så vinder man alligevel indirekte en helt del. Optimere man sin htaccess, og har man muligheden for slet ikke at bruge htaccess, vil man vinde utrolig meget på performance siden. Din server vil kunne håndtere flere brugere på samme tid, uden at den bliver belastet, hvilket også, indirekte, har en indflydelse på hjemmesidens hastighed og stabilitet.

Et eksempel fra den virkelige verden: jeg havde en kunde som havde skrevet rigtig mange linjer i sin htaccess, der var både redirects, rewrites og meget mere, men ved at optimere den kode, samt flytte meget af den fra htaccess til vHost, gav dette et performanceboost på hele 4000 %. Så det siger vidst det hele.[/su_note]

Skriv ordentlig og minifiseret kode

Jeg kan kun anbefale at man minificere sin kode, hvad enten det er html, CSS eller JavaScript kode. Det man gør, er at fjerne alt White Space fra filerne, fjerner eller omskriver kode som kan forbedres mm. Og det man spare er på filens størrelse. Ja et mellemrum gør også at filen fylder mere.

Et eksempel er amino.dk som godt nok har gjort noget ved det efter jeg har anbefalet dem det, men alligevel har de ikke gjort nok. For besøger man fx http://www.amino.dk/kim-tetzlaff-ktj er der 74.129 tegn, men med fjernelse af al White Space samt optimering af koden, kan de 11.420 tegn blive fjernet. Hvilket svare til ca. 11kb. Hvilket i praksis betyder at den html side kunne blive hentet 17ms hurtigere på en 5 Mbit forbindelse Dette tal er selvfølgelig noget højere på deres forumsider.

Så det kan bestemt betale sig at gøre noget ved det også.

Yderligere er det vigtigt at du skriver ordentlig kode, og at denne lever op til standarderne. Grunden er at det gør det nemmere for browsere at fortolke koden, og dermed også hurtigere, hvilket også resulterer i en lidt hurtigere hjemmeside. En så simpel ting som at huske at skrive bredde og højde på et img tag, gør altså noget for hastigheden, da browseren ikke selv skal finde ud af hvor stort billedet er.

[su_note note_color=”#ececec” radius=”8″]Sværhedsgrad Generelt: Det kræver indgående kendskab til HTML, JavaScript og CSS. Og vil du minificere on the fly som KTJ-Media.dk gør det, så skal du også have en del kendskab til PHP og kodning i det hele taget.

Sværhedsgrad WordPress: I WordPress er det lidt nemmere, dog skal du være opmærksom på at der tit sker fejl med JavaScript, og derfor kan du typisk kun fjerne lidt af den kode. Yderligere bruger WordPress også tit inline JavaScript i deres plug-ins, hvilket også gør at der kan ske fejl der.

Resultat: Dette varierer fra bruger til bruger, da det kommer meget an på deres internets hastighed, men selvfølgelig også serverens hastighed.[/su_note]

Minimer brugen af plug-ins

Her tænker jeg selvfølgelig mest på de Open Source løsninger som findes på markedet, fx WordPress, Drupal, Joomla mf. Alle har muligheden for at installerer plug-ins og moduler, hvilket faktisk også er nødvendigt for at få den funktionalitet man gerne vil have.

Men prøv at minimere antallet af dem, og test nogle forskellige før du beslutter dig for hvilket det skal være. Der er ikke så meget at skrive om dette emne, men det gør den jo ikke mindre vigtig, for de fleste glemmer det nemlig, og resultatet af det er typisk en langsommere hjemmeside.

Se på hvordan hjemmesiden loader

Ja vi kommer ikke uden om det at du skal se på din hjemmeside, jeg har skrevet det i et tidligere indlæg om hastighed, men jeg skriver det alligevel igen.

Se på din hjemmeside, loader den hurtigt, er der noget der hakker, er der noget som kommer senere eller er der andet som gør at det virker som om hjemmesiden loader langsomt. Der hvor jeg typisk ser at det hakker er ved de sociale medier, de kommer typisk senere end resten af hjemmesiden, og kan virke forstyrrende på en dårlig måde.

Måden du skal teste på er ved at huske at slette ”temporery internet files” hver gang du tester, så du agerer en helt ny bruger. Og har du muligheden for at nedsætte din internet hastighed, så gør det, der findes fx NetLimiter.com som har et udmærket program til formålet. Test gerne på forskellige hastigheder.

Løsningen er lidt simpel, men den virker. Du skal med CSS skjule ikonerne til de sociale medier, og du kan så med JavaScript fade dem ind efter 1 sekund. Det betyder at de loader i det skjulte, og når de så er loadet fades det ind, og forstyrre ikke på en dårlig måde. Det samme kan du gøre med andre ting også. Vær lidt kreativ og find den bedste løsning for dig.

Det kunne se ud sådan:
HTML:

<div class=”socialeikoner”>sociale ikoner loades her</div>

CSS:

.socialeikoner{display:none}

jQuery:

 $(”.socialeikoner”).animate({"display":"none"}, 1000, function() {
     $(". socialeikoner ").fadeIn('slow', function()
     });
 });

Eksempler på denne metode kan ses på www.henrik-bondtofte.dk hvor jeg netop har brugt denne metode til de sociale ikoner, samt Google+. Hans hjemmeside ligger på en server i Dallas, Texas.

[su_note note_color=”#ececec” radius=”8″]Sværhedsgrad Generelt: Det kræver minimal viden om CSS, og jQuery til fade ind funktionen er også forholdsvis nem at lære.

Sværhedsgrad WordPress: Ingen tilføjelser i forhold til den generelle sværhedsgrad.

Resultat: Det giver intet på hastigheden af hjemmesiden, men den synes hurtigere for dine besøgende, og samtidig kan du også skabe positivt fokus på forskellige områder[/su_note]

Test din hjemmeside og forskellige ressourcer

Det er vigtigt at du før, under og bagefter optimering tester dit websites, da du ellers ikke ved om de ting du gør, kan gøres endnu bedre. Her er nogle af de værktøjer og services jeg bruger til hverdag.

Pingdom Tools (http://tools.pingdom.com/fpt/)
Et godt allround værktøj, som kan vise dig forskellige ting om din hjemmeside, både hvor lange ventetider der er, men også hvor lang tid det tager et hente filer mm. Yderligere kan du teste fra 3 forskellige lokationer, jeg bruger typisk Amsterdam.

Load Impact (http://loadimpact.com)

Godt til at teste performance på hjemmesiden, typisk til at teste hvor mange brugere man kan have på samme tid på hjemmesiden, uden at det belaster serveren for meget. Man skal dog lige lære det at kende og vide hvad man skal kigge efter, og hvad der er overdrevet og måske irrelevant. Men ellers et godt værktøj.

Google Chrome (https://www.google.com/chrome?hl=da)

Ja det er en browser, men der er så mange muligheder for at teste forskellige ting på hjemmesiden, fx hvordan ting loader og køre, samt det at bruge yslow og Google Page Speed mm. Det er en god browser til udviklere og folk som gerne vil teste forskellige ting.

Apache Serveren

Apache har også et testværktøj (AB), som benchmarker din hjemmeside, altså tester fx belastninger mm. Men dette er kun muligt når man har egen server enten dedikeret eller virtuel server, samt har adgang til SSH. Men det er utrolig godt og har du muligheden så brug det. Prøv fx som en lille ting at lave en enkelt html fil på din server, som indeholder de samme ting og elementer som din forside. Og test så din hjemmesides forside med værktøjet og derefter den html fil. Så skal du se løjer. Du vil finde ud af at din server pludselig kan håndtere så mange flere brugere på en gang.

Andre ressourcer som er gode at læse lidt på
Htaccess filenApache ModulerMod_rewritemod_aliasmod_expiresmod_headers
PHPjQueryCSS

Skriv en kommentar

Målet er kvalitet

Det er mit mål at levere kvalitetsløsninger med høj fokus på hastighed og teknisk seo. Uanset om der er tale om små eller store løsninger, vil fokus altid være på hastighed og teknisk seo.