Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 150 reacties

Individuele pagina's van websites zijn op dit moment gemiddeld net zo groot als de bestanden die nodig zijn voor de installatie van Doom, de gameklassieker die in 1993 verscheen. Dat becijferde webontwikkelaar Ronan Cremin.

Doom coverDe install image van Doom is ongeveer 2250 kilobyte groot en volgens cijfers van Http Archive is de gemiddelde grootte van een internetpagina op dit moment 2301kB. Ronan Cremin voorspelde in juli 2015 al het moment waarop webpagina's net zo groot zouden zijn als de installatiebestanden voor Doom. Hij zat er uiteindelijk twee maanden naast met zijn berekening, omdat de groei in grootte van pagina's iets is afgezwakt.

Dat webpagina's nu net zo groot zijn als een volledig spel is niet alleen een opmerkelijk feit; Cremin wil ook een punt maken. Hij vindt dat er meer aandacht moet worden besteed aan de grootte van webpagina's. Doom is immers een spel met een 3d-render engine, meerdere levels en bijbehorende geluidseffecten. Websites hebben anno 2016 moeite om één pagina weer te geven met dezelfde bestandsgrootte.

Wel merkt Cremin op dat webpagina's van de top tien van meest bezochte websites juist kleiner zijn geworden de afgelopen jaren. In 2014 was die categorie nog goed voor zo'n 1500kB per pagina, nu is dat minder dan 1200kB. Volgens Cremin is het groter worden van webpagina's niet alleen het gevolg van advertenties, maar ook vanwege de vele features die worden toegevoegd, zoals webfonts en analytics. De boodschap van Cremin is dat ontwikkelaars zich de afgelopen jaren niet genoeg bezig hebben gehouden met prestaties en het verkleinen van webpagina's.

Web is Doom

Lees meer over

Moderatie-faq Wijzig weergave

Reacties (150)

Dit is een van de betere videos over de problematiek:
https://vimeo.com/147806338
goeie video, echter ben ik er ook van overtuigd dat het web natuurlijk mee mag groeien en een vaste grens aanhouden van 1mb is hier natuurlijk niet vordelijk voor.

je zou eigenlijk een grens moeten hebben in "time to load"
en die op maximaal 1 seconden. via DSL
1 seconde is maar relatief, zelfs via DSL. Het hangt van zoveel meer factoren af. Het zou gewoon in iedere webdever zijn aard moeten zitten om zo effectief mogelijk te coderen :)
Hahaha, het zou ook vrede op aarde moeten zijn en iedereen zou genoeg te eten moeten hebben. Feit is dat programmeurs altijd 'lui' zijn.
Feit is dat programmeurs altijd 'lui' zijn.
Nu ga ik niet ontkennen dat ik lui ben, een luie programmeur automatiseert uiteraard meer zodat dit alles minder energie of tijd kost.
Maar luiheid is vaak een ondergeschikte oorzaak. In veel gevallen draait het niet om luiheid, maar om budget. Extra optimaliseren kost meer tijd, en daarmee meer geld.

Il ben het er persoonlijk mee eens dat er meer gekeken moet worden naar performance, size en loading/render speed, maar dat kan vaak pas nadat de functionaliteit zelf staat, en de business value gaat vaak niet mee omhoog. Dus zie het budget maar te krijgen.
Ik ben als peogrammeur zeker niet lui.. En ik ben wel een peogrammeur die the extra Mile gaat om het nog net iets beter te krijgen.

Ik ben zeker niet lui en ik heb een hoge standaard voor mezelf.

Dus een grote groep maar niet iedere programmeur is lui, ik ken wel een hoop die of slecht zijn of er inderdaad geen fck om geven.

Er zijn er een hoop die ik graag een schop onder hun kont zou willen geven.

[Reactie gewijzigd door Zezura op 24 april 2016 12:09]

De uitzonderingen bevestigen de regel. Maar goed, het geld natuurlijk niet voor iedereen daarom had ik 'lui' ook tussen aanhalingstekens gezet. Het woord 'altijd' moet ook weg.

[Reactie gewijzigd door dezwarteziel op 24 april 2016 08:43]

Hmm ja met async page Loading gaat die vlieger niet helemaal op.

Misschien als Load + alle scripts :)
zonder Ads dan he... en je ziet in de chrome dev tools wanneer alle scripts geladen zijn ook asynch.
Zeker, maar ik bedoelde aan te geven dat een simpele wget niet specifiek genoeg is
Ik zou zeggen time to interact. Want laden is een... eindelijk klaar om te doen waarvoor je kwam zonder laadbalken en spinners.

En ik zou zeggen, via een verbinding in de trein en met een mobiel van de Aldi.

Anders blijf je jezelf op die i7 met SSD waar je op ontwikkeld rijk rekenen.

HTTP/2 Push is er niet voor niets jongens!
Ga het nu eens gebruiken, je zult je stakeholders en bezoekers blij verbazen.

[Reactie gewijzigd door djwice op 22 april 2016 20:28]

