NitroPack - Black Hat SEO
speed optimisation plugin

Table of Contents
Summary:
To confuse Google tests, NitroPack is postponing all JavaScript execution. It destroys the visual appearance of pages with dynamic content and presents static content without interactive functionality. It will take extra two seconds after the first click on a mobile device’s menu button to parse JavaScript files. Only after that unwelcome delay, your menu buttons will start responding correctly.
Johnny Nguyen
Thank you for this finding! I appreciate your write-up and due diligence in getting to the bottom of it.
Adam WPCrafter
Very interesting,
and I just shared this in my Facebook group.
Gijo Varghese
I’ve been discussing your article with my team. It’s really well written! We’ve felt the same.
I took a good look at this, thanks for sharing it. I discussed your article with a VERY trusted and internationally renowned WordPress developer, and he agrees with your conclusions that NitroPack is more smoke and mirrors than having any actual performance improvement over the usual caching or performance improvement plugins. Everyone decides what they want to do with it, but here at Local Marketing Institute, we’ve removed NitroPack from our site.
JWP (John) from Google Search Console Help Community has responded to our article:
“It’s still very possible to scam people who only look at Lighthouse test numbers. Unlike the PageSpeed Insights Lab test, which looks at the page as it loads, the Core Web Vitals Chrome “field” data takes into account how the web page responds as users scroll and navigate the page. It is also not forgiving if visitors who come across the page are not served page content quickly enough due to a remote location, lack of CDN, or high server load. Any tool that tries to outsmart the “lab” tests will only worsen the results of the field tests. Sure the client will say “wow” when they see the first Lighthouse results, but then what will they say when the difference between “lab” and “field” is even greater than it might otherwise be because you fudged the static “lab” results. Considering that ultimately it is the end-user who is the important one here, this is similar to the flawed logic behind faking diesel vehicle emissions tests. If you want a super-fast site, code directly in HTML/CSS/ JS. Unfortunately, you don’t get anything for free here; there is no magic bullet for a quick fix.”
Toward the end of this post, you can find a detailed technical discussion of our arguments by JWP (John) from the Google Search Console Help Community.
27 minutes read | Last modified on June 21st, 2021

Executive Summary

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. 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). The NitroPack plugin fetches all script files and delays all JavaScript evaluations and executions until the first user interaction, such as scrolling or selecting a menu item. NitroPack is using a successful cheating strategy that is not yet caught by Google’s field testing tools. Google is aware of its defeat and plans to implement time audits for user flows beyond the initial page load. Thus we believe the NitroPack scam will lose its magical power by 2022.
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 fails to pass Web Vitals because CLS scores are not satisfactory. 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 Web Vital. 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 Web Vital’s score.
NitroPack is working hard to improve the performance of its plugin to stay competitive even after future Google’s updates to Lighthouse, which might sweep away their cheating. The NitroPack plugin improved a lot last year, but it’s still not competitive with the completely free LiteSpeed Cache plugin integrated with QUIC.cloud CDN and provided by all LiteSpeed web server hosting providers.

Caching plugins with minimal settings

