Further to the above, my curiosity while investigating and writing this up led me to both the root of the problem, and the solution.
I was certain this hasn’t always been the case, which led me to look at issue 1 and check the results. I was initially relieved but confused to discover this doesn’t happen on this page, for example: https://branch.climateaction.tech/issues/issue-1/
With reference to the above numbers, for this page we get:
Low: 931.87 kB transferred
Moderate: 581.65 kB transferred
High: 19.01 kB transferred
Damn dirty PNGs are the cause of the much bigger numbers relatively, but look how low the transfer is for high carbon intensity. That’s what we want to see!
So, what’s the difference with these pages? Well, the cover image on the issue 1 page has the loading="lazy" attribute, whereas the cover image on the homepage doesn’t. And this seems to cause the browser to hastily start loading the image before any of our CSS/JS has a chance to do anything.
But why does one image have a loading="lazy" attribute while the other doesn’t? Well, the “issue” pages are generated in a "sort of" programmatic way. The cover image isn't inserted directly in the editor, but is rather uploaded as a separate entity, with this file providing the layout.
So, what’s going on? Well, when lazy loading of images was introduced in WordPress 5.5, the method used added the loading="lazy" attribute to all images which had widths and heights defined. This would have been the default behaviour when we launched Branch. However, it has subsequently become a best practice for performance to not add the loading="lazy" attribute to images that are likely to appear “above the fold”. The core team duly enhanced the default behaviour in WordPress 5.9, whereby the first image in the main body of content no longer gets the loading="lazy" attribute. This is good news for most websites, but bad news for Branch!
So, what can we do about it? Well, the good news is that in the time-honoured way, the core team added a new filter that allows one to modify this behaviour. This PR uses this filter to fix the problem.
The performance loss for loading all images with loading="lazy" is only negligible anyway, and on Branch we’d only notice this slight hit during periods of low-carbon intensity. At other intensities, the improvement we experience here can be pretty huge. E.g. most of our pages should only need a handful of kB to load during periods of high-carbon intensity.
Further to the above, my curiosity while investigating and writing this up led me to both the root of the problem, and the solution.
I was certain this hasn’t always been the case, which led me to look at issue 1 and check the results. I was initially relieved but confused to discover this doesn’t happen on this page, for example: https://branch.climateaction.tech/issues/issue-1/
With reference to the above numbers, for this page we get:
Damn dirty PNGs are the cause of the much bigger numbers relatively, but look how low the transfer is for high carbon intensity. That’s what we want to see!
So, what’s the difference with these pages? Well, the cover image on the issue 1 page has the
loading="lazy"attribute, whereas the cover image on the homepage doesn’t. And this seems to cause the browser to hastily start loading the image before any of our CSS/JS has a chance to do anything.But why does one image have a
loading="lazy"attribute while the other doesn’t? Well, the “issue” pages are generated in a "sort of" programmatic way. The cover image isn't inserted directly in the editor, but is rather uploaded as a separate entity, with this file providing the layout.So, what’s going on? Well, when lazy loading of images was introduced in WordPress 5.5, the method used added the
loading="lazy"attribute to all images which had widths and heights defined. This would have been the default behaviour when we launched Branch. However, it has subsequently become a best practice for performance to not add theloading="lazy"attribute to images that are likely to appear “above the fold”. The core team duly enhanced the default behaviour in WordPress 5.9, whereby the first image in the main body of content no longer gets theloading="lazy"attribute. This is good news for most websites, but bad news for Branch!So, what can we do about it? Well, the good news is that in the time-honoured way, the core team added a new filter that allows one to modify this behaviour. This PR uses this filter to fix the problem.
The performance loss for loading all images with
loading="lazy"is only negligible anyway, and on Branch we’d only notice this slight hit during periods of low-carbon intensity. At other intensities, the improvement we experience here can be pretty huge. E.g. most of our pages should only need a handful of kB to load during periods of high-carbon intensity.Fixes #37