Has potential, not there yet.

Hello @aaronsingler,

Thank you for taking the time to share your feedback, and we’re sorry to hear about your experience. Your input is incredibly valuable to us as it guides our efforts to enhance our services and prevent similar issues from arising in the future.

It’s important to recognize the vast diversity within the WordPress ecosystem, with thousands of potential configurations available. In terms of speed optimization, the key factor lies not in the size of the website but rather in its construction.

This is why robust optimization platforms offer a multitude of configurable settings to tailor the performance to your specific requirements.

Regarding our Free Plan, we want to reiterate that it includes a small badge discreetly placed at the bottom of websites’ footers, a detail we’ve been upfront about in our product documentation: https://support.nitropack.io/en/articles/8390230-nitropack-s-free-plan-everything-you-need-to-know.

Regarding our documentation, while we endeavor to explain every feature comprehensively, we continuously strive for improvement and appreciate your feedback. We regularly update our articles to ensure clarity and understanding.

Furthermore, our Free Plan is crafted to provide everyone with the opportunity to experience NitroPack’s optimizations risk-free before any configuration adjustments are made. Rest assured, encountering limits during troubleshooting on our end will not impede the process or slow it down.

Upon reviewing your ticket, I noticed that almost all responses were provided within the day, if not by the following day.

We would genuinely appreciate the opportunity to address any concerns and assist you further if you choose to give NitroPack another chance. Your satisfaction is our priority.

Your response sounds pretty ‘AI generated’.

Like I said, the initial tickets were answered quickly. I’ll give credit where credit is due. However, the last couple of tickets took days to get a response. These tickets were regarding two things.

The first, optimization options caused many broken items on the site.
I entirely understand that this is normal and the exclusion process is the best method to handle it. However, your UI and lack of clear instructions make this process not very intuitive.

The second was that while in ‘test’ mode the ‘pageviews’ were still be counted by all users. Meaning, while we were in test mode with nobody seeing any cached pages, the counter was still going up on pageviews and using up our limited pageviews. This resulted in all pageviews being used before we even got out of test mode. That seems like a programming mistake to me. Given the amount of testing and debugging that is needed to make sure an existing site still works after applying your optimizations, it makes zero sense for noncached pageviews outside of the test mode, would be counted at all.

You have a good start on your product, but it needs work. Your best bet is to listen to reviews (especially from your user base) and make adjustments. I don’t recommend using review responses to swat at reports of issues. Makes you look lame.

Hello aaron,

My name is Mihail and I am one of the co-founders of NitroPack.

Thanks for reaching out and apologies for the reply above. Definitely not the way we want to represent the company.

Let me try to address the questions one by one:

1. On your initial report, I am happy to say that we’re working on a way to handle potentially broken or CLS-ed items post caching. Would be happy to show this to you and hear your thoughts.

2. In terms of exclusions, we have had many thoughts here but I guess still haven’t reached out an ultimate option on how to handle these ones easier than the way they are now. We have a few hypothesis that I would be happy to hear your opinion on. Would be happy to jump on a quick 10 min call if you have time.

3. What you are saying about the test mode and the pageviews makes total sense. I will take this with R&D and see what is the best way to handle this situation. An option would be to apply restrictions to not count views if coming from a certain IP or handle.

All in all, these are exactly the reviews I would like to go through because they specify how we can make the product and its experience better.

I am available at mihail[.at.]nitropack.com and would be happy to have a call if you are up to it to show you some of the solutions around 1 and 2 as well as show you some of the new cool things we’re working on.

Thank you once again for your feedback,

Mihail

Thanks for the follow-up. I’ll reach out to you via email.
For the benefit of this post, I’ll post more info on the areas where I (a developer) got hung up.

The Cache Settings > Cache area has the ‘Exclusions’ for addressing files that are breaking from the optimization.

See screenshot. https://prnt.sc/0VbHqulJTHe5

The documentation page for this is here: https://support.nitropack.io/en/articles/8390302-excluded-resources

I reccomend adding more examples of how to add these exclusions with examples of js, css, and various combinations. Make sure to include info on how to structure the selector. Example, is it relevant to the root, or are how much of the url is required? Put in more examples of wild cards (*).

Provide more info on how to use the resource relation. Give examples of inline vs external file and how each affects the asset url/code selector.

The process for identifying what files need to be excluded from optimization to fix render issues needs help. Your documentation page explains how to use the developer tools console to identify dependent files when there is a rendering issue. This would be good if your plugin operated that way. It doesn’t however. Instead of getting console info that indicates what/where dependent files are, we get mostly preload files listed in the console. And to view the page source is completely useless for debugging. It’s solid script info.

So for example, let’s say the mobile menu toggle isn’t displaying on page load until the user scrolls or takes interaction. Using the search console while Nitro is active or in test mode delivers a long list of preloads, but no errors or info on what file is reacting badly to optimization. Is it jquery, or a script in the theme file, etc. No way to know.

In the Cache Settings > HTML & CSS > CSS > Generate critical CSS.
The on/off toggle makes sense. But there is an ‘include’ and ‘exclude’ css selectors. Why is there both? Doesn’t make sense to have an on/off and then have an include and exclude. Seems like only one would be needed. More info and examples/use cases. Same with the ‘Remove unused CSS’ There is an on/off and then include/exclude.

The test mode pageview count issue is a separate issue and just needs to be changed, so I won’t get into that.

Thanks for responding in ‘human’ ??