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 , , 105 reacties

Google stelt dat het zijn Web Light-functionaliteit met succes heeft getest, waardoor meer landen er ondersteuning voor krijgen. Met de feature kunnen websites veel sneller geladen worden doordat een 'gestripte' versie ervan wordt vertoond.

Enige tijd geleden begon Google met een field test voor Web Light in Indonesië. Volgens de internetgigant was het experiment succesvol en krijgen nu ook Android-gebruikers in India en Brazilië ondersteuning voor het sneller laden van webpagina's door een gestripte versie te tonen. De snellere versie wordt getoond als wordt opgemerkt dat de internetverbinding traag is; wat Google precies verstaat onder traag is niet bekend. Dat westerse landen nog geen toegang hebben gekregen tot de feature heeft waarschijnlijk te maken met het feit dat de internetverbindingen daar sneller zijn. Het is echter aannemelijk dat de ondersteuning later nog verder wordt uitgebreid.

Google begon aanvankelijk met het tonen van een lichtere versie van zijn eigen websites in het geval er een langzame verbinding werd gedetecteerd, maar doet dit dus nu ook met websites van derden. Het werkt overigens alleen als de webpagina wordt ingeladen vanuit een Google Search-resultaat. Ook werkt het vooralsnog alleen op Android-smartphones waarop gebruikt wordt gemaakt van Chrome.

Volgens Android Police is het mogelijk om een gestripte webpagina te bekijken door deze te benaderen via een speciale url. Dat kan door de webpagina achter http://googleweblight.com/?lite_url= te plakken. Niet alle websites, waaronder Tweakers, lijken goed te werken. Volgens Google gebruikt Web Light 80 procent minder data en kunnen webpagina's dus vier keer sneller worden ingeladen. Webmasters kunnen er overigens voor kiezen om het tonen van een gestripte versie te blokkeren.

Google Web Light

Moderatie-faq Wijzig weergave

Reacties (105)

Dat dit nodig is spreekt boekdelen over de huidige status van web-development. Wat is een website nu eigenlijk, een document met informatie, wat voornamelijk uit tekst bestaat. Ja het web beweegt en updates moeten direct binnenstromen om altijd up to date te zijn. Dit vergt javascript en complexe systemen maar veelal is overbodig gemakzucht. Afbeeldingen optimaliseren, nee joh, doe niet zo raar. JavaScript en css samenvoegen tot 1 bestand, oké, maar alleen als het automatisch gaat. Functionaliteit nodig? Hier jQuery met 17 plug-ins die allemaal een overhead van heb je mij daar creëren. Een goede dom-structuur ontwerpen, dus niet oeverloos div na div na div in elkaar nesten? Hier een container voor je container zodat je container in een container zit terwijl de container er om heen zit.

Als je een website inspecteert kom je tekstbestanden (html, js en css) tegen van honderden(!) kilobytes. Dat is absurd, een hoeveelheid karakters waarmee je heel Tolkiens oeuvre mee kan vullen, and then some. Wanneer je op http://www.webperformancetoday.com kijkt zie je statistieken, hoe een website tegenwoordig makkelijk 2MB aan data verstuurt. Dit artikel laat zien dat een mobiele website gemiddeld 1MB bedraagt, daarvan is 64% afbeeldingen* waarmee je kan concluderen dat een gemiddelde pagina 360KB aan tekstuele dat bedraagt, dat is buitensporig absurd.

Heb een keer bij wijze van experiment een Google resultatenpagina nagemaakt, 1 op 1, pixel-perfect. 12KB, zonder gzip. Een pagina van Google zelf (gezocht op 'test'): 1011.6KB. Waar halen ze het vandaan?

* Waar ongetwijfeld nog een berg vanaf kan met optimalisatie, tools als svgo/OptiPNG trekken makkelijk 20–40% van de bestandsgrootte per afbeelding.

[Reactie gewijzigd door n8n op 13 juni 2015 16:15]

Vind het leuk dat je dit schrijft. Heb ook bij een bureau gewerkt dat heel raar keek naar de dingen die ik deed op de website zo optimaal mogelijk te laten functioneren. Dat is vooral te merken op een handheld. Ze snapte er geen reet van wat ik deed. Ik kwam ook met een website dat tinypng.com heet, ze wisten niet eens dat een png 256 kleuren met alpha transparantie kan bevatten. Meestal zijn nu de afbeeldingen/sprites heel eenvoudig dus dan kun 16 kleuren gebruiken, vaak nog kleiner dan een jpeg. Echt heel leuk om daarmee te experimenteren. Gebruik ook de Google speedtest om de optimaliseren maar vaak heb ik dat al in de code ingebouwd dus gaat dat automatisch en.... dat scheelt!

Maar dat is het niet alleen natuurlijk, het is ook cache header die vaak er niet is of niet correct is. Dus wordt bij elke request dat plaatje of javascript bestand opgehaald. Of er wordt een versie queryparameter gebruikt waardoor de url niet wordt gecached (je kunt dit ook anders oplossen door een rewrite en het versienummer in het pad op te nemen).

Als alles geoptimaliseerd is zul je jezelf verbazen hoe klein het kan zijn en hoe snel het kan laden en daarnaast ook goed voor de ranking. Maar overtuig je baas maar eens, daar zit um de kneep. Wat ik dus net vertelde dat ze totaal niet begrijpen wat ik aan het doen was en ze achten het niet nodig. "Als het maar werkt" is het vaak, de korte termijnvisie, als je over visie mag spreken. Net zoiets als zorgen dat de code foutloos werkt en voldoet aan de W3C standaarden. Je hebt er ontwikkelaars bij die hier totaal niet mee bezig houden. Dat zijn ook de ontwikkelaars die totaal niet weten wat er allemaal gebeurd in die browser. Dat zijn vaak ook de ontwikkelaars/designers die moeite hebben met (plain) javascript. Die kunnen alleen maar het framework toepassen en that's it. Waarschijnlijk komt het dat ik een hele andere achtergrond heb dan de meeste webontwikkelaars, vroeger heb ik maatwerk software voor de PC geschreven, ook op hardware niveau, dus dan denk je anders.

Heb vorige keer nog een site van iemand anders geoptimaliseerd, het is duidelijk merkbaar. Hoe minder de server hoeft te doen per request, des te beter het is. De site is bijvoorbeeld van totale grote 55mb naar 30mb gegaan. Nu denk je dat is niet zoveel maar doe het verschil * 100.000 bezoekers. Dan is het verschil ineens wel veel. Dat kan er zomaar toe leiden dat je een andere abbo kan nemen.

Vind het jammer dat binnen bedrijven hier zo weinig aandacht voor is. Zou best ergens willen werken waar dat prioriteit nummer 1 is. Dus als je nog een bedrijf weet, let me know.

[Reactie gewijzigd door Erwines op 14 juni 2015 11:16]

