Hello! How are y'all doing? Hope you're fine! I was watching the [video from The Linux Experiment](https://www.youtube.com/watch?v=VjQQhuVS26g) talking about GNOME Web and such and decided to investigate what is the reason for the mentioned slowdown on [ProtonDB](https://www.protondb.com/). Upon inspection, I realized that a style tag was responsible for all the slowdown in the page. The problem was that it compressed a lot of hidden CSS properties that were added by **styled components** added probably through React. The tag is generally empty, because React adds the styled components dynamically using JS, which makes it way harder to debug: ```html <style data-styled="active" data-styled-version="5.3.3"></style> ``` That made the inspection a little harder, but upon manual inspection, I could find what seems to be the root of the slowdown. It seems that one of the hidden properties of this tag, the **background-blend-mode** property present in the 93th hidden CSS Ruleset of this tag, to be more specific, when faced with the value "luminosity", just slows down the whole page. I tried making a simple test on this property on another page, and it didn't cause any slowdown, so it probably has to do with the specific dynamics of the ProtonDB page, but it could be related to some major issue I don't know about. The issue seems to not be present on Safari, so it seems to be a GNOME Web specific issue we're dealing with here. I opened an issue to the [GNOME Web's Gitlab Issue Tracker](https://gitlab.gnome.org/GNOME/epiphany/-/issues/1669), but they sent me here instead. According to them, it seems to be a WebkitGTK issue, or even a WPE (Webkit Port to Embeded) issue as well. Both me and a maintainer of GNOME Web tested the issue with both Accelerated Compositing turned on and off and the issue was present on both cases, so it seems to not be related to that. Steps to reproduce the bug: 1. Open the website <https://www.protondb.com/> with GNOME Web. 1. Try to scroll the website. **How to fix the lag issue:** 1. Run the command below in the JS console. It will get the styled-component mess created by React and will get all the hidden CSS rules within. Then it will get the 93th rule (index 92), get its internal style (which is composed of 8 elements), then it will get the background-blend-mode property (which is set to *'luminosity'* and set it to nothing, which fix the lag issue). ```js Array.from(document.querySelector('style[data-styled]').sheet.cssRules)[92].style.backgroundBlendMode = ''; // This fixes the slowdown ``` **Longer version** ```js const styledComponent = document.querySelector('style[data-styled]'); // Gets the styledComponent const cssRules = Array.from(styledComponent.sheet.cssRules); // Gets the hidden cssRules list const style = cssRules[92].style; // Gets the specific rule we need and extracts a stylesheet object console.log(style.backgroundBlendMode); // 'luminosity' style.backgroundBlendMode = ''; // This fixes the slowdown console.log(style.backgroundBlendMode); // '<empty string>' ``` I know opening issues for specific webpages is not ideal, but it might be a shared problem among other pages which might use the same CSS properties or have similar dynamics, and it is a quite popular website too, but if too specific, I understand if the issue gets closed, but I think it is an opportunity for us all to get an even better version of GNOME Web and WebkitGTK in general. Tested with **GNOME Web 41.3 Flatpak** (WebkitGTK 2.34.2) from Flathub. More info can be found at the original discussion in the [original issue at GNOME Web's Gitlab](https://gitlab.gnome.org/GNOME/epiphany/-/issues/1669).
I'm interested in your findings. The performance issues of Epiphany on some website hurt me for a long time - and I can confirm that hardware acceleration helps a little but it is not a fix: Sadly the line JS code doesn't work for me. Is it possibly that the cssRules are currently '0'?
(In reply to Peter from comment #1) > I'm interested in your findings. The performance issues of Epiphany on some > website hurt me for a long time - and I can confirm that hardware > acceleration helps a little but it is not a fix: > > Sadly the line JS code doesn't work for me. Is it possibly that the cssRules > are currently '0'? They changed the <style data-styled="active"> to be separated into two elements: <style data-styled="active"> <style data-styled="active" data-styled-version="5.3.3"></style> Not only that, but the index 92 is now changed to the index 143. (I show a better method to finding the correct index in the end of this message). Therefore, the current JS solution should now look like this: ```js Array.from(document.querySelector('style[data-styled][data-styled-version]').sheet.cssRules)[143].style.backgroundBlendMode = ''; // New fix to the slowdown. ``` Some more findings: > The element that causes all the trouble is the div with the class fmFeyz ```js const troublemaker = document.querySelector('.fmFeyz'); ``` > We can keep the background-blend-mode if we do not set the background-attachment to fixed. This might imply that the slowdown might be related to an image that shares those two properties together. ```css .some-class { background-image: url("./some-image.png"); background-blend-mode: luminosity; background-attachment: fixed; } ``` > We can target the CSS class directly with the JS code if we select the correct CSS rule by the selectorText property. That is a better solution than pointing directly to the cssRule index, which can change often. ```js Array.from(document.querySelector('style[data-styled][data-styled-version]').sheet.cssRules).find(css_rule => css_rule.selectorText === '.fmFeyz').style.backgroundBlendMode = ''; // Better solution ```
ProtonDB doesn't seem to cause performance issues for some time now. It might be worth retesting.