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. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 83 reacties, 32.340 views •
Submitter: Mitsuko

Toekomstige versies van Firefox moeten gevoelsmatig sneller worden, hoewel de laadtijd van pagina's feitelijk langer wordt. Dat komt doordat css, html en javascript sneller geladen worden, ten koste van afbeeldingen. Daardoor verschijnen sites sneller op het scherm.

Firefox-logoOp zijn weblog schrijft Firefox-ontwikkelaar Patrick McManus dat een patch die nu is ingediend bij Mozilla ervoor zorgt dat javascript-, html- en css-code voorrang krijgen bij het laden van webpagina's. Pas als die elementen binnen zijn, worden afbeeldingen en andere media geladen.

Omdat afbeeldingen en andere media zoals video's pas later worden ingeladen, en niet meer parallel met de css, javascript en html, neemt het laden van pagina's in zijn geheel meer tijd in beslag. Volgens McManus neemt de gevoelsmatige snelheid echter fors toe. De time to first paint, waarbij de eerste contouren van de website zichtbaar worden, zou dertig procent minder tijd in beslag nemen. Een website is dan al min of meer bruikbaar. Volgens McManus wordt de first paint nu soms juist vertraagd door parallellisering.

De verslechtering in de laadtijd van de pagina komt volgens McManus neer op circa 5 procent. Op websites met relatief veel afbeeldingen, zoals Pinterest, komt de verbetering in de gevoelsmatige snelheid neer op meer dan 30 procent. Als alles goed gaat, wordt de patch onderdeel van Firefox 20; op dit moment is Firefox aanbeland bij versie 17.

Reacties (83)

Maar als de img tags geen width en/of height hebben dan verspringt je pagina dus zodra de afbeeldingen worden gedownload. Daar word je ook niet blij van.
ligt er ook een beetje aan of de pagina uit vaste frames is opgebouwd. Als elke afbeelding in een los frame staat is dit geen probleem (wat de meeste sites wel hebben voor zover ik weet)
Je kunt ook een klein deel van het image laden, meestal zit in het begin van het image de breedte en hoogte opgeslagen.

Opera doet volgens mij ditzelfde al tijden en daar verspringen pagina's eigenlijk nooit.
Maar dan ga je dus toch afbeeldingen prio geven boven de rest van de pagina/css/js. Die connecties moeten wel geopend worden, ook al haal je maar alleen headers op (en vervolgens nog een keer voor de hele afbeelding).

Dit is meer een probleem dat web developers op moeten lossen door waar het kan dimensies op te geven ipv deze weg te laten, voor een vlotte en soepele opbouw van een pagina.
In bijna alle gevallen worden hoogte en breedte van plaatjes meegegeven in de code.
Het verspringen lijkt me juist vaker veroorzaakt door de parallelle afhandeling, waardoor stukjes code (met de afbeeldingsmaten) soms iets later binnenkomen dan de afbeeldingen zelf, waardoor dingen verspringen.
het laden zelf is volgens mij het probleem niet, maar de connectie tijd die nodig is om met de webserver te verbinden om de img op te halen kan vertragend werken.

Wanneer je dus alleen het eerste stuk van de img laadt behaal je weinig tijdswinst

img maps maken om het aantal connecties te beperken, img groottes opgeven, gebruik maken van stylesheets voor je images, zorgen ervoor dat je connecties beperkt blijven en de pagina al na het laden van de basis/css weergegeven kan worden en snel laadt.

[Reactie gewijzigd door iznogood op 6 december 2012 12:18]

Lijkt op een soort interlaced gif van vroeger... de pagina was er al, de plaatjes 'komen later' (worden steeds meer gefocust).

http://vesta.astro.amu.ed...1/graphics/gif_files.html
Frames zijn verouderd, daar werkt geen enkele zichzelf respecterende site meer mee. Als je een img meestuurt is er meestal in CSS code de height en width gedefineerd, dus krijg je geen verspringingen.
elke afbeelding in een frame? Bedoel je misschien iets anders?
Dit probleem treedt nu ook al op (Firefox 17.0.1), aangezien tekst vaak al beschikbaar is terwijl ie nog bezig is met de plaatjes (langzame verbinding). Maar inderdaad, dat is wel redelijk irritant want je blijft scrollen en zoeken naar je tekst.
Daarom is het ook good practice al jaren om afbeeldingen een width/height mee te geven. Ook in huidige browsers zorgen die repaints al voor vertragingen en flikkeringen.
Een van de allereerste lessen in webdesign is dus om altijd width en height aan te geven aan img tags, zodat dat dus juist niet gebeurd.