Bij de meeste websites is de bandbreedte goedkoper dan de arbeid die nodig is om de bandbreedte te sparen.
Zoals uit jou reactie blijkt is dat weer typisch een korte termijn gedachte. Er zijn toch ook nog meer voordelen, niet alleen bandbreedte, staat er toch (kijk anders bij mijn andere bericht hieronder). Trouwens een hoop is te automatiseren als je een beetje slim bent. Het lijkt wel of we tegenwoordig alleen maar automatiseren wat op dat moment nodig is, vanwege het prijskaartje. Ik kan je vertellen, dat is echt duurder op langer termijn. Slordigheid en/of weglaten heeft zijn prijs.

[Reactie gewijzigd door Erwines op 15 juni 2015 19:16]

Herkenbaar verhaal. Aan optimalisatie op verschillende vlakken wordt vrij weinig rekening gehouden en vaak niet begrepen.

Het verschil tussen een JPEG en PNG, 32- vs 8-bit PNG, JPEGs optimaliseren, correcte database-indices, JavaScript optimalisatie, webserveroptimalisatie, niet voor alles jQuery gebruiken of überhaupt jQuery gebruiken, lazy loading van afbeeldingen (bijvoorbeeld op 3G-verbindingen) etc.

Het effect van veel optimalisaties zie je niet direct terug maar pas later als er veel gebruikers tegelijkertijd een website benaderen.

[Reactie gewijzigd door Icelus op 16 juni 2015 10:32]

Ik kan je redenering volledig begrijpen. Maar is het voor webdevelopers niet wat overkill om elk framework (JQuery, AngularJS,...) en elke plugin te strippen van hun ongebruikte functies om zo ruimte te besparen? Dan moet je alles een voor een afgaan en achteraf wil je misschien iets gebruiken wat je hebt gestript. En bij elke update moet je het opnieuw doen.
Dat is het leuke aan die frameworks/plugins: je knalt het erin, je voegt wat code toe en je hebt direct veel resultaat voor weinig moeite.

Ja het komt erop neer dat ik mijn luiheid aan het verdedigen ben (ik doe het als hobby, niet als beroep). Maar waarom meer tijd in steken als je site snel (genoeg) laad op de meeste devices? (ik heb het hier over kleine websites, niet over google webpagina's)

Over de afbeelding-optimalisatie ben ik volledig akkoord: daar spaar je veel mee uit.

[Reactie gewijzigd door lampstoelkast op 13 juni 2015 19:27]

@lampstoelkast : Je moet zeker niet de functies eruit 'compileren' bijvoorbeeld met de Google Enclosure Compiler, dat gaat heel vaak fout. Maar gebruik wel de minified version ipv de dev version. Combineer zoveel mogelijk scripts om het aantal serverconnecties/lookups per pagina te beperken. Standaard heeft een browser maar 4 connecties dus hoe meer bestanden er zijn hoe langere wachtrij. Doe dit ook met CSS, voorkom @import bijvoorbeeld, laad dingen die je later kunt laden later. Zoals social 'shit' bijvoorbeeld, alleen wanneer iemand er op klikt . Zet scripts onderaan net de boven </body> tag zonder eerst alle content wordt gerendert en de gebruiker dus iets ziet.

Het kan natuurlijk zo zijn dat de site snel laad maar vergeet niet dat als je aan het ontwikkelen bent je vaak de enige bent die op de site zit. Daarnaast kun je onmogelijk op elk apparaat testen. Jouw ontwikkelmachine is natuurlijk niet het gemiddelde middelmatige systeem, daar moet je ook rekening mee houden. Als het sneller kan moet je het sneller maken, dan kan het daar in iedere geval niet aan liggen ;) Want soms kan het betekenen dat wanneer je het zo klein mogelijk maakt je gewoon een ander goedkoper abbo kan nemen omdat je minder data verstookt. Dat is interessant natuurlijk. Daarnaast wordt de server minder belast wat ook weer beter is wanneer er meer bezoekers op je site komen. Als de server al maximaal moest presteren dan krijgt de server het extra moeilijk bij extra bezoekers. Je kunt het vergelijken met een trechter, heel veel data door een klein gaatje. Een piek moet de server met gemak aankunnen en daarmee kan jij helpen door alles kleiner te maken en te zorgen dat de cache headers van de bestanden in orde zijn zodat de connectie minder lang duurt en alleen wanneer nieuw of een update vereist is. Dan kun je dus met minder meer doen. Het eheeft een dubbelzijdige werking, voor 'jou' minder dataverkeer en voor de bezoeker een snellere laadtijd. Daarnaast heeft het nog een ander positief effect en dat Google ranking, Google zal je belonen voor je inzet.

Wat jQuery en Zepto betreft, Zepto is niet hetzelfde. Wat snelheid betreft, ligt ook een beetje aan jezelf. Ik heb wel scriptjes gezien waarbij bij het opstarten van de pagina wel 20 keer of meer keer in de DOM wordt gezocht naar element(-en) waaraan een event moet worden gekoppeld. Gaat vaak door de tijd heen, het is altijd klein begonnen, weer even dit erbij en weer even dat erbij en voor je het weet heb je een hele lijst aan elementen dat je zoekt én doet voor elke pagina ook waarin sommige elementen helemaal niet voorkomen.

Ik heb bijvoorbeeld een systeem bedacht wat slecht éénmaal de DOM afloopt en fired events af van dingen die er zijn en daar kun je op reageren. Precies andersom en daardoor wordt er nooit code uitgevoerd wat niet hoeft worden uitgevoerd. Bijvoorbeeld alleen elementen met een data attribute waarbij de data attribute aangeeft waar de 'verbinding' over gaat.. Gangbaar is dus dat de javascript sturend is (de code) maar bij mij is dat juist de template, dat is voor de browser veel relaxter, dat merk je ook qua laadtijd. Dus ook als er iets via ajax wordt geladen gaat alles vanzelf.

Zo Dus :) Dat is wel een volledig antwoord he? :9

[Reactie gewijzigd door Erwines op 15 juni 2015 13:19]

