Tools like Page Speed Insights (PSI) are offered solely for testing and debugging to website developers. The PSI is not used to rank the Page Experience. To calculate Core Web Vitals for your site, Google collects field data from your site visitors’ Chrome browsers and sends it to Google servers as a CrUX report. PSI can be easily cheated by prefetching JavaScript and CSS files and not using them immediately. PSI ignores such prefetched resources. Many people do this, but most fail a trivial test like a local Lighthouse performed through your Chrome browser (go Incognito, use Inspect – Lighthouse).
Nonetheless, NitroPack already has a lot to answer for. NitroPack hides problems with the Cumulative Layout Shift (CLS) metric by cheating PSI. The field tools pick up on this. As a result, NitroPack own website failed to pass Core Web Vitals because CLS scores were not satisfactory. The results of NitroPack are already improved, but NitroPack could have corrected its score earlier if the CLS metrics in PSI were not manipulated. NitroPack team should sincerely apologise to all its users who might be currently facing the same problem.
There is concern among NitroPack users about the perceived drop in traffic to their sites as measured by Google Analytics. NitroPack has decided to remove a delay in evaluating and executing all JavaScript related to Google Analytics and Remarketing or Retargeting to avoid disputes. As a result, the LCP time for most websites using NitroPack is now 3 seconds on mobile devices – which is slower than the 2.5-second limit set by Core Web Vitals. Ironically, most professional users will not hesitate to delay Google Analytics or serve it locally with plugins such as Flying Analytics, CAOS, WP Rocket, or Perfmatters for better Core Web Vitals’s score.
Many other caching plugin developers were dismayed by NitroPack’s aggressive cheating strategies. However, since Google had so far failed to penalise NitroPack users, other companies decided to implement similar features.
NitroPack-enabled websites download all their assets from nitrocdn.com. If you use NitroPack, you’re not only cheating Google, you’re screaming about it to the rest of the world. Do you think it’s crucial to be humble and remain discreet when cheating? If you can’t be good, be careful!
Our article cites several comments from Google Search Console Community experts. It isn’t very comfortable to point out that they have failed to convey a simple message. The CrUX reports do not include critical metrics such as Speed Index, Time to Interactive, and Total Blocking Time, so users should ignore their aggregated PSI score. The CrUX reports an entirely new value – the First Input Delay (FID). With this new FID value, Google is trying to detect delays between the time your visitor activates a menu item and the time your web page responds to it. If your users will explore the content of a page before going to another page on your site – it gives you plenty of time to run any delayed JS code on the first user interaction like a scrolling event.
CrUX does not collect enough data from end users to include the First Input Delay (FID) value in Google’s field report for most medium traffic sites with less than 20,000 monthly visitors. FID is particularly susceptible to missing because, unlike other Core Web Vitals, it is based on user interaction. All page views result in an FCP, LCP or CLS, but not all result in user interaction. It depends on the design of your website and your target audience. Chrome does not collect FID values when most visitors leave your site without exploring different pages.
Regardless of whether the CrUX field report on your website is missing FID data, improving LCP time should be your primary focus. A few seconds off your LCP score in the mobile test is all you need to pass the Core Web Vitals assessment.
Using expensive NitroPack services to reduce the LCP time is a sign of pure incompetence of your web design agency. Run away from them as fast as you can! There are so many free options to achive the same. You should seriously consider a free PhastPress plugin. Make sure it does not cause artefacts on your pages by installing and trying it in a staging version first. In theory, PhasePress should do its job better than the more popular Autoptimize plugin used on 1 million websites, but you can try delaying render-blocking resources using Autoptimize.
Using the WP Rocket caching plugin, users can already select specific JS files for delayed execution. This feature is opt-in. Meaning that only the scripts that the users have selected will be delayed. An option similar to this will be added in the next release of LiteSpeed Cache. More than 2.5 million websites use the free LSCache plugin. Over 1.5 million websites use the premium WP Rocket plugin. Instead of being persuaded by the cheating options offered by the NitroPack, you might do better long-term using the more effective options offered by some of the most reliable and popular page caching plugins.
The objective of this article is to provide you with the most recent information on how web page loading acceleration technologies can help you keep your website as fast and as efficient as possible. By reading it, you will learn more valuable suggestions about how to improve Core Web Vitals.
While it should be possible to have fully automated caching solutions to help users with zero knowledge of speed optimisation achieve a significant improvement in the page loading speed, it is not practical to outperform a diligent user. It is not forever; people are not better than Machine Learning for certain tasks.
Nothing prevents the Machine Learning to move a dial forward for fine-tuning Caching plugins settings, but this is not what is happening under the hood at NitroPack. It is something entirely different and dodgy.
So, how NitroPack works? NitroPack developers have found a much easier way to impress their potential users. They have discovered a holy grail of cheating all major Page Metric Test systems. It turns out that there is a simple way of not including the entire process of evaluating and parsing CSS and JavaScript files when the Page Metric Tools measure your website performance.
It is quite an understatement – currently, all Page Metric Test Tools don’t report the load caused by bloated JavaScript and CSS if served with the HTML files created with the NitroPack plugin.
According to our preliminary understanding, JavaScript files and CSS files are pre-fetched by the NitroPack plugin on your local browser. While CSS files are processed immediately in the browser, all JavaScript files’ evaluation is further delayed if no mouse movement is detected in the browser window. The rendering in the Google PageSpeed Insights lab test and GTMetrix is based entirely on the inline CSS and JS in the HTML file without considering using additional CSS and JS loaded on the page.
The process of complete parsing of JavaScript in your browser for this specific website is taking over six (!) seconds on the desktop (!). The correct time can be measured only by moving the mouse in the browser window when the website is loading. Otherwise, the loading, evaluation, and parsing process will stall and resume again when you start moving the mouse. Of course, it will result in a much longer full processing time in that case. The same website would have fully finished the JavaScript parsing in less than two seconds on the desktop before the NitroPack plugin installation.
A trick from the NitroPack plugin entirely excludes the time for processing CSS and JS from the measurements undertaken by Google PageSpeed Insights or GTMetrix. The solution from NitroPack to load JS and CSS in a separate thread was probably a stroke of genius to hide these files from the Page Metric Test Tools’ existing algorithms. The reported boost is the same as achieved by WebWhim when optimising JavaScript performance using legitimate methods. The difference in evaluating data by the Page Metric Test Tools vs evaluating the data by the live visitor’s browser helps NitroPack’s users to trick Google to report the Time to Interactive and Speed Index improvements. Technically speaking, NitroPack websites never become interactive in Page Metric Tools because all interactivity is derived from JavaScript and CSS execution.
Most JS generated in WordPress by the page builder tools like Elementor relies on jQuery library and is not functional without jquery.min.js file loaded, evaluated, and parsed on NitroPack driven websites. Kadence Theme and Kadence Blocks are some of the best examples of WordPress development tools used for providing web pages with plain JavaScript without relying on jQuery. Many designers report a mobile page speed score above 90 using Kadence Blocks without having to cheat on Page Speed tools. As they put it: “No jQuery, No Font Awesome, No JS jank = Fast Sites!”
Since publishing the original text, we have received a reply from NitroPack:
It sounds like a great story from the start-up developing a top-notch technology. Before we begin our analysis of related issues, we would like to point out our concern about the slippery slope towards adopting cheating strategies that some caching plugin developers have taken. We believe these companies are building something more professional than simply adopting the same scam strategy as NitroPack. But let us return to the concept of lazy loading of assets and provide a NitroPack plugin review.
LiteSpeed Cache works in a similar way to Varnish. Caching is implemented at the server level. Consequently, LiteSpeed can cache dynamic content that is not limited to PHP pages. Unlike Varnish, LiteSpeed has integrated its Cache Engine directly into its web server, so no reverse proxy is required. This results in higher efficiency for static content.
LiteSpeed can cache pages in a public cache, a private cache, or leave a page uncached. Public caching is often used by simple websites that cache the same page for every visitor. If a user can see a particular version of a page multiple times as a static page, that page is cached in the private cache. The shopping cart is a classic example of data that should be privately cached. If the response changes each time the page is requested (and therefore cannot be provided as a static page to anyone ), the page is not cached.
ESI (Edge Side Includes) markup allows dynamic pages to be managed by combining public and private content on a page. Typically, you start with a public page and then add “punched holes” for private or non-cached content. Each element of the page can be cached separately, in a public cache, a private cache, or not cached at all.
With ESI, you cache most of the page publicly and add dynamically generated specific content that changes each time the page loads. When many users access the same customised page, most of the HTML, inline scripts, images, etc. remain static.
An example of this would be a shopping cart widget on a shopping site. While the content of the widget needs to be cached privately because it differs from customer to customer, the rest of the shopping page is the same for everyone. You would cache the page publicly while caching the widget privately with ESI. Mixed content would be reassembled and delivered together. With ESI, LiteSpeed Cache Engine is able to handle all dynamic web pages from the cache without any intervention from the backend servers. This way you can serve more eCommerce visitors with the same hosting plan without increasing the usage of CPU.
The loading of hybrid dynamic ESI pages has been significantly improved recently. The latest version of LiteSpeed Cache adds Guest Mode for WordPress. The site loads quickly on a user’s first visit to improve the Core Web Vitals Score. With Guest Mode, you can defer decision making for user-specific content and instantly serve a default cached version. This is the first visit and there are no caching variants or ESI. You do not have to worry about whether the visitor is logged in or not.
The eCommerce page loads faster because there is no ESI processing on the server. Basically, the cached “public” page is displayed. During the HTML loading process, an Ajax call is made. Any factors that were ignored are processed at this point, and the “correct” version of the page is loaded with ESI for that user.
The LiteSpeed Cache plugin is designed to understand app rules and implement public, private, and ESI caching as needed. Most LiteSpeed hosting providers automatically enable ESI on their servers.
The ability of LiteSpeed Web Server Enterprise to fully automate ESI integration with WooCommerce is one of their advantages. The WooCommerce plugin specifies which parts of the page are suitable for processing ESI markup, and LiteSpeed considers this when generating the page. Most WordPress caching plugins do not include ESI. With LiteSpeed, you get advanced ESI caching for free, making it the ideal platform for hosting WooCommerce.
ESI is a markup language extension designed to be inserted into HTML to tell a CDN how to combine static and dynamic content. LS Cache Engine does heavy lifting on your server isnstead of CDN. With other advanced caching plugins like WP Rocket, ESI must be implemented in the CDN. To use Cloudflare CDN and ESI without LS Cache, it is best to have a web host that supports Railgun. Railgun compresses requests received from a web server using the delta method – the Railgun listener only sends the dynamic difference if ESI is enabled on the page. The CDN caches the public part of the page and retrieves the rest from the Edge-Side-Include destination. With Cloudflare Workers, you can combine both the static and dynamic parts of the web page. Your software developer will need to create the custom logic within the Edge using Workers.
Be aware that it is not yet possible to run Cloudflare Railgun on RedHat 8, CentOS 8, AlamLinux 8, or CloudLinux 8 as Cloudflare has not updated its software. As a result, many providers offering Railgun are unable to use it. This story may sound more complicated than switching to LiteSpeed Web Host, and you are not alone!
Let us interchange such an object as “JS file” with an “image” object and reflect what is going on with postponing all JS execution. NitroPack approach is similar to pioneering the concept of preloading every single “image” used on the page but showing “images” only after the first user interaction. Such an approach has no connection with the Lazy Loading concept, which was developed to allow the browser to load and show without any delay all “images” which are visible (“used”) without scrolling. The rest of the “images” are lazy-loaded on scrolling. NitroPack SEO improvements are imaginary, so don’t be surprised in receiving reduced traffic to your website after installing it on your WordPress website.
PhastPress integrates stylesheets into the HTML file during asset preparation before caching. PhastPress removes CSS that uses class selectors that are not present on the page. This step removes most of the CSS that is not needed so that the inline stylesheet does not become too large.
The remaining stylesheets will block rendering, so they will not load with the HTML immediately. The HTML code of the page in combination with the inline CSS is sufficient to allow initial rendering without external resources. Certain elements that require JavaScript to render will be missed at this stage.
The external stylesheets are downloaded and injected into the document after the “DOM is ready” event. JavaScript may well depend on rules that were not included in inline CSS, so the original stylesheets must be loaded and parsed first. Some missing images and fonts are loaded in parallel with the external stylesheets. Parsing stylesheets do not slow down the rendering process.
After the stylesheets are parsed, all the JavaScript is loaded at once, and the scripts are executed. When JavaScript is loaded, the LCP event is usually already fired. Thus parsing and evaluating JavaScript does not overlap with the rendering process. You may observe an unusual change in content at this moment. It can only occur when JavaScript is used to add dynamic content or change some classes.
By using the PhastPress plugin, it should be possible to reduce the LCP time. With the old PageSpeed Insights, which scored websites differently, PhastPress had a much better lab performance score. The new PageSpeed Insights does not care when JavaScripts are running. However, your CrUX report still focuses mainly on LCP metrics. So the user who avoids overlap between JavaScript parsing and page rendering will be rewarded with a better Page Experience score.
The PhastPress plugin is compatible with most caching plugins like LiteSpeed or WP Rocket. You should disable at least JS optimization in various plugins like LiteSpeed when using PhastPress. To identify possible artefacts caused by the installation of PhastPress, you can try to run initial tests in the staging version.
Optimise images, CSS, and HTML with caching plugins like LiteSpeed Cache or WP Rocket. Assign PhastPress the task of delivering JavaScript and monitor the LCP values recorded by the PSI lab test. Next, you could try using PhastPress for all other optimisation tasks and compare the LCP values again. You may see little reason to use PhastPress for anything other than JavaScript optimisation. It reflects a high level of optimisation of your asset delivery provided by your existing caching plugins.
Compared to the PhastPress plugin, WP Meteor adds a few extra seconds before JavaScript is executed. It waits for the onLoad event and therefore can mislead the PSI Time to Interactive metrics in lab testing. For real visitors to your site, the difference between PhastPress and WP Meteor is minimal. Both plugins eliminate overlap between JavaScript parsing and page rendering. JavaScript execution in PhastPress will finish a few seconds earlier than WP Meteor. However, WP Meteor will score higher in the lab PSI test by successfully cheating the measurement algorithm!
WP Meteor can also be used in addition to WP Rocket and almost any other caching plugin but is not compatible with NitroPack. The developer has provided the ability to exclude scripts added to the list from “optimisation”. The developer of WP Meteor should strive to provide a similar user interface to that of the Asset CleanUp plugin. That will allow granular control over the various JavaScript postpone modes (defer, postpone by 2 seconds, or postpone until the first user interaction) per page and asset on the page. That will create a flexible adjustment for the JavaScript asset loading and execution patterns unique to each website. Therefore, such approach does not break the visual aspects of the site above the fold or does not compromise its menu functionality.
We recommend switching to WP Meteor until Google changes its algorithms if you are determined to cheat the PSI score. Visitors to sites optimised with the NitroPack plugin load all assets through nitrocdn.com. Please be aware that by using NitroPack, you are not only cheating Google, but also shouting to the rest of the world about it. Do you agree that it’s important to maintain some level of humility and be discreet with your cheating?
We agree with Ivailo Hristov. If NitroPack tone down its marketing emphasise of the “Ludicrous” optimisation mode, which we consider as an industrial scale cheating of Google speed measurement tools, it will showcase the same functionality as the rest of the caching plugins listed above. NitroPack will lose its unique selling proposition, however, as it will have to compete with an entirely free solution such as LiteSpeed Cache with integrated QUIC.cloud CDN, especially if this is further combined with free Flying Scripts or WP Meteor plugin for delaying non-critical JavaScript execution.
We, as users, will benefit if the Elementor team will catch up with this development by providing a curated list of JS files generated by WordPress, Elementor, and Elementor Pro, which can be safely included in the postponed JS group. Elementor is trying to find a reasonable approach to reducing JS load on the web pages. Unfortunately, up to now, their attempts are counterproductive and lead to reduced page load speed performance in the Page Metric Test tools. Elementor came with the idea of loading and executing specific JS files dynamically – only if needed by other deferred JS files.
The current embodiment is crashing page loading speed metric on mobile devices. It introduces unwanted delays for loading extra files very late in the waterfall timeline when almost everything else is parsed. Now the browser should further separately evaluate and parse these new JS files. Google PageSpeed Insights observes extended JS processing time and gives a penalty in the form of much longer Time to Interactive, Speed Index, and Largest Contentful Paint metrics. The situation is, ironically, the reverse of the NitroPack treatment. Elementor is diligent but is punished by Google algorithms. NitroPack plugin users cheating but are awarded the top rank by the same Google algorithms.
The Elementor development team should consider implementing the loading and executing of specific add-on scripts on user interaction. This way, they will save the sanity of their numerous users who are observing continuous slow-moving scaling down of the mobile speed score from one update to the next update. And who is better qualified than Elementor to provide a curated list of various JS files which can be included in the postponed JS group? Why not provide us with detailed guidance about circumstances in which it will be reasonable to postpone evaluating such JS files as swiper.min.js, frontend.js, share-link.min.js, wp-polyfill.min.js, and many others.
Only a small fraction of web designers currently use Kadence Blocks, but this percentage is changing rapidly. Elementor and WordPress missed their chance to buy Kadence from a lone developer. The company was sold by its founder, Ben Ritner, to Liquid Web in order to focus on the accelerated product development of the Kadence ecosystem. Kadence offers a yearly membership that is much cheaper than contributing to the cheating done by NitroPack.
There is a major problem in the hosting industry. For the last 16 years, Nginx was a dominant web server software. Nginx is used on approximately 50 million websites and installing it on a web server can be difficult. All major hosting providers became software development companies and were tasked to customise Nginx software. All this effort has gone to waste – LiteSpeed Web server is a much faster option. Approximately 5 million new websites are using LiteSpeed as of now. You should stay away from hosting providers that cling to outdated technologies.
We offer comprehensive solutions for all aspects of a business, from designing logos to building eCommerce stores. We provide a range of services, including technical SEO optimisation and support with the relocation to more appropriate web hosting. We also have the graphic design expertise necessary to meet any other needs that arise.
