Comment by lucgommans | Hacker News Reader

Comment by lucgommans | Hacker News Reader

Parent Full thread

Speaking of Firefox performance, does anyone know what introduces pauses in page loading? A page of 900 bytes HTML, with 2 KB of CSS and a 33 KB background image, takes 918 ms to load. Only a third of that is network stuff (DNS resolving, TLS setup, etc.; adding up the 'duration' values). Screenshot of page with loading graph: https://i.snipboard.io/AcqWb4.jpg Notice the huge gap between HTML loaded and starting to load CSS, for example, where it does not appear to be doing or waiting for anything.

Seeing the title and initially glancing at the drawing where it says "reading XUL.dll" I thought they addressed this, as I noticed this problem a while ago and I figured it was something about this multi-process browser experience having to load everything anew or constantly do inter-process communication, but the post is actually about various other performance issues. Does anyone know what's up with this one?

Just to be clear, I'm not saying Firefox is slower than browser X or anything. I just happen to notice this in Firefox because I'm a Firefox user.

See if disabling the setting "Uncloak canonical names" in uBO helps.

There are similar loading delay issues as you describe when uBO has to resolve DNS names if you are behind a proxy.

Thank you a lot! I just tested it on my Android phone and finally I don't have to wait seconds before I see any page content. I was really puzzled what caused this problem for a while.

What does this do?

See here in the uBlock Origin wiki: https://github.com/gorhill/uBlock/wiki/Dashboard:-Settings#u...

Which in turn, links to this for background information https://www.theregister.com/2021/02/24/dns_cname_tracking/

Oh wow, this is more than a performance problem, this is a mitigation for a data security problem that only got introduced because trackers try to work around per-domain cookie isolation.

Use the new https://profiler.firefox.com/ .

It can literally tell you what can go wrong inside the whole Firefox architecture (Includes network, webtension, firefox internals, page scripts and so on).

My personal guess about it is about extensions, did you retry it again in safe mode?

And if you suspect it is a issue in firefox itself, you can upload the profile and open a bug at https://bugzilla.mozilla.org/home , so someone more familiar with Firefox can investigate it.

Wow, good stuff. But why is such a fantastic tool hidden from the default developer toolbar?

Probably because they want to catch all edge case before it totally replace the current profiler?

Try it in safe mode with your plugins disabled, it will at least show you if it is vanilla behaviour

Good point, should have thought of that. I have a bunch of things open where I don't want to reload the page so restarting in safe mode is a bit tricky now, but unless someone happens to know the exact answer I can try this on the weekend and perhaps narrow it down, thanks :)

Some issues are caused by the current profile, so it is a good idea to use a temporary profile for testing weird bugs. Here is a script to automatically create and clean up a temporary Firefox profile:

  $ head -n-0 ~/bin/firefox-tmp-profile 
  #!/bin/sh
  # Workaround for missing feature:
  # https://bugzilla.mozilla.org/show_bug.cgi?id=1604376
  set -e
  dir="$(mktemp --tmpdir --directory firefox-tmp-profile-XXXXXXXX)"
  cleanup () { rm --recursive --force "$dir"; }
  trap cleanup EXIT
  firefox -no-remote -profile "$dir" "$@" || true

about:processes is also a decent way to pinpoint the most impactful extension.

Edit: my bad, I meant to say about:performance.

The really interesting part is the huge gap between loading the CSS and starting the load of "patternbg.png", which is linked to by the CSS. When I load https://lgms.nl/ locally, I see the CSS finish loading at the 397ms mark in the overall pageload and the image load get queues at the 411ms mark, which is more like what I expected.

My best guess is that there is some extension involved that takes a long time to process attempted fetches and decide whether to allow them or not.... It would be interesting if the timeline included "we are ready to go fetch this and waiting on extensions to make up their mind" bits.

I have no idea what causes it for you, but I see this : https://i.imgur.com/KEWYqIW.png

(ff 91.0)

Which OS is that on? Mine was on Linux, perhaps that makes a difference. Also I have a rather crappy cpu (i5-8250U); for you I still see the gaps even if they're smaller (both in absolute terms but if I'm seeing it correctly also in proportion to network loading time), so perhaps a faster cpu helps as well.

I have FF 91 on Linux and mine takes ~200ms: https://i.imgur.com/EzdLYXb.jpg

This is with uBlock, HTTPs Everywhere, "I don't care about Cookies", Greasemonkey, etc etc

I have a 1700x, so a bit faster than your 8250U, but released the same year.

I am seeing similar bad performance on Chrome on my fully loaded enterprise laptop.

I think it's that background pattern and Firefox might be lying to you, or at least in Chrome the pattern is what eats up all the rendering time.

Have you tried using the profiler? It will give you a lot of detail. It's under the "performance" tab on the dev tools.

Reply on news.ycombinator.com