Kategoriarkiv: Webb

Bloggen flyttad till WordPress

Sådär. Då är bloggen flyttad till WordPress med allt vad det innebär i form av enklare möjligheter att blogga mobilt och upprätthålla manuella och automatiska kopplingar till sociala nätverk och andra bloggare.

För mig är spontanbloggande på överbliven tid troligen nyckeln till kontinuitet och bloggen bör passa perfekt som komplement till mitt twittrande.

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)

Hänger ditt publiceringsverktyg med?

Jag fick äntligen lite tid idag att läsa Jajjas SEO-test av CMS-verktyg som publicerades några dagar innan jul. Som alltid är testet intressant och en sak som blir väldigt uppenbart nu när testet publicerats ett antal år är att CMS-verktygens SEO-egenskaper är färskvara. Vissa av de system som klarar sig riktigt bra i årets test har presterat sämre i tidigare tester. Det är en naturlig följd av att sökmotoroptimering hela tiden är en jakt mot rörligt mål där dagens sanningar är förlegade om ett eller två år.

Av det här drar jag tre slutsatser:

  1. Skräddarsydda publiceringsverktyg blir en allt sämre idé. Det finns inga möjligheter för de kunder som låter skräddarsy ett system för allmän webbpublicering att hänga med i utvecklingen. Förvaltningskostnaderna för att hålla ett skräddarsytt system aktuellt blir helt enkelt för höga.
  2. Den som ska bygga en ny webbplats bör säkerställa att man väljer ett publiceringsverktyg som lever. Döende system där uppdateringarna kommer allt glesare innebär ett rejält problem. Det handlar inte längre bara om att information är instängd i systemet utan också om att sajten successivt får allt sämre synlighet i sökmotorerna.
  3. Sajten måste underhållas. I vissa system, t ex Dynamicweb som är ett av de system som vi jobbar med, installeras nya versioner automatiskt men i de flesta system måste någon installera uppdateringar manuellt. Oavsett vilket så är det viktigt med regelbundet underhåll under huven på sajten så att den alltid drar nytta av moderna SEO-tekniker. Alltså, se till att teckna uppgraderingsavtal eller motsvarande för det CMS du använder och säkerställ att uppdateringar också installeras så att ni drar nytta av ert verktygs fulla potential.

Det finns ett problem med testet, nämligen att några av de absolut vanligaste systemen i Sverige inte finns med. Såväl Joomla! (som är Sveriges näst vanligaste öppen-källkodssystem), Umbraco (ett annat vanligt öppen-källkodssystem) och de kommersiella systemen EPiServer och SiteVision saknas. EPiServer och SiteVision är nummer ett och nummer två bland publiceringsverktyg i offentlig sektor och denna sektor lämnas nu alltså utan vägledning kring SEO-egenskaperna för sina system och det är lite synd.