Daarnaast zijn steeds meer images sites ingericht dat de foto's en zo pas later via een Javascript geladen worden, dus dan is het handiger om de JS eerder te laden ;-).
Ik dacht eigenlijk dat het goed gebruik was om de width's en height's in een CSS file te zetten. Maar daarmee voorkom je dit probleem dus ook.
Dat is alleen wel onhandig als je een CMS gebruikt waarin gebruikers in een wysiwyg afbeeldingen kunnen toevoegen zonder dat die resized worden, dan kunnen er verschillende afbeeldings formaten voorkomen die je niet in je css hebt staan... Dan kan een width en height in je tags wel een oplossing zijn... Of je moet altijd vaste image maten afdwingen...

Overigens wel apart dat browser snelheid nu ineens zo'n issue is... PC's zijn tegenwoordig razendsnel, internet connecties ook, servers snel genoeg om compressie toe te passen op html, css, js, we hebben HTTP1.1 keepalive om meerdere bestanden over 1 connectie te kunnen downloaden...Caching reverse proxies als Varnish om de delivery aan de serverkant supersnel te maken. Je zou zeggen dat snelheid steeds minder een issue zou moeten zijn...

[Reactie gewijzigd door mxcreep op 7 december 2012 11:00]

Ik hoop dat ze ook het gedeelte van de protected mode (Adobe Flash) eens onder handen nemen.

Sinds kort geeft dit bij mij problemen. De PluginContainer.exe wordt tweemaal geladen en neemt grofweg 50% CPU in beslag, alwaar Firefox.exe ook nog eens 40% voor z'n rekening neemt. Het gevolg is dat sommige sites met Flash gewoon niet vooruit te branden zijn. Tijdens het afspelen loopt Firefox ook steeds korte tijd vast.

Ik had al geprobeerd met een oudere Firefox versie en zelfs een oudere Adobe Flash versie, maar de problemen blijven bestaan. GPU drivers zijn ook up to date en heb verder niks aan het systeem gewijzigd. Het probleem onstond van de een op de andere dag.

De uiteindelijke oplossing was om de protected mode uit te schakelen waardoor Flash-content direct werd weergegeven zonder het gebruik van de PluginContainer.exe
Dat is een symptoom van die 'fantastische' sandbox die Adobe geimplementeerd heeft en de complete gare manier waarop de plugin API v/d browser aangesproken moet worden om die gammele zwik werkend te krijgen.

Ligt niet aan de Firefox devs.
De video's blijven steeds een seconde of 5-10 hangen als ze te lang zijn. Niet te doen.
Bij mij word er dan een hele core gebruikt, gewoon aan Firefox zelf.

Daarbij lijkt het of er ergens een geheugenlek zit, ram blijven vreten tot de 2 a 2,2GB en dan steevast crashen.
fout van de developers. die moet gewoon width en height meegeven imho.
Edit: anderen waren me al voor

[Reactie gewijzigd door aikebah op 6 december 2012 21:18]

Ze mogen hun memory-leak problemen ook oplossen. Dat is de reden waarom ik ben overgestapt ben naar chrome
En het cpu gebruik van CSS transities ... opera heeft ook geen hardware acceleratie maar doet het veel beter op dat vlak.

Ben sinds ik terug wat webdev doe ook fan geworden van chrome :)

[Reactie gewijzigd door spoonman op 6 december 2012 11:11]

En het cpu gebruik van CSS transities ... opera heeft ook geen hardware acceleratie
Jawel, het staat alleen nog standaard uit op het moment.
En daar zijn ze hard mee bezig en er is op dat vlak al erg veel progressie geboekt:
https://wiki.mozilla.org/Performance/MemShrink
https://blog.mozilla.org/nnethercote/
Ze mogen hun memory-leak problemen ook oplossen. Dat is de reden waarom ik ben overgestapt ben naar chrome

Dat is er al jaren niet meer. Niet in de kale browser tenminste. Zodra je 100 addons erin gooit en dan gaat klagen over de opstarttijd of geheugengebruik, wijs je toch echt de verkeerde schuldige aan.

[Reactie gewijzigd door DeathMaster op 6 december 2012 11:23]

Chrome kan er anders ook wat fvan, met een aparte thread per tab. Neemt net zoveel geheugen in..
Dit zorgt er wel voor dat als één tab crasht, de rest wel door kan draaien. Kwestie van prioriteiten...
Wat je bij chromium dan ook wel weer hard nodig hebt, met tabs die drie à vier keer per dag crashen.
Een aardig idee, maar veel afbeeldingen maken ook de content. Tekst kan nog verspringen (zoals hier het FF logo om de tekst heen loopt) en afbeeldingen in CSS voor de opmaak zullen dan ook pas later beschikbaar komen waardoor b.v. op sommige sites je witte tekst op een wit achtergrond krijgt terwijl er eigenlijk een afbeelding in zit met b.v. een zwart kleurig achtergrond.