JavaScript evaluation and parsing are significant issues affecting the metrics measured by the online speed test tools. It is essential to execute JavaScript only after the HTML page is rendered to optimise visitors’ experience. The render-blocking nature of JavaScript execution is a well-known issue, and Google’s Web Vitals are monitoring that it is carried out in a deferred manner. In our separate post How to Choose a Web Design Agency, we discussed some diligent steps undertaken by WebWhim to optimise overall JavaScript execution, which took us from the mobile PageSpeed metrics of 35 to 75 and finally to 99.
We appreciate that optimisation of JavaScript generated by Elementor Pro and WordPress is a rather technical issue for most web design agencies. After all, it is well reflected in their low-speed score revealed by our study. But what can they do now when Google is updating its algorithms to include Page Experience metrics? A new solution has emerged in the middle of 2020. The new NitroPack plugin from the young Bulgarian startup can solve all their problems. It indeed provides a boost in the mobile page load sped measured by PageSpeed Insights and GTMetrix. The plugin’s developers advertise clever software optimisation steps for their caching algorithms leading to impressive speed improvements. But is it real? After all, any person who had ever received a solid computer science education is familiar with one of its primary axioms: “Garbage in, garbage out“. This axiom is as fundamental as the conservation of energy law in physics.
There is no question that the proper caching tools, image compression, and JavaScript unloading plugins play a critical role in improving page loading speed. The most potent combination of entirely free tools is LiteSpeed Cache (for minification, merging, critical CSS, lazy load, image compression, JS defer, CDN with edge-caching of HTML files), OMGF (to host fonts locally), and Asset CleanUp (for reducing the JavaScript bloat). However, such tools have many settings relying on the user’s intelligence to making critical decisions for improving a website’s performance. It seems like the initial motivation by the NitroPack team was to fill in that special gap of not only giving clients the tools but actually making the best decisions for them. The goal is not to help users make a better judgment, not to offer many case studies and video tutorials, but to make all decisions automatically. The NitroPack is not alone in this quest, with Gijo Varghese and his team also coming with the new FlyingPress plugin to address similar users.
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. The Artificial Intelligence Copywrite assistant Jarvis from Conversion.ai already delivers a better copy than a freelancer by using GPT-3 DaVinci model from OpenAI. And what is even more terrifying, using Jarvis you can write educated blogs with a pedestrian view on any subject by combining and paraphrasing content from numerous posts written by human bloggers. If you want to write the post without trying to say something new – do it together with Jarvis, and you will get a more professionally researched text for your blog. 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.

NitroPack- under the hood

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.
NitroPack explains that: “NitroPack utilizes modern CPUs’ multi-core nature to offload some blocking operations away from the main thread. NitroPack plugin also rearranges the way resources are fed to the main thread to increase efficiency. Nitropack move out certain processes off the CPU main thread, and some Page Metric Test Tools don’t report that processes”.
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.
Content powered
We might benchmark technical details for a specific website https://rvingwithfamily.com/ in a separate post, but let us cut a long story short – for this particular webpage, NitroPack serves only 12 individual requests and 400kB of data to Google PageSpeed Insights and GTMetrix. More shockingly, the NitroPack plugin forces CSS and Fonts files to be loaded from the local cache in the GTMetrix test system (with hindsight, these files might have been loaded in a separate CPU process and are ignored by the GTMetrix processing algorithms). Both GTMetrix and Google PageSpeed Insights had failed to identify any CSS stylesheets and JS scripts provided separately to the inline code in the HTML file. All of the processing load was caused by inline CSS and JS, which took only 100 ms.
WebPageTest tool shows 46 requests for the same website as above, including four CSS and thirty-two JS files loaded on the page. WebPageTest identifies that the “Document Complete” event happens before loading CSS and JS files. It marked these extra 36 CSS and JS files as provided “After on Load” event and did not include any further evaluation process of these files in its metrics. Nevertheless, WebPageTest identifies that something is wrong by not providing a Speed Index value for such an abnormal website. By comparison, in your local web browser, the same webpage will serve 149 requests with 984kB of transferred data.
We are not alone to find the dodgy tricks of the NitroPack. In his review WP Johnny writes: “I think NitroPack cheats the page scores. For example, when I tested a client site, it wouldn’t show the proper number of requests. My browser network tab showed 152 requests (5.3Mb), but GTmetrix only showed 19 requests (246kb). Congrats. They found a way to cheat the page score…but you can’t cheat the user experience.”
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.
PagePipe recommend to uninstall NitroPack
NitroPack endorsement removal at https://pagepipe.com/nitropack/
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!”
It is hard to agree that the NitroPack plugin had managed to deliver the page loading speed improvement over what is achievable with the usual caching and optimisation tools. In some cases, it will degrade optimised performance solely to trick Google PageSpeed algorithms.
Another fatal marketing flaw of the NitroPack team, making their offer cost an arm and a leg, is the wrong choice of the CDN provider. The Amazon CloudFront CDN is too expensive for what you get in return. Read our review “How to Choose Your CDN Provider” to appreciate the correct choice made by the FlyingPress team, who are offering discounted services of already substantially cheaper BunnyCDN. Why do you want to pay through the nose to Amazon? It does not make sense even if you are in a charity business.

Lazy loading? or Lazy arguments?

