Welcome to the new era where cloud-caching goes mainstream (over server-caching).
What is NitroPack? What does it do? And why do people rave about it so much? How does it help speed up sites and improve page scores?
And more importantly (for my fans), does Johnny like it?
Where should I start first? The good or the bad? Ok…let’s start with the GOOD!
NitroPack features:
1. It really does speed up sites.
The sites feel fast. Most of the time, instant load upon a single click. Then again, it IS a caching plugin/service and this is what caching is supposed to do.
2. It gives you better page scores.
Oooooooh! Now it sounds like I’m just teasing but it’s real! Turning on NitroPack is quite possibly the easiest most effortless way to improve your page scores. You don’t need to learn a damn thing about speed optimization. Just enable NitroPack and your “D” grade can become a “B” or even an “A”. Hate all you want, the NitroPack really delivers the nitro!
3. (REALLY) Easy to use.
Listen up, “simple” cache plugins….NitroPack really is the simplest cache plugin out there. Like stupid simple. The plugin settings is one screen with 3 toggle switches and one slider. You don’t have to read online guides on what settings to pick or learn speed optimization. Of course, of course…all the settings are on their website. But still…it feels simpler and that’s all that matters for many people.
4. Tons of features.
Really comes with everything. Caching. Pre-caching. Minification, merging, critical CSS. CDN. Lazy load. Image compression. JS defer. It really does have nearly every single website speed optimization feature and function you could ever ask for. And all conveniently loaded into one service. How handy, right?!
5. Automated optimization service.
NitroPack fills in that special gap of not only giving clients the tools but actually making the best decisions for them. It makes you realize where all caching plugins fall short…that they don’t help if users don’t know how to use them.
NitroPack drawbacks:
1. Ugly FOUC issues.
Every single client of mine using NitroPack has a FOUC issue. Heck even the official NitroPack site has it. LOL. You can see a split second where the styling slides into place. Call me a dinosaur but IMO it looks so unprofessional. But hey… if it doesn’t bother you…then it doesn’t matter!
2. Sometimes not that fast.
It bothers me to no end that even the official NitroPack site is kinda *sticky* load. It’s not that fast. Even after I’ve already visited the pages and pre-warmed its cache, they’re still sticky! The good news is that my client sites do load fast with NitroPack.
- You can see fast sites like this: https://thriveagency.com/
- And then slow sites like this: https://www.ishine-trade.com/
Yes…both are on NitroPack. So whatever the case may be…you know it’s not always a guaranteed miracle. I hate that even the fast one still has sporadic FOUC issues.
3. The price is wayyyyy too expensive.
The price you pay for NitroPack can be even more than your webhosting, especially for the higher plans. And kudos to them, taking advantage in a consumer market that doesn’t know any better. Repackaging overly technical services into a dumbed-down simplified product for end users. It’s great marketing and product execution. But if only people knew…just put that money into your webhosting server and you’ll might get a much better overall loading experience for so much less (depending on your webhost).
- NitroPack costs $132/month per site if you have 1 million pageviews/month.
- That same $132/month easily get you a VPS server that’ll handle 2-3 million pageviews (if not more) and cover as many websites in there as you want.
But of course…in this random match-up scenario, we have to assume that you have a good webhost or server.
4. 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 was showing 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. If all you care about is the number…then stick with it. But if you want to know how many MPG your car actually gets, then be cautious.
UPDATE JAN 16, 2021:
- This has since been commented on by Deyan (NitroPack CEO) that it only seems that way because NP moves certain processes off the CPU main thread and some page tests don’t report that.
- So while NP doesn’t cheat the scores it certainly optimizes things in a way that cause your site to appear better and loading fewer things on those scores.
- In reality, your website is still loading everything. I’ll comment more on this if I come back to check on this further.
- UPDATE MAR 21, 2021 – webwhim finds more explanation for potential NitroPack black hat SEO cheating?
5. Automated cache configurations can cause issues.
If you have a complex site with complex caching or optimization needs, I think NitroPack may get in your way. Its strength of being super easy to use can also be a con for advanced users. WooCommerce sites or sites with lots of custom/dynamic AJAX stuff may have issues.
I don’t actually know this for a fact, ok? It’s just speculation. If you have a complex site and slow as heck, please try NitroPack for us all and report back here in the comments!
My verdict on NitroPack
I like what NitroPack is doing…but I don’t like NitroPack.
- It delivers a fantastic user experience and pushes the limits of what caching can do.
- I love that it’s bringing edge-caching to the masses (only they just don’t realize it).
- I also enjoy the in-house (automated) JS combine tactics. A centralized cloud service like that could certainly benefit from a known list of JS conflicts similar to how Wordfence benefits from a known list of security exploits.
- NitroPack is also a great bandaid fix for sites on slow servers and with limited caching options.
- Another side benefit is that it’s an easily-reversible optimization attempt. If it doesn’t work, you only paid for a single monthly fee. It’s not like you bought a super expensive plugin, hired an expensive speed-op developer, or migrated everything to a new server.
My gripe with NitroPack is that it’s stupidly expensive (especially for someone like me who knows what they’re doing) and still doesn’t deliver a professional page load experience. FOUC is just a major no-no in my book. I think of the word “amateur” every time I see it.
The edge-caching revolution continues!
The good news is that edge-caching technology has already advanced so much. It used to be only for simple CDN things like static assets (CSS, JS, images, etc) but has now grown into caching even the full page cache at the edge.
There are so many boundary-crossing cache plugins and cache services that do more or less of the same thing. In time, they’ll all compete with each other to improve performance while decreasing prices.
- Cloudflare APO – utilizing their massive CDN presence and long experience in cloud-caching and cloud-processing.
- QUIC.cloud (by LiteSpeed) – leveraging their amazing free LiteSpeed cache plugin with their own CDN network. And it’s much cheaper than NitroPack.
- Rocket.net – webhosting service that does page-caching at the edge.
- All existing cache plugins – you give it some time and I bet many plugins and hosting services will start offering some degree of this (page-caching at the edge).
Who should use NitroPack?
Anyone on a crap server, bloated site, with zero knowledge of speed optimization, care (too much) about page scores, and don’t mind paying the premium.
- NitroPack – the quick-fix bandaid solution to all your speed and page score troubles!
For everyone else…trust me, you can get a better experience with normal cache plugins and save a ton of money in the process. Or better yet, put that money towards fixing/rebuilding your site and remove the crap that was slowing you down in the first place. Fix your problems at the root cause!
Definitely cheats Gtmetrix.
You know better than me Johnny , one can use [REMOTE _HOST] on Apache that is to set some conditions and a rule in .htaccess if this host are Gtmetrix ,PSI, Pingdom,etc.
Tried to explain it to a friend of mine running his site on NGINX ( i know nothing about NGINX) but he was so “in love” with NITRO and didn’t listen to me.
Prefer CF APO though it needs a bit polishing.
Saving this review in order to open his eyes!
Yeah, people are in love with things they haven’t experienced before. It’s natural to make positive association with things. But once your friend sees many ways to skin a cat, he might choose differently. Either way, it’s great that NitroPack makes him happy.
Add another con: not compatible with advertising platforms like Ezoic.
Lol, I see that as a PRO! Hahahaha.
Do yourself a favour and get rid of Ezoic. So many better ad platforms out there that allow you to use your regular cache services.
I’m not eligible for those other ad platforms (they accept a mostly US audience).
Hey Luis,
NitroPack is compatible with Ezoic integrated via their WP plugin.
Best,
Deyan
Thanks for letting me know but may I ask where you got that info? Because Ezoic says that Nitropack is incompatible: https://www.ezoic.com/compatibility/
Hi all,
Constructive feedback is always welcome. Thanks for taking the time to write this detailed review.
There’s one misconception I’d like to shed some more light on – the part about NitroPack somehow cheating speed testing tools.
First, a bit of context:
NitroPack has always delivered real solutions to web performance problems. And two of the modern web’s biggest issues are:
1. The large number of resources per page
2. JavaScript execution
Resource loading and JavaScript execution take precious CPU cycles from the main thread, which hinders the page rendering process, even with modern devices having multi-core CPUs (including low-end ones). We believe these cores must be utilized in the best way possible to achieve a great user experience.
Most devices are truly capable of loading a modern web page fast. It all comes down to hardware resource utilization. NitroPack utilizes modern CPUs’ multi-core nature to offload some blocking operations away from the main thread. Our product also rearranges the way resources are fed to the main thread to increase efficiency.
This can cause confusion when looking at waterfall charts generated by public testing tools. Most of these testing tools are designed to measure page performance, assuming standard page structure and resource loading techniques. That’s why trying to understand the output of these tools doesn’t always make sense in NitroPack’s context, which may lead a person to believe there is something funky going on.
NitroPack simply preloads assets like CSS, fonts and JS in a separate thread, that’s why it can look like assets for GTmetrix (or any other tool) are not being loaded. And because their loading does not block the main thread, they aren’t listed in the waterfall.
All this can be double-checked on any page, any site, using DevTools.
If you encounter any rough edges along the way – do get in touch, we appreciate honest and straightforward feedback.
At the end of the day, what matters to our users is real-world performance. That’s what also matters to us. And that’s what NitroPack provides.
Innovation takes a little bit of shaking up “the way things have been done” 🙂
Best,
Deyan
CEO
NitroPack
Thank you for the simple and beautifully-explained discrepancy, Deyan. I had no idea page scores weren’t reporting secondary thread operations. And have adjusted my article to account for your comments. If you have anything else new to announce, feel free to comment it below. Thanks again for your work!
This is interesting dialouge for one who has their finger hovering over Nitropack’s Purchase button. I have tried it and the improved results obtained through page speed insights are truly phenomenal.
My main concern is the amount of code Nitropack inserts into a page. Looking at your two example sites and switching to view source and running a Ctrl F entering ‘nitro’ pulls up 254 & a staggering 1484 on the respective sites. These figures are not the total extent of the extra code but just an indication of the number of code segments added.
Any thoughts?
The extra code won’t matter much if everything is pre-cached. 1KB is not an issue at all. If that’s your only concern, NitroPack should be just fine for you. After all…you’re already seeing proof that it works *magically*.
Hi Johhny,
I discovered NitroPack just recently and today decided to make my own investigation of how are 100 mobile, 100 desktop Pagespeed Insights scores possible with no effort (case study – https://metrica.bg/).
This website reported stellar results in GTMetrix and a size of 150KB, while Pingdom calculated 877.5 KB. Interestingly, GTMetrix shows no JS loaded even though the site has a slider, ReCaptcha, FB chat, etc. Also CSS and fonts are reported as 0 bytes in size, while just one of their fonts is 65KB.
I decided to test everything in the devtools where I disabled the cache. Here is what I saw:
120 requests
2.2 MB transferred (significantly larger that the tests above)
6.9 MB resources
Finish: 1.0 min
DOMContentLoaded: 405 ms
Load: 533 ms (comparable to Pingdom)
Among the loaded elements we naturally have plenty of JS, incl. 133KB ReCaptcha and 128KB FB chat.
In my testing Nitro does nothing over a careful optimisation even only with free tools. A recent client of ours (https://translation.legal/) even drops on desktop from 98 to 95 when tested on Nitro’s homepage. Yes, it improves on mobile (80 to 92) but we didn’t target that due to the audience and budget of the client.
All in all, Nitro have figured out a clever trick to fool the test bots (for now) but it is not a magic wand for actual speed optimisation. What it’s effect on SEO is another matter all together.
We shall not be using it personally or in our client work.
Thanks for your careful testing, Viktor. As per NitroPack’s CEO…he says the test-fooling part is due to it having multi-threaded processes which aren’t reported in test tools. But yes, I agree with you exactly.
> he says the test-fooling part is due to it having multi-threaded processes which aren’t reported in test tools.
So in other words it does not have any actual real word advantage whatsoever. It’s all purely cosmetic in regards with the testing tools (something that eventually will be fixed – seems Pingdom already figured it out and reports the real data).
No your conclusion is wrong. Page Speed Insights is focused on user experience metrics. It would not make ANY difference to your total score on PSI whether your waterfall loads things one way or another or the number of requests are high or not.
PSI might recommend you make less requests as a way to impact your score/performance – but in no way would that impact your performance or score. So no, they are not cheating, and it’s garbage to say there is no real world advantage.
Thank you for this great review.
Hi Johnny,
According to my 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 initial rendering in the Page Metric Test Tools is likely based entirely on the inline CSS in the HTML file without using additional CSS loaded on the page.
Our study at https://www.webwhim.co.uk/how-to-select-a-web-design-agency/#NitroPack indicates something fishy on a par with the Dieselgate scandal.
Thank you Victor for this finding! I appreciate your write-up and due diligence in getting to the bottom of it. We’ll see what others unfold over time.
Sorry, forgot to add. The mobile Google PageSpeed Insights score depends entirely on the amount of JavaScript bloat generated by Elementor Pro, WordPress, and other plugins. Our home page https://www.webwhim.co.uk has a mobile speed score of 99 once the jQuery is unloaded from the page. This step removes with it all JS generated automatically. NitroPack plugin achieves the same boost in the mobile page speed score with Google and GTMetrix by not evaluating and parsing JS files – there is no mouse movement in the browser when testing with Page Metric Test Tools. The multi-core solution to load JS and CSS in a separate thread was probably a stroke of genius to hide this cheating from the existing algorithms of the Page Metric Test Tools.
Hey all,
Picking up on some unanswered questions.
@Luis – We know NitroPack is compatible with Ezoic via plugin, we’ve tested it and it is a supported setup
Here’s in-depth, technical explanation, with examples on how we load things and why that makes sense:
https://nitropack.io/blog/post/faq-nitropack-is-not-magic
Hey Deyan,
Please follow the link at
https://www.webwhim.co.uk/how-to-select-a-web-design-agency/#nitropack-answer
to find a detailed answer to your blog mentioned above.
The concept of postponing JS execution is not an innovation to be proud of.
When NitroPack is working correctly, they seem to do a great job on many items.
However, you often do NOT know when it’s not working. Three issues come up there. First, when publishing or updating a single page it may have a cascade effect, with dozens of pages purged for re-optimization. And, during this time, those pages may be served with no optimization or caches being used, until Nitro has them available again. How long this takes may be minutes to many hours, depending on both the work needed, and their current load.
This appears to be an inherent characteristic from the degree of optimization they are doing on scripts used in many pages. However, the extent of this often isn’t realized until you browse through their logs. And, currently, according to their customer support, you may have to login to their site and purge failed attempts in order for it to retry the optimization.
Second, apparently the Nitro cache will drop pages, even if they have been successfully optimized and previously served by the cache. And there are no log entries to show this. While some may have been dropped due to the first item above, many others were found with no such log entries. I recorded an optimization log entry, then watched the http header until it was dropped from their cache (about 2-1/2 days). Returning to the Nitro logs, nothing had changed on that page’s status.
Third, in some cases, a single browser pageview will refresh their cache for subsequent views. However, sometimes that doesn’t work until many very slow browser pageviews have been taken. Their Cache Warming does not appear to be triggered here.
According to NitroPack, a reliable caching indicator is in the header as:
x-nitro-cache: MISS vs x-nitro-cache: HIT
re: https://help.nitropack.io/en/articles/4838039-how-to-check-if-nitropack-is-serving-optimized-pages-to-visitors
(Scan done using “curl -I -L ” and finding the value of x-nitro-cache: as HIT or MISS)
A brief scan was just done on several of their customers
thriveagency.com sitemap:1918 nitro-MISS:1339
hostmycode.in sitemap:55 nitro-MISS:32
sendcloud.com sitemap:130 nitro-MISS:41
goatsontheroad.com sitemap:1355 nitro-MISS:1303
scienceofpeople.com sitemap:487 nitro-MISS:334
skymall.com sitemap:33651 nitro-MISS:33573
socialchorus.com sitemap:507 nitro-MISS:371
soft-lite.com sitemap:489 nitro-MISS:449
shotkit.com sitemap:2068 nitro-MISS:466
A very few of those may be from failed optimizations, but many samples became cached right after a browser hit, so the optimizations had been successful. I then saw those same items soon dropped from their cache, even though the earlier optimization record had NOT changed. This was found by periodically logging their cached URLs, and examining any changes.
Of course, one could say that for 500 views on one page, only a single view will be slow. However, with 500 views on different pages, perhaps half of them could be quite slow, from the numbers I reported above. And this could also repeat over time.
Most NitroPack users are likely not aware of this, although NitroPack is reportedly working on this 2nd issue. However, they do not seem to believe the first issue, as simple cache drops alone do not show in their logs.
Hopefully, they will soon have this fixed. But, I have no idea how long this issue has been there, and it simply wasn’t visible until other issues caused me to start scanning the entire site.
Ouch. This wouldn’t surprise me as pre-caching is a lot of work on their edge servers. Any cache misses would benefit in their favor (at the cost of end visitor performance).
And this is somewhat worse than it sounds. Since Nitro precludes other caching, minimization, and image optimization, their cache miss means your site gets served at its worst.
And a client just asked Nitro why the mobile score on one of their pages was down to 50. Nitro tech support blamed the TTFB and told them they need a faster host. I looked at the same screenshot and saw the LCP was way high. Sure enough, when Nitro re-optimized the page the LCP went down and the score up to 87. Did Nitro not know how to read Insights, or was he just deflecting?
I really don’t know as I’m not a NitroPack user. I don’t like it. Only time will tell whether it continues to do magic or becomes decloaked.