NitroPack - Black Hat SEO
speed optimisation plugin

Table of Contents

Executive Summary
Caching plugin with minimal settings
NitroPack – under the hood
Lazy loading? or Lazy arguments?
Faster WooCommerce
Black Hat SEO strategy
PhastPress Plugin – White Hat SEO
WP Meteor
Innovation in JavaScript delivery
Next steps

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 @ WPJohnny

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 @ WP Speed Matters

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.

Eric Shanfelt
President at
Local Marketing
Institute

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.

Disclosure: Our actions are consistent with what we write in our study. This webpage is optimized for mobile speed using free LiteSpeed Cache and Asset CleanUp plugins, and has a PSI score of 98 and LCP of 2.4 seconds. QUIC.cloud CDN is used for HTML edge delivery.

35 minutes read | Last modified on September 19th, 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 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).

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 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.

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 during last 12 months, but it’s still not competitive with the completely free LiteSpeed Cache plugin integrated with QUIC.cloud CDN and provided for free by all LiteSpeed web server hosting providers.

Very detailed article! Nitropack is good at one thing, and that’s marketing. If you try to activate the “Ludicrous” mode, it will break most websites running third-party JavaScript code. I had to uninstall this plugin on multiple client websites as this plugin rendered their website completely useless.
Thanks again for the great article!

Mark Crowell
Wicky Design

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.

If you’re determined to cheat the CrUX, we recommend the free plugin WP Meteor or the plugin Flying Scripts, which allows you to manage the postponed JavaScript files more effectively. This should work just as well as a Ludicrous mode in an expensive NitroPack plugin until Google changes its algorithm. 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!

Thanks for your article! Your main argument for the scam is that NitroPack delays all JavaScript until user interaction, and most websites require JavaScript to be interactive. When the user interacts with the site, all the crap that was delayed is processed, so the user experience isn’t much better than it was before NitroPack was installed. Delaying JavaScript is a good technique to get better scores, but it should not be used to delay everything, only to delay non-critical JavaScript. If you want to go that route, then use “WP Meteor”, it basically does the same thing for free.

Fernando Benito
fernandobenito.com

The PhastPress plugin provides the least offensive option for fine-tuning JavaScript delivery to improve Core Web Vitals ratings. To speed up page rendering, this plugin prevents JS from loading immediately. The main goal is to start evaluating and parsing JS as soon as possible after the Largest Contentful Paint (LCP) event. The plugin has no intention to falsify the CrUX report; it just trades the reduction in LCP time for an increase in Time to Interactive. This plugin can reduce LCP time by about 2 seconds in a mobile test on a typical web page while increasing Time to Interactive by 2.5 seconds. PSI’s Lab score does not reward such tradeoffs. For this reason, many developers ignore this plugin.

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.

Let us summarise the big picture. With PSI tools, Google provides an objective measure of how much the bloated JavaScript is impacting the speed of your site. This tool allows you to benchmark the skills of your favourite web design agency to compare to those of their competitors. We describe this approach in detail in our research paper “How to Choose a Web Design Agency”. Page Experience ranking is not based on data collected using the PSI tool. It is important to note that only two parameters of the PSI test – LCP and CLS – are measured and reported in the CrUX report.

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.

New websites should use Kadence Theme and Kadence Blocks page builder to get the most out of Gutenberg. Kadence generates clean JS code without using jQuery. Designers using Kadence tools can easily achieve a mobile PSI score of over 90.

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.

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 Core Web Vitals are monitoring that it is carried out in a deferred manner. In our separate post How to Choose a Web Design A gency, 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.

Armenian startup 10Web offers another impressive application for Machine Learning for WordPress echo systems. The company can rebuild any website based on an old theme or even a website created with Wix. Using Machine Learning, 10Web AI Builder allows you to rebuild any website on WordPress in just a few clicks without copying a single line of code. Paste the URL of the website and let AI Builder do the rest! Elementor-based drag-and-drop 10Web editor let you customise all sections of your newly created website, including headers and footers.

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.

Hey WebWhim!

Wow, I had no idea about JavaScript delay by NitroPack. I read your post on your site, fascinating stuff.

Thanks for letting us know.