Since publishing the original text, we have received a reply from NitroPack:
What you’re describing is JS and CSS “lazy loading”. NitroPack offers the first real-world implementation of this that works and yields those fantastic results. Now, WP Rocket and Flying Press are building the same approach after it was proven to work reliably by NitroPack. How would that be “Black Hat” if everyone else is following suit? Site owners should be looking at Core Web Vitals. That’s directly going to impact their ranking. Google’s ranking update is going to rely on real-world data, not lab data. If a solution works in the real world and provides tangible benefits to the users, that would mean that it works, wouldn’t it? Detailed explanation from NitroPack’s blog and YouTube video.
It sounds like a great story from the start-up developing a top-notch technology. Before trying to analyse it, we are pausing to express our concern with the unproven inclusion of WP Rocket and FlyingPress to the answer from the NitroPack. Below is our interpretation of what these companies are building, which we believe is more professional. They have not yet adopted the same scam strategy as NitroPack. But let us return to the concept of lazy loading of assets and provide a NitroPack plugin review.

HTML Lazy loading

To decrease the initial DOM size, some plugins re-write the code to lazy load HTML elements below the fold. It reduces the First Contentful Paint (FCP) time and Largest Contentful Paint (LCP) time. As visitors scroll down the page, they might be annoyed to find that content isn’t rendered in the browser immediately. So, it all depends on whether your visitors can notice a difference. It should be acceptable if delays are less than a fraction of a second on a desktop device. This new option was created only so that Google Web Vitals would rank your website higher. The concept is introduced in the LiteSpeed Cache and FlyingPress plugins with due care to avoid SEO issues. WP Rocket has announced its intention to provide this feature soon. Ivailo Hristov, CTO of NitroPack, replied to our article stating that NitroPack would also be providing users with similar functionality.

Image Lazy loading

It is an excellent White Hat SEO page speed optimisation strategy. Most visitors will not scroll down and will leave the website immediately after it is loaded. Lazy loading saves bandwidth – for visitors and your hosting provider. Unresolved issues:
  • to accelerate page loading, you have to exclude images above the fold (those which are visible without scrolling) from the lazy loading manually. Not a big deal with LiteSpeed Cache and other top caching products, but still a hassle.
  • background images are included in the CSS by Elementor and therefore are not a part of the lazy loading exclusion. A strategy to overcome this is explained by Gijo Varghese. NitroPack team had managed to solve this issue automatically – outstanding achievement, NitroPack! However, the same functionality is also provided by the LiteSpeed Cache plugin.

Critical CSS

This is a valid White Hat SEO page speed optimisation strategy but is not always working as it should. It is entirely dissimilar to the image lazy loading concept and allows to render the HTML page using an inline CSS without waiting for loading the full range of external CSS files. Unresolved issues:
  • Most of the times, the Critical CSS does not work perfectly because different web pages will have different styling. The caching plugin should not serve such pages with a single critical CSS file. The LiteSpeed Cache has the capability to generate different critical CSS for each web page. It does extra work by reducing unused CSS from elements in the combined file. Cleaning up bloated CSS is also available through the FlyingPress plugin. The NitroPack team recently released a similar feature.
  • Some websites will work fine with critical CSS; some will fail miserably. Not all sites are working correctly with the critical CSS generated by NitroPack, but we are unsure whether they will work fine with the LiteSpeed Cache. Most users of a proper CDN provider or hosting their website on the fast server can ignore utilising critical CSS as their First Contentful Paint time is already good enough. We are not using critical CSS on our website, but it does not prevent us from enjoying a mobile page speed score of 99. Many designers hate using Critical CSS as it provides the most persistent caching layer you have on your website. It will prevent propagating design changes to the live website and should not be used with the website under construction.
  • The critical CSS leads to the initial page rendering that can differ from the ultimate page rendering, which considers external CSS files. The technical term for this failed critical CSS is the flash of unstyled content (FOUC). It looks immature to your visitors. You want to utilise external CSS files as soon as they are loaded to correct any errors caused by the critical CSS deficiencies. There is no lazy loading – you might call it an accelerated loading of inline (critical) CSS.
  • The FOUC event, along with some other visual stability issues, is monitored in the Google Lighthouse performance score with the Cumulative Layout Shift metric. The NitroPack team has decided to load external CSS in a separate thread via inline JS code to cheat this test. The loaded external CSS is hidden from Google PageSpeed Insights tools and is not used when rendering the lab test page. This way, the FOUC issue is never created, and NitroPack users have a perfect Cumulative Layout Shift score in the lab test regardless of the critical CSS failure. The actual visitor will see these external CSS files parsed and executed but with a noticeable delay. The unstyled content caused by critical CSS errors will flash for your visitors for much longer – about one second instead of 100 milliseconds and therefore will look uglier. Chrome’s field data will undoubtedly pick up on this kind of issue, and your score might drop accordingly. NitroPack plugin implemented a Black Hat SEO speed strategy as it is performed solely to cheat Page Metric Test tools in the lab test, inadvertently aggravating visitors’ issues.