Trein verbinding is 10kbit/s omdat alle gebruikers in de trein een halve 3G verbinding delen (half omdat een trein beweegt en er dus veel gewisseld wordt van mast).
Bij ons zie ik dat de meeste contracten in de trein worden afgesloten. Blijkbaar een dull moment om het FF te regelen... :)
Tsja met al die vertragingen heb je rustig een uur de tijd om dat soort dingen te regelen. Ik ga er iig niet op zitten interwebsen. Gelukkig wordt eind dit jaar een upgrade naar 4G geplant. Dus in 2017 hebben we ws 64tot 128 kbit/s per persoon ;)
Goeie presentatie! En de eye vergelijking op het dollarbiljet, hilarisch!
Cremin wil ook een punt maken. Hij vindt dat er meer aandacht moet worden besteed aan de grootte van webpagina's. Doom is immers een spel met een 3d-render engine, meerdere levels en bijbehorende geluidseffecten.
Meneer vergeet even dat we nu content bekijken op schermen met resoluties oplopend tot boven de 3840x2160 pixels. Dat is wel even andere koek dan wat Doom op het scherm toverde. Alles moet haarscherp zijn, dus foto's worden meteen een stuk groter. Dan zijn er nog de databases die alsmaar groter worden, meer code om te zorgen dat het allemaal lekker werkt op enorm veel browsers, op diverse schermformaten, etc.

En daarbij: wat is 2MB voor een pagina nou? Mobiele bundels worden steeds groter en de internetsnelheid is al lang geen beperkende factor meer.
Dan zijn er nog de databases die alsmaar groter worden
Dat is niet echt een relevant feit, want dat is vooral een backend aangelegenheid. Je download als gebruiker niet die database :)
En daarbij: wat is 2MB voor een pagina nou?
Om dat even in perspectief te plaatsen: met een 1GB abonnement (niet heel vreemd) mag je dus maar 500 pagina's per maand opvragen, oftewel 16 a 17 per dag. Dat is niet bijster veel. En dan verbruik je je bundel volledig met het opvragen van webpagina's en niet met overige diensten/apps, dus in de praktijk ligt het aantal veel lager.

Wel moet je er denk ik een kanttekening bij plaatsen: ik gok dat het hier gaat om de complete content van een pagina. Dat download je niet elke request, want een hoop statische content (oftewel vrijwel alles behalve de daadwerkelijke HTML) wordt gewoon gecached. Het gemiddelde HTML document is volgens de bron slechts ~20kB.

[Reactie gewijzigd door .oisyn op 22 april 2016 11:36]

Hoewel technisch gesproken officieel geen onderdeel van HTML5 worden WebSQL (sqlite) databases wel vaak onder de noemer HTML5 geplaatst, maar is inmiddels depricated. Maar je kunt dus wel degelijk client-side sql databases hebben.

Wij gebruiken de client-side db om client-side performance statistieken (full roundtrip) bij te houden. Periodiek wordt die data naar de server gestuurd.. Want een oude pc op een budget ADSl lijn geeft toch een heel andere performance welke wij ervaren hier op kantoor..

[Reactie gewijzigd door Niemand_Anders op 22 april 2016 12:14]

Maar daarbij wordt er dus geen data gedownload, en dat is waar het hier om gaat :)
En vergeet de responsive/mobiele variant van een webpagina niet.. dat kan ook data schelen.
Het suffe is dat responsive paginas niet perse kleiner zijn. Sommige desigers denken slim te zijn door dynamisch mee te schalen op basis van schermgrootte, maar op de achtergrond haal je net zoveel zooi binnen als de desktop versie. Het is eerder wat lui en wat dat betreft is er echt nog wel een case te maken voor dedicated mobiele versies van een site.
Vandaar dat ik zei "dat KAN ook data schelen" ;)
Sommige developers zijn inderdaad te lui om het goed toe te passen en schalen inderdaad maar domweg in plaats van dat ze responsive images (mbv. srcset) gebruiken. Dat bestaat al een paar jaar, dus aan ondersteuning kan het niet aan liggen. Je hoeft niet persť een dedicated mobiele versie te hebben tegenwoordig.

Van de andere kant worden de resoluties van mobiele devices ook steeds groter. Mijn smartphone heeft een vťťl grotere resolutie dan mijn desktop..
De responsive variant is daarmee dus niet data besparend. Deze werkt namelijk met dezelfde css bestanden als op desktop. Misschien dat plaatjes met lagere resoluties worden geladen, maar gezien de huidige trend van FHD displays in telefoons denk ik dat niet.
Daarom haalde ik op het laatst ook de resolutie aan ;)
Een smartphone met QHD zou dan veel meer data trekken dat een desktop met FHD scherm, maar zelfs dŠn kun je nog meerdere kanten uit. Het hoeft namelijk niet alleen te gaan om aantal pixels, maar ook om pixeldichtheid en viewport. Een website op een QHD scherm kan als een 800x1280 mode gerendered worden, met een pixeldichtheid van 1, 1,5 of 2.. dat is met srcset allemaal in te stellen. Je kunt dus de browser forceren dat een afbeelding van 800px breed ook als 800px afbeelding wordt geladen, ondanks dat de resolutie in werkelijkheid 1600px (pixeldichtheid 2) is. Daarmee bespaar je weer data.

[Reactie gewijzigd door deco1974 op 25 april 2016 10:10]

Als jij een 1gb abbo afneemt, dan ben je gewoon een klein verbruiker en dan zul je waarschijnlijk niet constant via je provider data afnemen maar voornamelijk via wifi browsen.

En via wifi is het verkeer gewoon onbeperkt.
Ondanks al die recentere abo's waar je momenteel mee om de oren wordt gegooid, zal de gemiddelde persoon nog gewoon rond de 1GB hebben, hoor.
En die mensen gebruiken dan Wifi en niet 4g voor alles zoals ik.

Overigens...