Een paar maanden geleden las ik een interessante blogpost over het gebruik van frameworks (http://love2dev.com/#!art...ike-Fast-Food-Restaurants). De strekking was dat frameworks te groot en log zijn, terwijl ze dankzij verbeteringen in JavaScript / ECMAScript minder waardevol worden. In principe zou je voor de meeste websites moderne JavaScript / ECMAScript kunnen gebruiken in combinatie met polyfills (die vullen de gaten in ondersteuning op waar nodig).

Meer gebruik van in de browser ingebakken functionaliteit (een nieuwe functie die mij erg aanspreekt is object.observe) plus in plaats van grote, logge applicaties het gebruik van modules (met een library zoals require.js) is mijn visie op een sneller web. Dit is echter geen populaire opinie. Mensen investeren veel tijd in het leren van frameworks in de hoop dat dit in de toekomst tijd bespaard. Het is echter de vraag of ze de opgedane kennis vaak genoeg zullen toepassen om de tijdsinvestering terug te winnen, aangezien er dagelijks nieuwe frameworks uitkomen, en er dus altijd wel iets nieuws te leren valt.

[Reactie gewijzigd door Florisjuh op 14 juni 2015 01:34]

Veel mensen hebben ook geen JavaScript geleerd maar jQuery wat door de fluent interface meer weg heeft van css - op zich een hele prestatie. Wanneer er dan een afbeeldigsgallerij nodig is wordt er een plug-in gepakt met 1000 functies (je moet immers elk denkbare variant kunnen maken) terwijl het niet veel meer hoeft de doen dan door een array elementen met wat clicckevents een classname aan te passen.
Als de lib maar van een consequente source wordt geladen is dat toch niet erg. Je moet ook niet het wiel opnieuw gaan uitvinden. Daarnaast is het zo dat vele projecten ook weer groter worden dus kun je het wel minimaal houden maar dan snij je daarna weer in de vingers want heb je extra code gemaakt en er is geen tijd om het aan te passen. En wat heb je dan, bloat. Zo gaat dat, zo ontstaat, zo vaak gezien.
Voor gebruikers van je website maakt het sowieso veel uit.

Afgelopen week ben ik begonnen met het optimaliseren van mijn website https://SuperRepo.org. Elke page view kostte rond de 2 seconden om te tonen en nog 7 om alles te laden (Disqus is drama). Het strippen van veel ongebruikte code, flinke caching en resizen van plaatjes heeft dit teruggebracht tot een fractie daarvan. Nu laden de pagina's 'direct'.

Het gemiddelde aantal pagina's dat bezoekers nu bekijken ligt 3x zo hoog! Blijkbaar vonden ze het bewust of onbewust (kreeg nooit klachten) toch zwaar irritant.

Het kost flink veel werk maar het maakt dus wel degelijk een hoop uit.
Het begint natuurlijk bij de basis. Stel je maakt een website voor de bakker op de hoek. De eigenaar ken je goed en je hebt wel wat kennis van html, css en javascript.

Mooie afbeeldingen van versgebakken croissants, gave animaties met jQuery en Scrollmagic. De eens zo kleine webpagina weegt ineens ruim 2MB.

En stel nou dat als je als gebruiker even de openingstijden wilt opzoeken. Omdat je over je data limiet heen bent is je snelheid teruggeschroeft naar 50kB/s. De homepage van de bakker duurt nu 40 seconde om te laden. En dan moet je nog naar de openingstijden van de bakker.

Alternatieven zijn er natuurlijk ook. Voor jQuery kun je ook http://zeptojs.com/Zepto.js gebruiken. Dit scheelt al enorm. Hier is een interessant artikel over de optimalisatie van Smashingmagazine: http://www.smashingmagazi...e-performance-case-study/
Nog los van de tracking en advertentie rotzooi die het laden soms tergend langzaam maakt, vooral op mobiele apparaten via 3G/4G. En dan scripts die een pagina functioneel maken als die rommel pas ingeladen is.
Volledig mee eens. Te veel webdesigners / developers kiezen tegenwoordig voor form over function. Gigantische afbeeldingen, tig verschillende typefaces en allerhande libraries om onnodige animaties mee te faciliteren.

Persoonlijk denk ik dat heel veel van de design patterns die je tegenwoordig overal ziet niet ten goede komen van de user experience. Maar een "wow" effect nadat je 10 seconde hebt mogen wachten op het laden is natuurlijk veel belangrijker dan de content waarvoor je eigenlijk op de pagina kwam...
Je bent wel een beetje dramatisch. Je hebt 100kb en hebt 100kb. Als je gzip goed gebruikt dan kan je al veel optimaliseren. Conbineren is ook niet alles. Het heeft alles te maken met je update frequentie, naamgeving, tools, en ik kan nog wel ff doorgaan. Async is zeker niet de oplossing voor alles.

Pngs zijn duur. Maar er is meer dan alleen lite. Het is behoorlijk genuanceerd hoe er je kan gaan. Da's bij ins ook dagelijks werk: wat accepterr je wel en niet; hoeveel performance mag iets gaan kosten en in hoe verre wil je dataverbruik van je klanten gaan opofferen. Het komt dan ook regelmatig voor dat we geen zaken doen met bedrijven die niet mee kunnen in dat soort overwegingen.

Fonts zijn overigens ook erg groot.
Heb een keer bij wijze van experiment een Google resultatenpagina nagemaakt, 1 op 1, pixel-perfect. 12KB, zonder gzip. Een pagina van Google zelf (gezocht op 'test'): 1011.6KB. Waar halen ze het vandaan?
Ik ben het helemaal met je eens, maar behalve technische efficiëntie barsten moderne sites ook van de tierelantijntjes die imho amper toegevoegde waarde hebben.

https://www.netmeister.org/blog/the-art-of-plain-text.html maakt daar imho wel wat goede punten:
Plain text is portable, flexible, light-weight, and doesn't
require any special tools to generate; it looks the same on
different platforms, lends itself to trivial processing or
quoting, yet allows you to present even complex ideas in a
manner that lets users quickly and easily absorb them.

Plain text thankfully puts away with distractions, but being
able to create text documents that are easy to read is a
subtle skill, all too often lost on those who grew up with
HTML emails, online forums, and wiki pages.
Vergeet niet dat de meeste code die gedownload moet worden niet nodig is voor de functionaliteit van de website, maar wel nodig is om je te tracken.
Ik merk de laatste jaren dat het web een flink stuk trager is geworden - het is net of Flash weer terug is. Dit heeft niet zoveel met langzame computers of verbindingen te maken. Flink debet hieraan zijn alle reclames en designers die weer op een nieuwe resource-slurpende design hype-train springen. Gelukkig is er adblock.

[Reactie gewijzigd door drvinnie op 13 juni 2015 11:29]

Flink debet hieraan zijn alle reclames en designers die weer op een nieuwe resource-slurpende design hype-train springen.
Zaken als 'responsive design' vergroten ook de hoeveelheid handelingen die client-side verwerkt moet worden. Reclame en andere voor de gebruiker niet-functionele third-party crap helpen ook niet mee, maar het is niet alleen daaraan toe te wijten.

Ik merk dit nog het meest bij sites die over-tablet-vriendelijk zijn: alles op 1 zeer grote pagina, grote elementen, een lage informatiedichtheid en kilometerslange JavaScript code om alles aan elkaar te plakken.

Iets meer on-topic: volgens mij heeft Firefox sinds de laatste versie een ingebouwde functie om sites versimpelt te weergeven. Waarom zou je hiervoor Google gebruiken, anders dan om Google meer inzicht te geven in je surfgedrag?

[Reactie gewijzigd door The Zep Man op 13 juni 2015 11:45]

Ben ik bijna geheel met je eens. Responsive [i][hoeft/i] een site niet trager te maken. Het meeste kan je gewoon met media queries afvangen welke geen javascript nodig hebben. Het aan elkaar knopen van talloze libraries voor allerlei functies geven in mijn optiek de traagste sites. Plus het embedden van tig scripts buiten de site maakt een site ook niet sneller. Sommige website mogen wel op dieet.
"Responsive" zelf hoeft een site niet per se trager te maken nee. Maar wat je wel ziet is dat één website zowel de mobiele gebruiker als de desktop gebruiker met 27 inch scherm bedient. De gebruikte beelden zijn dan niet langer precies op maat (en met de breedte en hoogte in het stijlsheet gedefinieerd) maar worden in de browser geschaald. Omdat het beeld ook op de retina schermen er goed moet uitzien wordt soms ook nog de dubbele resolutie gebruikt. De gemiddelde website is hier de laatste jaren flink zwaarder van geworden. Ook veel gebruikte frameworks en gridsystemen geven een hoop overhead met stylesheets met vele duizenden regels en minimaal een handvol scripts.
media queries kosten niet zo veel, maar ze zijn nou ook niet echt gratis.

Oftewel ook met media-queries wordt je site trager.
Uh ja. Alles wat je aan je site toevoegt maakt hem trager.
Precies, ik zou persoonlijk wel eens willen weten wat voor impact complexe css selectors hebben. Ze moeten toch geresolved worden e.d. Maar ook wat voor performance impact float's en andere 'dynamische' positioneringen e.d. hebben. Niet om het niet meer te gebruiken, maar om er wel bewuster mee om te gaan. Zodat als je een keuze hebt dat je niet altijd perse de voor de 'ontwikkelaar' eenvoudigste variant gebruikt.
E zijn genoeg docs over. Ids zijn het snelste. Drop shadows en gradients vermijden, etc.

Javascript is erg snel. Wat duur is zijn dom veranderingen, selectie op data attributen en globale functies. Jquery is prima, alleen zou het een stuk sneller werken met een shadow dom-achtig iets zoals React. De Dom is de huidhe bottleneck. De vraag in alle gevallen is; wil men er tijd in steken om dit goed te doen
Als front ender kun je natuurlijk altijd ja roepen; maar iedereen weet dat goed responsive design met de juiste design beslissingen en juiste performance afwegingen een hoop tijd kosten.

Als je css wilt meten heb je in Chrome behoorlijk veel goede tools voor in de development tab. Zorg wel even voor een schone chrome zonder plugins geinstalleerd ;-)