Deferred JavaScript

The HTML attribute script “defer” was introduced to ensure that the JS script would not run until the browser has loaded the web page. This way, you can ensure that no blocking assets prevail, preventing parsing CSS and rendering the page. Google check that JS defer is adequately implemented and will advise if this is not the case. LiteSpeed Cache and other leading caching plugins provide a further possibility to select between the After DOM Ready and Deferred options for inline JS to fine-tune its parsing in the browser. All external JS files are set to the Deferred option by default. Unresolved issues:

  • WordPress and Elementor Pro are using the jQuery library for generating JS code. It takes about 1.5 seconds on a mobile device to evaluate the jquery.min.js file.
  • It takes much less time to evaluate and parse all other combined JS files than a single jquery.min.js file.
  • JavaScript automatically generated by the page builder tools like Elementor can not be functional until the parsing of the jquery.min.js file is accomplished.
  • To improve page rendering speed, jQuery should be deferred. While this is possible on most Elementor sites, it can be problematic on eCommerce sites. To address such issues, LiteSpeed Cache has a default option to exclude jQuery from deferred execution. It is recommended that LiteSpeed users disable it under Page Optimization – Tuning – JS Deferred Excludes to determine if jQuery defer is causing any problems with their site. Recently, Flying Press has introduced an improved functionality to defer all JavaScript, including jQuery, on eCommerce sites. This is a welcome move to help the Elementor community get better scores in Core Web Vitals.
  • Current tools fail to evaluate whether JS files are required for the page. You have to use a manual exclusion process assisted by the Asset CleanUP plugin to remove about 80% of JS files otherwise loaded to your pages. NitroPack has nothing to contribute – you can find that it loads the unnecessary jquery-migrate.js file. The issue comes from the apparent entanglement of different JS functions and cannot be solved efficiently without user intervention and testing.
  • If you cannot correctly determine that certain JS assets are not in use on the page, how exactly will you choose which one of them is required above the fold? WP Rocket, Flying Scripts, FlyingPress, and under the Strong or Medium mode in the NitroPack plugin provide the initial yet lacking answer. They empower the user to specify keywords that can identify JavaScript files that should be delayed and executed only on user interaction. We don’t see anything abnormal with such an option. It is the next logical step after using tools like Asset CleanUp. Instead of unloading specific JS files, the user can decide to delay their execution. It is a further option for fine-tuning with all responsibility given to the user of the tool. WP Rocket provides a curated list of keywords to identify specific scripts that are safe to delay. Colm Troy from CommerceGurus has recently shared his list of files worth being included in the postponed JS group of the Flying Scripts plugin. That approach is professional, and we regret that NitroPack has slipped to the cheating with its “Ludicrous” optimisation mode.
  • We will only applaud if, in the next releases, instead of following NitroPack cheating path, other plugin developers from WP Rocket, LiteSpeed, and FlyingPress will offer their users an interface similar to the one used by Assent CleanUP where you will be able to go manually through the list of remaining JS assets on specific pages for selecting some of them (one by one) for the postponed execution – globally on the whole website or only on the specific web page. It will work perfectly well if the users are knowledgeable in what they are doing.
  • It is possible to postpone all JS evaluation and execution instead of deferring it. However, it will destroy the visual appearance of any page with the Table of Content, animated header, auto scroller, sticky menu items, and a video player. Also, the NitroPack plugin will present an initial web page rendering without interactive functionality. After the first click on a mobile device’s menu button, it will take two seconds to parse postponed JS files, including the jquery.min.js. Only after that unwelcome delay, your clicks on a menu button will start responding correctly. The user will become confused and blame his mobile device or the buggy browser software because the menu was not responsive during that initial two-second delay.
  • We are afraid that the concept of postponing all JS execution looks like a fault at your end, NitroPack! It is not something to be proud of. It would be wise for you to remove the “Ludicrous” optimisation mode from your plugin. This scenario will, however, result in only about 1% of the current users remaining. Customers would be better served by the free LiteSpeed Cache plugin and by the edge delivery of static HTML files by free QUIC.cloud CDN. We recommend using geo-replicated Perma-Cache with BunnyCDN’s Push CDN option to ensure excellent performance on low-traffic websites.

