När jag och Robert NybergRobert Nyberg arbetade ihop för ett par år sedan var det inte sällan man såg att hederliga HTML sidor kunde spöa skiten ur moderna sidor som genererades via något CMS, och jag minns att detta diskuterades ett antal gånger om varför det varit så. Nu har jag ägnat en del tid till att optimera för pagespeed och en tanke dök upp för ett par nätter sen.

Ett litet tankeexperiment...

Jag har pluggat en del och älskar att leka med tankeexperiment för att ta fram hypoteser och sedan bevisa dom genom experiment, dock har jag idag inte tiden för att testa, vilket är väldigt synd, men vi kör...

En del antaganden..

Vi börjar med att fastställa ett par antaganden som sedan står som bas för experimentet, och därför kommer ett par påståenden.

  1. Om vi antar att Sökmotorn inte favoriserar någon plattform, utan endast utgår från externa parametrar som genererad HTML kod, pagespeed, länkbarhet etc så bör det gälla att alla siter är i grunden lika inför sökmotorn, om den genererade koden och länkflödet är detsamma (ink inlänkar).
  2. Så om alla andra faktorer är identiska så bör pagespeed vara den faktorn som avgör vilken av dessa siter som rankar bäst.
  3. Att hämta data från disk är oändligt mycket långsammare än att hämta från arbetsminnet.
  4. Kod som genereras via ett CMS bör vara långsammare då den först skall generera en HTML output som sedan skall serveras till klienten.

Härifrån skall vi arbeta utifrån 2 st olika scenarion, i båda fallen så antar vi att CMS-lösningen arbetar med för-cachning, dvs att den cachear automatiskt varje, låt oss säga kvart, för att inte den genererade koden skall ramla ur minnet.

Cachen....

För att speeda upp cms genererad kod lite kan man arbeta med att mellanlagra färdig html-kod, något som kallas för cache, detta är ett mycket förenklat diagram, men man bör förstå principen.Enkel skiss över cache

  1. klienten ställer en fråga till servern
  2. servern letar i cache om det begärda dokumentet finns lagat där.
  3. vid JA! skickas det cacheade dokumentet till klienten.
  4. vid NEJ! begär vi en systemet att skapa dokumentet som sedan skickas till cache och till klienten.

Cachen blir utdaterad efter ett tag och det brukar fungera så att dokument som blir begärda efter ofta får tillbringa mer tid i cachen.

Det finns dock en teknik att man automatgenererar träffar så att dokumnten ständit har en uppdaterad kopia av alla dokument i cache, i vårt tankeexperiment utgår vi ifrån detta.

Vi kommer också att arbeta utifrån 2 olika cacheningstekniker, disk och arbetsminne.

Frågeställningen: Om jag har 2 st identiska siter, vilken laddar snabbast, den cacheade eller den som är i ren html?

Scenario 1: HTML vs no cache.

Här bör HTML vara klar vinnare!

filen serveras direkt från servern till klienten från disken, inga som helst mellansteg, om vi har ett CMS så måste först scripten hämtas från disk, köras av programtolkaren som sedan genererar HTML som sedan skickas till servern, detta bör ta mycket längre tid.

Scenario 2: HTML vs Disk Cache.

Här blir det svårt, teoretiskt sett borde det vara oavgjort vid identiska förhållanden, men jag tror att den lilla extra svängen med att fråga om dokumentet finns KAN komma att spela till HTML's fördel, men jag är inte säker.

Scenario 3: HTML vs Cache i arbetsminnet.

Det var här min tankegång började och jag är rätt säker på att CMS-lösningen i de flesta fall kommer att komma ut som vinnare ur detta, och svaret är enkelt: busshastigheten mellan processor och disk är oändligt mycket långsammare än mellan processor och arbetsminne, men jag kan ha fel...

Slutsats:

Min slutsats är enkel, man bör ha en bra servermiljö i dagens läge och utnyttja de cacheningsmöjligheterna som finns, jag är rätt säker på att man tjänar mycket på att ha en servermiljö som stödjer opcode cachening eller memcache, jag är bara förvånad över att flera av de stora webbhotellen inte snappat upp det än.

Är det någon som har lust att testa om jag har tänkt rätt? Då skulle jag vara ytterst tacksam!

/Cristian Herrera