Speculative Loading API

[Leftfield]

Last week, WordPress introduced a performance plugin promising "Near-Instant Load Times." While I won't comment on my personal experience with WordPress (let's just say it hasn't been ideal), or speculate on potential security implications (with which WP is super proud) of this plugin and how it will kill server resources on share hosting accounts, the focus on improved performance is certainly commendable. After all, ProcessWire was built with speed and efficiency in mind.

This brings me to an interesting proposition: the development of a Speculative Loading API module for ProcessWire. My proposition is that this module would allow users to selectively load only the fields they require, further optimizing page load times.

Example, problem and solution: The WordPress plugin reportedly loads the entire page, including Google Analytics code. This triggers a visit registration in Google Analytics, even if the user didn't see the page. Ideally, for better performance and to avoid this kind of problem, only essential elements like body field (with its images) and a few essential (by someone needs) choosable fields would be loaded initially.

[Denis Schultz]

For me, that is optimizing "above the fold content" and delay/lazy loading after that. So the first impression is fast and everything else the user is not seeing is loading in the background or when the user is near to it.

For the fields loading... i use (template-) cache on potential landing page such as the homepage/start page. So I doubt it would benefit performance when (ProcessWire-) fields are selective loaded. Even more when you go the ProCache route. For the user, it is more important what you do via the FrontEnd code with it. How you handle defer/lazy loading and co.

For GoogleAnalytics, here in the EU, you need conformation of the user, before you transfer data to Google. So it does not trigger until the user accept it. So I look that my cookie banner is using CriticalCSS (The css rules in the style tag in the document's head) as also elements where are "above the fold".

Everything else is coming after that and the user don't have to wait for elements to load, they direct can see in the beginning.

PageSpeed/Lighthouse (https://pagespeed.web.dev/) is testing this and give indication, where you can optimize.

[Leftfield]

Hi @Denis Schultz, thanks for your input. I'm from Europe too and very familiar with GDPR law.

Side story: On the landing page, users first need to accept cookies. Having them accept a GDPR-compliant agreement there eliminates the need to accept it twice.

Main story: Loading certain fields before the user clicks can improve page load speed, regardless of caching. However, module should load the parts of cached version in this case. This is a whole new philosophy.

[Denis Schultz]

20 minutes ago, Leftfield said:

Side story: On the landing page, users first need to accept cookies. Having them accept a GDPR-compliant agreement there eliminates the need to accept it twice.

Yes that is what i mean.

20 minutes ago, Leftfield said:

Main story: Loading certain fields before the user clicks can improve page load speed, regardless of caching. However, module should load the parts of cached version in this case. This is a whole new philosophy.

But the Analytic code is not loaded until the user is accepting the cookie. In this time, the Cookie Banner is loaded without the Google code and the "above the fold" content is also loaded without it. The Google code should be there 2-5 rows (w/o compression) as Plain-Text, but not as processed code from the browser. So there was no "loading".

When the GoogleAnalytic Code is written in the FrontEnd files, there is also no ProcessWire field, who was/wasn't loaded it. So no database interaction, no server process time used for it. And not process by the browser until the cookie banner give the signal. If the GoogleAnalytic Code comes completely from a module and is not self wrote in the source code, then yes, the loading of the site trigger the module to load the GoogleAnalytic code (not the trigger itself), but the loading "delay" can be prevented with the template-cache again.

The "loading" part are 5(?) rows of plain-text, what the browser is not interacted with, until the cookie banner say so.

When you use PageSpeed, 90% of the performance problems are bad compressed image, not lazy loading (what is more or less what you describe!) and using of wrong technics (like not optimized above the fold content).

[wbmnfktr]

I am not sure I really understand the goal of that module idea.

What fields are you talking about? My pages only load the necessary content anyway. There is no overhead or something.

🤔

 

[Leftfield]

@Denis SchultzWhile we can't control the exact moment a user accepts cookies, it has a minimal impact on meaningful paint. If a user accepts quickly, the script might load from another page since it's typically placed in the <head> and you know this so IDK why we are delving.

@wbmnfktr While IDK the exact percentage, around 35% of all websites are built on WordPress and tend to be slow due to overloaded scripts and CSS files. Google previously (long time ago) de-emphasized speed as a direct ranking factor because of that. However, considering the potential impact of improved user experience with faster loading times, it's possible Google might develop ways to measure and potentially re-evaluate speed (Speculative Loading as a solution) in the future.

[wbmnfktr]

That's INP then. I guess. New performance metric.

https://web.dev/articles/inp

And you can already check that here:

https://page-speed.dev/