Web Performance Optimization (WPO)

Achtung! Smush.it orsakar strul i WP

I en tidigare post rekommenderade jag pluginet WP Smush.it för att optimera bilder och därmed sänka laddningstiden. De senaste veckorna har jag haft problem med att ladda upp bilder till bloggen, det slutar oftast med ett HTTP error meddelande. Efter lite felsökning stötte jag på detta inlägg där utvecklaren berättar att det beror på ett (förhoppningsvis) övergående problem som helt har med Yahoos tjänst att göra. Så om ni upplevt samma problem med uppladdning av bilder, avaktivera pluginet tillsvidare.

Adios.

Sänk laddningstiden på din webb! Bra presentation om WPO.

Med ojämna mellanrum så hittar man ibland presentationer som får en att känna: YES, detta var bra! Den här gången är det företaget Bono SEO som bjuder på lite tankar kring Web Performance Optimization. Presentationen innehåller bra och övergripande information om vad WPO handlar om, de mest effektiva åtgärderna samt gedigna länklistor till verktyg. Dessutom tillåter de nedladdning av presentationen i PPT-format (yeay!).

Skynda och fynda innan han upptäcker misstaget, denna presentation borde alla ha på sitt skrivbord!

WPO: Din CSS drar laddningstid – så minimerar du den

Har tidigare skrivit inlägg om hur laddningstid inte bara påverkar träffbilden på sökmotorer men även hur den påverkar användarnas interaktion med webbplatsen. Ju mer du kan sänka laddningstiden desto bättre resultat får du, oavsett vilka dina digitala mål är.

Ett av de enklaste knepen man kan använda sig av för att sänka laddningstiden är att komprimera CSSerna på webbplatsen. Genom att komprimera de så kan du spara in många bytes vilket leder till  minskad fördröjning i nätverken, onödig information slipper parsas och exekveras vilket resulterar i mindre laddningstid.

För att komprimera dina CSS:er så kan du antingen använda dig av plugins till WordPress eller av gratistjänster som YUI Compressor och cssmin.js.

Jag testade själv att att slumpvis välja ut två webbplatser, Trygg-Hansa & Nordea, och crunchade deras CSS:er i cssmin.js. Resultatet blev en cirka 20% sänkning av vikten på filerna.

nordea css minify

Nordea kan sänka antalet byte med 21% i en av sina CSS:er

Trygg Hansa CSS Minify

Trygg-Hansa kan också komprimera sina CSS:er med cirka 20%

Snabb matte: 6000 byte sparas * 1 000 000 besökare per vecka = cirka 5,58 GB

Att spara in 5,58 GB i bandbredd kanske inte märks av så mycket utdraget på en vecka, men vid en redan tung belastning och ett tillfälligt stort tryck på webbplatsen (tänk biljettsläpp på Ticnet) så kan de där GB göra en viss skillnad.

WPO-trick: Därför bör du göra din favicon liten och cachebar!

Man skulle kunna tro att jag fastnat i ett WPO (Web Performance Optimization)-träsk men så är det inte. Har bara råkat stöta på en hel del bra tips vilka är enkla att skriva om när timmarna inte riktigt räcker till. Det kommer material av mer varierande slag inom kort.

Men tillbaka till ämnet faviconen!

Faviconen är en liten bild som bör ligga i roten av din server. Den är ett nödvändigt ont för din läsare kommer att begära den oavsett om du har lagt dit en eller inte. Har du inte placerat en favicon i roten så kommer det att generera ett 404 Not found vilket inte är så bra.

Utöver detta så kan skickas cookies varje gång en favicon anropas och dessutom så stör faviconen även nedladdningssekvensen av sidan. Detta leder alltså inte bara till fler HTTP-anrop men stoppar även upp nedladdningen av den befintliga sidan.

Så vad skall du tänka på gällande faviconen?

  • Gör den liten i filstorleken, gärna mindre än 1 KB
  • Lägg in “Expire headers” för faviconen vilket gör den cachad och leder til färre HTTP-anrop
Färre HTTP-anrop samt mindre filstorlekar gör sidan mer effektiv och får den att ladda snabbare. Enkelt.

WPO-trick: Utnyttja flush() för att en snabbare sidladdning

När en användare har begärt en sida så kan det ta allt från 200ms till 500ms innan backend hunnit snickra ihop HTML-sidan. Under tiden som backend snickrar så sitter webbläsaren passivt och bara väntar på att data skall anlända vilket upplevs som väntetid för användaren.

