Optimaliseer browser rendering

[van.der.schulting]

Aan een img-tag voeg ik altijd een width en een height attribuut toe om de pagina sneller te renderen.

Ik vroeg me echter af hoe het zit bij een background-size. Stel ik heb een image van 100x80 pixels die ik gebruik als achtergrond. Heeft het dan zin om aan mijn CSS toe te voegen 'background-size: 100px 80px'? Of maakt dat voor het renderen geen verschil?

[Ook al Bezet]

Dat lijkt me niet uitmaken. De snelheidswinst van het opgeven van de dimensies van afbeeldingen komt, als ik het goed hem, doordat de browser ruimte in de pagina kan inbouwen voor het plaatje, nog voordat het geladen is. Bij achtergrondafbeeldingen is dit niet nodig omdat ze de indeling van de pagina niet kunnen veranderen, hoe groot of klein ze ook zijn.

[_Thanatos_]

Het maakt niets uit. De snelheidswinst bij de <img> tag is technisch geen snelheidswinst, omdat het alleen sneller *lijkt*. Dit komt doordat je plaatjes al ruimte innemen vóórdat ze geladen zijn, waardoor het initieel lijkt alsof de pagina al helemaal gelayout is. Als je de width en/of height weglaat, zal de pagina relayouten voor ieder plaatje dat begint met laden, waardoor het voor de bezoeker trager lijkt, omdat er nog vanalles aan het gebeuren is.

Elementen resizen zich nooit naar een background-image, dus het zetten van afmetingen daarop maakt geen enkel verschil. Je maakt het potentieel zelfs trager, omdat de browser allerlei berekeningen moet doen om die background-size te respecteren.

[RobIII]

_Thanatos_ schreef op maandag 11 juni 2012 @ 02:27:
Het maakt niets uit. De snelheidswinst bij de <img> tag is technisch geen snelheidswinst, omdat het alleen sneller *lijkt*. Dit komt doordat je plaatjes al ruimte innemen vóórdat ze geladen zijn, waardoor het initieel lijkt alsof de pagina al helemaal gelayout is. Als je de width en/of height weglaat, zal de pagina relayouten voor ieder plaatje dat begint met laden, waardoor het voor de bezoeker trager lijkt, omdat er nog vanalles aan het gebeuren is.

Het maakt wel degelijk uit (voor de imgtag) en is wel degelijk sneller. Elke reflow die je kunt voorkomen moet je gewoon doen.

[Wolfboy]

Het doel van de grootte opgeven is dat je browser de pagina niet hoeft te re-renderen. Als de grootte van te voren bekend is blijft de pagina er dus hetzelfde uitzien als eerst behalve dan dat het plaatje dan opeens zichtbaar is.

Bij background images maakt dat niet uit omdat die de grootte van het element niet aanpassen.

[Soultaker]

_Thanatos_ schreef op maandag 11 juni 2012 @ 02:27:
De snelheidswinst bij de <img> tag is technisch geen snelheidswinst, omdat het alleen sneller *lijkt*.

Zelfs als dat waar is, is het nog steeds de moeite waard, omdat het tot een betere gebruikerservaring leidt. Het gaat er niet om hoe snel je site feitelijk is, maar om hoe de gebruiker hem ervaart. Die twee zijn natuurlijk gecorreleerd, maar uiteindelijk telt de subjectieve ervaring.

[_Thanatos_]

RobIII schreef op maandag 11 juni 2012 @ 08:23:
[...]

Het maakt wel degelijk uit (voor de imgtag) en is wel degelijk sneller. Elke reflow die je kunt voorkomen moet je gewoon doen.

Daarom zei ik ook dat het wél tot een betere gebruikerservaring leidt doordat er minder reflow nodig is. Maar als je er een stopwatch bijhoudt, dan zul je zien dat alle verschillen in de foutmarge vallen. Als iets sneller *lijkt*, dan *is* het nog niet sneller. Maar dingen sneller laten *lijken* ben ik een groot voorstander van - je maakt de website immers voor de bezoeker en niet voor de server