Canary heeft altijd de interessantste tools vind ik.
Ik ben niet bekend met een dergelijke functie in Firefox, maar een client-side oplossing biedt niet dezelfde kansen voor optimalisatie. Een image transcoden heeft geen zin als je hem eerst moet downloaden over je trage verbinding.
Het gaat waarschijnlijk om deze functie: https://support.mozilla.o...acking-protection-firefox. Een anti-track optie die verder gaat dan de Do-Not-Track functie. Het lijkt op de Ghostery, Disconnect en uBlocks van deze wereld. Werkt heel aardig, en levert performance verbetering op omdat al die trackingscripts niet gedraaid hoeven te worden.
Opera heeft al een hele tijd iets wat lijkt op waar Google nu mee komt in Opera Mini (die nu blijkbaar is hernoemd naar Opera Turbo)
Dat hangt helemaal af van welke websites je bezoekt. Soms sta ik tegenwoordig versteld van de snelheid, vooral bij "grote" websites als Youtube (pagina laadt en video start meestal binnen een seconde) en bij bijvoorbeeld Tweakers die slim omgaat met caching en dergelijke.

En inderdaad, er zijn ook sites die nodeloos traag zijn. Hele grote afbeeldingen, o.a. voor retina-schermen, dragen hieraan bij, evenals reclames en uit de hand gelopen designs zoals je aangeeft.

Helaas wordt er tegenwoordig vaak te makkelijk gedacht over het bouwen van een website. Er is veel zelfbouw en er zijn veel amateur-ontwikkelaars en dan krijgt performance vaak niet de aandacht die het verdient. Ook grotere bureau's hebben performance soms nog niet hoog genoeg op de prioriteitenlijst staan, naar mijn mening.

Goede ontwikkelaars zijn echter alleen maar meer aan performance gaan denken, en marketeers zijn inmiddels ook steeds meer overtuigd van de meerwaarde. Snelheid blijkt een betere conversiedrijver te zijn dan veel visuele poespas of nutteloze video's en afbeeldingen. En hostingbedrijven hebben door de jaren hun hardware en stacks ook wel verbeterd, dus over het algemeen merk ik een verbetering door de jaren. Van mijn favoriete sites laadt het leeuwendeel binnen een seconde. Ik bezoek dan ook weinig sites die overdreven vol gestampt zijn met reclame.

Hoe dan ook; ik denk dat HTTP/2 een betere stap is naar meer snelheid, dan initiatieven als deze nu van Google. Zo'n lichte versie van een site, door Google samengesteld, zal niet in alle gevallen perfect werken en geeft vaak sowieso niet dezelfde ervaring. Het is meer een noodgreep voor hele trage verbindingen, zoals Google zelf ook aangeeft. HTTP/2 zal, wanneer het voldoende wordt ondersteund door hosts en browsers, voor het gehele web een verbetering zijn zonder in te leveren in kwaliteit en features.

[Reactie gewijzigd door geert1 op 13 juni 2015 21:16]

De meeste logge en lompe sites die ik tegenkom, zijn toch echt 'professioneel' ontwikkeld, maar dat is natuurlijk een beperkte steekproef. Wel aanleiding voor een hypothese; Jouw stelling over zelfbouw en amateurs is misschien inmiddels achterhaald, of vraagt toch in elk geval om onderbouwing.

[Reactie gewijzigd door mae-t.net op 13 juni 2015 14:27]

De professionele sites zijn vaak de sites met de meeste reclame en tracking shit omdat ze aan elke millimeter dat jij je muis beweegt geld willen verdienen.
Ik bedoel zeker niet alle zelfbouwers over één kam te scheren; ze zijn er natuurlijk in alle soorten en maten. En het komt ook zeker voor bij websites die wel door een bureau zijn gebouwd. Af en toe zie ik sites waarvan ik gruwel: drie verschillende javascript-frameworks inladen die allemaal hetzelfde doen, een carrousel met afbeeldingen van 2MB per stuk, 100 resources per pagina, enz.

Oftewel dat er nog niet altijd genoeg rekening wordt gehouden met performance, vanwege een gebrek aan kennis, tijd, geld of aandacht. Dat had ik niet zozeer specifiek op zelfbouwers hoeven richten eigenlijk.
Er is veel zelfbouw en er zijn veel amateur-ontwikkelaars
Gelukkig maar! Dat is wat internet internet maakt. Ik mis dat oude DIY internet wel met al die eenheidsmeuk die je tegenwoordig ziet.
In die zin helemaal met je eens: Het is een grote kracht van het internet dat iedereen er zelf gemakkelijk mee aan de slag kan. Alleen die ogenschijnlijke eenvoud heeft wel eens z'n nadelen wanneer mensen hun eigen kennis te buiten gaan en niet genoeg rekening houden met bijvoorbeeld de performance. En voor sommige sites is dat wel nodig (afhankelijk het doel, publiek en functie van de site).
De website van de volkskrant is even mooi voorbeeld, zo zwaar dat laden via een trage verbinding zomaar een minuut kan duren.

Tweakers laat zien dat responsieve design ook snel kan zijn (al is ook tweakers niet meer zo snel als een jaar of 5 geleden). Kan tweakers de collega's van de Volkskrant niet helpen hun website te fixen?

Ik ga wel even kijken of mrt web light sommige sites beter werken.

