Spdy misschien niet significant sneller dan http of https
Een web performance researcher stelt na het uitvoeren van een reeks tests dat het spdy-protocol in de praktijk zelfs iets trager is dan het http-protocol. Spdy zou wel een fractie beter presteren dan versleutelde https-verbindingen.
Onderzoeker Guy Podjarny beschrijft op zijn blog hoe hij tests heeft uitgevoerd met de top-500 websites uit de Alexa-lijst. Deze websites plaatste hij achter de proxydienst Cotendo, om ze vervolgens via de Chrome-browser op te vragen. Daarbij werden http-, https- en spdy-verbindingen opgezet via zowel trage als razendsnelle internetverbindingen. Ook gebruikte de onderzoeker bij zijn metingen geen client-side proxy maar een reverse-proxy, in de ogen van Podjarny een meer realistisch scenario.
Uit de testresultaten blijkt volgens Podjarny dat spdy circa 4,5 procent sneller is dan https en gemiddeld zelfs 3,4 procent trager is dan onversleutelde verbindingen die via http verlopen. Volgens de web performance researcher zijn er diverse redenen waarom in de praktijk met spdy minder snelheidswinst wordt behaald dan diverse andere onderzoekers stellen. Zo gebruiken veel websites content die afkomstig is van een groot aantal domeinen van derde partijen, maar omdat spdy de verbindingen per domein optimaliseert, wordt het aantal http-verbindingen niet significant minder. Verder zou http voor veel websites niet de voornaamste flessenhals vormen als het gaat om prestaties; veelal zijn het niet-geoptimaliseerde scripts of css-code die een site stroperig maken.
De onderzoeker concludeert dat spdy weliswaar een solide protocol is, maar dat sitebouwers die het protocol willen gebruiken geen al te hoge verwachtingen moeten hebben. Daarnaast kunnen de ontwikkelaars van het spdy-protocol, die met name binnen Google zijn te vinden, nog diverse optimalisaties doorvoeren om de 'http 2.0-kandidaat' beter te laten presteren. Zo zou spdy nog 'agressiever' content kunnen aanbieden terwijl de browser nog bezig is met het verwerken van javascript en css. Dit vergt echter ook verdere verbeteringen in de diverse browsers die met spdy overweg kunnen.
Reacties (35)
Zoals ook al in de bijbehorende Reddit-thread is genoemd, valt het wel mee met de kwaliteit van de conclusie, de auteur wordt voornamelijk afgerekend op het feit dat hij een proxy gebruikte om de vergelijking "eerlijk" te houden:
Verder wordt genoemd dat de verzameling sites die hij heeft geanalyseerd niet handig is; deze top-500 sites hebben namelijk al dermate veel bezoekers te verwerken, dat de makers de sites helemaal hebben geoptimaliseerd volgens HTTP/1.1. Met het bestaan van SPDY is geen rekening gehouden bij het opzetten van CDN's en dergelijke. Juist reguliere sites waar minder aandacht is voor optimalisatie (die dus uit veel losse requests naar dezelfde host bestaan) kunnen erg profiteren van SPDY.What was tested wasn't SPDY vs. HTTP, what was tested was HTTP->SPDY vs. HTTP. This is basically a completely uninteresting test. If you want to compare the two, you need a real SPDY implementation. SPDY contains numerous features that you can not use by simply using an HTTP proxy.
[Reactie gewijzigd door CodeCaster op maandag 18 juni 2012 12:31]
Zeer slecht onderzoek inderdaad.
Je zou zelfs kunnen zeggen dat het het uitleveren van files vanaf veel verschillende domeinen zoals heel veel grote websites (oa tweakers) doen om de beperkingen van http te omzijlen de voordelen van spdy te niet doen.
Dus als spdy wel goed gebruikt wordt krijg je meer voordelen dan nu en dat alles zonder al die (lelijke en vaak complexe) truuks om http(1/1.1) snel te krijgen.
Je zou zelfs kunnen zeggen dat het het uitleveren van files vanaf veel verschillende domeinen zoals heel veel grote websites (oa tweakers) doen om de beperkingen van http te omzijlen de voordelen van spdy te niet doen.
Dus als spdy wel goed gebruikt wordt krijg je meer voordelen dan nu en dat alles zonder al die (lelijke en vaak complexe) truuks om http(1/1.1) snel te krijgen.
Ik werk zelf aan een reverse SPDY proxy (dus een SPDY proxy die op de webserver draait en niet op de client) en ik zie gigantische snelheidswinsten bij kleine pagina's en bijvoorbeeld APIs. Bij statische API pagina's (update checkers, bijvoorbeeld) ben ik zelfs snelheidswinsten van ruim 80% tegengekomen. Dat SPDY trager zou zijn dan HTTP is gewoon pure onzin. 
-edit-
Over CDNs: ligt heel erg aan hoe ze geimplementeerd worden aan de serverkant. Ten opzichte van HTTPS is er sowieso geen performanceloss in wat voor geval dan ook, en tov HTTP is het alleen trager op het moment dat er slechts één bestand wordt geladen vanaf een nocookie-domein, en zelfs dan alleen onder bepaalde voorwaarden.
-edit-
Over CDNs: ligt heel erg aan hoe ze geimplementeerd worden aan de serverkant. Ten opzichte van HTTPS is er sowieso geen performanceloss in wat voor geval dan ook, en tov HTTP is het alleen trager op het moment dat er slechts één bestand wordt geladen vanaf een nocookie-domein, en zelfs dan alleen onder bepaalde voorwaarden.
[Reactie gewijzigd door TvdW op maandag 18 juni 2012 15:28]
De voornaamste reden is het scheiden van statische en dynamische content, performance is niet echt een issue voor de meeste sites.Je zou zelfs kunnen zeggen dat het het uitleveren van files vanaf veel verschillende domeinen zoals heel veel grote websites (oa tweakers)
Enkel grafisch intensieve sites zoals GoogleMaps hebben baat bij het serveren vanaf verschillende domeinen.
Het grote probleem is dat Google te hard heeft geroeptoeterd dat het SPDY protocol fantastische resultaten zou geven. Facebook is ook zo'n roeptoeter bedrijf dat om de zoveel tijd iets presenteert wat in de praktijk de verwachtingen niet waar maakt.
toevoegend:
De cijfers die hij heeft verzameld zijn ook wat kanttekeningen bij te plaatsen:
Cable (5,000/1,000, 28)
SPDY 6.7% faster(HTTPS)
SPDY 4.3% slower(HTTP)
DSL (1,500/384,50)
SPDY 4.4% faster(HTTPS)
SPDY 0.7% slower(HTTP)
Low-Latency Mobile (780/330,50)
SPDY 3% faster(HTTPS)
SPDY 3.4% slower(HTTP)
High-Latency Mobile (780/330,200)
SPDY 3.7% faster(HTTPS)
SPDY 4.8% slower(HTTP)
zo is de 0,7% slower bij dsl opvallend en lijkt buiten de trend voor data wat hij beschouwd als "more than enough for statistical accuracy."
Een ander opvallend punt is dat de resultaten lijken te verbeteren bij toename van de band breedte. nu zijn er veel te weinig meetpunten en te veel variatie in de test opstelling(zo wel bandbreedte als latency verschilt) om echt een zinnige conclusie te trekken, maar het lijkt mij ook een puntje om verder te onderzoeken.
Het hele 3rd party domains verhaal gaat er bij mij ook niet helemaal in - als het de boel zou helpen(en dat zou wel eens heel goed zo kunnen zijn) dan gaan we zo nodig dingen proxien om de gebruikers ervaring te verbeteren. (wordt, zie ik nu, ook genoemd in de comments) Dan komt dat allemaal wel van het zelfde domein en kan de optimalisatie wel weer plaats vinden. Maar ja het uitgangspunt was geloof ik dat hij het met sites in de huidige staat wou testen..
Dan is er ook nog het verhaal dat spdy op dit moment afhankelijk is van tls/ssl om te kunnen werken op het huidige web maar dat zou wegvallen bij adoptie in http 2.0
Ach het resultaat van onderzoek is meestal dat er meer onderzoek nodig is toch?
De cijfers die hij heeft verzameld zijn ook wat kanttekeningen bij te plaatsen:
Cable (5,000/1,000, 28)
SPDY 6.7% faster(HTTPS)
SPDY 4.3% slower(HTTP)
DSL (1,500/384,50)
SPDY 4.4% faster(HTTPS)
SPDY 0.7% slower(HTTP)
Low-Latency Mobile (780/330,50)
SPDY 3% faster(HTTPS)
SPDY 3.4% slower(HTTP)
High-Latency Mobile (780/330,200)
SPDY 3.7% faster(HTTPS)
SPDY 4.8% slower(HTTP)
zo is de 0,7% slower bij dsl opvallend en lijkt buiten de trend voor data wat hij beschouwd als "more than enough for statistical accuracy."
Een ander opvallend punt is dat de resultaten lijken te verbeteren bij toename van de band breedte. nu zijn er veel te weinig meetpunten en te veel variatie in de test opstelling(zo wel bandbreedte als latency verschilt) om echt een zinnige conclusie te trekken, maar het lijkt mij ook een puntje om verder te onderzoeken.
Het hele 3rd party domains verhaal gaat er bij mij ook niet helemaal in - als het de boel zou helpen(en dat zou wel eens heel goed zo kunnen zijn) dan gaan we zo nodig dingen proxien om de gebruikers ervaring te verbeteren. (wordt, zie ik nu, ook genoemd in de comments) Dan komt dat allemaal wel van het zelfde domein en kan de optimalisatie wel weer plaats vinden. Maar ja het uitgangspunt was geloof ik dat hij het met sites in de huidige staat wou testen..
Dan is er ook nog het verhaal dat spdy op dit moment afhankelijk is van tls/ssl om te kunnen werken op het huidige web maar dat zou wegvallen bij adoptie in http 2.0
Ach het resultaat van onderzoek is meestal dat er meer onderzoek nodig is toch?
[Reactie gewijzigd door Mr_Light op maandag 18 juni 2012 13:27]
Geweldig dat een onderzoeker hier zijn tijd in steekt. Dit is weer zo'n techniek die wellicht een lange periode (tientallen jaren?) gebruikt zal gaan worden, dan is wat extra efficiëntie wel mooi, en nu krijgt Google de handreiking om nog wat puntjes te optimaliseren. :d
edit:
Lees ook CodeCaster^^ voor een iets kritischer reactie.[Reactie gewijzigd door Barleone op maandag 18 juni 2012 12:54]
....triest dat een onderzoeker dit zelf moet uitzoeken. Ook browser bakker Opera had verschillende punten van verbetering voor dit 'nieuw' protocol
Zo werkt dat nou eenmaal met standaarden die breder gebruikt moeten gaan worden. SPDY heeft momenteel 'Internet Draft' en daarmee is dat een 'officiele' draft. Vervolgens kunnen derden met het protocol aan de slag en feedback geven.
Vervolgens vinden er een aantal iteraties van het protocol plaats en als de meerderheid van het IETF de standaard goedkeurt krijgt het de status 'Standard' welke dan waarschijnlijk als een RFC standaard wordt gepubliceerd. Overigens is SPDY slechts 1 van de voorstellen voor de HTTP 2.0 specificatie.
Microsoft heeft bijvoorbeeld als HTTP S&M (Speed+Mobility) als voorstel gepubliceerd welke verder borduurt op SPDY. S&M heeft bijvoorbeeld al support voor WebSockets waardoor webservers berichten kunnen pushen naar de browser. Een van de aanbevelingen welke Microsoft heeft gedaan is om de standaard compressie en encryptie te laten vallen. Mobiele browsers (smart phones) hebben een beperkte accu en extra cpu cycles for compressie en decryptie zijn dus niet gewenst. Waarschijnlijk zullen browsers later kunnen aangeven of zijn encryptie en/of compressie wensen.
Meer informatie kan gevonden by SPDY en HTTP S&M. Alle voorstellen voor HTTP 2.0 kun je hier vinden.
Dit proces verschilt niet zoveel van de procedures welke bijvoorbeeld HTML5 of CSS3/4 doorlopen.
Het wachten is tot SPDY als module for Apache/IIS uitkomt zodat web developers niet meer zelf SPDY hoeven te implementeren maar de webserver dit zelf afhandelt waardoor het transparant wordt toegepast. Dat zal de acceptatie pas echt op gang brengen..
Vervolgens vinden er een aantal iteraties van het protocol plaats en als de meerderheid van het IETF de standaard goedkeurt krijgt het de status 'Standard' welke dan waarschijnlijk als een RFC standaard wordt gepubliceerd. Overigens is SPDY slechts 1 van de voorstellen voor de HTTP 2.0 specificatie.
Microsoft heeft bijvoorbeeld als HTTP S&M (Speed+Mobility) als voorstel gepubliceerd welke verder borduurt op SPDY. S&M heeft bijvoorbeeld al support voor WebSockets waardoor webservers berichten kunnen pushen naar de browser. Een van de aanbevelingen welke Microsoft heeft gedaan is om de standaard compressie en encryptie te laten vallen. Mobiele browsers (smart phones) hebben een beperkte accu en extra cpu cycles for compressie en decryptie zijn dus niet gewenst. Waarschijnlijk zullen browsers later kunnen aangeven of zijn encryptie en/of compressie wensen.
Meer informatie kan gevonden by SPDY en HTTP S&M. Alle voorstellen voor HTTP 2.0 kun je hier vinden.
Dit proces verschilt niet zoveel van de procedures welke bijvoorbeeld HTML5 of CSS3/4 doorlopen.
Het wachten is tot SPDY als module for Apache/IIS uitkomt zodat web developers niet meer zelf SPDY hoeven te implementeren maar de webserver dit zelf afhandelt waardoor het transparant wordt toegepast. Dat zal de acceptatie pas echt op gang brengen..
[Reactie gewijzigd door Niemand_Anders op maandag 18 juni 2012 14:58]
mod_spdy
Heeft helaas wel problemen met de PHP-programmeertaal als deze via mod_php gedraaid wordt (probleem ligt overigens bij PHP, niet mod_spdy)
Heeft helaas wel problemen met de PHP-programmeertaal als deze via mod_php gedraaid wordt (probleem ligt overigens bij PHP, niet mod_spdy)
Praktijktesten van iets wat niet de praktijk is 
.
.Quote: Zo gebruiken veel websites content die afkomstig is van een groot aantal domeinen van derde partijen, maar omdat spdy de verbindingen per domein optimaliseert, wordt het aantal http-verbindingen niet significant minder.
Als ontwikkelaars Spdy implementeren gaan ze ook hun websites ernaar inrichten, dan loont het om alle content van 1 domein te plukken, dus doen ontwikkelaars dat dan vanzelf. De performance zal dan zeker stijgen.
(Om maar niet te spreken van een http proxy....)
Als ontwikkelaars Spdy implementeren gaan ze ook hun websites ernaar inrichten, dan loont het om alle content van 1 domein te plukken, dus doen ontwikkelaars dat dan vanzelf. De performance zal dan zeker stijgen.
(Om maar niet te spreken van een http proxy....)
Dan moet die content wel allemaal in een domein te vinden zijn, en dat is erg onwaarschijnlijk. Denk voor het simpelste voorbeeld aan stat counters, advertenties of like buttons.
Inderdaad. Tweakers heeft een tijd geleden juist een appart domein voor images opgezet dus daar zit je al met 2 domeinen.
Daarbij zijn heel veel systemen er op gericht dat je web componenten embed via javascript die vervolgens allemaal request naar het domein van de leverancier gaat maken.
Ik vraag mij ook af hoeveel tijd er in de daadwerkelijke requests gaat zitten, je browser is veel langer bezig met het laden van de content. Gaat het over secondes hier of milisecondes die we er af aan het schaven zijn?
het lijkt mij dat je de externe resources ook van een spdy server moeten komen, dus die moeten het ook aanbieden.
Daarbij zijn heel veel systemen er op gericht dat je web componenten embed via javascript die vervolgens allemaal request naar het domein van de leverancier gaat maken.
Ik vraag mij ook af hoeveel tijd er in de daadwerkelijke requests gaat zitten, je browser is veel langer bezig met het laden van de content. Gaat het over secondes hier of milisecondes die we er af aan het schaven zijn?
het lijkt mij dat je de externe resources ook van een spdy server moeten komen, dus die moeten het ook aanbieden.
Ik weet dat het enorm veel gebruikt wordt hoor... Sub domeinen voor bijv plaatjes. Ik vraag me dan wel af waarom het nou gebruikt wordt? Gebruiken we sub domeinen vanwege gebreken in het HTTP protocol? Is het dan niet gewoon het kip en ei verhaal? Je hebt eerst iets nodig waardoor die extra subdomein hack niet nodig is waarna de subdomeinen pas zullen verdwijnen...
Qua advertenties valt het naar mijn mening wel mee... Dat zijn maar enkele requests terwijl het aantal plaatjes snel kan oplopen in de tientallen
Qua advertenties valt het naar mijn mening wel mee... Dat zijn maar enkele requests terwijl het aantal plaatjes snel kan oplopen in de tientallen
Er wordt een subdomein gebruikt om verkeer eenvoudig naar een andere server te kunnen versturen. Eén die speciaal is ingericht voor het serveren van statische content. Dit kan ook een Content Delivery Network (CDN) zijn.
Dat heeft volgens mij niet zoveel te maken met gebreken in HTTP, maar met hoe efficiënt de server is.
Dat heeft volgens mij niet zoveel te maken met gebreken in HTTP, maar met hoe efficiënt de server is.
Totaal overbodig om dit op deze wijze te doen. Je kan 1 domein aanhouden, bijvoorbeeld tweakers.net met daaronder virtual folders naar andere servers toe en op top niveau met bijvoorbeeld een "reverse proxy" koppelen.
Dat is helemaal niet overbodig, omdat de gemiddelde browser slechts zo'n vier verzoeken per host tegelijk toestaat. Toen alles van de host tweakers.net moest komen (dus eerst de html, dan diverse .js-files en nog een stapel images), was de browser het grootste gedeelte van de tijd bezig met wachten op het voltooien van eerdere verzoeken.
Met het invoeren van "subdomeinen", zoals bijvoorbeeld images.domein.tld en scripts.domein.tld, kunnen er ineens twaalf (want ook naar (www.)domein.tld) requests tegelijk gedaan worden.
SPDY neemt (onder andere) dit hele probleem weg (door vele parallelle verzoeken naar dezelfde host toe te staan), en zal inderdaad bij een site die veelvuldig gebruikmaakt van subdomeinen of CDN's weinig nut hebben.
Met het invoeren van "subdomeinen", zoals bijvoorbeeld images.domein.tld en scripts.domein.tld, kunnen er ineens twaalf (want ook naar (www.)domein.tld) requests tegelijk gedaan worden.
SPDY neemt (onder andere) dit hele probleem weg (door vele parallelle verzoeken naar dezelfde host toe te staan), en zal inderdaad bij een site die veelvuldig gebruikmaakt van subdomeinen of CDN's weinig nut hebben.
[Reactie gewijzigd door CodeCaster op maandag 18 juni 2012 14:24]
Met een simpele register aanpassing laat ik mijn Chrome/Firefox/IE 25+ connecties uitvoeren als dat nodig is. Chrome is standaard op 8 gelimiteerd denk ik. Maar als ik 25 files wil downloaden, wil ik ze gewoon alle 25 aanklikken en moeten ze tegelijk starten. Een uurtje later kom ik dan terug en is alles klaar.
Deze aanpassing kon je al doen voor IE6 of vroeger, dus niks nieuws.
Tegenwoordig is het een nonissue: al die content komt supersnel toe, wachten op css bestanden of dergelijks doen we niet meer met onze 100Mbps verbinden thuis. Meer verbindingen doet de server enkel nog meer stressen.
Deze aanpassing kon je al doen voor IE6 of vroeger, dus niks nieuws.
Tegenwoordig is het een nonissue: al die content komt supersnel toe, wachten op css bestanden of dergelijks doen we niet meer met onze 100Mbps verbinden thuis. Meer verbindingen doet de server enkel nog meer stressen.
Virtuele folders hebben een aanzienlijk snelheidsverlies tot gevolg in tegenstelling tot een rechtstreekse benadering van een server via een subdomein. Vooral bij grote (aantallen) afbeeldingen / video's.
[Reactie gewijzigd door mrdemc op maandag 18 juni 2012 14:43]
Dat heb je mis. Adsense van Google doet bijvoorbeeld ontzettend veel requests. Je zet zelf 1 script in je pagina die vervolgens weer enkele andere scripts opvraagt. Er zitten zelfs verschillende redirects bij die het laden nog meer vertragen.
Tijdens het testen van de snelheid van mijn eigen website ben ik verschillende malen tegen het probleem aangelopen dat mijn eigen website snel genoeg was, maar dat externe script als Adsense de boel verziekten. Plaatjes kunnen ook een probleem zijn, maar veel sites maken tegenwoordig gebruik van image sprites en dan heb je weer helemaal geen last van die overhead aan aanvragen.
Tijdens het testen van de snelheid van mijn eigen website ben ik verschillende malen tegen het probleem aangelopen dat mijn eigen website snel genoeg was, maar dat externe script als Adsense de boel verziekten. Plaatjes kunnen ook een probleem zijn, maar veel sites maken tegenwoordig gebruik van image sprites en dan heb je weer helemaal geen last van die overhead aan aanvragen.
Inderdaad. Ik sta zelf in voor de optimalisatie van een middelgrote website (alexa 26k met groei van 15% per maand) en de grootste factor bij het inladen van de paginas zijn 3rd party scripts. Denk aan twitter/facebook/reddit knoppen en Analytics. Daarbovenop heb je nog systemen zoals Disqus voor de comments af te handelen. Om nog maar te zwijgen over advertenties die tegenwoordig enorm veel impact hebben.
Kan je leuk sprites maken, server- en clientside caching zo goed mogelijk optimaliseren, scripts verhuizen naar de footer etc... Het blijft frustrerend als je de hele pagina op nog geen seconde op je beeld staat (met caching) als daarna leuk 1 voor 1 de share knoppen tevoorschijn komen omdat ze perse big brother willen spelen met hun dikke scripts...
Kan je leuk sprites maken, server- en clientside caching zo goed mogelijk optimaliseren, scripts verhuizen naar de footer etc... Het blijft frustrerend als je de hele pagina op nog geen seconde op je beeld staat (met caching) als daarna leuk 1 voor 1 de share knoppen tevoorschijn komen omdat ze perse big brother willen spelen met hun dikke scripts...
We hebben al decennia lang persistent connections (zolang http bestaat eigenlijk), maar Je ziet maar weinig sites die daar hun voordeel mee doen. Dus helaas, jouw verwachting gaat niet op.
Veel sitebouwers zullen niet eens weten of hun site via spdy of http wordt uitgeserveert.
Veel sitebouwers zullen niet eens weten of hun site via spdy of http wordt uitgeserveert.
Nou wat een nieuws zeg, hij heeft dus een testopstelling gemaakt die totaal niet relevant is.
Dus ga je dan binnenkort als website bouwer moeten gaan afchecken of je site gerequest werd over HTTP danwel over SPDY? Om afhankelijk daarvan content van subdomeinen of hetzelfde domein te moeten gaan serveren?
Als je er nu al maximaal gebuik van wil maken wel. Maar je kunt natuurlijk ook wachten tot het de standaard is en dan de optimalisaties voor standaard HTTP laten vallen.
Edit "De vraag is denk ik wanneer spdy aangenomen word als standaard."
De vraag is denk ik OF spdy aangenomen word als standaard. ;-)
De vraag is denk ik OF spdy aangenomen word als standaard. ;-)
Dat zou je kunnen doen, maar de winst die hiermee behaald is natuurlijk minimaal. Het loont slechts voor grote websites met tig requests per seconde.
Spdy heeft nog even te gaan denk ik, maar het gaat zeker een goed alternatief zijn. Alleen al de betere performance in https verbindingen is een groot voordeel. Nu zijn er vaak nog hardware accelerators nodig om veel SSL verbindingen tot een goed einde te brengen zonder gigantische serverparken.
De vraag is denk ik wanneer spdy aangenomen word als standaard.
Spdy heeft nog even te gaan denk ik, maar het gaat zeker een goed alternatief zijn. Alleen al de betere performance in https verbindingen is een groot voordeel. Nu zijn er vaak nog hardware accelerators nodig om veel SSL verbindingen tot een goed einde te brengen zonder gigantische serverparken.
De vraag is denk ik wanneer spdy aangenomen word als standaard.
Een hardware accelerator versnelt de rekenkundige bewerkingen nodig voor de encryptie / signing etc. Dat zijn zaken die binnen het gebruikte encryptieprotocol vallen en welke dus weinig te maken hebben met het transport van de gecodeerde data. Je koopt een SSL accelerator dus doorgaans voor een totaal ander doel
Ik vraag me toch af in hoeverre spdy daadwerkelijk een verbetering van de snelheidservaring voor de gebruiker op zal leveren. Thuis zie ik het bv al gebeuren dat de site gedownload is, maar dat de browser dan nog een tijdje bezig is met renderen.
Ik denk dat daar meer winst te behalen valt. Zorg ervoor dat de site sneller gerenderd kan worden.
Ik denk dat daar meer winst te behalen valt. Zorg ervoor dat de site sneller gerenderd kan worden.
[Reactie gewijzigd door Daeron op maandag 18 juni 2012 13:02]
De winst op zo'n website zit dan niet in content of performance, maar de hoeveelheid 'overige zaken' die moeten worden ingeladen. Neem nu bijvoorbeeld het grote plaatjes of filmpjes topic, pagina is zo goed als instant, maar de rest moet allemaal nog inladen.
Hoe meer sites gebruiken van 'offside content' (veelal reclame) of juist client-side programma's (Flash met name), hoe trager zoiets gaat lopen. Zet voor de grap flash uit en laad een aantal 'pedia' sites, ze gaan opeens een aanzienlijk stuk sneller. Dit geld ook voor dataverkeer en CPU usage, zeker met die overlay/popup onzin.
Je kan een auto wel een nieuwe motor geven, maar als die nog steeds volgeladen is met 100kg+ mensen en enorme lading, zit je nog aan de verkeerde kant.
Hoe meer sites gebruiken van 'offside content' (veelal reclame) of juist client-side programma's (Flash met name), hoe trager zoiets gaat lopen. Zet voor de grap flash uit en laad een aantal 'pedia' sites, ze gaan opeens een aanzienlijk stuk sneller. Dit geld ook voor dataverkeer en CPU usage, zeker met die overlay/popup onzin.
Je kan een auto wel een nieuwe motor geven, maar als die nog steeds volgeladen is met 100kg+ mensen en enorme lading, zit je nog aan de verkeerde kant.
Als ik alle reclame aan zet zie ik exact hetzelfde gebeuren.
Ik heb eerst een korte piek aan dataverkeer dat de bulk gedownload wordt. Daarna begint de browser met renderen en even later staat de pagina er. Het grootste deel van de wachttijd besteed ik aan het renderwerk van de browser, niet aan het downloaden van de site.
Ik heb eerst een korte piek aan dataverkeer dat de bulk gedownload wordt. Daarna begint de browser met renderen en even later staat de pagina er. Het grootste deel van de wachttijd besteed ik aan het renderwerk van de browser, niet aan het downloaden van de site.
Hebben we dus niet veel aan dit protocol, het is een minimale verbetering van de bestaande. Het is wat mij betreft pas echt een verbetering als alles significant beter wordt en niet zoals nu een klein beetje.
Dit is een significante verbetering, aan de kant van de content-provider.
Met een klein beetje kom je heel ver als het impact heeft op de afhandeling van elke individuele connectie. Dat jij als gebruiker het niet merkt wanneer de render-tijd van de javascript er bij opgeteld wordt (wat client-side gebeurt) betekend niet dat het google geen tonnen kan schelen aan hardware-capaciteit. Van de 4 miljard mensen op internet zal grofweg 70% google als start-pagina hebben... bij 4x naar google per dag en 10 http-requests heb je het al over 120miljard roundtrips naar hun servers.
Dan gaan de bytes wel tellen..
De getallen die ik hierboven noem zijn arbitrair, google heeft ook analytics en +1 knopjes op miljoenen websites, dus waarschijnlijk zijn de getallen nog groter.
Wat ik probeer duidelijk te maken is dat het hier om de wet van de grote getallen gaat... heel veel x een paar bytes is ineens een fixe hoeveelheid aan memory, cpu, warmte (en dus cooling) die je kunt besparen. En dat op elk stukje infrastructuur dat iets met http moest doen en straks bespaart met SPDY.
Met een klein beetje kom je heel ver als het impact heeft op de afhandeling van elke individuele connectie. Dat jij als gebruiker het niet merkt wanneer de render-tijd van de javascript er bij opgeteld wordt (wat client-side gebeurt) betekend niet dat het google geen tonnen kan schelen aan hardware-capaciteit. Van de 4 miljard mensen op internet zal grofweg 70% google als start-pagina hebben... bij 4x naar google per dag en 10 http-requests heb je het al over 120miljard roundtrips naar hun servers.
Dan gaan de bytes wel tellen..
De getallen die ik hierboven noem zijn arbitrair, google heeft ook analytics en +1 knopjes op miljoenen websites, dus waarschijnlijk zijn de getallen nog groter.
Wat ik probeer duidelijk te maken is dat het hier om de wet van de grote getallen gaat... heel veel x een paar bytes is ineens een fixe hoeveelheid aan memory, cpu, warmte (en dus cooling) die je kunt besparen. En dat op elk stukje infrastructuur dat iets met http moest doen en straks bespaart met SPDY.
tja hoeveel sneller als instant kan je zoiezo nog worden....
bijna alles op het insternet is instant tenzij de server traag is of over een trage/overbezette lijn gaat.
bijna alles op het insternet is instant tenzij de server traag is of over een trage/overbezette lijn gaat.
hoop dat het niet veranderd wordt http blijft
Op dit item kan niet meer gereageerd worden.
Populair: Asus Samsung Websites en communities Mobiele telefoons Laptops Sony Games Microsoft Consoles Microsoft Xbox One
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