Black Hat SEO strategy

The Page Metric Test Tools are not yet developed to evaluate the web pages’ performance in which all JS code execution is brutally postponed.  The Chrome tools are measuring the time for 0% CPU utilisation. They will be fooled on the live pages the same way as the PageSpeed Insights is fooled in the lab testing. It is not their fault – they never thought that someone would dare to implement such a Black Hat strategy to hack the tools on the industrial scale:

  • There is no benefit of postponing all JS execution for the visitor. The page’s performance will feel strange, and the visual appearance of any dynamic effects will be destroyed.
  • There is no benefit to the mobile device or desktop. Modern CPUs are multi-threaded and are happily multitasking. A short delay of the order of 100ms after the CPU has finished all rendering is the optimal setting for JS execution for improved user experience.
  • A diligent user who can create a website without relying on jQuery for the Mega menu or some visual effects above the fold has the skills to postpone any appropriate JS files with Flying Script plugin. There is no need to pay $250 a year to fine-tune the delivery process of JS files on a website.
  • It is common for NitroPack customers to not be skilled in fine-tuning JS for their website. Apparently, they use the “Ludicrous” optimisation mode because it’s just a single button click to get over the green line in PSI’s mobile page speed metrics. In most cases, their menu will be built using JS and jQuery library, and they will be unaware that their webpages will be loaded stripped out of all interactivity.
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.
NitroPack is not alone in cheating Page Speed Metric Tools. A similar scam of hiding all JavaScript is now offered by several developers on the Shopify platform, albeit on a much smaller scale. You can listen to the opinion of Shopify experts Kurt Elster and Paul Reda, who discussed their dismay of specific case on their YouTube video chat. With the typical Shopify website mobile score below 30 in the PageSpeed Insights test, it is not strange that shop owners are worried about the new Page Experience metric. Paul and Kurt suggest that anyone should worry more about being delisted in the Google search results once Google will retaliate the fraudulent tactics. Nowadays, Shopify store owners have a much better White Hat solution described in our separate post. They can reach 100% in the mobile speed score by using the WP Shopify plugin, Kadence Theme and Kadence Blocks for integrating the WordPress platform with Shopify as a store back-office. As a result, they will get a beautifully designed, fully adjustable, and bespoke WordPress online store with the blazing-fast upload speed and sophisticated business processing capabilities provided by the Shopify back office.
eCommerce with WP Shopify
WooCommerce vs WordPress with WP Shopify plugin

Innovation in JavaScript delivery