För att simulera en snabbare laddningstid och ge användaren en indikation på att sidan faktiskt laddas så kan man i PHP använda sig av en funktion som heter flush(). Funktionen tillåter dig att delvis ladda in färdiga delar av HTML-sidan till läsaren så att läsaren kan börja hämta information medan backend fortfarande snickrar ihop den resterande sidan. Störst skillnad gör detta på sidor med antingen en upptagen backend eller väldigt lätt frontend.

Vart skall man då sätta in flush()?
Ett bra ställe att sätta in funktionen på är precis efter <HEAD> då den delen oftast är enklare att producera. Dessutom så tillåts webbläsaren även att hämta eventuella CSS:er och Javascript samtidigt som backend fortsätter med sin process.

Så här kan det se ut:

      ... <!-- css, js -->
    </head>
    <?php flush(); ?>
    <body>
      ... <!-- content -->

WPO: Använd LINK istället för @import för att snabba upp nedladdningen

I en post nyligen förklarade jag varför en CSS bör alltid läggas i <HEAD>, och om du hunnit glömma den främsta anledningen så var det för att få en progressiv laddning.

När man jobbar med CSS så kan man använda sig av @import vilket gör att man laddar in externa CSS-filer till den som laddas för tillfället. Undvik detta kommando. I IE så beter sig det kommandot som om du hade lagt CSS-filerna längst nere på sidan och därmed går du miste om den progressiva laddningen.

Summa summarum: Använd en vanlig läkningen till CSS:en uppe i <HEAD>.

 

WPO: Lägg stilmallarna i HEAD och “sänk” laddningstiden

Jag har tidigare skrivit lite om Web Performance Optimization (WPO) och jag är övertygad om att alla inser vikten av detta. Tänkte i detta inlägg, och även i några framtida, komma med några konkreta tips på hur man kan jobba med webbplatsen för att optimera laddningstiderna.

De smarta forskarna på Yahoo! upptäckte under sina prestandatester att om man flyttar stilmallarna upp till dokumentets <HEAD> så kan man få sidan att verka ladda snabbare. Detta är ju givetvis något av en standard idag, men alla kanske inte är helt med på varför. Genom att lägga stilmallarna i headern så tillåts nämligen sidan att laddas progressivt.

Vad betyder progressiv laddning?
Jo det betyder att vi vill att så fort det finns något att visa så skall webbläsaren visa det. Detta är speciellt viktigt om man antingen har mycket innehåll på en sida eller om man sitter på långsam internetuppkoppling. Vikten ligger i att ge användarna återkoppling om laddningsstatus på sidan vilket bevisats är av stor vikt för användarupplevelsen.  När sidan laddar progressivt så funkar alla element på sidan (huvud, meny, logga etc) som en visuell återkoppling på att sidan laddas korrekt och tillfredsställer förhoppnignsvis därmed den ivriga anvädnaren.

Skulle du fundera på att lägga stilmallarna i botten på sidan så kan detta avrekommenderas.  Dels för att W3C inte tycker att det är en bra idé men även för att detta hindrar många webbläsare (bland annat IE, surpirse) från att progressivt rendera sidan. Om sidan inte laddas progressivt så kommer användarna att sitta där med en blank skärm utan att veta vad som händer.

Summa summarum: Genom att lägga stillmallarna i headern så uppfattar användarna det som att sidan laddas snabbare och får även viseuell feedback om att sidan fakiskt laddas.

Så optimerar du dina bilder för bättre WPO

När du jobbar med WPO för att optimera din webbplats är det självklart flertalet variabler som du du bör tänka på. En generell rekommendation är att börja med de bitar som tar upp den största laddningstiden. Vilka dessa delar är varierar från webbplats till webbplats men ofta förekommande bovar är tredjeparts javascript och okomprimerade bilder.

Det är inte sällan man stöter på webbplatser som helt struntat i att beskära bilden och tror att det räcker med att ange en nya storlek i koden. Det gör det inte.

Börja med att beskära din bild till rätt storlek i valfritt bildredigerare och spara som  JPG eller PNG. Om du funderar på GIF så släpp den tanken, det filformatet är nämligen inte speciellt WPO-vänligt då den väger betydligt mer än till exempel PNG.  Men visste du att det går att komprimera bilden ytterligare för WPO:n och användarupplevelsen?

Surfa in på Smush.it och ladda upp dina bilder eller ange URL:en där de ligger. Tryck sedan på knappen “Smush” och PANG så får du en optimerad version av din bild.

Yahoo Smush.it

Så vad är det Smush.it gör egentligen? Jo, tjänsten sparar om bilden i “progressive JPG” istället för “baseline JPG”. Det betyder att bilderna laddas in på olika sätt. Baseline laddas uppifrån och ner likt exemplet nedan.