Je klaagt dat pagina's te groot zijn. Eens gekeken naar dat oh zo grappige plaatje naast je naam? 70kb. 70 hele pagina's tekst. Alleen voor jouw alleen die al die arme mensen met een 1GB abbo moeten downloaden. Stouterd!
En die mensen gebruiken dan Wifi en niet 4g voor alles zoals ik.
De mensen die 4G voor Šlles gebruiken zijn imho vrij zeldzaam. Misschien moet je dus niet zo generaliseren.
Je klaagt dat pagina's te groot zijn
Oh? Waar doe ik dat precies? En had je mijn voetnoot ook gelezen? Dat plaatje hoef je niet elke page request te downloaden.
Ik moet zeggen dat ik dit sinds een week nu ook doe behalve thuis en bij een medetweaker waar ik wel eens kom thuis heb ik 150mb down en bij hem 250Mbit/s symmetrisch dus dan heb ik liever dat icm lage ping. Voor de rest alles 4G.
[...]
Dat plaatje hoef je niet elke page request te downloaden.
Hmmm, dan ga je er dus vanuit dat elke bezoeker hier dat plaatje dus al ergens in zijn cache heeft staan omdat hij het ergens anders al is tegengekomen.

Alhoewel je wel leuk uit de hoek komt, betwijfel ik toch of 100% van het t.net publiek bestaat uit de .oisyn fanclub die niets anders bekijkt dan pagina's waar .oisyn op reageert :)
Natuurlijk leest iedereen mijn posts, hoe durf je dat in twijfel te trekken :P

Maar mijn punt is natuurlijk dat het niet per se bij ťlk request naar t.net opnieuw dat plaatje hoeft te worden gedownload. Zeker de regelmatige bezoeker zal wel over een rijk gevulde cache aan user icons beschikken. Maar idd, de sporadische lezer zal wel geconfronteerd worden met een aardige hoeveelheid data aan icons. Al heb je volgens mij wel de mogelijkheid om dat uit te zetten ik je voorkeuren (waar de sporadische bezoeker dan typisch weer niet van weet)
WiFi hier in Nederland is misschien onbeperkt. Maar Belgie bijvoorbeeld heeft data limieten.
Dat is niet echt een relevant feit, want dat is vooral een backend aangelegenheid. Je download als gebruiker niet die database

Optimalistatie voor SQL injectie zodat de DB sneller naar binnen getrokken kan worden. Normalisatie mensen! Ik zeg doen :)
Ik vind eigenlijk dat je heel selectief quote en niet het gehele punt benadrukt wat hij wil maken... hij wil aangeven dat er te weinig aan optimalisatie wordt gedaan bij vele websites, maar dat het daarbij wel opvallend is dat druk bezochte webpagina's juist wel kleiner in formaat zijn geworden en dat is om een goede reden; dat gaat niet alleen om de databundels van de consument maar ook de hoeveelheid data aan verkeer wat een webserver e.d. moet verstouwen. Als een webpagina van 2MB geoptimaliseerd zou kunnen worden naar bijvoorbeeld 1,5MB, dat levert je een opbrengst van 25% aan minder dataverkeer en dat is niet mis eerlijk gezegd, zeker niet als je het over een pagina hebt die miljoenen hits per dag heeft. Die 25% werkt dan op vele manieren voordeliger voor leverancier en consument... sowieso dus qua data, maar uiteraard ook aan energie, kosten etc.
"En daarbij: wat is 2MB voor een pagina nou? Mobiele bundels worden steeds groter en de internetsnelheid is al lang geen beperkende factor meer. "

Juist door die instelling is dit probleem er. Op mobiel bijvoorbeeld zijn gemiddelden van 7-12 seconde laadtijd gebruikelijk (op 3G, en op 2G ver boven de minuut). Het gemiddelde netwerk wereldwijd is nu en de komende 10 jaar hooguit crappy 3G.
Daarnaast zijn er voor veel websites een mobiele versie die lichter is dan de complete bulk website dit is ook nog een belangrijk punt die je niet moet vergeten.
Tegenwoordig werken veel websites met responsive design: Dat is 1 pagina die zich aanpast aan elk formaat. Je downloadt dus de hele pagina voor die websites. Bijvoorbeeld een overdaad aan Javascript code (soms ettelijke megabytes aan code) moet nog altijd volledig zijn voor op je GSM. Dit zorgt niet alleen voor grote download sizes, maar ook voor laggy pagina's die batterij vreten.

Ook is het nog altijd ongelooflijk moeilijk om afbeelding te resizen naar het juiste formaat voor het scherm. Responsive images (waarbij een GSM een kleinere foto dan een PC krijgt) zijn absoluut nog een zeer actueel probleem. Men is bezig aan oplossingen maar op dit moment is er nog geen goede oplossingen zonder compromis die snel en eenvoudig te implementeren is voor developers.
De komende 10 jaar crappy 3G? Hoe kom je daarbij? 4G is tegenwoordig zowat overal met zelfs al verbeterde versies ervan. Het lijkt me dus zeer onwaarschijnlijk dat we de komende 10 jaar hooguit "crappy 3G" gebruiken. Dat punt ligt al een tijdje achter ons.
Je leest over het woordje 'wereldwijd' heen. Internet is immers wereldwijd, dus je moet buiten ons ontwikkelde landje kijken. Wij zijn extreem verwend met een dekkend 4G netwerk.
Excuus, daar heb ik inderdaad overheen gelezen. Dat veranderd echter niets aan mijn mening. De komende 10 jaar crappy 3G...beetje overdreven in mijn ogen.
Zelfs in het gebergte in sri lanka had ik 4 jaar geleden een dekkende 3G verbinding van 7mbit/s op mn iphone 3G. Ik denk dat het in dat opzicht dus alleszins meevalt met "crappy"
Hier in Nederland misschien, maar ik denk dat grote delen van de wereld nog wel even moeten wachten op goede 4G dekking.

