Google: Spdy-protocol versnelt opvragen websites tot 40 procent

Google heeft nieuwe cijfers gepubliceerd over het steeds breder gebruikte Spdy-protocol. Spdy, dat zal dienen als basis voor het http 2.0-protocol, zou bij trage internetverbindingen websites tot ruim 40 procent sneller inladen.

Het Spdy-netwerkprotocol werd door Google in 2009 geïntroduceerd met tot doel het inladen van websites te versnellen. Daarvoor past het protocol onder andere compressie en flow control toe. Ook worden https-verbindingen afgedwongen in het http-alternatief. Nadat Chrome als eerste browser het protocol benutte, volgden ook browsers als Opera, Firefox en Internet Explorer. Websites en -servers gingen eveneens het protocol toepassen.

Inmiddels heeft Google nieuwe cijfers vrijgegeven over de prestaties van Spdy ten opzichte van reguliere https-verbindingen. Daarvoor zijn statistieken gebruikt van miljoenen Chrome-gebruikers met zowel snelle als trage internetverbindingen. Als versie werd voor Chrome 29 gekozen.

Uit de cijfers van Google blijkt dat met name internetgebruikers met een trage verbinding profiteren van Spdy. Zo zou Google News tot 44 procent sneller laden, tegenover 32 procent voor personen met een rappe verbinding. Ook Google Sites, Drive en Maps laden sneller met respectievelijk een snelheidswinst van 27, 23 en 24 procent.

Google denkt dat er nog meer snelheidswinst is te boeken met Spdy. Zo werkt het aan 'slimmere' compressiemethoden, terwijl ook extra optimalisaties in de prioritering en de flow control worden bestudeerd. Wanneer deze verbeteringen zichtbaar zullen worden, is nog niet duidelijk.

Reacties (69)

Een goed iets. Ik heb een tijdje geleden een presentatie gegeven tijdens college over dit onderwerp, velen kenden het nog niet en waren zeker verrast.

SPDY is zeker snel, voor Google Chrome is een plugin beschikbaar die aantoont wanneer SPDY wordt gebruikt. Wanneer de browser SPDY niet ondersteund is er ook een fallback.

edit: link toegevoegd SPDY plugin

[Reactie gewijzigd door NeFoRcE op 21 november 2013 14:06]

Google is bezig met een flink aantal initiatieven om de internet-ervaring te verbeteren. Meer snelheid, complexere toepassingen, meer standaardisering, meer toegang en meer productiviteit. Prettig dat ze in dit geval wel hun "don't be evil" adagium lijken toe te passen.

• Spdy applicatie protocol;
• Angular framework voor single site applicaties;
• Polymer framework voor (toekomstige) webapps;
• Open source V8 virtual machine voor javascript performance;
• Open source Chromium project voor de browser;
• WebM en WebP voor media;
• Internet via ballonnen;
• Internet via glasvezel;
• Alternatief voor Javascript: Dart;
• Een sandbox omgeving voor native code: PNaCl
• Graphics via de browser: WebGL

De strategie mag duidelijk zijn. Hoe meer online gebeurt, des te relevanter is het voor Google. Ik verwacht niet dat alle initiatieven zullen slagen, maar met name Dart belooft een revolutie te gaan zijn.

De intentie is ook duidelijk: Als mensen door deze technieken 10% meer pagina's kunnen bekijken in dezelfde tijd, zien ze ook 10% meer (google-) adds.

Neemt niet weg dat de hele wereld er van profiteert en dat het goed in hun doelstelling past alle mogelijke informatie voor de hele wereld te ontsluiten.

[Reactie gewijzigd door mcDavid op 21 november 2013 16:48]

Je lijstje is bijna compleet maar sommige ervan zijn helemaal niet door Google ontwikkeld en sommige zijn alleen maar door Google overgenomen.

WebGL is designed and maintained by the non-profit Khronos Group.
AngularJS was originally developed in 2009 by Miško Hevery and Adam Abrons
Google had WebM en WebP eerder overgenomen van On2 Technologies