Baseline JPG

Progressive å andra sidan laddar in bilden så som namnet föreslår, progressivt. Det betyder att hela bilden laddas in direkt fast till en början i låg kvalité och ökar sedan i kvalité tills den är färdigladdad.

Progressive JPG

En fördel förutom mindre bildstorlek och därmed även snabbare laddningstid är även ur ett användbarhetsperspektivet. Använder du dig av progressiva JPG:s så ser användarna direkt att något är på gång och kan ta del av hela bilden även med en sämre uppkoppling.

Övervaka din web performance med Google Analytics

Som jag lovade förra veckan så skulle jag visa hur ni med hjälp av trevliga Google Analytics kan mäta upp er web performance, det vill säga hur bra webbplatsen presterar i laddningstid etc. Genom att leka med GA:s ”Custom Variables” kan man åstadkomma mirakel även om lösningen i sig är lite klumpig då Google Analytics inte är skapad för detta ändamål. Lösningen kommer att fungera på följande vis:

  1. När en besökare hamnar på webbplatsen så skapar vi en tidstämpel så att vi kan mäta sidans laddningstid
  2. Vi spelar in laddningstiden i en Session Scope  Custom Variable.
  3. Sidans laddningstid skickas till Google Analytics med ett trackPageview anrop
  4. Datan aggregeras i Google Analytics och hittas under Visitors > Custom Variables menyn

Lätt som en plätt va? Så här går du tillväga:

Steg 1 – Addera javascriptet i headern

Det första vi måste göra är att försäkra oss om att vi fångar upp laddningstiden, annars är hela det här inlägget lite bortkastat.. Än så länge funkar bara skriptet för en sida, appliceras den på flera så skrivs den förgående laddningstiden över vilket kan leda till värdelös statistik. Det som händer är att du får då bara ut statistik på den sista sidan som besökaren befann sig på (och då alla besökare lämnar webbplatsen i olika skeden så blir den heller inte jämförbar). Ett skript för att kunna spåra flera sidor på en webbplats är under utveckling dock. Ett tips är att sätta detta skript på din mest trafikerade sida, t.ex. startsidan.

Klistra in följande rader så högt som möjlig, gärna direkt under starttagen för headern så att du kan fånga upp besökarens tidstämpel så tidigt som möjligt.

<html>
<head>
  <script type="text/javascript">
  //<![CDATA[
    var page_load_start = new Date();
    var _gaq = _gaq || [];
    window.onload =  function() {
      var page_load_end = new Date();
      var load_time = page_load_end.getTime() - page_load_start.getTime();
      load_time = parseInt( load_time / 100 )*100;
      _gaq.push(["_setCustomVar",1,'landingPageTime',load_time,2]);
      _gaq.push(["_setAccount","UA-xxxxxxxx-y"]);
      _gaq.push(["_trackPageview"]);
    };
  //]]>
  </script>
  <!-- Here goes the rest of your head section --/>
</head>

Skriptets första två rader fångar besökarens starttid och initierar GA:s async tag. De följande fyra raderna efter det sätter en stoptid för när sidan har laddats färdigt och räknar ut den totala tiden. Slutligen så tilldelar skriptet den uträknade laddningstiden till en “Custom Variable” och skickar den till Google Analytics.

Steg 2 – Lägg till Google Analytics async kod i footern
Om du missat att använda dig av Googles async kod så är det dags att göra det nu, förutom fördelen att kunna mäta t.ex. laddningstider så har en del förbättringar gjorts som gör att du kan fortsätta ladda sidan samtidigt som Google Analytics skriptet läses in.

<body>
  <!-- Your web page goes in here --/>
  <script type="text/javascript">
  //<![CDATA[
    (function() {
      var ga = document.createElement('script');
      ga.type = "text/javascript"; ga.async = true;
      ga.src  = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
      var s = document.getElementsByTagName('script')[0];
      s.parentNode.insertBefore(ga,s);
    })();
  //]]>
  </script>
</body>
</html>

Steg 3 – Vänta på att datan ska börja komma in

Om du lyckas genomföra de ovanstående stegen korrekt bör data börja ticka in inom några få timmar. För att ta del av den går du till ditt Google Analytics konto, klickar dig sedan in på Visitors > Custom Variables i den vänstra menyn. Där kommer du att se följande:

GA custom variables

Ovan ser du den Custom Variable som vi precis skapade, landingPageTime. Har det gått mer än 24 timmar och du fortfarande inte ser någon sådan variabel så kan det vara att något gått fel i installationen av skriptet,  gå då tillbaka till steg ett och felsök.