Ik weet het niet, 30% sneller voor het gevoel met als resultaat een 'Min of meer bruikbare'-site terwijl puntje bij paaltje het dus langer duurt dan vroeger voor de site 'helemaal bruikbaar' is. Het klinkt niet juist.

HTML + Javascript als prio lijkt me dan veel logischer op die manier is de DOM sneller klaar en kan een site alvast beginnen met jquery event bindings etc (je kan je script altijd laten wachten op doc-ready ipv dom-ready als je toch iets met afbeeldingen doet).

Welk invloed zou dit eigenlijk hebben op huidige javascript code van sommigen?

[Reactie gewijzigd door ultimasnake op 6 december 2012 11:11]

Ik zie dat effect ook wel een inderdaad, maar wat mij betreft is dat een fout van de designer. Als je witte tekst over een donder achtergrondplaatje zet, dan zou de achtergrond onder dat plaatje ook al donder moeten zijn zonder dat het plaatje geladen is.
Ik vraag me af of het slim is om grafische elementen zoals afbeeldingen pas later te laden. meeste sites zijn juist afhankelijk van de afbeeldingen. Denk daarbij aan nieuwssites en veel webshops.

Mensen zijn visueel ingesteld dus in mijn mening is het laden van een afbeelding belangrijker dan de functionaliteit.

Ben ook benieuwd hoe je gevoelsmatige snelheidsverbeteringen in kaart gaat brengen.

[Reactie gewijzigd door 911GT2 op 6 december 2012 11:17]

Het gaat niet alleen om de functionaliteit. Je kan het volgens mij beter vergelijken met hoe een kantoor pand word gebouwd. Eerst word het frame neergezet (html+css) en daarna worden de muren en ramen erin gezet (afbeeldingen e.d.).
Javascript is in dit geval een buitenbeentje maar functioneerd zodra de opmaak gereed is.
Filmpjes heb je ook weinig aan als die daarna nog verspringen in het scherm wat in theorie kan.

Ik verwacht ook dat met de nieuwe generatie browsers en de komst van HTML5 het aantal afbeeldingen flink zal afnemen om de pagina er goed uit te laten zien. Dus heeft deze aanpassing nog minder effect.
Creatief omgaan met css en javascript zullen we maar zeggen!
Ik vind Firefox nu ook al vrij snel, is mijn favoriete browser.
Gevoelsmatig sneller bij start van de browser, of ook nog na 2 uur gebruik? Het geheugengebruik blijft een heikel punt bij deze browser namelijk. Ik begrijp niet waarom ze daar nog steeds geen goede oplossing voor hebben gevonden, maar ondertussen wel hun tijd 'verdoen' met dit soort verbeteringen.
Zie ook een bovenstaande reactie.

Er lopen al een tijd projecten om het geheugen gebruik terug te dringen (en uit ervaring weet ik dat dit al sterk is verbeterd) en de responstijden te verbeteren.

Dus ik zou zeggen gebruik een recente(re) versie en kijk dan nog eens.
Dit is toch niet hun tijd verdoen? Als ze de browser sneller aan kunnen laten voelen voor hun gebruikers, dan verbeterd dat de gebruikservaring toch aanzienlijk? Dat ze daarnaast volgens jou nog steeds last hebben van geheugengebruik (teveel, neem ik maar even aan) is natuurlijk jammer, ik heb echter de afgelopen jaren er geen problemen meer mee gehad.

[Reactie gewijzigd door drdelta op 6 december 2012 11:29]

Ik zag dat de planning van Firefox maar tot versie 25 loopt, wat gaan ze daarna doen?

Ontopic: Goede ontwikkeling, vooral als je even snel een linkje aan wilt klikken en deze sneller geladen is, bij deze actie heb je namelijk omringende afbeeldingen in principe niet nodig.
Planning verder maken.
Dan vergaat de wereld, net als de Maya kalender die niet verder gaat dan 21-12-2012.
Sorry dat ik zo kort door de bocht ga antwoorden, maar ik geloof het allemaal niet meer. Ik werkte met FF, nu 2 jaar met Chrome. Telkens als ik hoor dat het zogezegd weer eens sneller gaat check ik het altijd eens met de FF in kwestie. Opstarten, laden van pagina's, voor mij blijft het voelen alsof ik door modder aan het stappen ben. Bij Chrome heb ik dat gewoonweg niet, nooit gehad trouwens.

Ben (weer) benieuwd wat het gaat zijn met deze nieuwe versie...
Dan heb je toch een hoop verbeteringen gemist.