Alle Google trackers en advertenties verwijderen van een site levert denk ik ook een snelheidswinst van 40% op.

Yup, makkelijk te doen met een adblocker of cross-domain-request blocker. Je hele internetverbinding is enorm veel beter (zowel sneller ladende pagina's als minder flashy banners), daar is geen SPDY voor nodig.

Wow, dart bestaat echt,

had er sinds de aankondiging in oktober 2011 niets meer van gehoord van google, maar sinds vorige week echt een release, benieuwd hoe revolutionair het zal zijn, 2jaar later...

Het is een volwassen release. Het werk dat in de taal en libraries gestoken is, is werkelijk indrukwekkend.

Er zijn ook nog veel gaten, zoals een node.js of meteor achtig framework. Overigens zijn veel van de zaken in de taal zelf al afgedekt (zoals io) of zelfs beter (zoals concurrency). Beeldbewerking, etc etc.

De basis is er en de bal ligt nu bij de community. Al met al zou ik het nog niet in productie gebruiken en dan alleen aan de client kant.

Geeuw..

Heb even snel gezocht, en het blijkt dat Firefox standaard ook al SPDY ondersteunt.

Ook voor Firefox is een add-in beschikbaar waarmee je kunt zien op welke sites het gebruikt wordt:
https://addons.mozilla.org/nl/firefox/addon/spdy-indicator/

Bedankt voor deze tip!

Deze plugin werkt ook op Waterfox (een 64 bit variant van FF). En zeer waarschijnlijk dus ook in Cyberfox 9weer een andere 64 bit variant van FF).

Hoe kun je SPDY op de server kant gebruiken dan? Ik vind het zeer interessant.

Dit zorgt ervoor dat webapps nog verder in zicht komen. Nog een punt waarom een website vaak trager is dan een Native app is vanwege DOM manipulaties. Die moet je zo min mogelijk toepassen. Of er moet een oplossing voor komen voor snellere DOM Manipulaties.

Zie deze link:

https://developers.google.com/speed/spdy/mod_spdy/php

Bedankt, maar ik ga me geen PHP meer aanleren. Dat zal toch over een paar jaar in de vergetelheid gedrukt worden. Er is volgens mij ook een NodeJS of een GO toepassing voor.

Deze plugin werkt ook op Opera 18.

handig die link, thx!

1 van de redenen waarom google diensten nog exclusief op https werken, spdy werkt enkel met versleutelde verbindingen. Ik kan alleen maar hopen dat het gebruik van https snel de standaard word op internet.

Je kunt zelf beginnen.
Met het installeren van een browser-plugin die https afdwingt voor al je web-requests.

Genaamd "HTTPS Everywhere".
Gesponsored door de Electronic Frontier Foundation (de "good guys").
Available voor Chrome en Firefox.
Ik gebruik het nu zelf gedurende een jaar of zo. Nog nooit problemen mee gehad. Aanrader.

https://www.eff.org/https-everywhere

Ik gebruik zelf ook al jaren HTTPS-Everywhere en ben er erg tevreden over. Het werkt inderdaad met een fikse whitelist met bekende sites waar Secure alternatieven voor zijn.

Het enige kleine nadeel wat ik zover ben tegengekomen is hier op Tweakers. Ik browse standaard via HTTPS dankzij deze plugin maar omdat reageren niet over HTTPS gaat moet ik altijd een extra enter indrukken om de waarschuwing 'unencrypted connection' weg te drukken. Maar goed, daar ben ik dus ook al lang aan gewend.

* ^{Although this page is encrypted, the information you have entered is to be sent over an unencrypted connection and could easily be read by a third party. Are you sure you want to continue sending this information?}

[Reactie gewijzigd door Maurits van Baerle op 21 november 2013 16:16]

Hoe weet de plugin dat er een https versie is?

De plugin komt met een whitelist van websites die https ondersteunen.
https://www.eff.org/https-everywhere/faq
Ik had er nog nooit in detail naar gekeken. Ik had verwacht dat HTTPS Everywhere gewoon eerst https zou proberen, en terug zou vallen op http, als er geen https was. Niet dus. Jammer.