[Wolfboy]

_Thanatos_ schreef op vrijdag 15 juni 2012 @ 10:28:
[...]

Daarom zei ik ook dat het wél tot een betere gebruikerservaring leidt doordat er minder reflow nodig is. Maar als je er een stopwatch bijhoudt, dan zul je zien dat alle verschillen in de foutmarge vallen. Als iets sneller *lijkt*, dan *is* het nog niet sneller. Maar dingen sneller laten *lijken* ben ik een groot voorstander van - je maakt de website immers voor de bezoeker en niet voor de server

Verschilt heel erg per browser en nogal afhankelijk van hoe snel je CPU is.

Als je op een netbookje zit met IE7 bijvoorbeeld, dan merk je het verschil echt wel.

[Speedfreak230]

IE7 Bestaat dat nog?

Ontopic: Ik denk dat het met name inderdaad visueel lijkt dat het sneller gaat. Puur omdat die ruimte al gereserveerd wordt voor dat plaatje. Voor snelheidswinst zou ik gewoon niet te grote plaatjes pakken.

[Wolfboy]

Speedfreak230 schreef op vrijdag 15 juni 2012 @ 15:39:
IE7 Bestaat dat nog?

Ontopic: Ik denk dat het met name inderdaad visueel lijkt dat het sneller gaat. Puur omdat die ruimte al gereserveerd wordt voor dat plaatje. Voor snelheidswinst zou ik gewoon niet te grote plaatjes pakken.

Goed... IE7 zie je niet heel vaak meer, maar het bestaat zeker.

Voor meer info over het onderwerp: http://www.stevesouders.c...-performance-golden-rule/

Frontend performance (ook al is het alleen maar voor het gevoel van de gebruiker) is zeer relevant.

[Speedfreak230]

Dat klopt inderdaad, daar kan ik je geen ongelijk in geven.

Zie een website van mij, gericht op de consument met de stats van deze week:

[Barryvdh]

Ik zou IE wel opsplitsen in IE6/ie7/ie8/ie9, want anders zegt het nog vrij weinig..

[InZane]

Barryvdh schreef op vrijdag 15 juni 2012 @ 16:13:
Ik zou IE wel opsplitsen in IE6/ie7/ie8/ie9, want anders zegt het nog vrij weinig..

Inderdaad, zegt helemaal niks zo. Ben meer benieuwd hoe het met de percentages van de oude IE versies zit.
Niet dat deze stats heel representatief zijn volgens mij, want Safari staat op plaats 2..

[Wolfboy]

offtopic:
Sowieso is het een ranglijst en geeft het geen beeld van de verhoudingen, niet te moeilijk over doen het gaat gewoon om een indicatie

[_Thanatos_]

Wolfboy schreef op vrijdag 15 juni 2012 @ 12:28:
[...]
Verschilt heel erg per browser en nogal afhankelijk van hoe snel je CPU is.

Als je op een netbookje zit met IE7 bijvoorbeeld, dan merk je het verschil echt wel.

Dat nog niet eens. Als je een pagina laadt en direct naar beneden scrollt, en er worden vervolgens plaatjes boven je scrollpositie geladen, dan verspringt de pagina. Dan kun je een 800GHz CPU hebben, maar verspringen doet-ie. En bandbreedte van een bezoeker is helemaal 3x niks over te zeggen of over aan te nemen, tenzij je heel goed weet wie je doelgroep is en hoe/waar/wanneer ze het internet gebruiken.

[Speedfreak230]

Goed punt jongens, hierbij de uitgebreide versie die toch wat anders laat zien dan bovenstaand plaatje .

[Wolfboy]

_Thanatos_ schreef op vrijdag 15 juni 2012 @ 22:58:
[...]

