Google: webp maakt laden YouTube 10 procent sneller

Volgens Google zorgt zijn zelfontwikkelde webp-formaat voor afbeeldingen ervoor dat YouTube-pagina's 10 procent sneller laden. Gemiddeld genomen zorgt het gebruiken van webp in plaats van andere formaten voor 35 procent kleinere plaatjes, aldus Google.

Google meldt de resultaten op zijn weblog, nadat de internetgigant enige tijd geleden is begonnen met de uitrol van het webp-formaat voor verscheidene van zijn diensten. Zo is de videodienst YouTube sinds kort voorzien van thumbnails die in het webp-formaat worden weergegeven; volgens Google wijzen de eerste metingen uit dat het laden van webpagina's op YouTube daar 10 procent sneller van wordt.

Tevens stelt de internetgigant dat het gebruik van webp de grootte van afbeeldingen met 35 procent verkleint. Dat is gebaseerd op meetgegevens van de Google Play Store, waar al enige tijd gebruik wordt gemaakt van webp. Bij de aankondiging van webp in 2011 liet Google nog weten dat het formaat, vergeleken met jpeg, in theorie een 39 procent kleinere bestandsgrootte op kan leveren. Het gebruik van webp in zijn diensten zorgt bij Google voor een besparing van tientallen terabytes aan data.

Tenslotte zorgt libwebp 0.4.0, die momenteel in bèta-versies van Chrome wordt gebruikt, ervoor dat encoding van lossless webp-afbeeldingen twee keer sneller wordt. Het decoden van lossless webp wordt met 25 procent versneld, aldus Google. De internetgigant kondigde de komst van libwebp 0.4.0 al enkele maanden geleden aan.

Met de resultaten wil Google aantonen dat het voor webontwikkelaars aantrekkelijk is om webp te gebruiken. Vooralsnog wordt het formaat voornamelijk in Googles eigen browsers gebruikt, al zou Mozilla overwegen om ook ondersteuning te gaan bieden.

Reacties (115)

[twiFight]

Niet als flame bedoelt, maar als je een webpagina snel wilt hebben moet je 'm niet volstampen met social media troep en advertenties. Ik merk het heel duidelijk nu ik met een <56k verbinding zit. Als ik een pagina met een artikel wil laden (text only) moet ik soms meerdere minuten wachten totdat al die "klik op mij, ik ben superinteressant" plaatjes zijn geladen.

[edit] Ter verduidelijking: Google gebruikt snelheid als argument. Als snelheid écht een argument is, dan zijn er veel betere methoden om dat te bereiken. Ik vind het dus een slap excuus om hun eigen formaat er door proberen te krijgen. Als het formaat echt zo goed is als ze zeggen, dan verkoopt dat zichzelf wel.

[edit2] Voor Webgnome en Daenny en gelijkdenkenden: mijn punt is het volgende. Dit artikel presenteert het alsof Google zegt: "gebruik ons formaat, want dan laadt je website sneller". Ik vind dat een verkeerde benadering. Als het sneller laden van jouw website het doel is, dan moet je kijken naar wat je laadt en hoe je dat laadt. Youtube zelf is een goed voorbeeld. Als ik met mijn verbinding een youtubepagina wil laden dan zie ik eerst de headers en de frame voor de video. Maar de video gaat niet laden. Eerst wordt de hele social media hub geladen en vervolgens is hij (in mijn geval) minuten bezig met de thumbs van de suggested videos. Pas daarna gaat de video laden. Een snelle website, cq. de ervaring van een snelle website volgt uit het zo snel mogelijk beschikbaar hebben van de content waarvoor je komt.

Over het formaat: laat die kracht komen uit het zijn van een beter formaat. Betere kwaliteit / bestandsgrootte verhouding, goede ondersteuning, meer functionaliteit, etc. Als jouw formaat dat heeft, dan hoef je mensen ook niet over te halen met triviale statistieken.

[Reactie gewijzigd door twiFight op 23 juli 2024 04:37]

[Webgnome]

Je haalt hier nu 2 problemen door elkaar.

1) Dat er tegenwoordig wel heel veel content binnen gehaald wordt
2) Dat de hoeveelheid content eigenlijk het zelfde zou moeten zijn maar qua bestandsomvang minder.

Jij doelt met je edit waarschijnlijk op het weg laten van advertenties etc. Echter is dat nou juist geen oplossing. Dat is namelijk inboeten op functionaliteit. Men wil dezelfde functionaliteit (en liefst meer ) met dezelfde bestandsomvang.

Zie het als processoren.. Het moet meer kunnen maar wel kleiner zijn..

[Martinspire]

De gebruikers willen echter geen reclame, dat wil Google, maar dat is logisch want de boel moet ergens van betaald worden.

Toch is het wat mij betreft ook niet gebruiksvriendelijk om eerst reclame en social-stuff te laden om vervolgens de content te laden waar je voor komt.

Omdat je hier echter vrijwel overal fatsoenlijk internet hebt en ook mobiel een aardige snelheid kunt halen, is dat niet zo'n groot probleem dus sommige developers vergeten nu steeds vaker ook nog de wat tragere gebruikers van prima gebruikservaring te voorzien, net als dat ze vergeten te optimaliseren voor slechtzienden, slechthorenden of anderen met een anders-dan-doorsnee gebruikservaring.

[sfranken]

Een browser bepaalt wat het laad en in welke volgorde. Daar kunnen de developers van YouTube weinig aan veranderen. Tuurlijk kunnen ze hun collega's van het Chrome dev team eens aankijken maar ik kan me voorstellen dat die gewoonweg "nee" zeggen omdat zo'n uitbreiding van Chrome toch weer extra code is en weer extra werk. Bovendien weet je dan niet wat de (eventuele) bijwerkingen zijn op andere websites.

Leesmateriaal:
http://stackoverflow.com/...on-sequence-of-a-web-page

http://ejohn.org/blog/browser-page-load-performance/

[Verwijderd]

Met Google's Spdy protocol en het gelijkende HTTP2 voorstel komt hier verandering in. Het wordt dan mogelijk om een verbinding tussen de server en de client voor langere tijd open te houden en meerdere resources geprioriteerd tegelijk te versturen. De server kan hierin een 'push' geven, en zo dus alle resources voor een pagina alvast naar de client sturen zonder dat de client de pagina eerst moet parsen. Hierdoor zouden laadtijden een stuk korter moeten worden, omdat je geen vraag-antwoord-vraag-antwoord roundtrips meer hebt.