Overigens gebruikt hier in Ethiopië bijna iedereen opera mini. Werkt ook een stuk beter maar veel sites (waaronder tweakers) werken niet goed met opera mini.
Wat betreft tweakers. Als het allemaal te lang duurt kun je ook nog via http://tweakers.mobi. Daar zit een stuk minder aan 'tooltjes' in.
Deze mobiele website van de volkskrant is echt een aanfluiting inderdaad. Bijna onbruikbaar eigenlijk. Omdat er helaas ook geen app is voor Windows Phone zou ik bijna me abbo opzeggen om deze reden.
De website van de volkskrant is even mooi voorbeeld, zo zwaar dat laden via een trage verbinding zomaar een minuut kan duren.
Mee eens, die site opent zo traag dat koppen dwars door het menu heen staan, tot alles geladen is. Maar ik zit ook erg vaak te wachten vanwege advertenties die nb. "Optimized by Rubiconproject" zijn...
Speciaal even op VK gekeken. Die site is volgens mij de lelijkste 'grote' site die ik de afgelopen paar jaar heb gezien.
Overal bewegende flash-advertenties. Grote blokken die niets toevoegen. De meest zinnige navigatie-delen staan onderaan de pagina. Het enige kleur-gebruik zit in die advertenties, waardoor ze nog irritanter zijn. Geen categorisering in nieuws, waardoor voor mij relevant nieuws gemengt word met niet boeiende dingen.
Dat ze dat daar zelf niet doorhebben.
Volgens mij ligt dit vooral aan de hoeveelheid javascript die je tegenwoordig als webdesigner vaak nodig hebt. Het is in theorie heel handig, even een element toevoegen, of automatisch verbergen, of een responsive slideshow, maar in de praktijk maakt het dat je website toch merkbaar langzamer laadt.
Het is in theorie heel handig, even een element toevoegen, of automatisch verbergen, of een responsive slideshow, maar in de praktijk maakt het dat je website toch merkbaar langzamer laadt.
En dat is ook gewoon zo.
Aan de andere kant... Als je bij elke klik opnieuw de pagina moet laden, en dat duurt steeds 250 milliseconden, of je moet één keer de pagina laden maar dat duurt dan 2 seconden bijvoorbeeld, wanneer ben je dan beter af?

Ik vind het zelf vooral belangrijk dat nadat de pagina geladen is hij snel reageert. Bij elke klik opnieuw vertraging, dat is pas echt verschrikkelijk. En wat dat betreft is het er toch wel flink op voorruit gegaan. Ik vind GMail wel een goed voorbeeld. Die moet echt wel even laden (ze hebben zelfs een progress bar) maar zodra dat gebeurd is werkt hij supersnel.
Dat is wel weer waar ja. Sterker nog, je kunt zelfs javascript gebruiken om dingen ondemand te laden. Zo heb ik een slideshow van 30 plaatjes, die pas geladen worden zodra je naar de volgende gaat. Met een redelijke internet verbinding merk je toch niet eens dat de plaatjes ondemand geladen worden en gebruikers die de slideshow niet gebruiken besparen bandbreedte.

http://www.appelsiini.net/projects/lazyload
Door alleen met CSS spellen met bijvoorbeeld display: none; en hover kan je ook al een eind komen. Volgens mij downloaden veel webmasters maar wat javascripts. En weten ze meestal geeneens wat de meeste javascrips doen, en of het wel echt nodig is.
Is het ook niet gewoon zo dat het makkelijk is om een heel framework te laden terwijl je maar enkele functies gebruikt?
Maar dat zou niet zo'n probleem moeten zijn als het een bekend framework is en deze vanuit een algemene CDN komt. Probleem hierbij is dan weer vooral dat iedereen weer zijn eigen 'persoonlijke voorkeur' heeft wat CDN betreft. Maar goed, een grote library komt dan wel vanuit de cache. Maar moet wel volledig geparsed worden.
Inderdaad de adds. Ik had laatst tijdelijk mijn Adblock uit staan, waarom weet ik niet precies. Ik zag naast dat sommige site ontzettend irritante reclame hadden dat het laden verschrikkelijk veel trager werd.

Die adds moeten ze maar optimaliseren en niet zo irritant maken, dan zet ik 'm wel weer uit.
Inderdaad. Hoe vaak het niet gebeurt dat ik een hele tijd Connecting with "Ad-server X" in de statusbalk zie staan, en dat pas daarna de site zelf wordt ingeladen (dus ads moeten niet alleen geoptimaliseerd worden, maar ook mag de volgorde/afwikkeling van requests wel eens goed onder de loep worden genomen). Iets langer moeten wachten op een website vind ik op zich niet erg, maar wel als het veroorzaakt wordt door een brak/traag advertentie-netwerk.

[Reactie gewijzigd door w00t00w op 13 juni 2015 15:29]

Werkt ssl nog met zo'n tussenpartij er tussen?
Tuurlijk. Google downloadt tenslotte de pagina zelf en stuurt jou een aangepaste versie. Dat zal ook prima werken met pagina's via https. Die downloadt Google dan voor je, past ze aan en geeft je het eventueel via https door...

Uiteraard is dat niet helemaal hoe https bedoelt is, maar technisch zal het prima werken :P
Die "tuurlijk" is een beetje een vreemde reactie. Immers, je krijgt niet het originele certificaat te zien maar een van Google. Technisch is dat een SSL verbinding, maar met de verkeerde partij waardoor je zelf niets kan controleren. Je moet er vanuit gaan dat Google de boel op orde heeft.
Qua functionaliteit zal het voor veel gebruikers niet uitmaken, maar het is geen "tuurlijk" waard wat mij betreft.
Je vraagt helemaal niet meer een pagina op via de originele hosts en diens SSL-verbinding. Je vraagt googleweblight.com/?lite_url=eenurl op en dat eventueel voor een https-pagina.

Het ssl-certificaat dat dan voor je browser relevant is, is die van googleweblight.com. Dat er banken zijn die je erop wijzen dat je moet checken of er wel echt jebank.nl staat met een ssl-certificaat met extended validation gebruikt is natuurlijk leuk, maar niet iets dat je browser zal controleren.
Vanuit technisch oogpunt is dat niet relevant meer voor de specifieke https-request die je deed. Je zal dus ook niet zomaar foutmeldingen van je browser krijgen.

[Reactie gewijzigd door ACM op 13 juni 2015 13:23]

Klopt maar je bekijkt het dus volledig uit een technisch oogpunt: kan de gebruiker een pagina opvragen zonder foutmelding. 1 van de basis dingen die je met SSL kan doen, namelijk controleren of de site die je voorgeschoteld krijgt ook echt de goede is kan je nu dus niet (zelf) doen.
Dat het sowieso misschien niet verstandig is om gevoelige sites via een Google dienst te gaan bekijken is een tweede.
De vraag is ook,
Wat mag google met je gegevens die je bekijkt via de web-light dienst?

Stel je bent aan het bankieren via de dienst, wat mag google dan voor een gegevens over jou verzamelen en gebruiken?

De privacy voorwaarden zeggen dit:
We verzamelen gegevens op de volgende manieren:
  • Gegevens die u aan ons levert.
  • Gegevens die we ontvangen op basis van uw gebruik van onze services.
