Article lists are incredibly laggy on mobile Firefox and overall theme performance is very low

[ragibson]

Describe the bug
Scrolling through a list of articles is very laggy and jagged on Firefox. Overall performance of the theme is also slow.

To Reproduce
This appears to occur on pretty much every Blowfish website, including https://blowfish.page/docs/.

EDIT: For example,

• The Blowfish documentation achieves 56/100 on mobile PageSpeed Insights whereas most popular Hugo themes achieve at or near 100%.
• The "Welcome to Blowfish" article hits 35% on mobile and 72% on desktop.

Expected behavior
The page scrolls smoothly and overall performance is improved.

Screenshots
N/A

Desktop (please complete the following information):

• OS: Android
• Browser: Firefox
• Version: 118.1.1 and has persisted for many months beforehand

Hugo & Blowfish versions
The scrolling issue is on most sites I have checked and the issue has persisted for months, so it should affect all recent versions.

Additional context
N/A

[ragibson]

Importantly, this issue does not appear to be present in the upstream Congo.

[LITUATUI]

Seems fine on Linux using the version 118.0.2 (64-bit). Maybe it's an extension you have installed, try opening the page on a private tab.

[ragibson]

I'll edit the issue title back to the original -- this is predominantly a mobile effect

[ragibson]

Here, the Blowfish documentation achieves 56/100 on mobile PageSpeed Insights whereas most popular Hugo themes achieve at or near 100%.

[ragibson]

Actually, even the "Welcome to Blowfish" article hits 35% on mobile and 72% on desktop, so this is likely a device agnostic problem.

[jamesbraza]

A related issue previously observed is use of layoutBackgroundBlur lead to slowness: #907

[nunocoracao]

Any suggestions on what needs to be done?

[ragibson]

You'd probably have to profile the code to see which bits are excessively slow, but the layoutBackgroundBlur listener does appear to edit CSS style on every frame, so that would probably be more low-hanging fruit.

[nunocoracao]

@ragibson For setups with Views/Likes that makes some sense - a list page triggers a "couple" requests to the DB. Need further investigation. Would you be able to help translate this into a set of actions that we need to fix?

[Chow-Ray]

Indeed, I have this kind of problem too. Page scrolling is stuck, but when used on Firefox browser, it is better than edge browser. inPrivate mode is still stuck.

[ragibson]

@ragibson For setups with Views/Likes that makes some sense - a list page triggers a "couple" requests to the DB. Need further investigation. Would you be able to help translate this into a set of actions that we need to fix?

It's almost certainly not a network/DB bottleneck since it's tied to scrolling for the entire lifetime of the page. On a very cursory profile from my phone it seems that Blowfish pages are ~5x more intensive on the renderer than a similar one in Congo for some reason.

[ragibson]

I think it's due to an overzealous use of backdrop-filter in .backdrop-blur (and the -2xl, -sm, etc. variants) on many elements which is repeatedly invalidating a huge amount of the page. This, in turn, requires redrawing most of the site on every single frame of a scrolling event due to the view change. Importantly, this class is used pretty frequently even when layoutBackgroundBlur is disabled.

For example, https://blowfish.page/ requires 200-300 times as many draw calls on every frame of a scroll than other comparable sites.

For now, I've completely disabled those CSS classes on everything except the search widget and the scrolling issues are improved tremendously with effectively zero stutter.

[ragibson]

I think I've fixed the issue in the PR above for the case where the blur features are disabled. It has the same ~200x reduction in draw calls on Firefox in that case.

Otherwise, I found a lot of documentation stating that these blur filters are inherently intensive and should be avoided, especially on mobile devices. Even after the PR, Blowfish uses them very frequently (and on multiple elements) whenever header = "fixed" or "fixed-fill-blur" or layoutBackgroundBlur = true.

[demodeveloperlab]

Use webp images and add
loading="lazy"
to _default/_markup/render-image.html

Observe the difference

[ragibson]

@demodeveloperlab we already established this is unrelated to any network overhead or asset loading and is/was predominantly due to rendering overhead from extraneous CSS rules, but thanks for the suggestion

[nunocoracao]

added @demodeveloperlab suggestion in a commit for something else and @ragibson already provided a bunch of improvements for this closing the issue