Hi Google
The idea to postpone all JavaScript execution on the loaded web page is not an innovation – it is blatant cheating. Even worse, the NitroPack makes its clients liable for participating in the indirect contributory cheating of page speed measurement tools when selecting the “Ludicrous” optimisation mode. Apart from choosing a revealing label, users have no clear visibility of participating in the cheating scandal.
More sympathy should be given to Aleksandr Guidrevitch, the developer of the free plugin WP Meteor, who honestly states that the sole purpose of his plugin is to delay JavaScript execution. It allows you to set up delayed JavaScript execution after the CPU has completed all processing tasks. You can set the initial delay to 1 second (which is risky if you want to cheat Google) or 2 seconds. Alternatively, the code can wait for user interaction before starting the execution of JS. If you use this plugin in conjunction with the free LiteSpeed Cache plugin and the free QUIC.cloud CDN, you can achieve the same results as NitroPack’s Ludicrous optimisation mode, but without paying any monthly fee. 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.
The most important thing users of delayed JavaScript execution (including NitroPack users) should pay attention to is whether their site looks and functions the same as it would without it. Parsing JavaScript and modifying the DOM tree takes quite a lot CPU resources, which is CRITICAL on low-end mobile devices. In an ideal world, each section of a web page should load CSS, images, and JavaScript required to display it, LAZILY, when you navigate to that section. That’s our goal at digital agency DarwinApps, where I work as CTO.
We recommend switching to WP Meteor if you are determined to cheat the CrUX until Google changes its algorithms. 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?
NitroPack vs WP Meteor
In 2019, Glenn Conner from Instagram had stated that the use of JavaScript (parsing and executing) becomes the limiting factor on mobile devices. He further wrote:
It’s worth making a distinction between JavaScript that is executed on the critical path and JavaScript that is dynamically imported after the main page has completed. It would be nice to reduce the total amount of JavaScript in an application, but a key thing to optimise in the short term is the amount of eagerly executed JavaScript on the critical path. Dynamically imported JavaScript that lazy loads is generally not going to affect page load performance. It’s a valid strategy to move non-visible or interaction dependent UI components out of the initial page and into dynamically imported bundles.
The actual innovation providing visitors’ benefit is a curated separation of the JS files into two groups, such as deferred JS and postponed JS, allowing functionality similar to the Lazy Loading of images. Algorithms will fail to decide on the group’s assignment; the knowledgeable user should fully control it. This innovation, in its rudimentary form, is already available in the market. Ironically, NitroPack was one of the first to introduce it in their initial product. It was provided as a standalone plugin for WordPress by Gijo Varghese with Flying Scripts and later incorporated into FlyingPress. It also copied now by the team at WP Rocket. In our private conversation with the LiteSpeed Cache development team, we have received confirmation that they will release a similar functionality in the future update. There is nothing complicated in delaying JS; you can look at how this is done for Google Analytics by Sean Lloyd. 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.
The article does not take into account that the one thing that seems to be causing the author this much headache is actually an optional feature. NitroPack users have the complete freedom to disable the default script delays and use the rest of the service to their liking.
This is as simple as switching to Strong mode or going Manual and disabling it from the advanced settings. With that in mind, how is this different from having to manually disable a feature in any other plugin? How does this make NitroPack a “black hat” plugin?
We agree with Ivailo Hristov. If NitroPack removes its “Ludicrous” mode, which we consider as an industrial scale cheating of Google speed measurement tools, it will provide the same functionality as the rest of page cahing 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.
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.
A recent page experience update has brought a sharp focus to performance in the SEO sector, but it’s really a bigger factor in UX/Customer satisfaction. The Lighthouse and PSI tools are provided for developers to check what is happening with their sites. The First Input Delay (FID) metric is a way to measure how responsive and interactive your page is for users. The Chrome UX Report (informally known as CrUX) and related field data would really reveal some of the issues here when delayed execution on scroll introduces scripting and bloat. The way NitroPack and other plugins work can be problematic, and if you add something to your site that causes problems, like missing dynamic effects or janky stuff, you need to remove it. There are massive limitations to automated solutions.  That might not worry someone so much if they have no skills and capacities to handle it themselves. But it would worry me. The fact that traditionally problematic things like Elementor are working to improve things is fantastic, and really, that’s the core of the problem. The onus really is on the WordPress ecosystem, from the core product to plugin providers, to themes, developers, and designers like you, to make it more efficient and have better user experiences without things like NitroPack.
Elementor is currently struggling with JavaScript and, if you do not want to wait for the outcome of their struggle, consider using Kadence Blocks and Kadence Theme. Gutenberg Blocks by Kadence Blocks is a new page builder plugin for WordPress that could completely replace Elementor Pro. The plugin adds creative features to help develop more dynamic layouts. Some designers are already using Kadence Theme and Kadence Blocks to recreate website designs done in Elementor Pro. Kadence is an optimized platform that loads the jQuery library only when needed. Kadence’s Mega menu is built without the use of jQuery. So, unless you load a carousel or gallery that supports “Masonry” style, then your JavaScript code will run without jQuery’s bloat. This is the prerequisite to get a perfect 100 score in Google’s Mobile PageSpeed Insights test.
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.
The whole saga of modification of page speed tools and introduction of unified Core Web Vitals was based on a desire by Google to evaluate how much the bloated JS is slowing down your page. NitroPack has hacked the tools, and once Google discovers this, they will retaliate. Do you want to be involved in such a battle – it is your choice. In the best-case scenario, you will suddenly start getting a very low page speed score. Lets’ pray that it is all that you are risking. But you can not complain anymore. The NitroPack’s blog had made it crystal clear to you that you are buying into a questionable story.
JWP (John), Silver Product Expert of the Google Search Console Help Community:
It is a very slippery slope. Is it worth it to delay loading things that aren’t well optimised to the point when you ruin user experience (which should be the main issue here)? If they haven’t already lost interest, they won’t be impressed if they’re suddenly unable to interact with the page while the slow-to-execute JS stuff actually kicks in (just when they start scrolling).
Your delay is just a tiny fraction longer than the time “estimated” to “fool” Google (which will vary depending on server speed, user location, or CDN optimisation ). You will quickly lose that “perfect” 100 score as long as your lagging content trips the ‘time to interactive window’. By then, your pages will be rated as even slower than before (since you artificially increased the “real” load time).
To ensure that your page speed isn’t negatively impacted by all the “bells and whistles”, you need to properly optimise these features and not just fool yourself into thinking that delaying the execution of JS will somehow make everything okay.
You’re actually ceding control of (a) how your site loads and (b) what delays occur in that process to a tool that is coded by a third-party vendor who certainly has no inside knowledge of how Google’s processes actually work. Furthermore, if Google changes the timings they use literally overnight, the impact on you could be devastating (and completely out of your control).
This desire for fast and responsive websites is not just the result of Google’s being difficult, but a reaction to the lack of performance that occurs without optimisation. Delaying the irksome content makes it worse, not better.
So even if we give these tools the benefit of the doubt and assume they’ll mislead Google in the short term (which they won’t!), would you think Google will stop trying to make the user’s experience the best it can be?
This is all just “smoke and mirrors”. Correct the underlying problem with surgery, not by sticking on a cheap band-aid plaster (which may fall off in the future).

