The new version 1.1.0 of IndexReloaded has new features that further improve the performance of WordPress websites.
Many websites use CSS or JavaScript that is on external servers.
Pages that use such resources cannot fully benefit from chaining JS and CSS.
IndexReloaded can now store external CSS and JS locally and include it in the process of creating concatenated JavaScript, CSS and CCSS (Critical CSS).
The result is faster website loading times.
The feature can be activated or deactivated in the backend under ‘Settings->Rules for CSS and JS processing”.
The time in days until the external files are checked again can also be set there.
In the backend under Overview you can see whether and how many external CSS and JS files are available in the local cache.
In this sense, the associated ‘migration’ of ‘external data’ leads to a clear improvement in the performance of local systems. 😀
There is also a new ‘Reveal Cache’ button in the Overview panel, which displays a list of pages cached in the ObjectCache.
A distinction is made between ‘Cached pages used by Indexreloaded’ and ‘Pages prepared for CCSS’.
The former are fully cached pages for which CCSS is created.
These can be specifically removed from the cache using the -icon.
‘Pages prepared for CCSS’ are pages for which only the server-generated HTML model is available.
The HTML model created by the client has not yet been sent to the server for processing (and creation of CCSS).
Typically, these cache entries are created by visits from search engines such as Google or Bing.
These do not use JavaScript and therefore do not send the client-generated HTML back to the server.
For hidden, i.e. cached things, ‘trust is good, control is better’. With ‘Reveal cached pages’, we are addressing this more effectively than before.
There is now also a practical link back to the overview in the backend, in the settings at the top left of the page.
By default, the client-generated HTML is sent to the server 2 seconds after the web page has been fully loaded.
Anyone using the JavaScript library ‘ko’ must wait longer than 2 seconds until the web page contains all the HTML elements created by ‘ko’.
Perhaps there are other ‘Slowmotion-Solutions’ – we assume so – but so far we only know ‘ko’ – it is used by the plugin ‘Wallets’.
For ‘ko’ we set the delay in IndexReloaded 1.1.0 to 6 seconds, which is empirically sufficient to obtain a complete version of the final website from the client and thus form valid CCSS.
We meanwhile see CCSS as a dynamic and sequentially structured result that does not have to be conclusively sufficient after the initial creation of CCSS.
Let’s take the example of a ‘shopping basket’ page in a web shop:
The ‘shopping basket’ can be empty or full.
If the first CCSS is created from an ‘empty shopping basket’, it will work as long as the shopping basket is empty.
But if a user buys products and then looks at the shopping basket, this CCSS will not cover the additional HTML of the webpage.
IndexReloaded 1.1.0 is now prepared for this situation and will regenerate CCSS in such a situation.
With CCSS, ‘the path is the destination’.
This not only applies to the DOM path, it applies ‘overall’
2 bugs removed
It was during this adaptation that we noticed that HTML which is present in scripts of type ‘text/html’ in the webpage, unlike HTML in scripts of type ‘text/template’, was not included in the HTML model for generating CCSS.
This bug was fixed in 1.1.0.
Apparently, inline scripts that are noted directly after externally hosted CSS or JS files in the page source code were not included in the processing during concatenation.
This has also been corrected in version 1.1.0.
CDATA is dead, long live the Nonce
We came across this when we replaced the CDATA exclusion criterion with the ‘nonce’ exclusion criterion for processing inline scripts.
With the exclusion of CDATA, not every script with nonces was recorded – nor are CDATA entries marked as such in the page source code on every website.
The problem associated with CDATA are values that change often or every time and can therefore lead to a flood of generated JS files.
Typically, these are recognisable as ‘nonce’ in inline JavaScript.
However, the exception of the ‘WordfenceTestMonBot’ value in the inline JS of the ‘WordFence’ plugin shows that the rule for ‘nonce’ cannot be considered universally valid.
If you see an excessive number of JS files in the IndexReloaded backend, under Overview, you should identify the ‘inline JS villain’ and list it in the IndexReloaded settings under Excludes.
This identification is best done by comparing JS files of identical or almost identical size.
The benefit of JavaScript file links is that these files can be used over a longer period of time, i.e. several days, and across several pages
Automatically generated <link rel=”preload”-entries for jQuery, generated CSS and JS also help to improve performance in version 1.1.0.
This change is not entirely insignificant, as it means that even with the free version of IndexReloaded 1.1.0, PageSpeed Insights no longer complains about ‘render-blocking elements’.
For delayed loading of JavaScript, version 1.1.0 now also has the option of loading inline JS with a delay.
This is done by converting the inline JS into base64-encoded text, which is then loaded with a delay as src (source) (with defer in the HTML script tag).
However, if an inline JS is excluded via the Excludes list (and not via a nonce property), the original inline JS is left as it is.
It should be noted that servers that use the ‘Header set Content-Security-Policy’ directive in the Apache configuration must contain a data entry for data in addition to the corresponding value for ‘script-src’, for example: ‘data: data;’
With all these adjustments, the list of recommended excludes has been noticeably reduced, making it easier to install IndexReloaded for the first time.