Amazons Silk Browser Acceleration Testad: Mindre bandbredd förbrukad, men långsammare prestanda

Vi har arbetat på vår Kindle Fire-recension under helgen men jag tänkte bryta ut en särskilt intressant del av recensionen för utgivning lite tidigt. Vid lanseringen introducerade Amazon en ny webbläsare som heter Silk.

Silk är ännu en webbkitbaserad webbläsare med alla de vanliga funktionerna: surfning med flikar, Flash-stöd, integrerad sök-/URL-fält, etc… Det som gör Silk unikt är dess förmåga att kanalisera dina webbförfrågningar genom Amazons webbtjänster (AWS) ) moln. En typisk laddning av AnandTech.com hämtar innehåll från tretton olika värdar. Varje värd kontaktas, begäran bekräftas och sedan utbyts data mellan den och din webbläsare.

Amazon anser att detta är ett ineffektivt sätt att ladda en webbsida. Med Silk skickas förfrågan till Amazons moln, där Amazons servrar hämtar (och cachar) alla delar av webbsidan och levererar resultatet direkt till dig.

Tabellen nedan visar alla IP-adresser som kontaktas när du laddar AnandTech.com med och utan Amazons molnaccelerationsfunktion aktiverad:

Listan med 13 reduceras till en enda IP-adress. Minskningen är ännu mer imponerande om man tittar på vad den gör med en mer involverad förstasida som Engadgets: där sjunker listan från 34 till 1.

Amazon hävdar att cachelagring på molnsidan kan förbättra prestandan, men jag var skeptisk till detta påstående. En stor del av webbsidans laddning på smartphoneplattformar är faktiskt CPU-bunden. Det är därför du märker en prestandaskillnad när du uppgraderar från en två år gammal smartphone till en modern modell, även om båda körde samma OS. De delar av laddningsprocessen som inte är CPU-bundna är vanligtvis begränsade av hastigheten på det mobilnät du är på. AT&T:s 3G hemma hos mig når upp till 3 Mbps, men oftare än inte ligger den nere i intervallet 1 – 2 Mbps. Saker och ting är ännu värre på Verizons EVDO-nätverk där jag får hastigheter under 1 Mbps. Att konsolidera nätverksåtkomst på ett cellulärt nätverk verkar vara vettigt, det finns bara ett problem: Kindle Fire lanserades som en endast WiFi-modell.

Time Warner uppgraderade nyligen (äntligen?) Raleigh-området till DOCSIS 3.0. Kunder kan köpa kabelinternetabonnemang med maximalt 50 Mbps nedströms. WiFi-stacken i Kindle är begränsad till cirka 15 Mbps så även om du väljer ett långsammare internetpaket bör du kunna överträffa vad Kindle Fire kan konsumera. För att inte tala om de irriterande CPU-begränsningarna kommer att hindra dig från att ladda någon webbsida med ens 15 Mbps.

Valet att lansera denna moln-caching-funktion tillsammans med Kindle Fire verkade alltid misstänkt. Om Amazon skulle introducera en 3G Kindle Fire med en mycket prisvärd eller till och med free dataplan, kan molncache ha varit vettigt. Under tiden var jag nyfiken på att se vad det gjorde med webbupplevelsen på Kindle Fire.

Jag började med att göra några obearbetade laddningstester för webbsidor. Jag valde tre webbsidor: AnandTech.com, Engadget.com och NYTimes.com. Jag laddade var och en 10 gånger i rad och tog ett genomsnitt av alla körtider. Jag gjorde samma sak med och utan Silk-webbläsarens accelererade sidladdningsfunktion aktiverad (molncache).

Resultaten är nedan:

Som väntat gör Amazons accelererade sidladdning inget för att påskynda sidladdningar. Faktum är att det saktar ner jämfört med att gå direkt till servrarna jag försöker nå. Siffrorna speglas i min egen användning av Kindle Fire. Webbsidor laddas helt enkelt långsammare om du har den här funktionen aktiverad.

Bandbreddsbesparingar: Cirka 10 %

Amazon hävdar också att det kan förbättra prestandan genom att optimera innehållet för enheten du tittar på det på. Med andra ord kan Amazon utföra komprimering på serversidan av saker som bilder för att ge en till synes förlustfri minskning av filstorleken och därmed förbättra prestandan.

Detta påstående var lite svårare att undersöka eftersom att begära en fullständig okomprimerad JPG inte verkade gå igenom Amazons komprimeringsrutin. Istället sniffade jag Kindle Fires trafik på mitt nätverk och tittade på det totala antalet överförda bytes för en handfull sidförfrågningar. Den här gången tittade jag på samma tre webbplatser från tidigare (AT, Engadget, NYTimes) men lade också till CNN.com för något lite mer mainstream, och Reddit.com för något lite mer fantastiskt (och texttung).

