månadsarkiv: juni 2012

Så fixade vi bra Pagespeed-ranking på infobyte.se

Att vår egen sajt, infobyte.se är tekniskt välbyggd är såklart en prestigegrej för ett företag som bygger och driftar hemsidor av olika slag. Vi satsade tidigt på att se till så att vår sajt klarade W3C:s valideringstest och nyligen lanserade sajten Webbfunktion.com ett jämförelsetest över hemsidors ranking i Google Pagespeed.

Bland annat publicerades en jämförelselista över olika webbföretags optimeringspoäng. Vi hamnade högt redan från början med en ranking på drygt 90 av 100 möjliga poäng. Men trots allt fanns det en del att göra och med relativt enkla grepp har vi nu intagit en absolut topplacering bland svenska webbaktörer med poängen 99 av 100.

Goda förutsättningar

Vi använder Lemoon CMS på vår hemsida (och på denna blog) och vi driftar sajten på en egen server. Det ger oss säkert en del möjligheter att optimera som inte alla har. Om man till exempel placerat driften av sin hemsida på ett webbhotell kan man troligen inte ta till alla trix som vi gjort. Lemoon CMS innehåller i sig också goda möjligheter att skriva högpresterande hemsidor, bland annat tack vare Dotnets möjligheter att cacha data, siddelar och hela sidor på olika sätt. Dessutom funkar Lemoon CMS så att all kod som presenteras skapas av den som utvecklar mallar och funktioner. På gott och ont. En skicklig utvecklare har i Lemoon CMS och utvecklingsverktyget Visual Studio alla möjligheter att gör bra hemsidor men en mindre skicklig utvecklare har inget direkt stöd och hindras inte på något vis från att göra mindre lyckade saker.

Ändringarna vi gjorde

  1. Alla bilder som används i mallarna låg redan tidigare utanför Lemoon CMS:s filhantering. Vi brukar bygga så eftersom det gör det svårt att förstöra sajtens mallar av misstag. Om en redaktör inte kan radera eller ändra bilder som mallarna används så blir mallarna i princip oförstörbara (redaktören kan ändå inte ändra i mallarna i sig inne i Lemoon CMS). Katalogen där bilderna till mallarna lagrades hade dock inte optimala inställningar för cachening i besökarnas webbläsare. För hela mappen där mallbilderna lagras så har vi lagt in en expire-tag i http-headern.
  2. Vissa bilder i våra hemsidors innehåll var genererade med Lemoon CMS:s inbyggda funktion för att skala om bilder. Den komprimerar uppenbarligen inte bilderna optimalt. Till Lemoons försvar så ska man då säga att hård komprimering av bilderna nästan aldrig blir bra om det görs maskinellt eftersom det krävs en balansgång mellan hur det ser ut och vilken komprimeringsgrad som man önskar. De bilder som drogs med detta problem har vi lyft ut från Lemoon CMS och placerat i en filkatalog utanför systemet där vi också angett en expire-tag i http-headers. Det här är såklart inte optimalt ur redaktörssynpunkt eftersom redaktören då inte längre kan underhålla bilderna från Lemoons filarkiv, men för att ändå fullfölja experimentet med att se hur långt det går att optimera en hemsida som använder Lemoon CMS så gjorde vi ändå så.
  3. Vi har använt sajten minifycss.com för att minimera hemsidans stilmall. Vi har också slagit ihop ett par stilmallsfiler så att vi nu bara har en egen stilmallsfil.
  4. Vi har flyttat de Javascript som används för Google Analytics och AddThis så att koden nu ligger på vår egen server där vi kunnat sätta rätt cacheoptimering på scripten. Det är ju för övrigt lite pikant att Googles egen Analytics-tjänst inte publicerar sin programkod på ett sätt som uppfyller kraven i Google PageSpeed.
  5. Ett antal bilder, till exempel flaggorna för att hoppa mellan olika språkversioner av sajten, har slagits samman och placerats i CSS Sprites. Det borde vi egentligen ha gjort för länge sedan men först nu blev det av.
  6. En del annat mindre fix också som att ta bort onödiga radmatningar och renderingen av viss bortkommenterad htmlkod

Har detta någon betydelse då?

I vårt eget fall kan man nog säga nej. Vår sajt fungerade utmärkt även innan ändringarna gjordes och visuellt går det inte att se några skillnader alls och troligen kan en vanlig användare på en vanlig uppkoppling inte märka någon prestandaskillnad i praktiken. Vi har inte heller sådär överdrivet många besökare på vår hemsida att belastning är ett problem så vi behöver inte minimera antalet hämtningar av olika objekt av den orsaken. Så det här har mer handlat om att visa att det går att optimera bra om man vill.

Jag tycker att initiativet från Webbfunktion.com är bra. Det är skillnad på ”bra” och ”dålig” htmlkodning, i vissa fall duger mindre bra kod utmärkt och ofta ser en användare ingen som helst skillnad i sin webbläsare men en välskriven sajt som validerar hos W3C och som har hög ranking i Google Pagespeed bör fungera bättre när det kommer nya webbläsare och brukar därmed minska underhållskostnaderna.

En hemsidesköpare bör också kunna förvänta sig att sajten i alla fall är producerad med rimliga mått av fackmannamässighet och det finns väl alltså ingen bra anledning att acceptera en leverans som ligger lågt på Google Pagespeed-skalan eller innehåller många valideringsfel.

Nästa steg

Vi ska såklart försöka fixa den där sista poängen också om det går att göra med rimliga ansträningar. Problemet är dock att det inte längre finns några rankingpåverkande anmärkningar från Google så det blir lite som att söka efter ett problem som inte finns. Vi har dock fått nästan blanka experimentsajter att ranka 100 av 100 poäng så på något vis måste det gå även på en skarp sajt. Och någon gång när det finns lite tid över så ska jag såklart titta över även denna sajt som väl rankar runt 90 av 100 päng.

Mer läsning i ämnet

6 vanliga prestandaproblem och dess lösningar – Webbfunktion.com

The Need for speed – Technologyreview.com (PDF)