Ik stond wel even verbaasd te kijken toen ik las dat een gemiddelde pagina tegenwoordig 2 MB is. Dat is m.i. echt wel veel. Vroeger waren mp3tjes gemiddeld zo'n 3 MB.
Ja ik ben het met je eens dat 2MB wel vrij groot is, had ik zelf ook niet verwacht. Maar dit geeft denk ik meer aan hoe hopeloos de mobiele data bundels(voor acceptabele prijzen) achterlopen.
Nee, dat ligt niet achter ons, dat ligt VOOR ons. Moeite met de woorden "gemiddelde" en "wereldwijd"? Bij jou ook geen klimaatprobleem omdat het in je tuin fris is?
Je weet wat ze zeggen over het klimaat"probleem" ;)

:p
Pagina snelheid is een huge SEO factor, ook is het voor gebruikers een behoorlijke afknapper als het te traag gaat.
"Pagina snelheid is een huge SEO factor"

Dat klopt niet, iedereen praat elkaar daar over na en dus wordt het een geaccepteerde "waarheid" maar is feitelijk onjuist. Als je website echt uitzonderlijk traag is KAN je lager komen in de rankings. Een website die sneller is dan de gemiddelde website levert geen enkel direct SEO-voordeel op.
Sites die traag werken, dus loadtime, time to first byte, aantal data dat het verstuwt, worden wel degelijk 'lager' gerangschikt in de zoekmachine ( in ieder geval google ).

Het is daarom belangrijk je aan bepaalde zaken te houden wanneer je websites maakt, zeker als je dat organisch goed wil laten scoren.

- Caching
- Onsite optimalisatie, minify van HTML / CSS / JS
- Images comprimeren (lossless) voor minder 'onnodige' overhead

Vooral voor mobiele bezoekers is dat belangrijk. Met alleen al minify kan je per verzoek best wat KB's afschaven, wat qua verkeer met 1000 bezoekers een leuk aantal MB's tot zelfs GB's minder wordt.

Dus ja, voor goede SEO is een snelle en low-resource achtige website, wel degelijk belangrijk.

Doom bestond overigens uit "sprites" - dat waren vooraf getekende animaties die achter elkaar af werden gespeeld, het uit elkaar spatten van een imp of soldaat bijv. Zoveel nam dat niet in beslag, en verder ging de techniek destijds ook niet. Tegenwoordig vergen we game installs van meer dan 60GB.
"Sites die traag werken, dus loadtime, time to first byte, aantal data dat het verstuwt, worden wel degelijk 'lager' gerangschikt in de zoekmachine"

Ik heb hier nooit een uitspraak over gezien van Google, alleen SEO "experts" die elkaar napraten in fora e.d. Wat ik gelezen heb uit officiele Google-bronnen kan dat alleen in extreme gevallen zo zijn. Maar dan nog worden in mijn ervaring zeer trage populaire sites met veel inkomende links gewoon bovenaan gezet en helpt sneller dan gemiddeld al helemaal niet. Al is dat natuurlijk voor niet-SEO redenen nog steeds een mooi streven.

In ieder geval is het averechts om maar voor de maximale score in Google Pagespeeds je site te slopen.
https://www.youtube.com/watch?v=SO4YuDAkplU

Matt cutts, was ooit hoofd daar bij Google webmasters. Ja je kunt ranking verliezen als je server constant een hoge time to first byte uitspuugt. Let wel dat deze video uit 2011 is, en het algoritme hiertoe ook veranderd is. Sitespeed is echt wel degelijk een indicatie in SEO-algoritme. Ik heb het op tientallen sites getest, gebotvierd, en merk dat het gewoon net het verschil maakt tussen de rest wanneer je,

- Minified
- Cached
- SSD gebaseerde server die niet constant hoge TTFB doet
- Goede structureele code hanteert
Hoe snappier een pagina is, hoe fijner. Bandbreedte neemt verder wel toe, maar latency neemt niet heel veel harder af.

100ms of 200ms wachten is een behoorlijk verschil, ookal lijkt het niets.
Precies, als je normale afbeeldingen wil en geen 256 kleuren dan wordt het wat groter. Daarnaast worden er meer afbeeldingen gebruikt dan vroeger.

En dat Doom een 3d render engine gebruikt voegt niks toe, 3d modellen zijn een paar kilobytes groot, het zijn de textures die significante bestandsgrootte toevoegen al zou dat bij Doom wel meevallen want die gebruikt misschien 32x32 pixels per object?
Per bezoeker is dit niets natuurlijk. Maar wat als een website meer dan een miljoen pageviews per maand heeft? Dan kan server-side elke byte verschil maken.
Meneer vergeet even dat we nu content bekijken op schermen met resoluties oplopend tot boven de 3840x2160 pixels. Dat is wel even andere koek dan wat Doom op het scherm toverde. Alles moet haarscherp zijn, dus foto's worden meteen een stuk groter. Dan zijn er nog de databases die alsmaar groter worden, meer code om te zorgen dat het allemaal lekker werkt op enorm veel browsers, op diverse schermformaten, etc.
Databases zijn server-side. Code om het op verschillende browsers goed te laten werken kan je selectief sturen vanuit de server-side gebaseerd op hoe de browser zich identificeert. Voor schermformaten is er wel een punt, omdat er clients zijn waarbij de schermgrootte en -verhouding dynamisch aangepast kan worden zonder de pagina opnieuw te bezoeken. Denk bijvoorbeeld aan smartphones (portret/landschap).
En daarbij: wat is 2MB voor een pagina nou? Mobiele bundels worden steeds groter en de internetsnelheid is al lang geen beperkende factor meer.
Wat de reden is waarom vandaag de dag alles net zo stroperig aanvoelt als tien jaar geleden. Computerkracht is erop vooruit gegaan, maar we gaan er gewoon te lui mee om.

