Firefox 20 moet gevoelsmatig sneller worden

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.

Op 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)

[Qua Salébra]

Dit lijkt een simpel verschil, maar toch is dit in de huidige ICT wereld een belangrijk onderdeel van de ervaring, nmlk het gevoel.

Vaak hoor je dat Chrome veel sneller is dan FireFox, of dat IE 10 sneller is dan de Chrome, of dat er met Opera veel sneller gewerkt kan worden.

Uit veel benchmarks blijkt dat de werkelijke verschillen tussen de browsers bij het renderen van (complete) doorsnee pagina's niet zoveel (meer) afwijkt. Dan wordt de renderervaring dus belangrijk. Hoe snel staat (een deel van) de pagina op het scherm? Hoe snel heeft de gebruiker het gevoel dat de complete pagina op het scherm staat (ook al is dit niet zo).

Chrome heeft dit goed voor elkaar. Firefox ontwikkelaars zien dat hun JavaScript/CSS/HTML engine prima is, maar dat dit gedeelte ervoor zorgt dat men Chrome toch fijner vindt aanvoelen.

[Davio]

Voor mij gaat het er vooral om: Hoe snel is de pagina werkbaar?

Ik wil soms snel doorklikken naar een volgende pagina ook als de volledige pagina nog niet geladen is. Bij IE heb ik altijd het gevoel gehad dat ik helemaal niks kon doen zolang de pagina nog niet 100% klaar was. Bij Firefox voelde dit ook voor een deel zo.

Ik gebruik nu Chrome en die voelt voor het grootste deel vrij "snappy" aan.

[Leejjon]

Dit inderdaad. Had een paar versies (firefox 4 vs chrome van die tijd) geleden ook getimed hoe snel beide browsers opstartte, en firefox was even snel in tijd, maar chrome animeerde de animaties als de zandloper enzo sneller en bouwde de pagina wat smoother op en daar zijn kennelijk veel mensen heel gevoelig voor.

Zelf heb ik firefox nooit als sloom ervaren en vind ik firefox qua functionaliteit en aanpasbaarheid beter.

[conhen]

Het zou wellicht prettiger zijn als FF ook niet-gevoelsmatig sneller wordt...
Dus dat het meetbaar sneller wordt, en niet alleen maar zo lijkt...
(geldt overigens niet voor FF speciaal, maar men is alleen maar bezig om iets sneller te doen lijken ipv sneller te maken).

[blorf]

Ik vind eigenlijk alle browsers tegenwoordig wel snel. Het wachten is voornamelijk op trage verbindingen, laggende DNS-servers, gebruik van inefficiente technieken, overdreven veel reclame-zooi van externe bronnen en het aanbieden van een beroerde bandbreedte in het geval van multimedia. Deze voorpagina is hier binnen een seconde geladen en zit als je het mij vraagt goed in elkaar. Op bijv. nu.nl ben je alweer bijna een seconde langer aan het wachten omdat die via opendns een aantal banners moet ophalen van verschillende locaties.

[Verwijderd]

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...

[Joerdgs]

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.

[Mitsuko]

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).

[ReneX]

Dan heb je toch een hoop verbeteringen gemist.

En voor een deel is de snelheid van chrome ook de marketing van google.

[MsG]

Als Chrome geen meerwaarde bood waren echt niet zoveel mensen overgestapt. Chrome voelde hier wel degelijk veel sneller.

[R4gnax]

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.

[KirovAir]

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.

[Robtimus]

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.

[MineTurtle]

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)

[roy-t]

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.

[Bosmonster]

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.

[Fireshade]

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.

[iznogood]

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 23 juli 2024 11:54]

[airell]

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

[sfranken]

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.

[fs76]

elke afbeelding in een frame? Bedoel je misschien iets anders?

[alfredkayser]

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 ;-).

[sorted.bits]

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.

[mxcreep]

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 23 juli 2024 11:54]

[Titan_Fox]

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

[R4gnax]

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.