För att hantera det faktum att det här är webbsidor med ständigt föränderligt innehåll körde jag alla tester rygg mot rygg, för att säkerställa att det faktiska webbplatsinnehållet inte ändrades mellan körningarna. Jag körde också varje test minst 5 gånger för att hantera eventuella skillnader i annonser som laddas. Jag rensade cachen mellan varje körning för att alltid begära data från Amazons servrar. Resultaten var anmärkningsvärt konsekventa. Återigen finns uppgifterna nedan:

Det genomsnittliga komprimeringsförhållandet för dessa testwebbsidor via Amazons servrar var 0,891. Allt verkade minska ganska förutsägbart, undantaget är CNN.com som såg ett kompressionsförhållande på 0,801. Det är möjligt att CNN:s innehåll är onödigt stort och kan stå för en egen optimering på serversidan. Det är intressant att till och med Reddit, en texttung sajt, kunde se några fördelar med Amazons accelererade sidladdningsfunktion.

Det är värt att notera att den genomsnittliga kB som sparas genom att aktivera accelererad sidladdning är endast 174 kB. Det motsvarar knappt 10 % av den genomsnittliga sidstorleken på 1758 KB i detta test. Om du är starkt begränsad av bandbreddstak kan dessa besparingar komma till nytta, men annars är de inte tillräckligt stora för att märkas.

Om mängden överförd data är mindre, men sidorna tar längre tid att ladda kan detta bara betyda en sak: överföringshastigheterna är långsammare från Amazon. De är faktiskt:

När jag laddade NYTimes.com hade jag i genomsnitt (igen, över fem körningar, cache rensad mellan var och en) 1,93 Mbps med accelererad sidladdning inaktiverad och 1,26 Mbps med funktionen aktiverad.

Nyfiken på att testa min teori om att cachelagring på molnsidan är ett bra mål för en framtida 3G Kindle Fire, kopplade jag surfplattan till min iPhone 4S och använde AT&T:s 3G-nätverk för alla sidladdningar.

Jag valde tre sajter den här gången: AT, CNN och Engadget. Jag valde dessa tre eftersom CNN hade mest nytta av Amazons komprimering och AnandTech straffades mest genom att gå igenom Amazons servrar. Engadget var helt enkelt en bra mellandatapunkt mellan de två.

Tyvärr även på AT&T:s 3G-nätverk gjorde Amazons accelererade sidladdning saker långsammare. Effekten var inte lika märkbar som den var över WiFi, men den finns där. Om du är en Kindle Fire-ägare och vill ha den snabbaste surfupplevelsen, vill du inaktivera Silks accelererade sidladdning.

Men varför?

Jag har några frågor om molnsidans cachingfunktion i Amazons Silk-webbläsare. Idag finns det inga uppenbara prestandafördelar med att använda funktionen och även på AT&T:s 3G-nät såg jag ingen fördel. Ur slutanvändarens perspektiv är Silks “molnbaserade” cachelagring inte bara meningslös, utan det är en nackdel för den övergripande användarupplevelsen.

Visst måste Amazon ha gjort denna testning internt och valt att lansera Kindle Fire med den ändå. Det finns en enorm fördel ur Amazons perspektiv för miljontals Kindle-användare som surfar med det aktiverat: datautvinning. Amazon kan lära sig mycket om sina användares användningsmönster genom att bara övervaka Silk-förfrågningar till AWS-servrar. I teorin skulle Amazon kunna ta dessa data och ytterligare optimera surfupplevelsen för Silk-användare. Det finns mycket mer smutsiga förklaringar också som jag inte kommer att dyka ner i här.

Det är värt att notera att alla webbplatser jag testade med idag verkar vara på ganska robusta nätverk. Funktionen för accelererad sidladdning kan ha en positiv inverkan när du besöker webbplatser som inte är värdar. Jag skulle säga att listan förmodligen är ganska snäv nuförtiden med tanke på uppsjön av free innehållshotelltjänster (wordpress, blogger, imgur, flickr, etc…).

Det finns också möjligheten att Amazon arbetar för att möjliggöra en 3G Kindle Fire med en mer prisvärd/free dataplan. Därvid skulle det vara motiverat att minska bandbreddsförbrukningen så mycket som möjligt.

Tills Amazon antingen blir mer aggressiv med Silks molnsida-caching eller släpper en enhet som verkligen kräver bandbreddsbesparingar, är jag lite förbryllad över fokus på funktionen vid lanseringen.