Volgens mijn eigen statistieken is tenminste 15% van websites zaken als advertenties en analytics. Dat is waarschijnlijk meer, omdat er alleen rekening gehouden wordt met wat er direct geblokkeerd wordt. De third-party content die door third-party content wordt opgehaald wordt daarbij niet meegerekend. Zelfs 15% van het aantal geblokkeerde bestanden is een significant deel, zeker als we aannemen dat de meeste advertenties bestaan uit grote afbeeldingen en animaties.

[edit]
De reacties op Kapitein Edward bevestigen mijn vermoeden. Advertenties vergroten de hoeveelheid data om T.net te laden met een factor 3.

[Reactie gewijzigd door The Zep Man op 22 april 2016 11:42]

Ik weet niet of ze met dit onderzoek ook rekening gehouden hebben met de grote van plaatjes / foto's. Zoals je zegt ben je dan namelijk nogal snel klaar. :)
Maar voor layout en design kunnen tegenwoordig een hoop plaatjes vervangen worden voor CSS opmaak of vectoren wat een hoop ruimte kan besparen.

Hoewel 2MB niet zo veel lijkt, is dat best fors. Als iedere pagina 2MB zou zijn, dan brand je snel door je bundel heen. :)

Maar opzich is het een mooi streven: Maak pagina's kleiner, zodat er minder data getransporteerd hoeft te worden, wat een lager energieverbruik met zich meebrengt. Dus goed voor het milieu!
Er kan m.i. een hoop beter, ondanks de hogere eisen aan bijv vormgeving.
Het probleem is vooral dat men "lui" wordt omdat de bandbreedte geen factor meer is dus is het niet meer zo aantrekkelijk om tijd de steken in optimalisatie.
Als je je layout netjes met CSS en HTML maakt renderd de browser alles waardoor je pagina in principe gewoon licht is.
Voor grafische elementen heb je uiteraard gelijk maar de gemiddelde website zou niet over moeten lopen van de statische plaatjes.
Plaatjes verwerken in je layout is toch al enige tijd een beetje not done als je het mij vraagt, buiten een e.v.t. header of logo.

Hier in NL waar iedereen die met een kabelaansluiting gewoon mega snel internet kan krijgen is het niet zo'n issue maar als je ergens in ťťn of ander ver oord een brakke verbinding te verdelen hebt is websiteoptimalisatie erg prettig.

[Reactie gewijzigd door Alpha Bootis op 22 april 2016 13:10]

Klopt allemaal, alleen is er daardoor ook totaal geen noodzaak meer om efficiŽnt te programmeren. Ik heb altijd enorm veel bewondering gehad voor programmeurs in de tijd van de C64, die hadden maar 64kb tot hun beschikking en als je ziet wat ze daar in de nadagen van de C64 mee konden, is ongelofelijk.
Daarom vind ik het zo raar dat Chrome op OSX 120 a 250mb per tab RAM gebruikt.
dit vind ik wel raar, je hebt het over mobiele databundels die steeds groter worden, maar in werkelijkheid, had je een paar jaar geleden nog onbeperkt 3g voor bedragen van 35 tot 45 euro

nu krijg je voor dat soort bedragen hooguit een gb of 2, kortom hooguit 50 pageloads per dag, en uiteraard veel minder als je (zoals op bijv facebook) ook nog video's automatisch binnenhaalt...
Ik heb momenteel 6GB en vrijwel overal waar ik dagelijks kom is wifi. Mobiel internet gebruik ik eigenlijk alleen onderweg en tijdens het rijden kun je moeilijk internetten.
Leuk vanuit jouw eigen perspectief, maar niet iedereen op deze planeet heeft een 10Mbit + verbinding tot zijn beschikken.
Beter nog de meerderheid heeft dit NIET.

Je geeft heel mooi aan hoe kortzichtig de westerse wereld is naar de rest van de planeet.

No offense trouwens, snap het heel goed maar als je zoals ik dagelijks met krappe satelliet verbindingen van 1Mbit of krapper moet werken waar meer dan 200 man achter zit ergens op zee of Afrika dan heb je een hoop meer begrip dat 2 MB voor een webpagina gewoon achterlijk is.
Helemaal terecht, er zit nu eenmaal op dit moment veel meer in een webpagina. 2 MB is het zelfde als een halve ouderwetse MP3, zo kan je ook zeggen; en iets meer dan wat er op een 1,44 Mb floppy past. Tegelijk in 8-bits karakters evenveel als een aardige paperback.

Maar uhm, DOOM kwam 23 jaar geleden uit. Dus als je deze versie ooit hebt gespeeld ga je al richting de middelbare leeftijd. Je kent de afmeting van een 3,5" floppy nog, hebt ergens in huis nog een paar 5,25" floppy's van 360 Kb slingeren en USB is een nieuwigheidje.