[lezzmeister]

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.

[FabianNL]

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.

[Bosmonster]

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.

[Menesis]

fout van de developers. die moet gewoon width en height meegeven imho.

[aikebah]

Edit: anderen waren me al voor

[Reactie gewijzigd door aikebah op 23 juli 2024 11:54]

[B64]

Nou dat wordt dan einde Firefox voor mij, en ik ben toch al jaaaaren fan. Ik bekijk vrij veel fotografie-gerelateerde websites, dus hier wordt ik niet blij van.

Een jaar of 2-3 geleden heb ik een tijdje Opera geprobeerd, en die had hetzelfde euvel: tekst en opmaakelementen die razendsnel laadden, maar plaatjes duurden veel te lang (en ja: Opera Turbo stond aan). Daar ben ik toen dus ook snel mee gestopt.

[Mitsuko]

Ik denk dat die 5% op de totale tijd niet zo merkbaar is in vergelijking met de 30% gevoelsmatige verbetering. Zeker voor websites die voornamelijk uit plaatjes bestaan zal het weinig uitmaken - de plaatjes krijgen een wat lagere prioriteit, maar als de rest al gecached is maakt dat echt niet uit.

Overigens raad ik aan om eerst de testversie te proberen om te kijken of het echt een verslechtering is - deze verandering moet zich hoe dan ook nog eerst bewijzen

[Reactie gewijzigd door Mitsuko op 23 juli 2024 11:54]

[alfredkayser]

Voordat je overstapt of zelfs maar conclusies trekt, probeer het eerst eens, en maak dan pas een opinie. Veel foto-sites laden tegenwoordig de foto's al later (pas als ze zichtbaar worden), zodat eerst de pagina er wel staat met alle menu's en zo.

[Verwijderd]

Nou dat wordt dan einde Firefox voor mij...

Let dan op dat je ook de Webkit gebaseerde browsers mijdt.

Patrick McManus:
The basic approach here is the same as used by Webkit's ResourceLoadScheduler. So Webkit browsers already do the basic idea (and have validated it).

Een jaar of 2-3 geleden heb ik een tijdje Opera geprobeerd

Misschien is Internet Explorer iets voor je?

[Ook al Bezet]

(en ja: Opera Turbo stond aan).

Turbo maakt het laden van een site alleen sneller als je op een langzame verbinding zit. Als je breedband gebruikt vertraagt het de boel alleen maar omdat de site eerst door Opera's servers geladen moet worden, vervolgens verwerkt wordt en dan, gecomprimeerd, aan jou wordt doorgestuurd.

[Remz-Jay]

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.

[ReneX]

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.

[drdelta]

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 23 juli 2024 11:54]

[ultimasnake]

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 23 juli 2024 11:54]

[ATS]

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.

[911GT2]

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 23 juli 2024 11:54]

[atacama]

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.

[Verwijderd]

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.

[hackerhater]

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

[Maximilian]

Het zou misschien fijn zijn als alle browsers een optie krijgen om een "laad-schil" in te schakelen tijdens het laden van een pagina.

Een beetje het idee van een applicatie die vastloopt onder Windows 7 waar simpelweg in staat "Loading . . . "

Als de pagina dan echt klaar is, komt hij op.

Geen gezeur meer met verspringende pagina's, rustiger lezen en je krijgt pas echt het gevoel dat het snel is als je die "Loading waas" voor 1 of 2 tellen ziet en de pagina is er gewoon.

Deze "ontwikkeling" is eigenlijk een vergroeiing naar Chrome, die doet dat ook.

[Verwijderd]

Fijn met paginas die dynamisch bijgewerkt worden. Die zie je dan nooit meer.

Ik wacht gewoon tot dit ingezet wordt, en ga dan eens kijken wat prettiger werkt. Als het gevoelsmatig beter is winnen we. Zo niet wordt het een andere non-Webkit browser.

[Navi]

Dit is geen goed idee en zal voor enorme laadtijden zorgen.