James Parsons
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.

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.

Johnny Nguyen
WPJohnny.com

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.

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.

Deyan Georgiev
CEO of 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.

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 rendering the HTML page using an inline CSS without waiting to load the full range of external CSS files. Unresolved issues:

Most of the time, 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. However, if the process fails, you can troubleshoot LiteSpeed by following the steps outlined in this video tutorial. Using this approach, you will retain the CSS used by your JavaScript and avoid broken layouts. Many designers hate using Critical CSS as it provides the most persistent caching layer 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 and some other visual stability issues are 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 had loaded the web page. This way, you can ensure that no blocking assets prevail, preventing parsing CSS and rendering the page. Google checks 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 Optimisation – 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 the NitroPack plugin under the Strong or Medium mode 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.
Instead of mimicking NitroPack’s scam methods, other plugin developers should offer their users an interface similar to Assent CleanUP. It would be ideal for users to manually select any remaining JS assets for postponed execution (globally or on a specific 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 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.

The most important lesson you can take away from our article is that you don’t need to spend a lot of money on expensive hosting providers like Cloudways or expensive caching plugins like NitroPack. With a budget of less than $10 per month, you can achieve a perfect Core Web Vitals Score. Switch to one of the best LiteSpeed hosting providers shown in the above Figure. Use the free LiteSpeed Cache plugin and the free QUIC.cloud CDN offered by LiteSpeed. This reduces TTFB to 40 ms globally and significantly speeds up the loading of your assets into your visitors’ web browsers.

MechanicWeb is by far the fastest and the best value for money option providing servers in the US and Germany. NameHero is a good option for the US. BKHosting and Serwer.io are reasonable choices for European visitors. EthernetServers offers ultra-cheap rates from data centers in the UK, Europe, the US, Sydney, and Singapore.

Read our dedicated detailed study to find out further guidance on how to choose LiteSpeed hosting providers. Our separate post explains why a low traffic site would benefit from a geo-replicated Perma cache from BunnyCDN. BunnyCDN will cost about $1 per month, but, as a Push CDN, it delivers far better performance for the low traffic websites than the expensive Amazon CloudFront CDN used by NitroPack.

Faster WooCommerce

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. With other advanced caching plugins like WP Rocket, ESI must be implemented in the CDN. To use Cloudflare CDN, you must 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!

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 free Flying Script or WP Meteor plugins. 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.

PhastPress Plugin - White Hat SEO

Following best practice, PhastPress delays JavaScript execution until the “DOM is ready” event. Unlike the WP Meteor plugin, PhastPress does not wait until the onLoad event because then it would also have to wait for the images to load. The main goal of the PhastPress plugin is to allow initial rendering without having to download or execute external resources. However, the plugin does not unnecessarily delay the execution of JavaScript.

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.

Hey WebWhim,
Thank you for reaching out to me to double-check your description of my PhastPress plugin workflow. Yes, I think your explanation is correct.
Also I have to say that you have done some incredible research and I am impressed with your analysis. Your article is a rare example of high-quality content!

Albert Peschar,
PhastPress,
Developer at
Kibo IT

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.

WP Meteor

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 PSI score) 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.

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.

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 of CPU resources, which is CRITICAL on low-end mobile devices. Avoiding temporal overlap between these two CPU hungry processes will improve your visitors’ experience. 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.

Aleksandr Guidrevitch,
WP Meteor
CTO at DarwinApps

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?

Innovation in JavaScript delivery

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.

Glen Conner
Software Engineer at Facebook

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. In any case, the Swift Performance plugin probably used this approach first. 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. The LiteSpeed Cache development team have recently released a similar functionality in their beta stage 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?

Ivailo Hristov
CTO at NitroPack

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.

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.

Dave Smart
Platinum Product Expert
TameTheBots.com

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“. Even if your website has medium-to-high traffic, the 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.

MechanicalWeb is a hosting company that offers the best value for money and is using the fastest servers. The servers used by NameHero are two times slower, but they offer two times more CPU resources to compensate. NameHero is 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.

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 svetlana.zh@webwhim.co.uk, 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.

NitroPack - Black Hat SEO speed optimisation plugin