1993: het laatste jaar dat je de Volvo 240 nog kon kopen, Boris Yeltsin is president van Rusland, de eerste P5 Pentium chip op 60 MHz komt op de markt als opvolger van de 80486 processor (met een kleine fout in de floating-point unit). Rusland trekt haar troepen terug uit Polen en Litouwen. Windows for Workgroups 3.11 komt op de markt (Wikipedia). O ja en in 1993 begon XS4ALL als allereerste met openbare internettoegang (via modem uiteraard).

Inmiddels weten kinderen niet meer wat een floppy is, is de DVD dood want veel te klein en download mijn telefoon over the air zo'n 7 DOOM-images per seconde en per maand kan ik gratis 500.000 DOOM images aan data downloaden voordat ik een paar euro extra moet doneren aan de telco...
Buiten dat ik het een grappige constatering vind.. vind ik het ook een beetje vergezocht om gelijk te melden dat webpagina's te groot worden. Het is 2016, floppy's zijn geen 720kb meer of 1,44mb.. Je intern geheugen is vast hoger dan 640kb, je modem gaat sneller dan 2400 baud.. Webpagina's nemen wat meer ruimte in beslag.. Ik kan er niet wakker van liggen.
Als er echt sprake is van enorm inefficient gebruik van ruimte dan kan ik het nog begrijpen.. Nu vind ik het een beetje klinken als gezeur.
Je moet rekening houden met mobiele hardware en de bijbehorende databundels. Daarbij is het internet wereldwijd en heeft lang niet iedereen de beschikking over een fatsoenlijke (mobiele) internetverbinding.
Nou weet je... je gaat naar een webpagina waarvoor je in 99,9% van de gevallen niet betaald, ja je genereert wat inkomsten omdat ze een advertentie aan je mogen laten zien. En vervolgens ga je eisen stellen aan de grootte van zo'n website omdat jij anders snel door je databundel raast?

Misschien zou er een oplossing moeten zijn dat je van te voren ziet dat een webpagina ophalen je 3megabyte kost, en als je dat accepteert dat je dan pas doorgaat naar de pagina, dan kun je je eigen verbruik budgeteren.
Misschien dat die advertenties geoptimaliseerd kunnen worden ? Om bij iedere website 3MB af te tikken vanwege reclame (waar ik toch niet op klik - laat staan dat ik dat product koop) vind ik wel wat ver gaan. Mijn databundel kost al geld genoeg.
Zelfs op een snelle verbinding voelt een compacte webpagina beter. Dus je kunt er maar beter zoveel mogelijk aan doen als ontwikkelaar. Ook vanwege andere argumenten die al genoemd zijn zoals het besparen op kosten voor bandbreedte.
hij heeft anders wel gelijk. Hetzelfde gaat in mijn ogen op voor programmeurs. Geheugen is goedkoop, we moeten er niet op letten. Bandbreedte is beschikbaar, we moeten er niet op letten. En je merkt, dat als de ontwikkelaar er wel op let, in het geval van webpagina's, het wel een pak sneller werkt. Om over mobiel nog maar te zwijgen. Dat is geen gezeur, dat is een feitelijke vaststelling.
Dat ligt anders niet aan de programmeurs hoor! Ik heb met lede ogen aangezien hoe de markt zich ontwikkelde. Natuurlijk kost geheugen, processorkracht, opslag en bandbreedte niets meer in vergelijking met een aantal jaren geleden, maar... de inefficiŽntie is het gevolg van snel willen/moeten ontwikkelen en vooral besparen op personeelskosten. Vandaar dat met inefficiŽnte middelen applicaties in elkaar worden geflanst met de daarbij behorende gigantische overhead. En natuurlijk helpt het niet wanneer optimalisatie achterwege wordt gelaten op sites... door bijvoorbeeld foto's in de hoogste kwaliteit met een gigantische hoeveelheid pixels op te nemen...
Hoe zit dat bij de tweakers.net frontpage eigenlijk :?
77 requests, 647 KB transferred :)
En met adblocker uitgeschakeld: 218 requests, 1.5 MB transferred. :X
Ik gebruik geen adblocker, maar het zou kunnen zijn dat het netwerk hier het een en ander tegenhoudt.
Ik krijg sowieso bij Tweakers niet op elk request advertenties geserveerd, adblocker staat hier altijd uit maar is misschien 10% van de requests dat ik ook daadwerkelijk een advertentie zie.

87 requests en 733kb hier voor de homepage, met caching (in de browser) ingeschakeld kom ik uit op nog geen 100kb.
En met de blocker ingeschakeld ?
176 request 1.1 MB transferred. Heb jij adblocker of stond een deel in de cache?
Ik gebruik geen adblocker, maar het zou kunnen zijn dat het netwerk hier het een en ander tegenhoudt :)
Is dat met of zonder Adblock ? Ben ik wel eens benieuwd naar.
Ik gebruik geen adblocker, maar het zou kunnen zijn dat het netwerk hier het een en ander tegenhoudt.
Veelal worden er libraries geinclude waar misschien 1 of 2 functies van gebruikt worden. Die libraries zijn al snel een paar honder kb.
Ja maar die libraries worden toch gecashed door je browser?
Jup, files die meerdere keren worden aangeroepen staan in je browser cache, dus dat scheelt weer.
Maar zullen wel mee tellen gok ik.
Maar bij een nieuwe pagina opvragen hoeft het niet zo te zijn dat deze uit de cache gehaald wordt.
Zeker als de server verkeerd/niet ingesteld staat en bij een HEAD request of Not-modified ook de volledige inhoud meestuurt. Volledig nutteloos dat die data alsnog over de lijn gaat.
Precies. Ik vraag me hoeveel mensen daadwerkelijk de compile functie gebruiken van bv jQuery of Bootstrap.
JQ is maar 95kb... dat verklaart de huidige gemiddelde paginagrootte toch niet?
Maar het telt wel mee, vaak zit er nog modernizr, bootstrap js, bootstrap css bij. Toch al bijna een halve mb aan enkel wat scriptjes als ze niet zijn geminified.