[HellFury]

Nee, veel gebruikers willen/verwachten het gratis. Google's vorm van gratis - via reclame of tracking - komt voor veel gebruikers overeen met gratis.

[Reactie gewijzigd door HellFury op 23 juli 2024 04:37]

[Daenney]

Ik vind het dus een slap excuus om hun eigen formaat er door proberen te krijgen.

Hoezo 'hun eigen formaat er door proberen te krijgen'? Ze hebben webp zelf ontwikkeld en gebruiken het in hun eigen diensten en platform. Daarbij presenteren ze netjes cijfers over de snelheidswinsten die ze er mee kunnen winnen. Werkt YouTube voor mensen zonder WebP? Jazeker. Werkt Google Images voor mensen zonder WebP? Jazeker. Werkt $random_google_dienst voor mensen zonder WebP? Jazeker.

Het enige wat ze proberen te doen en aan te tonen is dat hun formaat het laden van assets zoals plaatjes op sites kan versnellen en dat is voor sommige sites zeker wel van belang. Dat je met je <56K verbinding een uur moet wachten op moderne sites komt door je 56K verbinding, men gaat er tegenwoordig vanuit dat je meer tot je beschikking hebt. Als dat echter niet zo is is jouw 56K verbinding als nog geen argument tegen een beter comprimerend bestandsformaat. Zeker voor telefoons is dit wel degelijk relevant.

[Verwijderd]

100% eens dat het een goede beweging is om waar mogelijk te optimaliseren. Tegelijkertijd ben ik totaal niet onder de indruk van WebP. Een nieuw image formaat op het web uitrollen is iets wat eens in de 10-20 jaar misschien kan, en jaren kost voordat het gemeengoed is. En in dit geval winnen we daar TOT 30% mee.

Alle beetje zijn meegenomen, maar serieus, mijn verwachting van een nieuw formaat ligt bij 200-300%, niet een matige verbetering zoals deze.

[Verwijderd]

Als snelheid écht een argument is, dan zijn er veel betere methoden om dat te bereiken.

Als jij met een <56k verbinding zit dan ben je niet representatief.
Ja en met zo´n lage bandbreedte zijn er inderdaad methoden om meer snelheid te bereiken, methoden die men ook 20 jaar geleden gebruikte: minder afbeeldingen, kleinere afbeeldingen, meer tekst, etc.
Maar je snapt toch hopelijk wel dat er met het ontwerpen van een webpagina een balans is tussen snelheid en grafisch geweld?
En ook dat deze balans opschuift richting meer bandbreedte gebruik naarmate de gemiddelde internet snelheid stijgt?

Ik vind het dus een slap excuus om hun eigen formaat er door proberen te krijgen.
Als het formaat echt zo goed is als ze zeggen, dan verkoopt dat zichzelf wel.
...
Over het formaat: laat die kracht komen uit het zijn van een beter formaat. Betere kwaliteit / bestandsgrootte verhouding, goede ondersteuning, meer functionaliteit, etc. Als jouw formaat dat heeft, dan hoef je mensen ook niet over te halen met triviale statistieken.

Google hoeft helemaal niemand over te halen en al helemaal niets te verkopen met WebP
WebP is ontwikkeld door Google en daarna vrijgegeven. Met het vrijgeven (open source) heeft Google ook een webpagina online gedaan met een FAQ en documentatie.
Google had ook gewoon WebP native kunnen ondersteunen in Chrome en het formaat gesloten houden en WebP als een argument gebruiken waarom je Googles browser EN Googles services moet gebruiken.
Maar nee, Google heeft het formaat vrijgegeven, en nu kunnen we allemaal het formaat gebruiken, aanpassen en in de broncode loeren. Netjes van Google.