Dat nog niet eens. Als je een pagina laadt en direct naar beneden scrollt, en er worden vervolgens plaatjes boven je scrollpositie geladen, dan verspringt de pagina. Dan kun je een 800GHz CPU hebben, maar verspringen doet-ie. En bandbreedte van een bezoeker is helemaal 3x niks over te zeggen of over aan te nemen, tenzij je heel goed weet wie je doelgroep is en hoe/waar/wanneer ze het internet gebruiken.

Inderdaad, het is ook gewoon vervelend.

Ik had het simpelweg over de redraws die gewoon traag zijn. Dat is ook goed merkbaar bij tragere systemen.

[RobIII]

Speedfreak230 schreef op vrijdag 15 juni 2012 @ 15:50:
Dat klopt inderdaad, daar kan ik je geen ongelijk in geven.

Zie een website van mij, gericht op de consument met de stats van deze week:

[afbeelding]

Speedfreak230 schreef op zaterdag 16 juni 2012 @ 12:35:
Goed punt jongens, hierbij de uitgebreide versie die toch wat anders laat zien dan bovenstaand plaatje .

[afbeelding]

Ik snap niet wat je denkt aan te tonen met deze afbeeldingen. Het is nogal een verschil of de percentages die hierachter zouden staan 50%, 48%, 1%, 0.01%, 0.001%, 0.001%, 0.001%, 0.001%, 0.001%, 0.001% of iets als 20%, 20%, 10%, 10%, 10%, 10%, 10%, 5%, 4%, 1% resp. zijn. Het is een Top 10 maar het zegt letterlijk 0 komma nada over de verhoudingen omdat je steeds de percentages eraf knipt. En dan nog is het maar zeer de vraag hoe representatief jouw site (lees: jouw meting) is. Het posten van deze screenshots is dus ook totaal zinloos.

En dat staat nog allemaal los van 't feit dat, wanneer mogelijk, je gewoon altijd een reflow wil voorkomen al is 't maar omdat 't best-practice is of vanwege de eerder beschreven "verspringende pagina's". Gebruikers ervaren dat als storend (en op tragere verbindingen is dat nog veel evidenter) en als het voorkomen kan worden door gewoon een width/height te specificeren: why not

Dit artikel, dat notabene dezelfde titel heeft als dit topic, is een leuk startpunt. Hier is 't al wat breder (niet alleen client/browser specifiek meer) en dan kunnen er nog boeken vol geschreven worden over allerlei zaken die je kunt toepassen om de gebruikerservaring optima(a)l(er) te maken die in deze gelinkte pagina's nog niet eens beschreven worden.

[ Voor 63% gewijzigd door RobIII op 16-06-2012 14:31 ]

[Wolfboy]

Hier wat representatieve cijfers van een vrij grote site (ik vertel niet welke aangezien ik geen reclame wil maken )

Browser	Percentage
Chrome	47.67%
Firefox	19.22%
Safari	14.77%
Internet Explorer	13.26%
Mozilla Compatible Agent	2.11%
Opera	1.54%
Android Browser	0.95%
Opera Mini	0.25%
RockMelt	0.07%
IE with Chrome Frame	0.05%

[phex]

Browser statistieken zijn behoorlijk doelgroep specifiek.

Techminded: Chrome
Niet techminded: IE
Social: Safari/Android
Designers: Safari
Programmeurs: Chrome/Firefox
Opas en omas: IE

en ja iedereen weet hier uitzonderingen op, maar het feit blijft dat de schaal afhankelijk is van de doelgroep van de site.

[Wolfboy]

phex schreef op dinsdag 19 juni 2012 @ 15:39:
Browser statistieken zijn behoorlijk doelgroep specifiek.

Techminded: Chrome
Niet techminded: IE
Social: Safari/Android
Designers: Safari
Programmeurs: Chrome/Firefox
Opas en omas: IE

en ja iedereen weet hier uitzonderingen op, maar het feit blijft dat de schaal afhankelijk is van de doelgroep van de site.

De statistieken hierboven zijn van een hele grote mode website, niet zo zeer techminded dus

Chrome is tegenwoordig in een aantal landen veruit de grootste browser, niet alleen bij techies.