Klickar du på landingPageTime så får du upp en detaljerad rapport över laddningstiderna som bör se ut så här:

GA landing_page_time

Den kan vara lite förvirrande till en början men du tolkar siffrorna på följande sätt:

  • Custom Variable – Den här kolumnen innehåller de faktiska laddningstiderna. Står det till exempel “900″ så betyder det att det tog 900 millisekunder för sidan att ladda.
  • Visits – Berättar hur många besökare som upplevde den aktuella laddningstiden. I bilden ovan upplevde 52 stycken besök en laddningstid på 900 ms
  • Pages / Visit – Berättar hur många sidor per besök respektive användare med olika laddningstider gjort
  • Bounce Rate - Den här siffran berättar hur många avhopp du haft från sidan som besökarna hamnade på. I regel ser man att ju högre laddningstid desto större är avhoppen från sidan.

Svårare än så är det inte att använda sig av Google Analytics för att mäta upp laddningstiden och jobba med Web Performance Optimization. Ett råd är att exportera alla siffror till ett Excel ark och göra lite snygga grafer för att få en övergripande bild på hur siffrorna hänger ihop på just din webbplats.

 

Varför WPO?

Hur många gånger har du struntat att låta en sida ladda färdigt eller hoppade att köpa den där produkten mitt i köpflödet? Hur många av dina besökare har lämnat din sida för att den laddat för långsamt? Vi alla avskyr långsamma webbplatser.

Så vad är WPO?
Det står för Web Performance Optimization och innebär precis som det låter, att optimera webbplatsens prestanda. WPO är vad SEO var för många år sen. Inte många var medvetna om det men de som var blev väldigt framgångsrika på nätet och kunde skörda fina intäkter tack vare sökmotorerna.

Genom att börja jobba med och implementera WPO kommer du att märka (minst) tre förbättringar med din webbplats:

  1. Ökad trafik. Ju snabbare webbplats desto bättre upplevelse för användaren vilket i sin tur leder till flera återbesök. Även Google annonserade att webbplatsens prestanda är en parameter i deras algoritm, vilket då även innebär påverkad SEO.
  2. Ökade intäkter. Dina användare kommer att stanna längre på din webbplats och framför allt hinna utföra fler aktiviteter. Den förväntade laddningstiden för en e-handelsplats är cirka 2-3 sekunder. Allt över det uppfattas som långsamt medan en snabbare laddningstid ger en behagligare upplevelse.
  3. Reducerade driftskostnader. WPO använder sig av tekniker för att sänka antalet anrop samt minska belastningen av bandbredden.Genom att sänka antalet anrop kan vi minska CPU-belastningen men även öka skalbarheten

Allt det här låter ju jättebra men finns det några konkreta case eller siffror på påståendena ovanför? Ja men självklart finns det.  Steve Souders, WPO-expert på Google har presenterat följande case:

  • Amazon: 100 ms fördröjning orsakade en 1% nedgång i intäkter
  • Google: 400 ms fördröjning orsakade en 0.59% minskning i sökförfrågningar per användare
  • Yahoo!: 400 ms fördröjning orsakade en 5-9% minskning i trafik
  • Bing: 2 sekunders fördröjning orsakade en 4.3% nedgång i intäkter per användare
  • Mozilla förbättrade deras nedladdningssida med 2,2 sekunder och ökade antalet nedladdningar med 15.4%
  • Google Maps reducerade filvolymen med 30% och and fick 30% fler kartförfrågningar
  • Netflix aktiverade gzip på sina servrar och med den enkla förändringen blev deras webbplats 13-25% snabbare och de lyckades dessutom spara in på 50% av trafikvolymen!
  • Shopzilla minskade laddningstiden från 7 till 2 sekunder och ökade antalet konverteringar med 7-12%.Dessutom fick de en 25-procentig ökning av sidförfrågningar samtidigt som de kunde pensionera 50% av sin serverpark och reducera kostanderna.

Trevligt! Hur går man då tillväga? Det finns det ett antal tjänster som kan mäta upp och hjälpa dig med detta, t.ex. Keynote, men det är relativt enkelt att mäta det själv och genomföra åtgärder baserat på resultatet. Du kan antingen ladda ner Firebug och tillägget Page Speed som analyserar och generar en lista på vad du bör förbättra. Eller så kan du vänta till senare i veckan då jag gör ett nytt inlägg över hur du kan använda dig av Google Analytics till detta.

 

 Scroll to top