Je post maakt een hele gekke spagaat; hoe kan webpagina optimalisatie in zijn algemeenheid nu een punt van kritiek zijn als antwoord op een nieuw beeldcompressie formaat? Dat verhaal kan je altijd wel aanhalen, maar hiermee richt je je kritiek op webdesigners en niet op Google....die bepalen hoe `zwaar´ een pagina al dan niet gaat worden. En die webontwikkelaars hanteren de gemene deler en niet twifight met 56k modem.

ergo, Wat een slecht verhaal.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 04:37]

[MGutker]

Als je niet adverteert, dan zal niemand het weten.

Als jij nu een nieuwe "supercomputer" maakt en in de kast zet zonder te adverteren.. Denk je dan dat de mensen in je winkel staan te springen om hem te kopen terwijl ze niet weten dat jij hem wilt verkopen?

[MJLHThomassen]

Inderdaad, daar heb je wel een punt.

Is het echter niet zo dat als je "load images" uitschakelt dat hij die dan ook echt niet ophaald (he bik althands begrepen)? Het kan er iig niet sneller op worden daar heb je wel gelijk in.

Wat is er trwouens gebeurd met Jpeg2000? Ik gebruik het zelf ook nooit, daar niet van, maar dat bestaat toch ook al een hele tijd en moet toch ook sneller/kleiner/beter zijn dna normale jpeg?

[Reactie gewijzigd door MJLHThomassen op 23 juli 2024 04:37]

[10 feet high]

Wat is er trwouens gebeurd met Jpeg2000? Ik gebruik het zelf ook nooit, daar niet van, maar dat bestaat toch ook al een hele tijd en moet toch ook sneller/kleiner/beter zijn dna normale jpeg?

Dat wordt hoofdzakelijk voor heel andere zaken gebruikt, vooral bij professionele toepassingen. Denk dan aan medische beeldvorming, digitale cinema, satellietstreaming of live feeds in TV-studios (om maar een paar zaken te noemen).

Geen idee hoever je interesses gaan, maar dit is een rechtstreeks antwoord op je vraag: Wat is er gebeurd met JPEG2000
http://www.barco.asia/pro.../jpeg2000_LR_brochure.pdf

JPEG2000 werkt over het algemeen in andere kleurruimtes dan consumenteneletronica (vaak X’Y’Z’) en heeft nogal wat voordelen wat betreft real-time encoding en decoding, maar daar weet ik het fijne al niet meer van. We spreken dan ook van bitrates (video) die heel wat hoger liggen dan bij de consumentenelectironica. Grootte-orde 450Mbps. Bij YouTube, om maar een voorbeeld te geven, gaat het om veel lagere bitrates die ge(de)codeerd moeten worden. Bij wat nu de hoogste settings zijn (1080p) gebeurt dat 'maar' aan iets van 8Mbps.

[Joop Visstick]

JPEG 2000? Nou dit staat er in de engels-talige wiki:
[qoute]
JPEG 2000 has been published as an ISO standard, ISO/IEC 15444. As of 2013, JPEG 2000 is not widely supported in web browsers, and hence is not generally used on the Internet.
[/quote]
(Staat onder "Aims of the Standard" op http://en.wikipedia.org/wiki/JPEG_2000.

En ja of het nu JPEG2000 is of WebP of welk formaat dan ook, zonder goede support (of verkeerde licenties) kom je er niet . . . .

[InsomniaC81]

Helemaal mee eens - maar als het laden van een webpagina sneller wordt doordat er minder data verstuurd hoeft te worden per request dan is dat op zich een prima verbetering wat mij betreft.

Staat los van het feit dat een gemiddelde site vol gepropt staat met reclame en social media onzin.....

Ik hoop dat dat Mozilla en Microsoft uiteindelijk ook ondersteuning voor dit formaat gaan bieden.

[edit: typo]

[Reactie gewijzigd door InsomniaC81 op 23 juli 2024 04:37]

[alfredkayser]

Link naar de bugzilla entry m.b.t. de WebP support :
https://bugzilla.mozilla.org/show_bug.cgi?id=856375

Daarin is een enorme discussie over standaarden enzo te vinden.
Ook het huidige versie nummer van libwebp 0.4.0 geeft aan dat het allemaal nog erg vroeg is, en het voorlopig nog geen "standaard" mag heten.

[vali]

Daar zit ook de grote reden waarom adblock programma's volop gebruikt worden. Mensen zijn het zat dat websites traag geladen worden, we overal gevolgd worden door social media websites (Facebook button bv.) en het komt steeds vaker voor dat advertenties geïnfecteerd zijn met malware.

Ik vind het daarnaast erg jammer dat Google probeert zijn eigen standaard erdoorheen probeert te drukken en steeds meer afwijkt van de echte standaarden voor browsers..

[Reactie gewijzigd door vali op 23 juli 2024 04:37]

[benji83]

Ze wijken nergens van af, ze bieden ondersteuning voor alle standaarden, maar voegen dingen toe waarvan ze zelf overtuigd zijn.
Dat Mozilla overweegt ook WebP te gaan ondersteunen geeft al aan dat het blijkbaar doet wat Google belooft.
Als jij met Chrome websites bezoekt die geen webp gebruiken maar andere, gangbare formaten, werkt het nogsteeds prima.
Ze ontwikkelen een bestandsformaat waarvan ze claimen dat het werkt, bieden het aan anderen aan om te gebruiken als ze dat willen, maar verplichten niemand daartoe.

Als niemand andere formaten, protocollen en technieken zou bedenken omdat je dan je eigen standaard er doorheen probeert te drukken, zouden we nu allemaal nog met een telraam bezig zijn en briefjes per postduif versturen.

[vali]

Ze wijken wel ergens van af, ze bieden hun eigen standaard dat alleen in hun browser ondersteund wordt. In het verleden waren vele mensen boos dat Microsoft dit met internet explorer 6 heeft gedaan, maar nu dat Google exact hetzelfde uitvoert is het een goed iets?

Ik heb liever dat Google, Microsoft, Apple en Mozilla rond de tafel gaan zitten om het probleem gezamenlijk op te lossen, dan ieder hun eigen visie gaan implementeren en het voor developers alleen maar moeilijker maken om voor iedereen hun website beschikbaar te maken.

[Verwijderd]

Hier wil ik 2 dingen op zeggen:

- De kritiek op IE6 was voornamelijk het gebrek aan een IE7. Jazeker was IE6 niet helemaal volgens standaarden maar nog duizend keer storender was het feit dat Microsoft dat jarenlang zo gelaten heeft. Men heeft IE compleet links laten liggen en hierdoor kon het web niet vooruit.

- Wat Google hier doet is niet het afwijken van standaarden. Er is namelijk geen W3C webp standaard. Het is een uitbreiding die alleen in hun browser werkt. Mogelijk wordt dit ooit een W3C standaard. Als je je in het W3C proces verdiept dan zul je leren dat het merendeel van hun standaarden voort komen uit browser bakkers die zelf iets uitgevonden hebben.

[raro007]

Je vergelijken klopt niet en weetje waarom?
Jij kan net als een Chrome gebruiker naar die website toe gaan met Explorer.
Je woord niet gedwongen net als met Microsoft.

[vali]

Ik heb werkelijk waar geen idee wat jij probeert uit te leggen..

[Martinspire]

Mja je ziet adblock nog vrij vaak terug. Daarom vind ik het ook wel jammer dat je de whitelists niet effectiever kunt invullen. Ik volg bijvoorbeeld een paar youtubepagina's die ik mijn reclameview wel gun, maar omdat je het bij vrijwel elke video krijgt en je er niet echt op kunt filteren, vind ik het toch niet de moeite waard.
Ik denk dat als youtube zijn link-systeem zou aanpassen er ook meer mensen reclame zouden toestaan bij bepaalde gebruikers. Iets van youtube.com/<username>/video/<naam van video>

Ik snap nog steeds niet dat youtube van die lelijke linkjes heeft. Je hebt wel youtube.com/<username> maar dat is ook alles. Ik kan me voorstellen dat het voor websites lastiger is om bepaalde content te includen als de links veranderen, maar je kunt het ook aankondigen of desnoods met extra buttons de mogelijkheid geven om oude linkjes nog te genereren voor embedding.

Verder is het inderdaad jammer dat ze dit niet via de officiële weg doen en via het W3C erdoor laten werken in de echte HTML-standaard. Ik vind het prima als ze iets willen toevoegen, maar dan moeten ook alle browsers het gaan ondersteunen.
Grote probleem is nu al namelijk dat bedrijven een Android-app bijvoorbeeld ook voor versie 2.x willen hebben werken en dan moet je dus aardig wat gemakkelijke of snelle dingen laten droppen omdat die daar gewoon niet op werken.

[Reactie gewijzigd door Martinspire op 23 juli 2024 04:37]

[sfranken]

Het probleem met het W3C is dat het jaren en jaren duurt voordat die een beslissing hebben genomen over iets. Als je al "prior art" hebt dan gaat het hele proces opeens een stuk sneller.

Als je dus bij het W3C aanklopt en zegt "ik heb een nieuwe standaard voor afbeeldingen maar nog niemand die het gebruikt" zegt het W3C keurig "sluit maar aan in de rij, komt over X jaar wel"

Heb jij echter al browsers die het gebruiken, sites die het gebruiken én cijfers over waarom het beter is (iets wat Google heeft) dan is het voor het W3C opeens een stuk minder lastig zegt maar ;-)

[pj]

Precies!

Maar om al die social media crap uit te schakelen heb je een hele handige extensie: DoNotTrackme

Adblockers laden ze overigens wel maar laten ze niet zien i.t.t. DoNotTrackme

Pagina's laden weer super snel.

[Reactie gewijzigd door pj op 23 juli 2024 04:37]

[ElGamo]

Op DoNotTrackMe: Your email address is being sold to spammers.
Het eerste dat ze willen hebben van je is je mail adres. No Thanks

[pj]

Je mailadres wordt vervolgens gemaskeerd zodat je nooit meer je mailadres ergens achter laat waar je dat niet wil. Zij forwarden het dan naar je echte mailadres.

[JanvdVeer]

Ghostery is dan misschien een beter alternatief:

www.ghostery.com

[Martinspire]

Maar steun je met Ghostry nog wel de website?

En hoe gaat dat dan met reclame's in youtube video's? Imo de meest irritante reclames maar voor sommige youtubers de enige echte manier van inkomen

[joost_m]

Door het wel laden maar niet laten zien van de advertenties steun je een site financiëel. Als je de advertentie niet eens laadt ziet het adverterende bedrijf dat terug in de statistieken, die minder pageviews laten zien. Steun dus gratis sites met goede content (zoals Tweakers) door de advertenties wel in te laden!

[FreshMaker]

Ja, leuk en aardig, 'thuis' met unlimited bandbreedte heb ik er geen moeite mee, maar op mijn mobiele devices waar ook screen-estate beperkt is, pas ik ervoor om megabanners te laten domineren.

Ik pak daar zoveel mogelijk de mobiele variant icm adaway.

een reclame zo nu en dan is niet erg, maar zeker met de aanvallen van de laatste week, waar je gewoon wordt besmet DOOR een malafide advertentie op een verzekeringspagina pas ik daarvoor !

[seba]

Eigenlijk niet, je betaalt meestal voor CPM, clicks dus. Als je ze wel inlaadt, maar niet laat zien, krijgt de site geen geld, maar dalen ze ook in clicks-through ratio (aantal clicks in verhouding met aantal views)

[Dwar]

Geloof niet dat web paginas dezer dagen daar nog voor geoptimaliceerd worden

[Tonko Boekhoud]

Er zijn bergen bedrijven en zzp-ers die zelf hun content willen beheren. En bergen beheerders zijn niet bezig met laadtijd en payload. Ik zie geregeld webpagina's voorbijkomen - ook van grote bedrijven - met daarin plaatjes van meer dan 150 kb. Die plaatjes zijn, zelfs voor een grote monitor, veel groter dan nodig.

Er is daarom veel meer te winnen als cms-systemen foto-uploads automatisch schalen naar maximaal een paar honderd pixels breed en converteren naar een gereduceerde kleurdiepte.

[sfranken]

Er is daarom veel meer te winnen als cms-systemen foto-uploads automatisch schalen naar maximaal een paar honderd pixels breed en converteren naar een gereduceerde kleurdiepte.

Alsjeblieft niet. Als ik een 2160p HDR foto upload wil ik dat die ook 2160p HDR blijft.

Voor assets (plaatjes die van belang zijn voor je website) kun je GIMP/Photoshop gebruiken om ze correct te krijgen, of CSS als je dat leuk vind (met inline-data )

[Tonko Boekhoud]

Het ligt voor de hand dat als je doel is om hoge resolutie foto's te delen, dat je cms die niet automatisch schaalt.

Natuurlijk kan je plaatjes handmatig schalen vóór upload. Maar ik zie steeds dat beheerders van websites dat niet doen. Die zouden een handje geholpen mogen worden. Zij een automaat, jij een handbak, zeg maar.

Overigens in je tekst een misverstand: je kan met CSS wel de hoogte en breedte van een afbeelding op de pagina aanpassen, maar niet de bestandsgrootte in bytes. Daardoor kan je op websites afbeeldingen in een klein formaat maar met een grote payload krijgen.

[sfranken]

Ik bedoelde eigelijk dat je je plaatjes ook via base-64 via CSS kan inladen, dat is (soms) lichter dan de afbeelding uploaden en het zorgt voor een request minder per plaatje.

[Tonko Boekhoud]

Ah okee. Daarmee loop je wel het risico dat je css pas uitgevoerd wordt nadat de hele string binnen is. En die zal bij een 2160p wel meer dan 5 mb zijn toch?

Ik wil eigenlijk juist per pagina meerdere requests naar verschillende eindpunten, zodat niet de hele response uit één wachtrij komt.

Maar, alles hangt samen met het beoogde doel van de website. Als je hoge resolutie plaatjes beschikbaar wilt maken, loop je al gauw tegen interessante technische vraagstukken aan.

[sfranken]

Nee tuurlijk, als je het via base-64 doet moet je dat met kleine plaatjes doen, zoals een Twitter button e.d.

Echt grote afbeeldingen gaan het beste via een CDN

[Vexxon]

Dat heb je flink mis, zeker nu het bezoek van smartphones enorm toegenomen is, is dit weer een belangrijk issue.

[Atomsk]

Voor smartphones heb je vaak al een aparte, eenvoudigere website. Dat is echter vooral omdat het interface van een gewone website niet handig is voor smartphonegebruik, niet omdat smartphones zo'n trage dataverbinding hebben. Met 3G/4G heb je doorgaans namelijk heel wat meer snelheid dan 56kb/s tot je beschikking.

Dus nee, er is geen enkele reden om sites te gaan optimaliseren voor dataverbindingen uit de volgende eeuw. Jammer voor de die 36 belgen. nieuws: Nog 36 belgen hebben internet via inbelverbinding

[Niosus]

Bij responsive design wat tegenwoordig enorm populair is krijgt je exact dezelfde site te zien. Tenzij dat je knoeit met lazy loading wordt het probleem dus alleen maar groter. Op veel responsive sites zit je desktop-size afbeeldingen te downloaden die dan tot nog geen kwart van hun grootte worden geschaald.

Zelfs voor desktops is performance echt belangrijk. Als je site langer dan 3 seconden (gevoelsmatig) moet laden per pagina verlies je een groot deel van je bezoekers. Snelheid is enorm belangrijk. Je hebt server response time, transfer time en render time. Zeker als je advertenties nodig hebt (om je brood te verdienen) en een niet al te zware server hebt is het echt niet evident om een iet-wat complexe site onder de 3 seconden laadtijd te krijgen.

Je mag gebruik maken van bandbreedte, maar performance is echt veel meer dan alleen dat.

[sunflame]

Onzin... Je kan prima andere afbeeldingen gebruiken voor ieder device.
Kijk bijv. eens naar http://zurb.com/playground/foundation-interchange

[Niosus]

Er zijn oplossingen voor, maar er is nog geen optimale manier.

De manier die jij hier geeft maakt gebruik van Javacript. Dit zal wel werken, maar dan worden je afbeeldingen pas geladen na de rest van de pagina als de Javascript wordt uitgevoerd. Dit gaat problemen geven bij prefetch. Ook moet je je code gaan aanpassen om dit te ondersteunen. Als je wil switchen naar een andere JS library voor je responsive images ga je dus tegen migratiemoeilijkheden aanlopen. Verder moet je hier nog altijd 2 requests maken (+ 1x de JS library) per image: 1 voor de default kleine versie en 1 voor de versie die de goede grootte heeft.

Er zijn ook serverside oplossingen die andere groottes terugsturen afhankelijk van een cookie die clientside wordt gezet. Voordeel hiervan is dat je slechts 1 request per image nodig hebt en geen library moet inladen. Ook moet je je code niet aanpassen om dit te ondersteunen. Even serverside instellen, verschillende groottes van je afbeelding laten genereren en klaar. Nadeel is dat je last krijgt met caches.

Geen van beide oplossingen is optimaal. Ze werken, dat zeker, maar dit zijn geen oplossingen voor op lange termijn. Responsive images zijn een open probleem waar veel debat en discussie rond is. Anders zou er echt geen werkgroep rond dit probleem zijn bij de W3C

[Mlazurro]

YouTube is een sociaal platform. Waarom zou Google dat moeten kaalplukken omdat jij met een supertrage verbinding zit terwijl er miljoenen dagelijks van gebruik maken?

Om dan die individuele anekdote te gebruiken als leverage voor het compleet afbreken van een bestandsformaat dat potentieel kleiner en sneller laadt, gaat mij volledig voorbij.

[Silmarunya]

Mij gaat het niet voorbij. Zijn argumentatie komt neer op het volgende: software of hardware sneller maakt, zet developers aan tot inefficiënt programmeren en feature bloat en daardoor is het behaalde voordeel al snel ongedaan gemaakt.

Zie ook https://en.wikipedia.org/wiki/Wirth%27s_law

[Mlazurro]

Hij gebruikt een 56k verbinding. Hij vindt een sociaal medium uit 2014 te traag op zijn verbinding van 1994.
Hetzelfde sociaal medium komt met een potentiëel sneller ladend bestandsformaat. En toch breekt hij die innovatie af. Er is geen logica. With's Law verandert daar niets aan.

[Silmarunya]

De 56k-verbinding is hier irrelevant. Zijn kritiek dat het efficiënter maken van bestandsformaten zinloos is als feature bloat die efficiëntie teniet doet niet.

Dat zie je in software (Wirth's law) en helaas ook in het echte leven (Jevon's paradox).

[Mlazurro]

Ja het zou inderdaad veel zinvoller zijn om het internet terug te brengen naar het internet van 1994 en geen tijd, geld en energie te stoppen in efficientere bestandsformaten. Google moet ook stoppen met hun huidige businessplan en al hun services betalend maken zodat de advertenties verdwijnen.

Zodat de 0.1% met 56K modem nog ietwat tevreden blijft.

[Silmarunya]

Het zou zinvol zijn moesten programmeurs van nu dezelfde drang naar efficiëntie hebben van toen. Dat is niet hetzelfde als 'terugkeren naar het internet van 1994', eerder terugkeren naar een mentaliteit waarin zuinigheid en elegantie nog belangrijk werden geacht.

Denken dat efficiëntie verhogen zonder verspilling aan te pakken een goede oplossing is, is zo'n beetje de ziekte van deze tijd - niet alleen online, maar ook ivm energie, transport, landbouw,... Helaas is dat een race to the bottom waar weinig mee te winnen valt.

Laat die betere formaten maar komen, graag zelfs. Ik zeg enkel dat ze op hun eentje niet genoeg zijn.

[Mlazurro]

Een positieve innovatie gebruiken om een negatieve situatie aan te kaarten en uiteindelijk af te breken.

Dé ideale mentaliteit om programmeurs en webdesigners te stimuleren.

[Verwijderd]

Waarbij opgemerkt moet worden dat meestal de programmeurs geen keuze hebben. Het is niet zo dat alle programmeurs bewust inefficient programmeren, ze krijgen er vaak geen tijd voor.

[Ramon]

Onzin natuurlijk. Google verdient zijn geld met social shit (zoveel mogelijk mensen naar YouTube krijgen) en advertenties (al die mensen moeten advertenties zien). Hoe meer pagina's een bezoeker in een bepaald tijdsbestek kan bekijken, hoe meer geld Google verdient. Dat is de enige reden dat Google Chrome heeft gebouwd en dat Google nu WebP implementeert op hun eigen sites.

[djwice]

Over het formaat: laat die kracht komen uit het zijn van een beter formaat. Betere kwaliteit / bestandsgrootte verhouding, goede ondersteuning, meer functionaliteit, etc. Als jouw formaat dat heeft, dan hoef je mensen ook niet over te halen met triviale statistieken.

tja, was de wereld maar zo zwart wit, dat de beste techniek altijd de mainstream wordt. Helaas hebben we om een technisch goed, duurzamer en goedkpper product dan concurent, nog steeds ook andere competenties nodig, zoals marketing en verkooptechnieken.
Ik kan nu regeren aan het oude betamax verhaal, maar ook omgekeerd hoeveel senseo en nespresso wordt er verkocht? Hebben zijn superieure koffie? Of zijn de pads makkelijker dan een apparaat dat zelf bonen maalt en de juiste hoeveelheid bepaald?

Een kwalitatief goed product verkoopt zichzelf niet automatisch. Veel kleine en grote technologie bedrijven ervaren dat jaarlijks. Zie ook een recent gehouden evenement m.b.t failure van start ups.

[Zer0]

Over het formaat: laat die kracht komen uit het zijn van een beter formaat. Betere kwaliteit / bestandsgrootte verhouding, goede ondersteuning, meer functionaliteit, etc. Als jouw formaat dat heeft, dan hoef je mensen ook niet over te halen met triviale statistieken.

Het formaat is beter, het levert minder bandbreedte gebruik, en dus hogere laadtijden op. Ook dat zijn eigenschappen die (kunnen) bepalen of het beter geschikt voor je is.
Dat er nog andere manieren zijn om een pagina sneller te maken is leuk, en die kun je eventueel combineren met deze techniek, maar dat doet niks af aan het feit dat deze techniek voordelen heeft.

[maevian]

Maar dat is juist hoe websites hun geld verdienen, je kan ook je website proberen sneller maken zonder dat je je grootste bron van inkomsten moet opgeven.

[r.lautan]

Zoals de meesten hier ook wel door hebben kan je een website op verschillende manieren sneller maken. Google biedt het webp formaat om een kleine winst te halen uit de vele afbeeldingen die op de meeste sites staan. Dit is een manier om de load te verkleinen zonder concessies te maken. De kosten hiervan zijn een stuk lager in tegenstelling tot het alternatief.

Een betere website programmeren, minder afbeeldingen te gebruiken, toch weer alles spriten en samenvoegen om http requests te verminderen. Wil je het echt goed doen dan ga je ook nog eens heel gericht kijken welke delen op welk moment te laden via ajax en dan hebben we het niet eens over dynamic serving voor al de verschillende platformen. En daar kan niemand het hier mee oneens zijn dat het zeker mooier is, maar ook veel duurder is .

Daarnaast helpt dit webp formaat ook mee bandwidth te verminderen. Aanzienlijk zelfs. En dat is wel goed nieuws als je mobiel browst.

PS. Ik ben het er wel volledig mee eens dat al die social media crap websites nodeloos vertragen.. Maar ook hier zijn best mooie oplossingen voor die pas worden ingeladen wanneer het nodig is.

PSS. Om het allemaal makkelijker te maken zijn er ook wat tools en libraries om on the fly webp te verkrijgen. Als je dit goed implementeerd is het niet persé heel veel meer werk.

[Reactie gewijzigd door r.lautan op 23 juli 2024 04:37]

[satya]

Het valt mij op dat er een enorme focus is op de manier waarop content wordt aangeboden aan de gebruiker. Maar ook andere zaken hebben zo hun invloed kwam ik achter. Recent werd een van onze sites regelmatig met tcp_syn flood (dos) aangevallen, en zijn daarvoor op kernel nivo ip parameters aangepast.
Een onverwacht bijeffect is dat de responsivieit van de website en de daar onder liggende webservices die we hosten ook verbteterd zijn.

[NicoJuicy]

Welke aanpassingen heb je dan gedaan?

[satya]

/proc/sys/net/ipv4/tcp_fin_timeout > 15
/proc/sys/net/ipv4/tcp_max_syn_backlog > 2028
/proc/sys/net/ipv4/tcp_synack_retries > 3
/proc/sys/net/ipv4/tcp_keepalive_probes > 5
/proc/sys/net/ipv4/tcp_keepalive_time > 120
/proc/sys/net/ipv4/tcp_keepalive_intvl > 30

[Fiander]

Als ze echt willen dat de google website mij een snellere ervaring geeft,
laat ze dat weer echte linken naar andere pagina's geven, en geen redirects via de servers van google.
Dan werkt de back knop in me browser misschien ook weer zonder dat ik er twee keer snel op moet drukken.

Ik begrijp dat dit nodig is om mij te kunnen volgen zonder koekjes, en dat "ik" de belangrijkste inkomsten bron ben, maar het werkt wel vertragend.

verder: als dat webp even goed werkt als YouTube met dat nieuwe filmformaat, dan kan ik in de toekomst dus half geladen plaatjes en verminkt beeld verwachten?

[Reactie gewijzigd door Fiander op 23 juli 2024 04:37]

[r.lautan]

Geen zorgen Fiander! Ook hier zijn ze mee bezig... Ik snap je frustratie met al die redirects en het volgen en het wel en niet cookie maar Google (en natuurlijk vele anderen) willen het web alleen maar beter maken. Hier verdienen ze natuurlijk hun geld mee. Een van die experimenten om het web te verbeteren is bijvoorbeeld SPDY (nieuws: Google: Spdy-protocol versnelt opvragen websites tot 40 procent).

verder: Het zou zich lonen om het geheel even goed door te lezen dan gewoon een aanname te maken. Nu is niks perfect maar zonder die stappen ertussen word dat het toch nooit beter...

[Verwijderd]

Laat ze maar eens een player maken die maar één keer hoeft te bufferen ipv telkens opnieuw als je een stukje skipt

[Blokker_1999]

het volledig filmpje moet eerst volledig gedownload zijn voordat je kan gaan beginnen skippen zonder bijkomende buffering. Heb je een HD film van groote lengte dan is dit niet op 5s geladen.

[Verwijderd]

Nee, het opnieuw bufferen van iets wat al gebufferd is is efficiënt! Tuurlijk, als je naar een ongebufferd stukje skipt is t logisch dat ie moet bufferen... Maar telkens de hele buffer wissen is ook achterlijk en kost onnodig veel dataverkeer.

[iAR]

Dan ben ik met je eens. Hopeloos... en als je denkt laad het filmpje maar helemaal blijft ie steken op x% van de playhead.

[Silmarunya]

Zo'n player zou het volledige filmpje tegelijk moeten bufferen. Niet erg efficiënt, zowel client- als serverside.

[lf2]

Weet je wat meestal het traagste laad op een website...?

De javascripts van Google zelf. Zowel analytics en nog erger de advertenties. Daar zouden ze echt wat aan moeten doen en zoals eerder gemeld al die social media buttons die je ook nog eens tracken.

[Verwijderd]

Gewoon adblockers en track-me-not extensies installeren, die kapt alle tracking en advertising cruft af waardoor je browser veel sneller wordt en de content ook nog eens makkelijker wegleest want geen afleidende ads.

https://adblockplus.org
https://www.abine.com

[calvinturbo]

Daar laadt een pagina niet veel sneller van anders..
Ik heb wel op sommige sites adblock aanstaan omdat het aantal Adobe Flash advertenties daar zo hoog is dat het RAM verbruik veel te hoog is voor die pagina.
Track-me-not extensies heb ik niet, omdat deze helemaal niet zorgen dat je browser trager gaat / website trager laadt.

[Valentijn]

Youtube is er sinds een week door onverklaarbare wijze mee opgehouden / speelt nog maar 1 video af. Ik ben er niet achter. Welke plugins (versies) heb jij geactiveerd? ik dacht dat t door adblocker komt, maar zelfs in incognito (wwaar adblocker sowieso niet actief is bij mij doet het probleem zich voor

[MiesvanderLippe]

Damn, in incognito is AdBlock juist een hemel!

[Valentijn]

Ik heb veel.liever dat YouTube gewoon werkt

[Tonko Boekhoud]

Dat ligt eraan hoe je die javascripts laadt. Zowel ads als analytics kan je asynchroon laden, waardoor die de weergave van de content op de pagina op het scherm niet vertragen.

Waar we recent tegenaan gelopen zijn was het laden van een door jquery.com gehoste altijd-laatste-jquery-versie. Soms wachttijden van seconden. Juist de overstap naar googleapis heeft voor de nodige opluchting gezorgd.

[halofreak1990]

Volgens mij staat er ook op de jQuery site dat je dit niet moet doen, maar de scripts embedden in je site.

[Tonko Boekhoud]

Dat is lang zo geweest, maar tegenwoordig geven ze op http://jquery.com/download/ zelf de mogelijkheid van CDN aan.

[Blaise]

Het klopt niet helemaal wat je zegt.

Google Analytics wordt standaard asynchroon geladen en zal de pagina niet vertragen omdat alle synchrone html, stylesheets, scripts eerst wordt geladen. Zie http://www.stevesouders.c...gle-analytics-goes-async/

Google Adsense wordt ook standaard asynchroon worden geladen, tenzij je dat uitzet. Zie https://support.google.com/adsense/answer/3221666?hl=en. Dat websitebeheerders soms prioriteit aan advertenties geven, ten koste van het snel weergeven van de content, is niet de schuld van Google. Adsense-advertenties zijn vaak erg licht als je het vergelijkt met video-advertenties en andere grafische zooi.

Je kan je beschermen tegen online tracking met browser plugins als Ghostery en Disconnect.

[WokeBroke]

de sociaal media plug-ins zijn veel zwaarder, en die kunnen eventueel ook onclick(); geladen worden, maar dat doet bijna geen een webmaster.

[Verwijderd]

Die moet je dan ook helemaal onderaan je website plaatsen hé.

[halofreak1990]

Ja, maar wie doet dat nou. 't Is toch veel makkelijker om alle JavaScript bij elkaar in de <head> te proppen?

[Jarrichvdv]

Dat doet bijna elke website die zichzelf een beetje serieus neemt. Een grote moeite is dat niet he; om een scriptje te verplaatsen.

[Verwijderd]

10% voordeel komt me niet als baanbrekend voor zodanig dat er sprake zou kunnen zijn van het breed uitrollen van deze Google standaard. Als het nou 2x zo snel zou zijn spreken we van een moetje maar 10% waarbij Google waarschijnlijk naar boven afgerond heeft, lijkt me nou niet echt een wezenlijke vooruitgang zeker als je in het achterhoofd houdt dat computers en netwerken sneller worden en storage goedkoper.

edit@hieronder: ik heb geen website, ik reken vanaf de gebruikers (clients), wat Google verder voor beslommeringen in zn datacenters heeft qua optimalisatie is niet iets wat mij als gebruiker/consument interesseert.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 04:37]

[NicoJuicy]

35% kleiner en de impact op het laden is 10% omdat er zoveel factoren zijn die de snelheid beïnvloeden.

Wat jij verwacht is onmogelijk... Met 1 simpele wijziging een website 2x zo vlug laten laden is een onhaalbare eis en je commentaar vind ik uiterst kortzichtig. Google probeert overal efficiënter te werken en jou commentaar erover is dat storage goedkoper wordt en netwerken efficiënter. Daarbij ben jij wel verwend met breedband internet, maar niet iedereen in de wereld heeft ook die luxe.

[Reactie gewijzigd door NicoJuicy op 23 juli 2024 04:37]

[Verwijderd]

Dit is simpelweg niet waar. Iedere website die niet onder handen is genomen door een front-end expert met performance tuning kennis, en geloof me, dat zijn de meeste sites, kunnen met kleine ingrijpen vaak 200-400% kleiner gemaakt worden.

[NicoJuicy]

Voor die sites waarover jij het hebt is het een beetje een broodje aap verhaal.

Google is geen kleine website... Zoek daar eens een kleine ingreep waarmee er een 200-400% verbetering merkbaar is.

En daarnaast, minimizen van css, html en js zit tegenwoordig standaard in de webdev-toolbox (incl. correct resizen van images)... Maar kleine websites hebben zoiets niet nodig en worden meestal via een bepaalde toolbox gegenereerd..

Daar houden ze geen rekening met verbeteringen en dergelijke (behalve als het groot wordt) en daar is deze aanpassing ook niet nodig.

[basdej]

misschien niet voor jouw website, maar bij Google scheelt het al 10tallen terrabytes aan dataverkeer. Dus het is waarschijnlijk handig voor druk bezochte sites. mooi dat google het helpt ontwikkelen!

[Verwijderd]

10% is juist heel veel als je de gehele datastroom berekend. Voor Google betekend dit 10% kostenbesparing op bandbreedte.

Even iets verder redeneren dan je neus lang is. Dit is voor Google heeeeel veel.

[Ceejay]

Maar moet je dan niet allemaal extra conversies doen van je jpegs naar webp? En dan vervolgens toch al je jpegs aanhouden voor de oudere browsers die geen webp ondersteunen? Lijkt me dat dat eerder extra webruimte kost dan oplevert.

Allemaal boel extra werk voor de webdeveloper.

[Distael]

Ja nu nog wel. Als alle browsers dit formaat hebben omarmd heb je daar geen last meer van e heb je wel 10% besparing op bandbreedte...vooral naar mobiele apparaten toe zorgt dat voor een snellere laadtijd bij eenzelfde content...niet verkeerd dus.

Je moet toch ergens beginnen wil je dingen verbeteren...Google begint bij zichzelf

[Reactie gewijzigd door Distael op 23 juli 2024 04:37]

[NLAnaconda]

Maar dan ben je weer jaren verder omdat je oudere browsers ook wilt ondersteunen. Kijk naar de IE 8 die je op dit moment nog niet kan negeren.
Voordat je volledig op zo'n nieuw afbeeldingsformaat over kan gaan en niet meer voor fall-backs hoeft te zorgen ben je zo vier jaar verder.
Maar inderdaad, het moet een keer beginnen.

[MadEgg]

Internet Explorer 8 ondersteuning stop ik mee vanaf het moment dat Windows XP niet meer ondersteund wordt, nog een maandje dus. Reden: IE8 is de laatste beschikbare versie voor Windows XP. Op Windows Vista, 7 en 8 heb je geen enkel excuus om IE8 te draaien en automatische updates zijn ook veel meer gepusht. Er blijven dus veel minder mensen hangen dan op IE8.

Als je dan tóch willens en wetens blijft zitten met een verouderd OS wat niet meer ondersteund wordt hoef je ook niet te rekenen op mijn ondersteuning van de browser.

IE6 had grote problemen met ondersteuning omdat veel bedrijfskritische applicaties gericht waren op IE6 omdat MS heel lang is blijven hangen bij IE6. Voor IE7 en IE8 is dit nooit het geval geweest, dus is er ook daar weinig reden om nog op een antieke browser te zitten.

[Tonko Boekhoud]

Psies. <!DOCTYPE html> om IE8 zo compliant mogelijk te krijgen en verder jammer dan.

[jorisderoo]

Dat maakt op zich niet uit. Je kunt op basis van de gebruikte browser de juiste plaatjes laten zien.

[MadEgg]

Tja, en toch komt de meeste crap, ook voor mobiele websites, niet uit de plaatjes maar uit scripts en dergelijke reut. Het lijkt developers steeds minder te kunnen schelen hoeveel bandbreedte hun website in beslag neemt. Natuurlijk helpt verkleinen van afbeeldingen daar wel wat bij, maar het meeste gaat, zoals twiFlight hierboven ook al opmerkt, naar het laden van social media en advertising meuk.

Op vakantie maak ik nog wel eens gebruik van internet op mijn laptop via tethering met mijn mobiel. Een 3G verbinding dus. Ik merk echt een enorm verschil in laadtijd als ik wél of geen RequestPolicy gebruik wat al die nutteloze requests voorkomt. Dat kan zo het dataverkeer reduceren van 1 tot 2 MiB naar 200 - 300 KiB. Dát scheelt, niet die 10% winst van een ander formaat voor de plaatjes.

[NicoJuicy]

Je hoeft zulke verbeteringen alleen maar te overwegen als je populair genoeg bent, bv tweakers zou het kunnen implementeren vermoed ik.

[drakiesoft]

Laat ze eerst maar eens die reclame scripts, google analytics en al die andere scripts verbannen, dan wil ik het nog wel overwegen. Internet is dankzij google een grote trage reclame en cookies spambox geworden.

[Blokker_1999]

En vind jij dat abnormaal? Heb je dan liever een paywall? Vraag bijvoorbeeld eens aan tweakers hoeveel % van de gebruikers bereid is om te betalen voor een reclamevrije site ... . Of denk je nu echt dat duizenden servers over tientallen datacenters geen geld kosten?

[iAR]

Daar gaat het niet om. Volgens mij bedoelt hij te zeggen dat met al die scripts een nieuwe formaat de snelheid amper gaat uitmaken...

[NicoJuicy]

Betaal je dan liever voor alles?

[Silmarunya]

Het zou in ieder geval fijn zijn moesten ze de keuze geven. Sommige mensen willen graag betalen voor privacy en een cleane site.

[JoepD]

Zoals hierboven gezegd vind ik dit ook het verkeerd aanpakken van problemen. Ik snap dat advertenties nodig zijn om het platform draaiende te houden, maar misschien moeten ze er eens over nadenken om daar snelle alternatieven voor te ontwikkelen. Nu proberen ze een eigen afbeeldingsformaat erdoor te duwen waarmee dagelijks terabytes aan opslagdata bespaard kan worden. En dat in tijden dat opslagkosten al lang niet meer zo relevant als jaren geleden zijn.

Wanneer gaan we eens een alternatief voor Flash ontwikkelen? Ik heb altijd al problemen met Flash gehad, zelfs op mijn recent aangeschafte high-end desktop. Ik het het idee dat Flash echt gebaseerd is op zwaar ouderwetse code. Als dat waar is, wordt het tijd voor Adobe om eens from-scratch met Flash te beginnen of moet Google een snel alternatief ontwikkelen. Dat zou pas voor snelheidswinsten zorgen.

[codebeat]

Ouderwetse code, dat klopt wel ja maar ook optimalisatie. Dus bijvoorbeeld twee plaatjes die over elkaar bewegen a 24bits met transparantie. Dan gaat je CPU wel blazen. Het mag niet veel kosten zo'n advertentie dus daar is nauwelijks aandacht voor.

[Reactie gewijzigd door codebeat op 23 juli 2024 04:37]

[Silmarunya]

Flash kan behoorlijk efficiënt zijn, maar vaak wordt het gebruikt om overdreven fancy en slecht geprogrammeerde animaties te maken. Een slechte bouwvakker steekt het op zijn gereedschap...

HTML5 is dat alternatief, maar het zijn net voor de 'ergste' toepassingen van Flash dat HTML5 geen alternatief is.

[Verwijderd]

Als het inderdaad kleinere bestanden met dezelfde kwaliteit geeft kan ik de ontwikkeling van een nieuw opensource bestandsformaat alleen maar toejuichen.

[blorf]

Zo denk ik er ook over. Maar:

Gemiddeld genomen zorgt het gebruiken van webp in plaats van andere formaten voor 35 procent kleinere plaatjes, aldus Google.

Iets zegt me dat dat 'gemiddeld genomen' de misleidende truuk is. Is die 35% ook van toepassing op alleen lossless Webp compressie?