In geval van nood kun je zelfs de rulesets zelf aanpassen. Is bij mij nog nooit nodig geweest.
https://www.eff.org/https-everywhere/rulesets

Zomaar even https proberen en overschakelen als dat beschikbaar is, is niet echt een handige oplossing. Naast potentiële veiligheidsproblemen (die je juist probeert te omzeilen met https) kan het ook zijn dat in sommige gevallen de https site gewoon totaal anders is dan de http site. Ook het antwoord op dezelfde vraag in de FAQ die je linkte:

A. There are several problems with the idea of trying to automatically detect HTTPS on every site. Firstly, there is no guarantee that sites are going to give the same response via HTTPS that they give via HTTP. As of 2010, LiveJournal is a good example of this problem: compare these HTTP and HTTPS responses. Secondly, we don't think it's possible to test for HTTPS in real time without introducing security vulnerabilities (What should the extension do if the HTTPS connection attempt fails? Falling back to insecure HTTP isn't safe). Lastly, in some cases, HTTPS Everywhere has to perform quite complicated transformations on URIs — for example until recently the Wikipedia rule had to turn an address like http://en.wikipedia.org/wiki/World_Wide_Web into one like https://secure.wikimedia....ia/en/wiki/World_Wide_Web because HTTPS was not available on Wikipedia's usual domains.

Ik bezoek wel een aantal obscure sites die HTTPS aanbieden, maar niet in de lijst van HTTPS Everywhere staan. Kon ik zelf zeer gemakkelijk toevoegen (zelfs een waar HTTP op 80 draait en HTTP op een obscure port, vrij simpel met regular expressions).

Echt een aan te raden plugin inderdaad.

Helpt het ook tegen illegaal verkregen of gehackte certificaten? lijkt me niet, diginotar, digid... beter dan niks, maar nog niks beters dus.....
(Ik diss HTTPS-Everywhere dus niet, maar let wel op, het zijn ook maar hulpwieltjes aan een kinderfiets die over internet peddelt)

[Reactie gewijzigd door notsonewbie op 21 november 2013 16:43]

Nuttige maar wellicht ook gevaarlijke plugin, want daarmee leer je natuurlijk snel af om te controleren of je veilig bent...

Ik mis essentiele informatie. Is Spdy bijvoorbeeld standaard "enabled" in recentere versies van Chrome? En bijvoorbeeld de Google Chrome Frame plugin- for IE?

Ik mis essentiele informatie.

Voor degene die wat diepere technische informatie over speedy willen, hier is een goede webinar video. Van mijn favoriete technische blog over networking (IPSpace van Ivan Pepelnjak).

http://demo.ipspace.net/get/5%20-%20SPDY.mp4

Ook interessant is het objectieve oordeel of SPY nu echt de snelheid verbetert of niet. Valt wel mee dus. (Fast forward naar 12 minuten in de webinar).

[Reactie gewijzigd door 280562 op 21 november 2013 15:12]

IE11 heeft Spdy ondersteuning

Misschien moet Tweakers het ook maar gaan toepassen?

We houden het wel in de gaten... Maar het is in vergelijking met HTTP/1.1 een zeer complex protocol. Het is niet simpelweg een gevalletje van een module voor Apache installeren en dan klaar. Althans, dat is een onderdeel ervan, maar dan maak je er nog geen optimaal gebruik van.

Bovendien ondersteund onze reverse proxy software, Varnish, het nog niet (sterker nog, ze laten ook SSL zelf al over aan een andere laag in je netwerk).

"Ook worden https-verbindingen afgedwongen in het http-alternatief."

Die snap ik niet. Secure omzeilen voor snelheidswinst?
Heb me niet echt ingelezen, maar die zin doet mij denken om dat maar eens wel te doen.

@boeboe
Ok, dan mogen ze die zin (zoals meerdere zinnen in dit artikel) wel aanpassen voor meer duidelijkheid.

[Reactie gewijzigd door HMC op 21 november 2013 14:23]

euh, nee
Net het omgekeerde: Security afdwingen.

Hoe willen ze dat dan bereiken? Indiene met SSL en heel de certificaten zooi: leuk om kleine boeven tegen te houden, maar de grote krijgen juist meer macht. Dit is geen decentraal systeem. Als ze willen trekken ze je certificaat in en ben je machteloos. Dit lijkt me echt een geval van vrijheid inruilen voor schijnveiligheid.

Ik las het eerst ook verkeerd, staat er niet echt helemaal duidelijk naar mijn idee

Het http(2.0)-alternatief is spdy en ook https-verbindingen kunnen door het protocol worden afgehandeld Sterker nog, dat wordt geforceerd

[Reactie gewijzigd door BtM909 op 21 november 2013 14:41]

Als ik me het goed herinner, heeft het afdwingen van SSL ook een technische reden. Omdat anders oude proxy servers de mist in gaan.
Dit is ook de reden waarom WebSocket over alle data een XOR gooit met een willekeurige integer.

Voor als je een woord in je moerstaal (!) niet kent: http://vandale.nl/opzoeke...ngen&lang=nn#.Uo4NDf7g4Y0

De cijfers in procenten zijn spectaculair, maar het verschil kan evengoed minder dan een seconde zijn.

Ooit webdesigners horen praten over performance van hun webpages ? Dan praten ze over tienden en zelfs hondersten van een seconde. Alle kleine beetjes helpen om bezoekers op je website te houden.

[Reactie gewijzigd door 280562 op 21 november 2013 14:56]

Eerlijk gezegd heb ik ze er nooit over hiren praten. Ik hoor over Adobe Illustrator, Wordpress, SEO, bezoekers tracken en millimeters. Niks over milliseconden.

Ik kon het vanmiddag niet vinden.
Maar hier is de link.

https://www.youtube.com/watch?v=Il4swGfTOSM

Een Youtube film van een presentatie door Ilya Grigorik van Google.
Getiteld: Breaking the 1000ms Time to Glass Mobile Barrier

Als je klikt op een link naar iets van Google, wil Google dat alles op je scherm (het glas) staat binnen een seconde. Als je een hele webpagina wilt transporteren, renderen en laten zien binnen 1 seconde, dan telt iedere milliseconde.

Op 1m30sec vertelt Ilya waarom de snelheid zo belangrijk is.

Erg interessant praatje. Duurt 45 minuten. En is soms erg technisch. Maar reuze interessant.

[Reactie gewijzigd door 280562 op 22 november 2013 03:47]

Een halve seconde maal duizenden, miljoenen bezoekers die elk X pagina's en handelingen doen die calls naar de server maken tellen op.

Een halve seconde kost je 1 op de 5 bezoekers van je site. Lijkt me nog steeds spectaculair.

Uit de cijfers van Google blijkt dat met name internetgebruikers met een trage verbinding profiteren van Spdy. Zo zou Google News tot 44 procent sneller laden, tegenover 32 procent voor personen met een rappe verbinding. Ook Google Sites, Drive en Maps laden sneller met respectievelijk een snelheidswinst van 27, 23 en 24 procent.

Natuurlijk makkelijk met mobiel internet, welke vrijwel overal trager is dan de verbinding die men thuis heeft.
Ik zeg: goed bezig!

Natuurlijk makkelijk met mobiel internet, welke vrijwel overal trager is dan de verbinding die men thuis heeft.
Ik zeg: goed bezig!

Denk eens over de grens? Ik denk dat landen met mindere infrastructuur dan we hier hebben (lees: 90% van de wereld) er het meeste voordeel aan hebben. Hier hebben we zelfs mobiel relatief gezien hoge snelheden.

Ook in de VS zijn er zat plekken waar mobiel sneller is dan vast en dan niet alleen op het platteland.

Wat dan hier in NL? 4G is al sneller dan de gemiddelde ADSL verbinding

Wat dan hier in NL? 4G is al sneller dan de gemiddelde ADSL verbinding

dam vergelijk je ook wel de laatste mobiele techniek met de oudste DSL zo'n beetje

Met VDSL2 en profiel 30a moet je ook 200 Mbit/s kunnen halen. Met 17a (wat we hier gebruiken momenteel) 100 Mbit/s.

Maar ik heb 4G LTE in het echie getest in Japan toen het hier nog nauwelijks een test netwerk had (laat staan publiek), en dat was inderdaad behoorlijk spectaculair. 70 Mbit/s midden in een druk Shinjuku tijdens de ochtendspits

Of met mijn oude vdsl2+ aanbieder van wel 12mbit... Toen was 3g nog meer.

Of met mijn oude vdsl2+ aanbieder van wel 12mbit... Toen was 3g nog meer.

betere aanbieder kiezen?

Ik heb een 40/4 abo, en haal als ik het test 44 Mbit/s.

Of verhuizen zodat ik minder Ver van de centrale woon. Dat is nu ongeveer 3 tot 4km .

Maar nu hebben we kabel van UPC van 120mbps welke net zo duur is als TV internet en telefoon bij elkaar over vdsl.

Nu nog iets doen aan de latency en datalimieten. Want hoewel het in sommige gevallen vele malen sneller is is het niet bepaald bruikbaarder dan een ADSL verbinding.

Ik ben benieuwd wanneer tweakers dit protocol gaat toepassen op de web servers... Ik ben ook nieuwsgierig hoeveel impact dit heeft om te enablen...

Voor nieuw in te richten webservers zal het vast geen probleem zijn, maar hoe groot is dus de impact op het serverpark van bijvoorbeeld een tweakers?

[Reactie gewijzigd door BtM909 op 21 november 2013 14:15]

Exact. Indien je 10% extra servers nodig hebt is het niet de moeite waard. Dat gebruikers van mobiel internet vervolgens 25% meer dataverkeer verstoken zal voor veel websites hun probleem niet zijn. Daarbij is dataverkeer tegenwoordig spotgoedkoop in het datacentrum.

Daarbij is voor veel complexere websites de snelheid van de verbinding niet de vertragende factor, maar de verwerkingstijd voor het parsen van een gehele pagina. Google, Tweakers en Facebook zijn hier ijzersterk is, maar genoeg websites met een hogere parsetijd, waar meer vertraging inzit dan het overzetten van 100KB aan website. Zeker aangezien veel herhalende elementen als afbeeldingen gecached worden en er dan vaak nog maar 20KB aan HTML overgezet hoeft te worden, het onderdeel waarop Spdy de versnelling behaalt.

Waarom gebruikt Tweakers nog geen SPDY ?

spdy is niet sneller op niet secure verbindingen ?!

Sneller t.o.v. van wat ?

Lijkt op wij van "WC EEND vinden WC EEND het beste"

Als ze aangeven om welke pagina's het gaat (statische content, dynamisch) en configuratie file en welke httpd deamon ze gebruiken en hoe deze gecompiled was.

Of het dezelfde client betrof, het op openbaar internet, of op een door hen gecontroleerde netwerk is getest etc...etc...

Niet dat HTTP efficiënt is, maar waar we het nu voor gebruiken was niet de intentie toen het ontworpen werd.

Ook is overhead van HTTPS groter dan HTTP verkeer aangezien sessie openblijft staan, dit heeft ook gevolgen voor resources op zowel je client als je server (vele malen minder concurrent sessies mogelijk).

Op de volgende pagina kan je goed uitleg vinden over hoe het protocol werkt: http://www.chromium.org/spdy/spdy-whitepaper

Begrijpelijk is dat het niet altijd 44% sneller zijn. Maar daarom zeggen ze ook tot 44%. Hoe veel sneller de laadtijd zal zijn ligt af van een hoop factoren. Beste manier om dit te testen is door dezelfde website een x aantal keer te laden met en zonder spdy. In Table 1 vind je in ieder geval de resultaten van 25 geteste sites. Jammer dat er niet bij staat welke sites. Maar installeer het zelfs eens op een server en dan kan je het ook meten .

Ik vind het al heel wat dat het gewoon sowieso sneller is en dat je niet meer zult hakken tegen een paar 100 page requests die je op een gebruikelijke webshoppagina tegen komt.