En voor een deel is de snelheid van chrome ook de marketing van google.
Als Chrome geen meerwaarde bood waren echt niet zoveel mensen overgestapt. Chrome voelde hier wel degelijk veel sneller.
Chrome bevat een prefetch functionaliteit die optimistisch pagina's op de achtergrond al inlaadt als er bruikbare links in de huidige pagina gezien worden. Daarom voelt het veel sneller. Zelfde kun je met bepaalde extensies voor Firefox ook bereiken.
Chrome doet eigenlijk al langer wat dit artikel beschrijft. Ik merk het vooral tijdens web development: Firefox rendered pas wanneer alles geladen is, Chrome toont een splitseconde een onafgemaakte pagina tussen het refreshen door.
Wat je noemt is aan te passen met een verborgen about:config optie: nglayout.initialpaint.delay

Dit is een geval waar Firefox voor een andere standaardwaarde kiest dan Chrome, en de meningen verschillen over wat beter is. Wat hier besproken wordt zorgt er echter voor dat pagina's in een andere volgorde geladen worden. Dit zit ook al in Chrome (en IE10 geloof ik) maar in een wat andere vorm - de vorm die nu in Firefox wordt geïntroduceerd heeft volgens het artikel van Patrick McManus een paar voordelen, waaronder betere interactie met SPDY (die z'n eigen prioriteitensysteem heeft).
Ik ben op het moment aan het spelen met de laatste nightly, waar deze patch nog niet in verwerkt zit. En ik moet zeggen dat FF sinds tijden weer goed mee kan met de concurrenten. De GUI loopt vlot, ziet er slick uit en ook is het antieke downloadvenster in een goede manier vernieuwd. De manier van plugins/addons in/uitladen hoeft (eindelijk) ook niet altijd meer met een herstart verzegeld te worden en qua geheugen gebruik loopt FF al een tijdje voorop. (Gezien de laatste benchmarks.)

Nu alleen nog die laatste engine verbeteringen en dan verovert FF hopelijk weer een plaatsje terug in het hart (of op de HDD) bij ex-gebruikers zoals jij. :P
Wat mij betreft geen goed idee. Op zich lijkt het heel handig als een page sneller te gebruiken is, maar ik vind het erg irritant als ik de aanwezige tekst al aan het lezen ben, en deze vervolgens verspringt omdat grotere elementen als afbeeldingen/video's vervolgens toegevoegd worden.
Het gebeurt me nu al regelmatig dat ik op een link wil klikken en vervolgens misklik omdat er net op dat moment een reclame op het scherm vergroot wordt oid. Met dit voorstel voor firefox vrees ik dat me dit nog vaker gaat overkomen.
Als de site ontwikkelaars hun werk fatsoendelijk hebben gedaan zal dat niet gebeuren.
Dan weet de browser al hoeveel ruimte ie vrij moet laten voor de afbeelding/de video.

Dan zie je hooguit lege vlakken zolang de boel nog niet geladen is
Wat een onzinnig gedoe. Gevoelsmatige snelheid. En hoe meten we dat dan? Met synaptic brain flops per second zeker.
Je kunt door middel van visuele effecten de illusie creëren dat iets sneller is, terwijl het in werkelijkheid eigenlijk (iets) langzamer is.

Bijvoorbeeld (uit de duim gezogen, weet niet of er browsers zijn die het zo doen): het oude beeld langer vast te houden, nieuwe pagina in de achtergrond renderen en vervolgens omwisselen als deze bijna klaar is, zodat je geen knipperend beeld met een lege pagina ziet. Gevoelsmatig lijkt het dan iets sneller, en daardoor krijg je minder snel de neiging in de zin van "%#^$^ browser, schiet nou eens op!"
Denk nou eerst eens even na, voor je gaat ranten.

Als alle tekst al binnen is, de opmaak al klaar is, en er alleen nog maar een paar plaatjes missen, dan is de pagina's officieel nog niet compleet klaar, maar is voor de meesten de webpagina al klaar op gebruikt te worden. Dat is dus gevoelsmatig sneller.

Vooral als de plaatjes niet zo belangrijk zijn, of verder onderaan de pagina staan, zul je nauwelijks merken dat de pagina nog niet helemaal ingeladen is... Wanneer je kunt beginnen de informatie tot je te nemen, dan is de pagina gevoelsmatig 'klaar'.

Op dit item kan niet meer gereageerd worden.



Apple iPhone 6Samsung Galaxy Note 4Apple iPad Air 2FIFA 15Motorola Nexus 6Call of Duty: Advanced WarfareApple WatchWorld of Warcraft: Warlords of Draenor, PC (Windows)Microsoft Xbox One 500GBSamsung

© 1998 - 2014 Tweakers.net B.V. Tweakers is onderdeel van De Persgroep en partner van Computable, Autotrack en Carsom.nl Hosting door True