Kijk voor de gein eens naar de hoeveelheid js files in een gem. wordpress pagina.
Inderdaad, ik merk dat ik zelf ook doe, je wilt gebruik maken van wat handige functies en laad meteen alles in omdat het vaak een totaal pakket is.

Daarnaast gebruiken we steeds meer foto's en video's in de pagina waardoor de bandbreedte nog sneller oploopt.

Als je jquery en bootstrap niet zo includen bespaar je 150kb, maar een paar foto's op je website zit je al snel aan 1-2mb zelfs als je ze al ver compressed neemt het toch nog aardig wat ruimte in.

Als we de websites zouden maken met de graphics van doom en we hoeven daarbij dan ook niet rekening te houden met verschillende scherm verhoudingen dan lukt het wel om een website van een paar kb te maken :)
Het probleem zit em vooral in de Wordpress 'huismoeders'. Die bouwen websites die vol zitten met allemaal plugins, Bootstrap meerdere malen in verschillende versies aanspreken, en rechstreeks van de camera uploaden zonder enige vorm van compressie en optimalisatie.
Ik snap wat je bedoelt, maar Wordpress en Drupal zijn beter geoptimaliseerd dan je in eerste instantie zou denken.
Van drupal weet ik dat de plaatjes die neergezet worden altijd op maat gemaakt worden, de kwaliteit word wat terug gebracht. CSS en JS worden alleen van de active modules ingeladen en veel modules kunnen er voor zorgen dat die alleen geladen worden wanneer het ook echt nodig is.

Voor Wordpress geloof ik dat het ongeveer het zelfde verhaal is(hoewel ik Wordpress niet vaak gebruik heb...)

De grondlegger van PHP gaf wel ooit aan en dat is iets waar je helemaal gelijk in hebt dat system als Wordpress, Drupal, Zend Framework, Laravel, etc etc Onnodig veel data inladen die ook al hebben we het niet nodig.

Dit patroon zie je nu ook steeds meer ontstaan bij Javascript(Angular, jQuery) en CSS(bootstrap) en alle tools die daar tussen inzitten als de Ckeditors enzo.
Het beginnen allemaal grote logge systemen te worden omdat ze steeds meer functionaliteit gaan aanbieden. (ik weet dat ze proberen te verbeteren en dat backwards compatibility een oorzaak is van dit probleem).
Angular heeft dan weer het SPA voordeel. Oftewel, je laad een grote berg data, en daarna alles in kleine stukjes (JSON)
De vergelijking is oneerlijk.
Een game is in Assembly en eventueel compressed.
Als wij HTML, CSS en JavaScript ook precompiled in Assembly kunnen aanleveren, tja dan....
Tja, het feit dat nu vrijwel iedereen een website kan bijhouden zorgt voor een flinke boost van dit gemiddelde. Enkele hostingklanten bij ons zetten rustig foto's van 8mb per stuk op een pagina van een sfeerimpressie van een restaurant. Je kunt ze 20x uitleggen dat ze ze beter kunnen verkleinen en toch vind ik ze elke keer weer terug.
"Maar ik heb ze verkleind!"

width = "200px"
Als het CMS juist ingesteld is, herschaal je die 8MB foto's toch gewoon netjes?
Hangt niet af van het CMS, maar van het theme. Hobbyisten hebben daar vaak geen idee van.

Wordpress 4.4 heeft hier wel iets voor ingebouwd. Ben me daar toevallig net in aan het verdiepen.
was doom echt maar 2,2MB? Ik heb Doom1 laatst geinstalleerd en hoewel de engine ongeveer 1,5 MB is, zijn de levels 11MB hier...
Eenmaal geÔnstalleerd en uitgepakt is het spel groter, maar de image size zou zo'n 2,3MB zijn. Ik vind wel diverse websites waar je Doom kan downloaden in een zip met ongeveer die grootte. Wie heeft de diskettes nog liggen om het te checken? :P
Maar dan zou je voor de eerlijkheid ook de gecomprimeerde grootte van webpagina's moeten nemen. Die worden immers ook meestal met gzip verkleind. Het is uit het artikel niet duidelijk of dat ook is gedaan.
Volgens mij kijken ze gewoon naar wat er over de lijn gaat, en als een pagina minify gedaan heeft, scheelt dat ook behoorlijk. Echter, als eindgebruiker heb je daar 0 invloed op, en gaat gewoon de totale data-hoeveelheid van je bundel af.
Betreft het installatiebestand, niet de complete geinstalleerde game.
Sterker nog, volgens mij hebben ze het hier over de shareware-versie, die was inderdaad verkrijgbaar op iets van twee of drie diskettes, dus dan kan die 2,2 MB wel kloppen. De volledige versie was, eenmaal geÔnstalleerd, iets van 14 MB (een hele bult data in die tijd).