Next steps

What is the best website hosting for your needs? This is a question that many people ask themselves when they are looking to improve their website loading speed. We recommend reading our blog post “How to Choose a WordPress Hosting Provider“. If your website has medium traffic, then shared hosting would be perfect. You can find such an option from many web host, but it’s important that these companies provide LiteSpeed Web server and fast NVMe SSD storage.
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.
Providers with LiteSpeed Web servers are easy to find. Just google for ‘LiteSpeed hosting’ and you will get plenty of options. However, you should look for resolving another important bottleneck: the speed of the disk storage. Our blog post discusses the fastest hosting providers in the US and UK who use LiteSpeed WebServer Hosting and Solid State Drives with NVMe support. Such winning formula boosts about fourfold the speed of specific internal processes on a server, removing the bottleneck in its performance. Servers with such improved technical specifications will carry heavy traffic with more internal resources and degrade their response time more gracefully.
NameHero is a hosting provider that offers the best value for money. They are named as 2020 Best Web Hosting Company winners and have excellent service at an affordable price. So, why not study their Turbo Cloud offering and secure the best hosting for less than $8 per month? NameHero is hosting more than 500,000 websites – something we know you want to take into consideration when you’re looking for a quality hosting provider.
Namehero
Web design agencies are crucial to the success of any website. Selecting hosting and a content distribution network (CDN) can help with the web page loading, but you won’t get far without a professional design. The democratization of web page design tools has led to an influx of technically uninformed designers into website development roles. You may be surprised to learn that most designers are unable to develop websites with high-speed load times. Our article on “How to Choose a Web Design Agency” provides clear criteria for evaluating web design companies.
We offer great deals for our readers. We are one of the best web design agencies in Cambridge – and we specialise in website speed optimisation. Our company is experts in graphic and web design, with over 15 years of experience. We will work with you to explore your business needs and create customised solutions for them. To provide clients with a comprehensive design process, we have created an affordable website design package. To learn more about what we offer, please visit our web design services page on our website.
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.
If you need any assistance, please contact us at [email protected], and we will be happy to help you.
Learn more about WordPress by visiting our research portal. We interviewed WordPress hosts and plugin developers to provide six research articles that will help you understand the WordPress ecosystem. When launching a website, there are several important factors that an agency must be aware of. The most important ingredients for successful websites are good server software, plugins, modern hosting and CDN providers. These basic elements in your website should help ensure that it qualifies for Google’s newest technical SEO standards.