zlacker

[parent] [thread] 9 comments
1. otabde+(OP)[view] [source] 2023-07-18 12:40:43
> Chrome still feels snappier

I actually tested this and Firefox is significantly faster in rendering CSS and tables. (Not sure about complex Javascript.)

Chrome's snappiness is mostly UI smoke and mirrors, actual sites load faster for me in Firefox.

replies(4): >>insani+d >>dspill+yb >>solark+4c >>kevinc+Ns
2. insani+d[view] [source] 2023-07-18 12:42:05
>>otabde+(OP)
Maybe FF should take some tips on those UI "smoke and mirrors". What feels faster is what users are going to go off of. For example, a page that fully loads in 1 second vs a page that incrementally loads in 1.5 seconds - the latter may feel faster because the time to start loading is faster.
replies(3): >>causi+q2 >>ndiddy+y9 >>WhereI+kP
◧◩
3. causi+q2[view] [source] [discussion] 2023-07-18 12:55:04
>>insani+d
Not to mention that the things the user wants to see are probably early in the load order and all the worthless garbage is coming in later.
replies(1): >>Electr+hg
◧◩
4. ndiddy+y9[view] [source] [discussion] 2023-07-18 13:30:37
>>insani+d
That makes the user experience worse though. Anyone who's had a webpage layout change while they were trying to interact with it knows how frustrating it is.
replies(1): >>insani+xg
5. dspill+yb[view] [source] 2023-07-18 13:38:25
>>otabde+(OP)
> Chrome's snappiness is mostly UI smoke and mirrors

This can be very effective, which is why optimising complex pages for first contentful draw (perhaps at the expense of overall load speed) can make a huge difference to how your pages/app are perceived.

Back in the dial-up (and early ADSL) days many were convinced that IE was faster because of progress bar trickery: it would actively lie and could inch up to ~85% before the first byte of data had arrived from the server (I forget if it waited for the HTTP request to be sent or if it started edging up immediately upon TCP connection). It still did it right up to the end, though with local connectivity getting faster these days the amount you'll notice it is greatly reduced.

6. solark+4c[view] [source] 2023-07-18 13:40:46
>>otabde+(OP)
Yes, that's important. The funny part about it is that it's probably a lot cheaper than optimizing the engine.
◧◩◪
7. Electr+hg[view] [source] [discussion] 2023-07-18 13:54:41
>>causi+q2
Those SPA-filled days, all I get on those "early load order" pages are blinking blank rectangles and spinners.
◧◩◪
8. insani+xg[view] [source] [discussion] 2023-07-18 13:55:33
>>ndiddy+y9
Sometimes. The big offender here is advertising.
9. kevinc+Ns[view] [source] 2023-07-18 14:35:21
>>otabde+(OP)
Yup. I found that Firefox does incredibly well at long text documents and tables. I remember that Google's internal source code browser would warn you if you tried to open a "large" file (I don't remember what the threshold was). However with Firefox the files always opened fine and things like scrolling performed well. I thought the warning was just a relic of an earlier time. However I realized that my colleagues using Chrome would actually respect this warning and download the file to open it in a text editor. Testing showed that the files would truly grind Chrome to a halt. It seems that Chrome still has a performance edge on highly dynamic content but Firefox does appear to be significantly better at large pages of mostly-static content like long HTML and text documents.
◧◩
10. WhereI+kP[view] [source] [discussion] 2023-07-18 15:51:14
>>insani+d
Pretty much this, the overall feel of Chrome is snappier and the UI/UX is much better

I'm still not a fan of the latest UI revision on Firefox.. Chrome is able to make me forget there is an UI

I remember switching to Chrome because of a new UI update many years ago (performance too)

If Firefox manage to catch up performance wise, I might give it another try

[go to top]