Nu er der mange der har bedt mig skrive dette indlæg, så tænkte at jeg hellere måtte få det gjort. Jeg vil dog gerne sige med det samme, at det IKKE bliver et teknisk ”sådan gør du indlæg”, men nærmere et ”se hvad der skete for mig”. Så nu er du advaret!
Du får her hele historien fra A-Z.
UPDATE: Glemte at sige, at siden kører på det billigste af webhotellerne fra Meebox.
Average Page Load Time
I forbindelse med at jeg var ved at undersøge et af mine sites i Google Analytics, så kom jeg til at kigge nærmere på den sektion der omhandler ”Site Speed” (findes under ”Content”). Beklager hvis du kører din GA på dansk, men jeg bruger kun den engelske version.
Her opdagede jeg, at det pågældende site havde en ”Avg. Page Load Time (sec)” på 5,94 og det syntes jeg umiddelbart lød af ret meget. Siden indeholder mange billeder, så jeg kunne godt forstå at det ikke blev verdens hurtigste site, men jeg har trods alt haft to meget kompetente personer inde og hjælpe mig tidligere, så troede egentlig ikke at det kunne blive meget hurtigere.
Twitter kommer til hjælp
Hver gang der er noget jeg er i tvivl om, så har jeg fået for vane, at spørge på Twitter. Jeg har en fantastisk skare af super dygtige mennesker der følger mig og jeg får næsten altid 5-10 svar i løbet af få minutter. (Jeg er jer alle meget taknemmelig).
Mit spørgsmål lød som følger…
Jeg fik flere svar tilbage, men de mest udførlige svar (som til sidst endte med at jeg modtog en mail) kom fra Kim Tetzlaff (@ktjmediadk som driver siden KTJ-Media.dk.
På den mail Kim sendte til mig, kunne jeg læse, at han havde styr på sine ting. Jeg vil tillade mig at referere hvad han skrev i e-mailen, da jeg som sagt ikke er super teknisk og helst ikke vil skrive noget forkert.
Problemet med det at måle hastigheder er at der er så mange ting som spiller en rolle.
Her er bare nogle af tingene:
– Land (fx har jeg set loadtider på min hjemmeside, på op imod 25 sek fra et europæisk land)– Internet udbyder, nogle er lidt bedre end andre.
– Netværket og dets belastning i besøgsøjeblikket. jo flere der bruger en linje jo langsommere vil hjemmesiden blive hentet.
– Hvor mange ting der sker på computeren der ser, jo flere ting en computer laver, jo langsommere køre den og jo langsommere loader hjemmesiden.
– Selvfølgelig antallet af elementer og ikke mindst javascript på en hjemmeside
– andre elementer og javascripts, fx addthis etc.
– Tid på dagen 🙂
Ja som du nok kan se er der så mange ting der spiller en rolle at man rent faktisk ikke kan få et helt præcist tal med nogen eksterne værktøjer.
Så derfor skal man helst bruge forskellige værktøjer til det, jeg bruger blandt andet:
– Webmaster tools og GA
– Pingdom
– Alexa (fortæller også hvor hurtigt siden hentes)
– ChartBeat (du kan se eksempel på amino her: http://chartbeat.com/dashboard2/?url=amino.dk&k=3d426203b0da6e4b7ff71db339cc6164) det er live.
– http://www.websiteoptimization.com/services/analyze/
– http://www.iwebtool.com/speed_test
– Google Page Speed (Primært til at se på om der er elementer der kan gøres bedre)
– Yslow (Til at se på om elementer der kan gøres bedre)
Vi udvekslede et par mails frem og tilbage for at jeg lidt bedre kunne forstå hvad Kim evt. kunne gøre for mig. Som sagt havde jeg allerede haft gode mennesker til at hjælpe, så forventede ikke noget. Nævnte også for Kim, at hvis han kun mente at han ville kunne forbedre load tiden med 5%, så var jeg ikke interesseret i at betale for hjælpen (dygtige folk koster gode penge).
Pingdom er god til test
En ting er, at Google Analytics viste næsten 6 sekunder i gennemsnit, men det er ikke det samme som at andre tools ville vise det samme. Så jeg måtte jo teste hvad Pingdom kunne komme frem til.
Det var desværre endnu mere nedslående og ramte hele 6,65 sekunder.
Så jeg spurgte Kim om han mente at han kunne gøre noget ved det og det mente han absolut (jeg var stadig skeptisk).
I løbet af næsten ingen tid havde han været igennem siden og lavet sine små tryllerier. Jeg ved at der er nogen derude som gerne vil vide hvad han har gjort, men jeg må erkende, at jeg ikke helt forstår det.
Det er noget om at omdanne php-forespørgslerne til html i baggrunden således at de besøgende kan få præsenteret html direkte i stedet for at vente på at den bliver genereret (beklager hvis jeg har misforstået noget).
Hvad blev resultatet så?
Som sagt gik der nærmest ingen tid (det har vel taget en time eller to) og så var Kim tilbage med et link til Pingdom http://tools.pingdom.com/fpt/ hvor han havde kørt en ny test. Resultatet var utroligt!!
Fra en load time på 6,65 sekunder til en tid på 1,40 sekunder. Vi taler altså en reduktion af tiden på hele 79% !!
Og husk igen, at siden havde været igennem to eksperter (og JA de er eksperter og super dygtige). Derfor valgte jeg også at skrive ud på Twitter og kalde Kim for en troldmand. Jeg var (og er) stadig målløs.
Ændringer i Analytics
Da alt dette er sket i dag, så kan jeg ikke ikke se hvordan grafen i Analytics kommer til at ændre sig, men jeg forventer at se et skarpt fald i kurven. Derudover er det også blevet en ren fornøjelse at surfe rundt på siden, men det gør omvendt også, at alle mine andre sider virker langsomme i forhold.
Så det bliver helt sikkert ikke sidste gang jeg hyrer Kim til at optimere mine WordPress sider. Han er som sagt ikke billig i timen, men han er hurtigt og resultatet ovenfor taler vist for sig selv.
Du kan finde Kim her: http://www.ktj-media.dk/
Et andet godt værktøj, som blandt andet kombinerer Google Page Speed og Yahoo Yslow er gtmetrix.com
Værktøjet forklarer på en meget overskuelig måde hvad der er langsomt og hvad der kan gøres for at få siden til at loade hurtigere.
Interessant indlæg – både af hensyn til brugere og søgemaskiner er det bestemt værd at bruge energi og evt. også penge på at forbedre loadtider.
Hvis man ikke har penge til at betale Kim, eller Kim ikke har tid, så kan WP plugin’et
http://wordpress.org/extend/plugins/w3-total-cache/
dog også gøre meget for performance.
Det er måske ikke helt så effektivt som en troldmand, men alligevel 🙂
@Tim – Takker. Der er mange af de tools der forklarer hvad der er galt, men er man ikke så teknisk, så kan man ikke bruge det til så meget (jeg forstår det i hvert fald ikke) 🙂
@Troels – Jeg havde tidligere brugt W3 Cache og det gav slet ikke et resultat i nærheden. Det er en lille hjælp og bedre end ingenting, men skal der fart på, så skal der (åbenbart) noget andet til.
Det er en øvelse man kan lave forholdsvis nemt. Det kræver en smule forståelse for html, og lyst til at redigere i sine templates til wordpress. Øvelsen går ud på at lave alle unødvendige kald til databasen om til statisk html. Der er jo ingen grund til at spørge hele tiden hvilken version af wordpress der bruges, når man enten kan indsætte dette som ren html, eller bedre endnu: helt slette det.
I de fleste wordpress templates er der rigtig meget overflødigt snask, som man sagtens kan fjerne, fordi det ikke giver nogen egentlig værdi til siden.
Et lille eksempel: min egen hjemmeside har en stump kode i head, som laver et link til et stylesheet. Det består af to dele: Dels et opslag i databasen for at se hvilken mappe jeg lige har valgt til dette stylesheet, og så en filendelse. Men hvorfor ikke bare indsætte hele linket som html, for jeg går jo alligevel ikke og flytter rundt på tingene i tide og utide.
Men det kræver altså at man ved hvad man laver – Er man det mindste i tvivl, vil jeg også anbefale at tage fat i Kim.
Tillykke med den store forbedring. Jeg har netop launchet mit første wordpress site for en lille uge siden. Det er forholdsvis tungt med en del javascript, dog viser pingdom tider på kun 2-3 sek, mens min egen oplevelse er at det kører noget hurtigere…
Men derfor kan det være ligeså relevant for mig at undersøge, da mit site i princippet kan være lige så “lidt” optimeret som dit, og dermed kan hente samme relative forbedring….
Spændende indlæg 🙂
Vi må have Kim til at fortælle os hvad han gjorde, så os tekniske nørder kan få stillet vores nysgerrighed 🙂
Nu har jeg siddet og tjekket en del URLer på mine hjemmesider, som i GA viser høje loadtider og i Pingdom viser forholdsvis lave loadtider…men hvilke af de to værktøjer skal man stole på/rette sig efter? Eller skal man teste med flere værktøjer for at få et retvisende billede?
Og hvad er generelt en god eller acceptabel loadtid? Det afhænger selvfølgelig af indholdet på siden, men hvis man nu tager udgangspunkt i sider med 1-2 billeder samt en tekst på 500-800 ord?
Fedt, fedt, fedt. Fart på nettet er altid dejligt.
Kunne være spændende hvis Kim havde lyst til at komme med et par tekniske ord på hvad han gør, selvom vi måske er en del der ville falde fra undervej, afhængig af detaljegraden 🙂
Jeg vil komme med et indlæg i løbet af ugen (på egen hjemmeside), hvor jeg kommer ind på nogle forskellige tekniske ting. Men jeg kan da sige så meget at det første skridt er at finde ud af hvor fejlen er. Og til det bruger man både sin sunde fornuft, lidt logik og selvfølgelig sin erfaring og viden for ej at glemme, hjælpen fra forskellige værktøjer til at indsamle noget data.
@Per – du er inde på noget af det rigtige, men hvorfor ikke gå hele vejen, og generere en fuldt ud flad HTML fil, som bliver serveret for brugeren i stedet for at tingene skal køre igennem PHP fortolkeren.
@Jesper G – Du skal kigge på GA på den rigtige måde, du kan ikke bare tage AVG load time og sige at det er sådan det er, du skal se på hvor brugeren kommer fra, fx kan en load tid på 25 sekunder forhøje AVG load time en del, men hvis denne bruger kommer fra italien og du henvender dig til danskere, så er det jo irellevant med den bruger.
Samtidig som jeg skriver til Mikael, så er der ingen værktøjer som kan give dig det helt rigtige tal, da der er så mange ting der spiller en rolle. Derfor skal man som udgangspunkt benytte forskellige værktøjer både før og efter optimering, så man kan se forbedringerne.
Det er samtidig ikke til at sige hvad der er acceptabelt, for der er nemlig også sådan noget som de eksterne ting man henter ind på siden som FX facebook, Google og andre sociale værktøjer der spiller en rolle for sidens loadtid, og er rent faktisk tit en af de faktore som er skyld i langsommere loadtider.
@Troels Kjems – Ja w3 Total Cache er et ret godt plugin, men problemet der er bare at selvom det er blevet bedre så man ikke skal have lige så meget viden om det som før, så skal man alligevel have noget viden for at kunne opsætte det helt rigtigt. og Ja i ovenstående er W3 Total Cache også brugt.
Når det så er sagt, så kan w3 Total Cache komme til at virke endnu bedre, hvis hjemmesiden flytter til en hurtigere og bedre server, man skal ikke undervurdere en god server.
@Karsten Stenzhorn – Prøv at slette midlertidige internet filer, og besøg så dit site igen, oplever du så stadig at det køre noget hurtigere end det tekst værktøjet viser? og har du fx nogle sociale plugins installeret, fx Google, Facebook, Twitter etc? nogle af dem kan godt loade langsomt nemlig, og de høre jo også med i den samlede loadtid, også selvom de ikke er så store på hjemmesiden, eller er placeret i bunden af siden.
Det var vidst det 🙂
MVH Kim Tetzlaff
Super relevant indlæg. Jeg har selv nogle WordPress sites som jeg synes kører lidt for tungt. Har også prøvet w3 Total Cache, men jeg har for lidt teknisk viden til at få det optimale ud af det.
Gad vide om Kim ikke får travlt den kommende tid 🙂
Jeg bruger typisk følgende cocktail
1) wp super cache.
Ja jeg ved at mange sværger til w3 total cache men man skal jo bruge timer på at sætte det op
2) minimere javascript og stylesheets. Der er forskellige plugins til dette
3) content delivery network. Amazon S3 med cloudfront spiller max
Denne combo kan virkelig give noget men især CDN kan godt være lidt teknisk for ikke nørder.
En lille video fra Yoast http://yoast.com/w3-total-cache/
@Henrik – Er sikker på, at Kim ikke vil have noget imod at få travlt 🙂
Jeg må æde mine ord 🙂
Den ovenstående combo har jeg brugt på et medlemssite med en del video osv, så jeg tænkte at jeg også lige ville pumpe min egen blog op med lidt god CDN.
Men det lader så til at plugin’et CDN Sync Tool som jeg hidtil har brugt er omskrevet til en version 2.0 der ikke rigtig funker.
Så nu prøver jeg at få W3 Total Cache til at funke med CDN og det er sgu ikke helt let.
Jeg har en tema fil på S3 her:
http://my4hours.s3.amazonaws.com/wp-content/themes/ThrillingTheme/images/snapshot-trans.png
Her er linket til samme fil på Cloudfront (har også sat flere CNAMES op, men dette er bare den rå url)
http:// doqf0s8qqhtd9.cloudfront.net/wp-content/themes/ThrillingTheme/images/snapshot-trans.png
Jeg får en key pair fejl på trods af at distributionen er sat til public og den derfor ikke burde have behov for nogen keypairs. Er der nogen troldmænd derude?!
Hej Mikael
Beklager alle mine kommentarer 🙂
Jeg havde oprettet Cloudfront distributionen med værktøjet Bucket Explorer. Jeg slettede den og oprettede dyret igen via Amazons egen AWS Management Console.
Og sør’me om CDN det ikke spiller nu.
Mit site er på engelsk og ligger på en Amerikansk server. Hvis jeg via pingdom tilgår dyret fra NYC så har jeg en load tid på under 1 sekund (986ms for at være præcis).
Nu er det så kun mine faneblade i venstre side der f… up fordi javascriptet åbenbart ikke kan tåle at blive minificeret :).
Tak for inspirationen til endelig at kigge lidt på egen blog. Så gik formiddagen også med det.
@Rasmus – Line break removal har en tendens til at ødelægge javascript, du kan eventuelt bruge combine eller som minimum have comment removal. Troldmanden ved sikkert mere om dette end jeg, så hvis jeg tager fejl, tager jeg gerne imod rettelser 🙂
Ja både linebreak og comment removal kan ødelægge en del, og det er både fordi mange plugins bruger gammeldags kode, især ved inline javascript, og her er der ingen kære mor, da de ser ud som om de er html kommentarer.
og så er der jo også den med linebreak removal som også ødelægger en del men kun hvis der bruges // i javascript til at udkommentere, og det er der stadig nogle der gør fordi det jo er lidt nemmere end at skulle skrive noget både før og efter det udkommenterede.
Men ja, du skal helst ikke slå comment removal eller linebreak removal til, du kan teste om det virker med comment, men jeg tvivler lidt.
MVH Kim
Der er mange måder, man kan optimere WordPress-installationer på, når det gælder hastigheden, og man skal bestemt også gøre en del.
Det kan dog også hurtigt tage overhånd, hvis man optimerer koden i core-filerne, temaer og plug-ins, for så er man måske på den, når der kommer opdateringer – og det gør der jo alligevel rimelig tit.
Hvis det er ens egen side, så kan man naturligvis bare give den gas, men er det kunders sider, skal man huske at gøre dem opmærksom på, at det kan betyde, at de ikke uden videre kan installere opdateringer selv.
Der er mange plug-ins til WordPress, som kan mere eller mindre det samme, og hastighedsmæssigt kan man komme langt ved at prøve at par forskellige plug-ins – måske kan man leve med et plug-in, der har lidt færre funktioner, hvis det til gengæld belaster siden mindre.
@Johnny – Nej det er ikke en god ide at rode med core filerne eller plugins, temaet kan der være delte meninger om, for rigtig mange temaer er nemlig kodet enormt dårligt, forbedring af PHP koden kan også gøre underværker.
når det så er sagt, så findes der bestemt plugins til meget, og rigtig mange kan godt li at installere rigtig mange plugins, som ja i sidste ende gør WP, Drupal, Joomla etc langsommere. primært fordider er så mange kokke, og selvom der er en opskrift man skal følge, så er det langt fra alle som alligevel følger den opskrift.
men jeg har allerede anbefalet et som kan det meste, hvis bare man opsætter det rigtigt.
MVH Kim
Hey…
Jeg bruger også w3 Total Cache og har gode erfaringer med det. Men det kræver alt tid at forstå at bruge, selv om man er udvikler.
Men en ting er hvad det gør for ens placering i Google. Jeg syntes det er langt vigtigere den optimering der sker for folk der bruger ens side.
Tak for godt indlæg!
@Lauge – Helt klart, det er vigtigt at tænke på brugerens oplevelse. Det er også derfor jeg som udgangspunkt bruger min browser til at vurdere en hjemmesides hastighed, derefter tager jeg fat i forskellige værktøjer.
Og det gør jeg fordi, selvom et site på papiret er hurtigt, kan der være andre elementer som gør at hjemmesiden synes at være langsom, fx gør nogle sociale plugins det at de har et lille delay, og så fader de frem. Det kan nogen gange godt gøre så det ser ud som om hjemmesiden køre langsomt, også selvom den ikke gør det.
Det kan også være måden som siden er bygget op på der gør at den kan virke langsomt.
så man skal ikke undervurderer det at besøge siden med en helt almindelig browser, og vurdere hjemmesidens hastighed visuelt.
MVH Kim
Rigtig godt blogindlæg – og ikke mindst relevant 🙂
Hvis man har evnen eller lysten til at sætte sig ind i det, så bør man bestemt tilpasse sit tema, så det ikke er fyldt med snask (som Per A. kaldte det). Man har også en tendens med at sætte en masse unødigt indhold på sin blog, der tager fokus på indholdet – som man jo alligevel kommer efter.
Så frem med støvsugeren, så kommer man langt uden diverse optimeringsplugins 😉
Imponerede godt!
Det indlæg giver blod på tanden til, at arbejde målrettet mod en forbedret loadhastighed!
Tak for indsparket og henvisning til de gode tools.
Man må nok få sat sig ind i det med hastighedsoptimering, da man med en dårlig loadtid også mister ret mange besøgende.
I hvert fald noget der vil være interessant for mange af mine affiliate sites 🙂
Måske skulle jeg tage fat i dig Kim 🙂
@Christopher, Du skal være velkommen 😉
Interessant indlæg. Kan du gøre det samme med hjemmesider bygget på platformen Drupal? Det er også et opensource cms, så det er måske bygget på samme principper som wp.
@Jørgen – Det vil jeg da gætte på at man kan.
Ja det er muligt at optimere en hvilken som helst løsning, spørgsmålet er bare hvor meget arbejde det kræver. Med fx WP kan denne opgave i mange tilfælde klares rimelig hurtigt, dog vil der være tilfælde hvor fx hjemmesiden er kodet så dårligt, javascripts laver rod, mange billeder, mange ikoner og meget andet hvor man bliver nød til at bruge noget mere tid.
Drupal har en indbygget “performance” forbedre, som fx minificere og sammenlægger css og javascriptfiler. Så den del kan også klares hurtigt. Men den gør dog ikke et lige så godt job som W3TC gør for WordPress.
Men jo som udgangspunkt kan alle løsninger optimeres i hastigheden, spørgsmålet er bare hvor meget tid det tager og dermed hvor meget det vil koste.
MVH Kim
Tak for linket Risaager til W3-Total-Catch, jeg kan nemlig slet ikke lige finde ud af hvad jeg skal gøre til eller fra for at vide om det tool hjælper mig.
Uden dog at have gjort noget andet ind det vil jeg mene min side har en okay load time.
2.09 sekunder via iwebtool
Googles er så på 0.35 sekunder 😀
Nu har jeg lige brugt 2 min på at se en youtube video til optimering af W3-total-catch og optimeret med 50 sekunder på luksustasker.dk
Lækkert
Hej Mikael.
Nu er der noget der har irriteret mig grænseløst i noget tid hehe.
Jeg kan ikke trykke -> Næste side
I bunden på din forside fx, når jeg gerne vil læse dine ældre indlæg.
Ligeså ved podcasts kan jeg ikke trykke næste side for at høre de ældre podcast.
Jeg ved godt jeg kan trykke ude i højre side, men jeg er så vant til at trykke frem eller tilbage i bunden, jeg ville ønske at det også var på din side nu jeg bruger den så meget 🙂 ??
Kunne det være en mulighed.
Mvh. Jesper Krogfelt
Hej Jesper – Den feature er bevist fjernet, så desværre nej. Den kommer ikke igen. Håber du kan nøjes med højre side hvor de alle er. Alternativt kan du downloade dem alle via iTunes.
Hej Mikael, jeg nøjes 🙂
Jeg har jo læst dine fine indlæg med Conduiet metoden og i den forbindelse har du også gået en lille belønning 🙂
Efter jeg er gået igang med at lave min hjemmeside om efter Conduit metoden har jeg søgt forgæves på et lækkert pris sammenlignings plugin, har du et godt et du kan anbefale?
Mvh. Jesper Krogfelt
@Jesper – Jeg ved at der er et på trapperne som langt vil slå alle andre ud af banen, så min anbefaling vil være at vente lidt hvis du har mulighed for det. 😉
Hej Mikael.
Uff det ser jeg frem til 🙂 Fortæller du om det herinde eller skal jeg bare holde dig op på det?
Jeg kan slet ikke vente, men indtil da så prøver jeg kræfter med noget andet!! Altså kønt det er det jo virkelig ikke, meget gerne lige tag et kig på min hjemmeside og kom med din mening.
Det sku gerne være så conduit som muligt jo 🙂
Jeg skal nok komme til at fortælle om det herinde. 😉
Hey…
Nu er der gået en rum tid. Kan du se nogen mærkbare forbedringer på placeringer i Google SERPen?
På forhånd tak 🙂
Hej Lauge – Det kan jeg ikke just påstå, men omvendt var det heller ikke noget jeg havde forventet. Hastighed (som jeg vurderer det) er kun en meget lille del af det Google kigger på.
Jeg fik udelukkende Kims hjælp af hensyn til brugerne (og fordi det irriterede mig selv at det gik langsomt) 🙂
Hey Mikael,
Læste lige (endnu) et indlæg hos Viperchill om hvordan han havde sat load-hastigheden op på sin hjemmeside, og kom til at tænke på dette indlæg.
Glen kommer med en masse gode tips til hvor man skal vælge CDN, lidt og dedikerede servere og lidt om komprimering af sin kode: http://www.viperchill.com/supercharge-wordpress/
Hej Frederik,
Læste godt det indlæg og helt enig i at det indeholder god information. Jeg synes måske det er lidt overkill, men der kan helt sikkert være situationer hvor det giver mening.
Super artikel Mikael.
Artiklen gav mig anledning til at checke mit eget site og resultatet var faktisk lidt nedslående, måske det hænger sammen med min alt for høje bounce rate.
Er selv igang med de lavt hængende frugter, men skal vel nok have Kim T på banen når det er gjort.
Spørgsmålet er hvor let er det i en DanDomain webshop – er det relativt let eller er der mange forhindringer på vejen – læs tid og økonomi.