Ik heb 'm (Ultimate, met vierde episode) nog op CD liggen, kan wel eens kijken hoeveel dat was.
Ik zat op dialup in die tijd en werd per tijdseenheden afgerekend (weet niet meer precies hoe), als ik tijd overhad downloadde ik wel eens extra levels voor DooM en die waren zelf al 2-3MB per stuk wat met 28k8 nog wel spannend was :)
Ik denk dat 90% van de web pagina's zo'n 50% code* heeft die overbodig is. *(inclusief css en javascript)
Wat bedoel je hiermee en heb je een voorbeeld?

In de zin van: de website werkt ook zonder css en javascript, maar is minder 'fancy'. Of eerder dubbele, of onnodig ingewikkelde code?
Als je Bootstrap of jQuery met je website meelevert dan is het vaak zo dat je niet alles daarvan gebruikt. Het kan zijn dat je alleen alle AJAX methodes gebruikt in jQuery maar de animatie effecten zitten nog steeds embedded in de library.

Dit maakt alle libraries onnodig groot. Echter kan je vaak ook een op maat gemaakte versie van een library krijgen waar alle "onnodige" functies zijn verwijderd.
makes sense, bedankt :)
CSS en Javascripts voor functies die er niet zijn op de desbetreffende pagina. Of CSS laten staan op iets wat overal uit de website gehaald is.

En er wordt ook veel met javascript of html gedaan, wat je gewoon achter de schermen met php opgelost kan worden. Bijvoorbeeld <!--[if lt IE 9]>
Wat heb je liever: eenmalig een iets groter CSS en/of Javascript bestand binnenhalen, wat geminified is en voor alle pagina's hetzelfde is?

Of voor elke pagina alleen de gebruikte delen ophalen, waardoor je voor elke pagina een andere combinatie hebt en dus ook weer apart gegevens moet opvragen.

In de meeste gevallen pak ik liever die 20-30kb extra voor optie 1. Of je moet echt een site hebben die uit compleet gescheiden onderdelen (en dus code) bestaat.
een CSS en javascript voor dingen die je op elke pagina nodig hebt. En voor dingen als een fotoboek, contact formulier, of wat voor interactieve funkties dan ook. Apart laden op die pagina.

Een huist heeft ook niet in elke kamer een gas en water en afvoer aansluiting. Maar wel gewoon in elke kamer stroom.
Het zal natuurlijk per site verschillen. Maar mijn ervaring is dat dit om minimale scripts gaat. Libraries zoals jQuery en Bootstrap zijn meestal de bulk van de data. En die heb je toch al nodig. Je kunt dan inderdaad die kleine 5kb scriptjes voor plugins gaan lostrekken. Maar dat scheelt je ook weer minimaal 2 requests (CSS en JS), er vanuit gaande dat je alle custom code per pagina geminified hebt.

In veel gevallen is het zinvoller om jQUery van een CDN te laten komen. Dan heb je nog een beetje kans dat het al in de cache zit.
Echter is een PHP user agent check niet 100% betrouwbaar, en levert het een aantal milliseconden op in parsetijd. Wat hij aanhaalt met <!-- [if IE9]> werkt Šltijd in IE, maakt niet uit hoe de sysadmin de UA string vern**kt heeft..
exact die foto's zijn geen issue, het probleem is de crappy third party content die tegenwoordig geladen wordt van een paar honderd andere servers.
Doom is tot in de treuren geoptimaliseerd om het zo klein mogelijk te houden. De meeste websites doen daar niet aan. "De website moet een stukje content onzichtbaar maken aan de hand van een id attribuut? Oh wacht even, ik pak wel jQuery erbij". Foto's worden ook steeds groter aangezien de computerschermen ook steeds hogere resoluties hebben. En dan heb je nog ontwikkelaars die denken dat ze alleen voor de pc (=geen data limiet) ontwikkelen...
Bij spelconsoles wordt er er ook gauw gekeken of het spel nog verder kan worden geoptimaliseerd.

Bij de iPhone waar de hardware een gegeven is, zie je dat ook. De apps worden ontwikkeld waarbij zoveel mogelijk gebruik wordt gemaakt van de hardware.

Bij Android zie je helaas een tegengestelde beweging zoals bij de PC. Steeds snellere soc's en meer geheugen,
maar de apps vragen vervolgens ook steeds meer omdat slecht programmeerwerk minder snel opvalt.
En wat is een 'webpagina' nu precies? Als ik bijvoorbeeld Facebook open, kan ik oneindig naar beneden blijven scrollen. Is dat allemaal 1 pagina?
Facebook lost het wel slim op, in eerste instantie wordt de hoeveelheid posts die geladen wordt beperkt. Als je naar beneden scrollt dan wordt dmv ajax-calls de pagina steeds uitgebreid. Zo voorkom je dat mensen lang moeten wachten op het laden van posts die ze waarschijnlijk toch niet gaan lezen.
Maar dan ben ik wel benieuwd wat de onderzoeker als 'webpagina' ziet. Waarschijnlijk dan alleen het deel wat de eerste keer geladen wordt, niet de rest die bij scrollen nog geladen wordt.
Dat is inderdaad 1 pagina :) De data wordt vervolgens dmv een Ajax Call opgehaald wanneer je het einde van de pagina gebruikt. Een efficiŽnte effectieve methode dus.

Op dit item kan niet meer gereageerd worden.



Nintendo Switch Google Pixel Sony PlayStation VR Samsung Galaxy S8 Apple iPhone 7 Dishonored 2 Google Android 7.x Watch_Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True