Als je internet bankiert via de dienst, dan lijkt mij het dat google de gegevens die het voor je verkleint, ontvangt op basis van gebruik van hun service.
Onze geautomatiseerde systemen analyseren uw inhoud (inclusief e-mails) om voor u relevante productfuncties te leveren, zoals aangepaste zoekresultaten, gepersonaliseerde advertenties en spam- en malwaredetectie.
Vervolgens bieden de privacy voorwaarden ook geen enkele beperking op het gebruik van die gegevens door google zelf. Zolang het valt binnen de 'bedrijfsvoering' van het aanbieden van services.
Hoe we gegevens gebruiken die we verzamelen

We gebruiken de gegevens die we uit al onze services verzamelen om de services te leveren, [..] en te verbeteren, om nieuwe services te ontwikkelen [..]. We gebruiken deze gegevens ook om gepersonaliseerde inhoud aan u te leveren, zoals relevantere zoekresultaten en advertenties.
Volgens mij is Google's SSL oplossing zoals je zegt ook enkel en alleen een schijnoplossing. Normaal weet je door ssl zeker dat je verbonden bent met de eindpartij waarmee je zaken doet, nu verbind je met 'de man in het midden' in plaats van met de eind partij waarmee je zaken doet.

Die man in het midden, lijkt zichzelf weinig beperkingen op te leggen om van jouw (Bank) gegevens gebruik te gaan maken.

Aan de andere kant, wordt je databundel 'gratis' 4x zo groot. Je browser bijna 4x zo snel. Dus ik snap ook dat sommige mensen er wel voor kiezen.

edit: ik zie dat m'n beide banken cookies op die manier gebruiken dat google niet langs de cookiewall komt dus om m'n bankgegevens hoef ik me geen zorgen te maken.

Edit2: ook langs de cookiewall van geenstijl komt hij niet, en op tweakers.net of facebook geeft hij de melding
Transcoding test failed:
Fetching from the origin site failed or timed out.

[Reactie gewijzigd door nul07 op 13 juni 2015 13:39]

Meen je dat? Internetbankieren kan dus via een server van Google, of iemand anders gaan?

Al moet ik zeggen: als je een browser in gebruik neemt, die gegevens van andere plaatsen ophaalt dan jij denkt, dan kan dat inderdaad gebeuren. Ik zou alleen nooit zo'n browser vertrouwen.
Het probleem is dat Google een vrij vertrouwde host is (bijna elke browser vertrouwt die wel) en zolang ze het idd via proxying doen blijft het allemaal lopen via het google-domein en is het certificaat dus goed.

Ik heb hier toch een gevoel bij dat Google een beetje dubbel denkt. Voor de search geven ze prio aan ssl, maar met dit soort toepassingen halen ze het idee onder ssl weer onderuit.
Ik kan me voorstellen dat Google net als in Chrome een waarschuwing zal tonen als het certificaat niet klopt bij de opgevraagde website. Hoewel jij als eindgebruiker het certificaat van bijvoorbeeld ING nooit zal zien als je Web Light gebruikt, kan Google deze natuurlijk wel controleren.
Hoewel jij als eindgebruiker het certificaat van bijvoorbeeld ING nooit zal zien als je Web Light gebruikt, kan Google deze natuurlijk wel controleren.
En als Google het niet goed controleert? Kan ik dan bij Google aankloppen als er 10.000 van mijn rekening af is? Want bij ING hoef ik het niet te proberen.
Natuurlijk zal Google niet altijd op de juiste momenten een waarschuwing tonen. Geen enkele beveiliging is immers perfect.

Net zoals Internet Explorer, Firefox en Chrome een melding tonen wanneer er een fout wordt gedetecteerd in het certificaat, zou Google dezelfde controle uit kunnen voeren op hun servers. Als een foutief certificaat tóch door die controle komt, dan was die er in jouw browser zonder het gebruik van Google Web Light ook door heen gekomen.

Het maakt niet uit waar je het certificaat controleert als het op dezelfde manier gecontroleerd wordt.
Ja, dat werkt: https://googleweblight.co...ps://www.paypal.com/&re=1

Zoals je kan zien wordt de pagina versleuteld met het certificaat van Google. Je weet dus niet zeker of je wel echt met Paypal verbonden bent, maar ik kan me voorstellen dat Google in deze service net als in Chrome een waarschuwing zal tonen als er iets niet klopt.
maar ik kan me voorstellen dat Google in deze service net als in Chrome een waarschuwing zal tonen als er iets niet klopt.
De waarschuwingen etc is niet het probleem, het probleem is meer dat je nu een gigantische SPOF hebt (Google)

Als googleweblight gehacked wordt dan heb je in 1x toegang tot al het mobiele bankverkeer van heel afrika / azie (/iedereen die "traag internet" heeft)
[...]
Als googleweblight gehacked wordt dan heb je in 1x toegang tot al het mobiele bankverkeer van heel afrika / azie (/iedereen die "traag internet" heeft)
Vanuit die redenatie is alles onveilig. Alles kan immers gehacked worden. Persoonlijk vertrouw ik er op dat Google dit goed in handen heeft.
[...]
Vanuit die redenatie is alles onveilig. Alles kan immers gehacked worden.
Nope, juist niet alles is onveilig, want alles is gescheiden. Een hack bij de ING heeft geen gevolgen voor ABN-klanten etc. etc.
Google heft hiermee de gescheiden verantwoordelijkheden op en denk maar niet dat je bij Google hoeft aan te kloppen als het fout zit hoor.
Persoonlijk vertrouw ik er op dat Google dit goed in handen heeft.
Persoonlijk vertrouw ik er snel op dat Google het beter voor elkaar heeft dan menig losse partij, alleen niet beter als 100.000 losse partijen...
[quote]
[...]
Nope, juist niet alles is onveilig, want alles is gescheiden. Een hack bij de ING heeft geen gevolgen voor ABN-klanten etc. etc.
[...]

Nope, een hack van Google Web Light heeft geen gevolgen voor mensen die Google Web Light niet gebruiken. In je beredenering ga je daar wel van uit.

[Reactie gewijzigd door RutgerSmeets op 13 juni 2015 13:26]

Nope, een hack van Google Web Light heeft geen gevolgen voor mensen die Google Web Light niet gebruiken. In je beredenering ga je daar wel van uit.
Ik ga er idd vanuit dat Google Web Light een succes wordt, Google ook, anders hadden ze het niet opgezet.
Maar zal het ook zo populair worden dat het voor criminelen interessanter wordt om Google Web Light te hacken dan een populaire bank? Als we er vanuit gaan dat beide diensten ongeveer in gelijke mate beveiligd zijn, zou het logischer zijn om bij de bank in te breken. Bij een succesvolle kraakpoging bij Google krijgen criminelen immers alleen het webverkeer in handen. Wanneer de populaire bank gehackt wordt kunnen de criminelen veel meer doen dan slechts het verkeer onderscheppen, zoals het aanpassen van saldi.
Laat maar zitten, jij snapt niet wat ik bedoel...

Alle banken ter wereld (al gebruikt maar 1% van de mobiele gebruikers het) "alleen het verkeer onderscheppen en aanpassen" is nog steeds lucratiever dan 1 populaire bank 100% gekraakt.

