Optimera Stockholm

Det är lite lockande att som Göteborgare passa på att skämta om bästkust och hur man har behov av optimering i Stockholm medan allt är fint i Götet, men dagens seminarie/minikonferens (twittertag #optsthlm) på ämnet webboptimering/webbprestanda förtjänar inget annat än lovord! Talarnas ämnen och innehåll var mycket väl utspridda över hela problemrymden från server till klient och allt där mellan.Organisatörerna skötte sig bra i alla hänseende, t ex i form av val av lokal, livesändning (som flera följde och kommenterade över twitter), strömförsörjning, hålla tiden och i allmänhet hålla sig i bakgrunden för att släppa fram talare och deras ämnen. Kanon! Innan jag sammanfattar dagens ämnen skall kort konstruktiv kritik framföras för det som kan förbättras: starta en kvart senare (9:15 istället för 9) så hinner man som Göteborgare och lite mer fikatid så blir det perfekt! :)

Introduktion

Måns Jonasson (@mansj) från .SE började med att jämföra med webben 1996, en tid då alla satt med 14.4-modem och bandbredd var både långsamt och smalt. På den tiden optimerade alla sina webbsidor för att ladda snabbt – optimering var naturligt och vanliga webbkonton hos t ex Algonet tilldelades hela 5 MB lagringsplats. Nu för tiden är disk på servrar billigt, liksom bandbredd (trafik och kapacitet) och Måns pekar på någon form av “alla har ju bredband ändå”-mentalitet. Tre saker utpekas som orsaker till att optimering inte genomförs:

• tidsbrist nedprioriterar optimering,
• erfarenhetsbrist – “varför skall man bry sig om att vinna en sekund snabbare laddning”?
• pengar – det kostar.

(Jag hade ju hävdat att tid är pengar och därför är det bara två punkter som pekas ut … :)

Hälsoläget

Patrik Wallström (@pawal) från .SE tog därefter över stafettpinnen och berättade om vad “Rapport Hälsoläget” är och hur .SE mäter och utvärderar hur “internet” fungerar. Bl a innehåller rapporten analys av DNS-delegeringen (dnscheck) av domäner under .se, kontroll av e-postsystem (mailcheck) inkl anti-phishing-tekniker som SPF, DKIM, TLS*, ADSP.

Hälsoläget är numera data-insamlad en gång i månaden. Medelstorlek på en webbplats under .se ligger på ca 200KB, fler och fler använder gzip. De 100 snabbaste siterna var i princip “It works!”-sidor från Apache (föga intressant) så Patrik hade istället tittat på de 100 långsammaste, som alla var långsamma CMS-installationer (Joomla, WordPress, Sharepoint). För identifiering har trends.builtwith.com använts hittills, men whatweb kommer nog användas (och utökas) i framtiden. Förslag på vad som kan och bör mätas mottogs tacksamt och jag föreslog att man försöker mäta upp hur dåliga DNS-servrarna är hos ComHem de få ISP:er vi har i landet (eftersom ISP:erna själva inte ser det som ett problem tycker jag det skall lyftas fram av de som kan lyfta fram det i ljuset).

Optimera WordPress

Erik Torsner från LoadImpact.com pratade om problemen som WordPress dras med och det främsta är minnesförbrukning för att generera sidor. En ren 2.9-installation kräver 16 MB per anrop till en sida med ett bloginlägg. Plugins som All-in-one SEO och Similar Posts lägger vardera på 1 MB. Värstingen är WPML (flerspråksplugin) som trycker upp minnesförbrukningen till 70 MB per anrop!

Ett par tips lämnades. Först ett par allmäna som att se över databas och mäta minnes- och CPU-förbrukning (lägg in en memory_get_peak_usage() i footern). Därefter tipsades om att använda en cache-funktion, t ex någon av alla de WP-plugins som finns. W3 Total Cache (W3TC) kan komprimera, minifiera, kombinera script-anrop och stödjer hosting av media på CDN. Dessutom kan den “kortsluta” (kringgå hade jag kallat det) PHP-stacken genom att skriva ner resultatet för en sida till disk och låta Apache serva den direkt (via mod_rewrite-magi).

Ragnar Lönn från samma bolag fortsatte sedan med att tipsa om mätverktyg. Påminde också om att Google sedan 2008 väger in landningssidans laddtid i AdWords quality score. Han nämnde också Shopzilla som genom att sänka sin laddtid från 7 sekunder till 2, såg:

• 25 % fler sidvisningar,
• 10 % ökade intäkter, och
• fick 50 % lägre infrastrukturkostnader.

Sidanalys

• Firebug med
  • YSlow och
  • Google Page Speed.

(Ragnar påstår i förbifarten att POST för Ajax är lika bra som GET(!) – YSlow hävdar motsatsen.)

Extern sidanalys (alla gratis i viss omfattning, men inte fria)

• pingdom tools (minus är att de inte parse:ar CSS:en och därmed inte tankar grafik som tankas i vanliga fall)
• Load Impact Page Analyzer – emulerar olika klienter, kan begränsa bandbredd
• webpagetest.org – bara IE7 IE8
• browsershots.org

Lasttest

• grinder (saknar bra medföljande GUI)
• openSTA (windows only)
• Apache Bench
• Load Impacts eget verktyg
• browsermob.com
• loadstorm

Fikapaus med frukt, kaffe/te och småmackor.

Ajax och REST

Stefan Pettersson från Netlight pratade sedan om hur han föreslår att man kan “Snabbare tjänster med Ajax och REST”. Innehållet var det inget fel på alls men så basic att jag inte förde en enda anteckning (förutom på min frågelapp, nämligen att de “hajpade noSQL-alternativen” faktiskt också skalar bort en box i hans presentation – datakonverteringen, lite bakläxa där tycker jag på ett annars bra innehåll).

Mer data på kortare tid, tack!

Daniel Stenberg från haxx fortsatte sedan med den tekniktungaste presentationen som rörde sig på transportnivå och pratade om problem med TCP och möjligheter med nya protokoll och experiment. Han sammanfattade själv i följande punkter:

• RTT står i princip still trots att bandbredd ökar
• TCP har fördröjning och det drabbar HTTP (och alternativ finns, men till skillnad från IPv4-IPv6 så står ingen och säger “nu MÅSTE vi byta”, betänk t ex alla brandväggslösningar som inte vill ha SCTP)
• använda rätt API:er (libevent vs poll/select) – upp till 70 % bättre throughput
• WebSockets, SPDY, SCTP, MPTCP

Daniel skulle inte bli förvånad om MPTCP (multi path) blir verklighet snart, dvs att man kan nyttja t ex både WLAN och GPRS/motsv från sina mobila enheter samtidigt.

Lunch.

Skalbarhet i molnet

Martin Källström från Twingly gick igenom grunderna i skalbarhet och landade tillslut i att det finns ingen teknik som ger skalbarhet från början, utan detta är något man bygger in i s in applikation (om han inte kört dotnet så mycket kanske han vetat att JEE-specen tar upp horisontell skalbarhet och “ger” (säljer in) stöd för det).

Konkreta tips delas liksom erfarenheter av t ex Amazon S3 (dyrt, långsamt, support kostar extra). Det dyra för twingly är de ca 4 miljarder anropen man får per månad – datamängden är inte stor alls. För skalning av long-polling-lösningar (Comet) använder man Hetzner.de. Andra erfarenheter Martin talade om var problematik kring:

• nertid och serverflytt,
• Comet kräver systemkonfiguration som saknades i VPS,
• fluktuerande valuta (balansera med intäkter i de aktuella valutorna).

Klientsideoptimering

Svante Adermark (med kompis) från Trimlabb (del av Fleecelabs) var först ut på detta ämne och gav en presentation som innehållsmässigt var väldigt lik den presentation jag höll för dotnet- och JavaForum i februari! (Jag försökte ha bilder istället för text.) Vi hade nästan exakt samma rekomendationer om lågt hängande frukter och ev skillnader tjötade vi om under eftermiddagens

Fikapaus.

Optimering av stockholm.se

Isac Lagerblad från Creuna pratade sedan om hur man hade tagit steget ut ur garderoben och tagit tag i webbplatsens prestanda med bl a CSS-spriting, minifiering och konkatenering … Dyrast tyckte Isac att konkatenering varit, samt underhåll av CSS-sprites.

JavaScriptoptimering

Jacob Hansson från Skyforge och VoltVoodoo höll dagens intressantaste presentation (tyckte jag) med lite tips och nyheter som jag inte sett tidigare: Speedtracer för Google Chrome. Seesmic hade tjänat tre sekunder i uppstarttid på någon applikation genom att slå ihop Ajax-anrop istället för att skicka dem ett och ett. Rekomenderade också att man lägger tid på code-splitting (optimera startsida från de andra t ex).

Övriga tips var att hålla sig under 50 millisekunder i all exekvering. Med QUnit och JSLitmus föreslog Jacob att man skall se till att man håller sig under den gränsen (regressionstester) och jake är ett byggverktyg som han förordade. För testning i multipla browsers nämnde han två lösningar: JS Test Driver och Mozillas croud source-baserade lösning.

Ingen nämnde under dagen lazy-laddning av JavaScript som kommer utkommenterad från serversidan, som sedan kan aktiveras vid behov genom att evaluera koden utan start- och slutmarkörer: eval(src.substring(2, src.length – 2)).

Squid och andra cachelösningar

Henrik Nordström avslutade dagen genom att titta på hur man kan sätta upp squid som reverse proxy för att avlasta, lastbalancera osv. Henrik gav sig också på att uppmuntra till alla att få Etag-headern rätt använd – modigt! :)

Sammanfattning

Detta var kanon och blev lite plåster på såren för att jag missar SWDC i år också. :P