Elk vergelijk met 1 bank (of enkele banken) is zinloos
Ik ben er niet zo zeker van dat dit probleem optreedt:

"Some pages are currently not transcoded, including video sites, pages that require cookies (such as personalized sites), and other websites that are technically challenging to transcode. In these cases, you will see a "not transcoded" notification if you request the transcoded page using one of the tools listed above."

Dat wil zeggen, zolang het verkeer dan niet alsnog via Google verloopt. Al met al vind ik het niet een geruststellende ontwikkeling.
Currently not transcoded...

En ik weet niet hoeveel verkeer FB etc veroorzaken, maar ik vermoed dat het een hoog percentage is (binnen de doelgroep) en alles is daar personalized, dus of het effect is weinig of ze zullen het ook bij personalized dingen moeten aanzetten vermoed ik.
Lijkt erop dat de google servers de site binnen halen en met name de afbeeldingen bijzonder comprimeert, foto's op mijn site worden compleet blurry (logisch dat data dan minder wordt). Maar door het responsive design is het wel werkbaar. De site word gewoon in delen geserveerd, naar gelang wat zichtbaar is. Het is beduidend traag op een PC met normaal internet, dus ik denk dat het op "traag" internet niet veel beter is als de site normaal laden. Alleen sites met images van 2-3mB op de homepage worden op deze manier wel goed aangepakt.

Fun fact, adsense wordt er ook uitgevist, dat moeten ze nog even aanpassen denk ik :+ (het is een ander domein dus logisch dat adblock dan blokkeert, goedemorgen...)

[Reactie gewijzigd door aadje93 op 13 juni 2015 11:32]

Bij mij worden websites wel in een keer geladen, en razendsnel ook. Worden elementen op de pagina's bij jou pas ingeladen als je er naar toe scrolt? Zou toch handig zijn, zo download je alleen de delen van de webpagina die je daadwerkelijk gebruikt, ik denk dat dat in de landen waarvoor dit bedoeld is belangrijker is dan de snelheid waarop ze geladen worden.
Het klinkt een beetje als de Blackberry Enterprise Servers, die comprimeerden standaard ook het internetverkeer van/naar de aangesloten Blackberries. Het betekende wel dat alle verkeer via die (proxy)server gaat, maar het gaf een flinke reductie van dataverkeer.
Al was Blackberry professioneler, ze verkochtten ook de software zodat bedrijven alles in eigen hand konden houden.
Ideaal voor mobiele en satellietverbindingen, waarbij je vaak voor je dataverbruik per MB mag afrekenen. :) Zo ben je dus (veel) goedkoper uit.

Of ter compensatie van de lage overdrachtssnelheden van Dial-up, waar nog een significant deel van de wereld gebruik van maakt. Je hoeft minder lang te wachten op je webpagina, scheelt telefoontikken. :)

[Reactie gewijzigd door timmie1 op 13 juni 2015 11:34]

Of ter compensatie van de lage overdrachtssnelheden van Dial-up, waar nog een significant deel van de wereld gebruik van maakt.
Welke delen van de wereld als ik vragen mag?!
[...]


Welke delen van de wereld als ik vragen mag?!
Binnenland van de VS bijvoorbeeld. Of in Siberië en verre oosten van Rusland.
Them poor guys -O-

[Reactie gewijzigd door tellavist op 13 juni 2015 11:50]

Bijvoorbeeld de buitengebieden in Nederland. Of je dat significant wil noemen lijkt me een smaak kwestie.
Vroeger (dailup tijdperk) zette ik het inladen van afbeeldingen gewoon uit. Dat hielp ook.
Altijd fijn op een site als Flickr. :+ ;)
Maar ff serieus, kan je dat nu ook nog ergens handmatig doen?
Dat was rond 1995. Toen bestond Flickr en consoorten nog niet.
Die optie bestaat nu nog steeds, maar zit wat verborgen. Bij Firefox staat hij bij about:config.
Oké bedankt, zal er eens rondneuzen! :)
Tumblr laadt gelijk veel sneller ;).
In sommige browsers (bv. Otter, à la klassieke Opera) heb je standaard site preferences. Dan kun je dus bv. globaal afbeeldingen en JS uitzetten en op site-basis activeren. In Fx heb je daarvoor extensies, wat mij betreft wat minder elegant, maar vaak dan weer met net iets meer mogelijkheden.
Dit is natuurlijk de logische volgende stap na Google Pagespeed: https://developers.google.com/speed/pagespeed/module/ . Dit is natuurlijk een grappige actie, maar dit gaat voor veel zaken niet werken in de toekomst. Aangezien Google hier als middelman optreedt werkt dit trucje alleen via HTTP en niet via HTTPS. Daarnaast doet Opera dit ook al tijden.

[Reactie gewijzigd door BCC op 13 juni 2015 11:38]

HTTPS werkt dus wel: https://googleweblight.co...ps://www.paypal.com/&re=1

Google treed inderdaad als middelman op, waardoor je als eindgebruiker alleen te maken hebt met het certificaat van Google. Onderweg is al het verkeer wel degelijk versleuteld, behalve voor Google zelf.
Dan werkt het dus niet :)
Het werkt wel, in de zin dat websites die via https werken via de service gewoon bereikbaar zijn.
De internetsnelheid in Indonesië staat in geen verhouding tot die in het westen. Voor vaste aansluitingen is ADSL nog steeds de standaard en als je meer dan een paar Mbps hebt dan mag je van geluk spreken. En dan betaal je ook nog eens makkelijk 80 euro of meer per maand.

De achterliggende oorzaak is het totale gebrek aan visie en planning, en de grootschalige corruptie. Nieuwe initiatieven krijgen hierdoor geen kans. Het is bijvoorbeeld heel normaal dat er een gloednieuwe glasvezelkabel in de straat wordt gelegd waar vervolgens jaren niks meer mee gebeurt. Het zit in de grond, de juiste zakken zijn gevuld en voor de rest blijft het bij het oude omdat andere belangen groter zijn.

Mobiel is het gelukkig een iets beter verhaal. Voor een paar euro per maand heb je minimaal 2 GB over 3G en tegenwoordig ook 4G/LTE. En dat prepaid! Snelheden liggen gemiddeld een stuk hoger dan de lokale ADSL. Alleen de verbinding is niet altijd even betrouwbaar. De mobiele markt is wat prijzen betreft een heel stuk prettiger dan in Europa. Bellen en SMS zijn ook bijzonder goedkoop (halve cent per SMS omgerekend) en het maakt daarbij niet uit waar in drie tijdzones je naartoe belt. Hoeveel je ook internet en belt, je krijgt je beltegoed bijna niet op.

Desondanks is het begrijpelijk dat er initiatieven zijn om in dit soort landen met kunstgrepen de surfervaring te verbeteren. Vanuit de overheden daar hoef je weinig tot niets te verwachten op gebied van verbeteringen. Uitvallende zendmasten zijn echter aan de orde van de dag en daar zal de beste compressietechniek niets aan kunnen veranderen.
Is het niet zo dat een groot deel van dat extra verkeer gegeneerd word door advertenties e.d.?

Dan is het des te opmerkelijker dat Google als marktleider in online advertentiediensten met dit initiatief komt. Het is ook wat dubbel: via een dienst van Google gaan we dus data comprimeren om een probleem op te lossen wat door een deel door Google gegeneerd word? Kijk, ik kan het data-compressie initiatief waarderen hoor, maar kan Google ook niet eens kritisch kijken naar het verkeer wat ze zelf genereren?
Je kunt het dubbel noemen, maar mij lijkt het juist een eenvoudige strategie: bouw technologie die veel bandbreedte kost -> zorg dat het populair wordt -> bouw techniek die internet sneller maakt (google fiber of dit) -> meer techniek die meer bandbreedte kost.

Ongeveer hetzelfde wat Microsoft doet. Een zwaarder OS maken zodat mensen snellere PCs moeten kopen en je nieuwe OS meer wordt verkocht omdat het standaard op alle pcs wordt geleverd. Ze kunnen niet meer verdienen door een lichter OS te maken.

Google wil juist niet kijken naar hun eigen dataverbruik, dataverbruik is bijna hun business model.
Zoals Microsoft? Slecht voorbeeld.....Microsoft is juist het voorbeeld van een bedrijf wat niet aan de system specs-race meedoet.

Windows 7

- 1 gigahertz (GHz) of sneller 32-bit (x86) of 64-bit (x64) processor
- 1 gigabyte (GB) RAM (32-bits) of 2 GB RAM (64-bits)
- 16 GB beschikbare schijfruimte (32-bits) of 20 GB (64-bits)
- Grafisch DirectX 9-apparaat met het stuurprogramma WDDM 1.0 of hoger

Windows 8 & 8.1

- Processor: 1 gigahertz (GHz) of sneller met ondersteuning voor PAE, NX en SSE2 (meer info)
- RAM: 1 gigabyte (GB) (32-bits) of 2 GB (64-bits)
- Beschikbare schijfruimte: 16 GB (32-bits) of 20 GB (64-bits)
- Grafische kaart: Microsoft DirectX 9 grafisch apparaat met WDDM-stuurprogramma

Windows 10
- Processor: 1 gigahertz (GHz) of sneller
- RAM: 1 gigabyte (GB) (32-bits) of 2 GB (64-bits)
- 16 GB beschikbare schijfruimte
- Grafische kaart: Microsoft DirectX 9 grafisch apparaat met WDDM-stuurprogramma
- Een Microsoft-account en internettoegang

Ik vertrouw mijn data persoonlijk liever toe aan MS dan aan Google. Niet dat MS heilig is, maar hun privacy-regels zien er veel beter uit dan Google.
Windows 8 is dan ook de eerste uitzondering op de regel dat Microsoft elk OS zwaarder maakt. Vanaf het begin totaan W7 was dat 100% waar en die strategie heeft heel veel nieuwe desktop pcs verkocht. Erg flauw dat je dat niet wilt erkennen.

Dat W8 lagere specs heeft is vooral omdat ze de specs verlaagd hebben (dwz dat wat MS acceptabele performance vindt wat naar beneden is bijgesteld) en omdat het OS aggresiever zijn swapfile vult en daardoor minder geheugen nodig heeft (en trager wordt)

Dat je je data uberhaupt aan een bedrijf "vertrouwt" (toevertrouwt), laat staan een die onder de Patriot Act valt, laat wel zien dat je niet veel snapt van privacy
Een bedrijf afrekenen op zijn fouten uit het verleden is ook twijfelachtig. Persoonlijk vind ik dat MS van de grote tech-bedrijven op dit moment een van de meest innovatieve is. Bij een bedrijf als Apple gaan de specs voor OS-X al jaren omhoog dus....

Ik snap niets van privacy? Mmm.......dat is nogal een bewering zeg: blijkbaar ken je me al heel erg goed. :)

Kijk, die Patriot Act is moeilijk omheen te komen. Maar dat zijn overheidsdiensten die data van mij opvragen. Dat wil ik evengoed niet, maar goed.....daar tegenop boksen is best lastig heb ik gemerkt. Als je goede tips hebt houd ik mij warm aanbevolen.

Echter, aan commerciele partijen die hetzelfde doen (denk vooral aan Google, Facebook etc.) heb ik een bloedhekel. Hoe ver gaat dat? Ik neem geen Google-diensten af en een Facebook-account....dacht het niet. Alle adblockers, ghostery etc. staan hier standaard aan. En ik heb een BlackBerry: zoveel houd ik van mijn privacy.

Persoonlijk vind ik de meeste mensen die zeggen dat ze niks te verbergen hebben (en daarmee het gebruik van deze gratis diensten proberen te rechtvaardigen) helemaal van het pad af maar hey: het is hun beslissing.

Nog steeds van mening dat ik niks snap van privacy? Persoonlijk denk dat als iedereen dezelfde kritische houding als mij aan nam naar dit soort 'gratis' diensten van Google en Facebook het heel snel bergafwaarts zou gaan met beiden...
Ik heb een Microsoft-account moeten maken voor deze pc en moet eerlijk toegeven dat ik nog steeds gmail gebruik vanwege android telefoon (dat zijn dus al teveel diensten bij Google)

Ik denk van al die bedrijven dat ze mijn data aan de hoogste bieder verkopen, lekke security hebben en zonder veel druk de overheid inzage geven. Daar leef ik dan maar mee. Je moet toch een telefoon hebben en een email-account, en het maakt imo niet zoveel uit of je nu blackberry of android of apple of wat dan ook hebt, zolang je data via het internet verzendt luistert er iemand mee. Alle moeite die ik doe om dat te ondervangen is verspild zolang point-to-point encryptie zoals Snowden heeft gezegd algemeen gebruikt wordt, en dan met een encryptie-methode waar de NSA of welke afkortingsdienst dan ook met z'n tengels niet aan heeft gezeten. Dat duurt nog wel een paar jaar. Tot die tijd kun je niet veel doen om je privacy te waarborgen.

Omdat je een Blackberry hebt en nooit Google gebruikt sta je waarschijnlijk al hoger op de terrorisme-lijst dan de rest van Nederland. Je wordt nu niet gevolgd door Google, maar wel door de grootste afnemer van hun data :P

Ik had misschien niet moeten zeggen dat je niet veel van privacy snapt, ik vond het vreemd klinken dat je zei dat je MS meer vertrouwde terwijl imo bedrijven intrinsiek niet te vertrouwen zijn. Ze hebben geen moreel besef, alleen aandeelhouders. Die privacy-regels gaan zo het raam uit als dat meer winst oplevert. Maargoed, ik hou er wel over op :)
Dit ziet er leuk uit, maar voor mijn gevoel niet meer van belang. Alle hardware is al snel genoeg, de verbindingen zijn in veel landen, zoals in NL erg snel. Van mij hoeft het niet sneller door webpagina's te strippen en terug te gaan naar de jaren 90.

Het is alsnog de keuze van een website eigenaar om het zo efficient en snel mogelijk te maken of juist wat meer responsive met mooie effecten. Dit zou ook eventueel ingebouwd kunnen worden in een website of een CMS zoals WordPress, automatische herkenning en het aanpassen van de website.

Idee is leuk, uitvoering wacht ik even af, werkt nu nog niet prettig.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat 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