Fast Velocity Minify WordPress Optimization Plugin – JS/CSS Wizardry!

Pros (+)

  • Relatively simple setup.
  • Superb audit results.
  • Unique features.

Cons (-)

  • Quirky implementation.
  • Lacking in some areas.
  • Critical CSS integration.

What’s in it for me? Here’s how to use this review to your advantage…

  • Beginners – Fast Velocity Minify isn’t too difficult to setup, but we’ll show you how. You can ask questions in the comment section below.
  • Intermediates – pay special attention to the Pro tab of FVM. It’s got some extra tools that you may find useful, such as include/exclude and merge external URLs.
  • Power users – the Developer tab will be right up your street. As always, we welcome your input and wisdom to strengthen the Page Speed Tweaks community spirit.
With FVMWithout FVM
Fast Velocity Minify WordPress Optimization Plugin - JS/CSS Wizardry! 1Fast Velocity Minify WordPress Optimization Plugin - JS/CSS Wizardry! 2

1. Fast Velocity Minify Essentials

You are no doubt asking ‘what use is Fast Velocity Minify to me?’ Let me tell you, it’s a lot of use. Especially if you’re rocking WordPress – like most of the blogging community.

What does FVM do then?

Fast Velocity Minify is above all else a WordPress optimization plugin offering the following:

  • Merge/aggregate JS and CSS files to reduce HTTP requests.
  • Inline CSS to speed up WordPress even more.
  • Minification of JS, CSS and HTML to reduce file size.
  • Apply changes globally or targeted to PageSpeed Insights only.
  • Ability to optimize Google Fonts.

There’s a whole heap of other good stuff that Fast Velocity Minify offers, similar to its main rival Autoptimize. You can see the full list over at and the FVM plugin page.

Although both FVM and Autoptimize are both amazing plugins for WordPress speed kings, they are both equally good and really just a matter of personal preference.

My advice is to try them both, but for now let’s concentrate on Fast Velocity Minify.

Fast Velocity Minify WordPress Plugin
Fast Velocity Minify WordPress Plugin

2. Benchmarking WordPress Plugins

In order to guage how useful Fast Velocity Minify is, we need to jump on the scales of authority and benchmark our current setup. That means heading over to GT Metrix and plugging in our test site’s URL.

Let’s do it then…

First of all here’s the basic infrastructure of our WordPress site.

GT Metrix is our preferred auditing tool, simply because we’re only looking at the following items:

  1. Number of HTTP requests.
  2. File size increase/reduction.

While speed is of course super important for user experience, it is network dependant and can be misleading if you don’t do enough testing to average things out. Requests and file size, on the other hand, are relatively robust. They don’t really change from test to test, which enables testing to be expedited.

3. Active WordPress Plugins

Aside from the GeneratePress Premium plugin, which is only for design use, we only have two active plugins in use. I’m sure you take our word for it, but for those that don’t…

It’s best practice to delete unused plugins, for performance and security reasons, but on our test site we make an exception.

WordPress Dashboard Active Plugins
WordPress Dashboard Active Plugins

*Fast Velocity Minify wasn’t activated until after the first round of tests.

4. Home Page – W3 Total Cache

GT Metrix is an obedient servant and never complains, especially when you sign up for a free account. With most auditing tools, this is a great move. You will be able to revert to earlier tests, always handy. Plus you can usually jump the queue ahead of non-members.

If you haven’t already signed up yourself – now you’ve got no excuse not to!

W3 Total Cache GT Metrix Audit
W3 Total Cache GT Metrix Audit

The results for our WordPress home page and W3 Total Cache are:

  • Page Speed Score: 99%.
  • YSlow Score: 96%.
  • Total Page Size: 133kb.
  • Requests: 22.

We’ve got the test site setup as a standard blog roll, with ten or so posts on the front page. They all look the same, as they’re from an earlier test of imaging plugins.

5. 20-Image Blog Post W3 Total Cache

Following on from the above mini-test we proceeded to try our blog post for size. Here’s what GT Metrix had to say on the matter.

W3TC 20-Image Blog Post GT Metrix Audit
W3TC 20-Image Blog Post GT Metrix Audit

Here’s the results for our blog post and W3 Total Cache:

  • Page Speed Score: 98%.
  • YSlow Score: 96%.
  • Total Page Size: 6.83mb.
  • Requests: 43.

Although the test site itself isn’t under a heavy load of, say, JavaScript or CSS, for the image test I intentionally grabbed 20 decent-size images from Pexels and Unsplash. This was in order to make up for the lack of real data, effectively adding a bit of weight to the page.

If we make the tests too easy, it’s not like we’re going to learn anything.

Bulking up the page size or throttling connections is a quick-and-easy way to strengthen the results.

6. Home Page FVM & W3TC

Now we’ve got something to measure against. Let’s see what GT Metrix thought of Fast Velocity Minify.

Fast Velocity Minify W3 Total Cache GT Metrix Audit
Fast Velocity Minify W3 Total Cache GT Metrix Audit

Adding Fast Velocity Minify to the equation has significantly improved our home page results:

  • Page Speed Score: 100%. (+1%)
  • YSlow Score: 100%. (+4%)
  • Total Page Size: 120kb. (-13kb)
  • Requests: 12. (-10)

While the results are good, in some ways it doesn’t do FVM justice. If we were starting out from a lower score to begin with, it’s quite possible that we would have seen an even bigger improvement.

That being said, we can only imagine and real-world figures are what counts – not imaginary ones.

On to the next one, then.

7. Blog Post FVM & W3TC

Running our 20-image blog post through the mincer again gave us the following GT Metrix result.

FVM W3TC 20-Image Blog Post GT Metrix Audit
FVM W3TC 20-Image Blog Post GT Metrix Audit

With a lower baseline to start from, you can see that we’ve climbed a little higher this time. Yes, we can’t go any higher than 100%, but we have more requests to nibble on and a chunky page size to feast upon.

Here’s the blog-post results with Fast Velocity Minfiy activated:

  • Page Speed Score: 100%. (+2%)
  • YSlow Score: 100%. (+4%)
  • Total Page Size: 6.81mb. (-0.02mb)
  • Requests: 32. (-11)

It’s worth adding that although I didn’t pay much attention to the download times, as explained earlier, they are both faster with FVM turned on. This isn’t likely to be a coincidence, but would need averaging out over a significant number of tests for me to comment on them with authority.

8. PageSpeed Insights

The last test results I’d like to show you are from PageSpeed Insights, which was mainly to point out the slight knock for not defering offscreen images on the mobile test.

FVM PageSpeed Insights Defer Offscreen Images
FVM PageSpeed Insights Defer Offscreen Images

Autoptimize has a lazy-loading feature, which reduces requests and helps pass the above PageSpeed Insights audit.

While it’s not a major issue, as there are lots of lazy-load plugins, either individual or combined with bigger plugins. Autoptimize’s lazy load is the best implementation of this well-known technology that I’ve personally come across.

The desktop test didn’t pose any problems for this highly-capable plugin.

FVM PageSpeed Insights Desktop Test
FVM PageSpeed Insights Desktop Test

You can probably imagine that other test results were all up to scratch, but there isn’t much to be gained from showing any more here.

With that said, let’s crack on with setting up the plugin.

9. Fast Velocity Minify Settings

To open Fast Velocity Minify from the WordPress dashboard, you need to go to the settings menu and then select it from the drop down list.

You’ll then see the six tabs for Fast Velocity Minify:

  • Status – the current list of aggregated JavaScript and CSS files, plus the total cache size.
  • Settings – general FVM settings tab that you need to set up for every site.
  • Pro – some more in depth settings for merging, excluding and blacklisting external files.
  • Developers – seriously powerful settings, such as HTTP headers, critical CSS and debugging tools.
  • Server Info – a useful tab that gathers your origin server data – variables, values and file names/paths.
  • Help – links to FAQs, affiliate offers, donation link and how to custom requests for work offers.

10. Status Tab

When you’ve installed and set up Fast Velocity Minify, you can check out various information. Unless you’ve got problems, the only thing you should need to do is purge the cache.

It’s possible to turn on the FVM Purge button from the general settings tab. The button then displays in the top of the WordPress dashboard, which speeds up the purging process. It’s worth noting that it also purges W3 Total Cache at the same time, which is a handy feature.

FVM Purge Button - WordPress Dashboard
FVM Purge Button – WordPress Dashboard

You can see from the image below that the Status tab offers a quick view of files that Fast Velocity Minify is currently processing.

The files are seperated into three main areas:

  1. Total FVM cache size.
  2. List of processed JavaScript files.
  3. List of processed CSS files – unless they are inlined.
Fast Velocity Minify Processed File List
Fast Velocity Minify Processed File List

Clicking on the blue View Log button shows the image below, giving you more details for the chosen file. It also shows where the file is placed – usually in either the header or footer.

Fast Velocity Minify View Log
Fast Velocity Minify View Log

11. Settings Tab

This is where you’ll find the common settings useful for every installation. The plugin’s author, Raul Peixoto, has broken the general settings tab down into three main sections.

  • Basic Settings – general settings that shouldn’t break your site, but still proceed with caution.
  • CDN Options – specify your own content delivery network.
  • Cache Location – the modified file paths to your chosen cache locations.

A good place to start is from the standard settings, however, you can also try the same settings that I’m using for the test site. Though I’m not using any advertisments, fonts or anything else so your results will definitely be different to mine.

If in doubt, the best thing to do is turn on one setting at a time. To speed things up, turn on between 3 – 5 settings at once, then if something breaks you know it’s one of those 5 settings. Then you only have to check.

Another way to do it is just turn all the settings on. If something breaks, turn off half of the settings. That way you will quickly find which half of the settings menu the problem is coming from. Once you’ve done that do half again (a quarter). So in two moves you’ve almost nailed the issue.

It just seems painfully slow when turning on one setting at a time.

FVM Settings Explained


  • Admin Bar Purge – turn on for WordPress dashboard button in main menu.
  • Preserve Settings – select this to keep FVM settings, in case you delete and reinstall plugin.
  • Fix Page Editors – will improve compatibility for logged-in users.

URL Options:

  • Auto Detect – let FVM try and detect your HTTP settings.
  • Force HTTP – will try and select HTTP for anyone still not using HTTPS.
  • Force HTTPS – the opposite of above, which is the most likely choice for modern websites.

HTML Options:

  • Disable HTM Minification – turns off FVM minify settings.
  • Strip HTML Comments – minify is turned on, but without removing advisory comments.
  • Cleanup Header – removes fluff that is no longer necessary to save a few bytes.

Font Options:

  • Stop Removing Emojis & Smileys – disables the removal of emojis in case you prefer them left in.
  • Disable Google Fonts Merging – prevents the merging of Google Font files, but increases requests.
  • Remove Google Fonts Completely – Google Fonts will no longer be enqueued.

Google Fonts:

  • Inline Google Fonts CSS – this uses font (browser) hinting to inline the Woff format of Google Fonts.
  • Async Google Fonts CSS – uses the Filament Group’s LoadCSS to load CSS in a non-blocking manner.
  • Async & Exclude Google Fonts – this prevents the font CSS from loading for PageSpeed Insights only.

Font Awesome:

  • Merge or Inline Font Awesome CSS – only applicable if you are using Font Awesome and inline CSS.
  • Async Font Awesome CSS file – same as for Async Google Fonts CSS above.
  • Async & Exclude Font Awesome – this prevents the font CSS from loading for PageSpeed Insights only.

CSS Options:

  • Disable CSS Processing – prevent FVM from processing all CSS files.
  • Disable CSS Minification – prevent FVM from minifying CSS files.
  • Preserve CSS Order – keeps your CSS loading order – can help speed up/stabilize rendering path.
  • Disable Print Stylesheets – can be safely removed if you have no use for users to print any files.
  • Inline CSS in the Footer – inlines CSS in the footer only.
  • Inline CSS in Header & Footer – inline’s CSS in the header, then remainder is in the footer.

JavaScript Options:

  • Disable JavaScript Processing – turns off JavaScript processing of all files.
  • Disable JavaScript Minification – leaves on aggregation and merging, but disables minify.

Render-Blocking JS:

  • Enable Defer Parsing of JS Files Globally – leaves parsing of JS files till last (best practice).
  • Skip Deferring jQuery Library – in case of problems you can check this box.
  • Skip Deferring jQuery on Login – worth checking in case of jQuery errors.
  • Skip Deferring Ignore List – check this to prevent FVM deferring the Ignore List.

PageSpeed Settings:

  • Enable Defer JS for PSI Only – defers parsing of JavaScript for PSI only.
  • Exclude Ignored JS Files – this wil hide the Ignored JS files from PSI rather than simply deferring them.

CDN Options:

  • Your CDN Domain – list your own CDN here, but shouldn’t be necessary for Cloudflare.
  • Force CDN Usage – experiment with this feature if you have issues with PageSpeed Insights scoring.

Cache Location:

  • Cache Path 1 – change your origin JavaScript file path from wp-content/uploads to a new path.
  • Cache Path 2 – same as above, but for your CDN, not origin server, base JavaScript URL path.

The settings image was a bit too tight to annotate, hence the explanation above.

Fast Velocity Minify Settings
Fast Velocity Minify Settings

The first setting in the Functionality section is the Admin Bar Purge we discussed earlier on.

Most of the settings are presonal preference. I’m using stack fonts, rather than Google fonts, but on the test site I turned them off out of habit.

Inlining CSS is something that I prefer to do, as it’s usually a big speed win, but is site dependant. You shouldn’t inline everything unless your total CSS is above 50 to 60 KB max.

If you are above this limit, there is no one rule that is set in stone. They are all advisory guidelines that people consider best practice, yet sometimes we hear them preached as if it’s going to kill us if we go over a set limit.

Site speed is best looked at as a whole. If you’ve hardly got any images or JavaScript loading, then use your own judgement. Test, test, test. If everything comes up good, that’s all that matters.

12. Pro Settings Tab

Fast Velocity Minify’s Pro tab has a few useful modules that you can use. The main purpose of this section is to carry out the following:

  • Ignore files and prevent them from merging, aggregating or minfying.
  • Merge, aggregate and minify files from your own external sources.
  • Blacklist known files that are problematic, also any of your own files you wish to blacklist.

From my own experience, the Pro tab is one of the lesser used when configuring this plugin.

Fast Velocity Minify Pro
Fast Velocity Minify Pro

13. Developers Settings Tab

You are probably expecting some bigger tools in this section. Bigger, better, badder… and you’re probably right. They’re not really any badder, just more interesting and exciting.

  • Development – this is the trusty old debugging section.
  • HTTP Headers – for preloading your resources in the browser.
  • Async CSS – great for testing your critical path CSS.
  • Critical Path CSS – now we’re getting technical. This is great for a one-page website that you hardly change. Otherwise it’s a pain in the backside, but there are easier solutions I will share with you.


The first section on the Developers tab is for debugging. You may or may not find it useful, but as instructed by the plugin author, you need to ensure the cache is clear otherwise the headings may not show up correctly during the debugging process.

Not much else to add, as this part speaks for itself.

HTTP Headers:

Next is the HTTP Headers section, otherwise known as browser hinting. You’re giving the browser hints such as preconnect, preload, etc. This is essentially giving the browser guidance.

The only trouble is that the first section is advertised as Preconnect when it is in fact DNS-Prefetch. If you only want the DNS-prefetch then use this option in FVM and ignore the slight misrepresentation.

Child Theme Header - Preconnect, DNS-Prefetch
Child Theme Header – Preconnect, DNS-Prefetch

There isn’t a great deal of difference, as you can see below. A true preconnect doesn’t just resolve the DNS lookup, it does three small steps in one go, saving precious milliseconds.

Preconnect resolves the DNS lookup, initial connection and the SSL negotiation in advance.

It won’t turn a slow site into a fast one, but all these small improvements add up. Together we’re stronger, as the saying goes. Same for humans, same for bits of code.

WebPage Test Preconnect, DNS-Prefetch
WebPage Test – Preconnect, DNS-Prefetch

You can find more information about such things at W3C Resource Hints.

Async CSS:

This is another brief section that you may find useful when coniguring your critical path CSS. It’s only two checkboxes so have a play around if you think it’s beneficial.

Asynchronously loaded CSS loads in the order the browser decides. In most cases, a premium browser like Chrome will do a good job on its own.

As always, try these things and make an informed decision based on your testing. Everyone’s site is unique and there is rarely a one-size fits all with WordPress and web design in general.

Critical Path CSS:

The first part of using any semi-autonomous Critical Path CSS tool is using it with a critical path CSS generator that strips your important CSS from the not-so-important non-CCSS.

If you only have a single page website that hardly ever changes, such as a small business site, then it’s fairly straightforward.

On the other hand, if your website is constantly evolving then using such methods for your critical path process isn’t ideal. You need a more streamlined approach.

Firstly, if your CSS is only small – say 50 to 60 KB, even slightly higher as long as the rest of your site is lightweight can be inlined. This is the easiest way and itself is super performant.

One chunk of CSS inlined in the header of your web page.

When you go down the critical path route, it might cause FOUT, FOIT or FOUC. You basically get a double loading of CSS rules, and a flash of unstyled content, so it changes before your eyes. It’s jarring and not very nice for users either.

Critical CSS will mean that your single block of inlined CSS will now be a smaller block of inline CSS and then another file of non-critical CSS. Sounds great in theory, but in reality it is often unnecessary and an even worse experience.

Some people swear by it, others don’t.

In my experience, I’ve always struggled to configure critical CSS smoothly. The only decent attempt I’ve had was with LiteSpeed Cache and that does it all automatically for you, once it’s set up right.

Due to the difficulty of delivering a stable critical CSS process, most plugin developers only offer half a solution. Obviously it’s no good for just one page. You need it for every one.

This isn’t a dig at FVM. It’s a tricky thing to do correctly, especially when you’re only one plugin. LiteSpeed has an advantage when they’re running the LiteSpeed Web Server, which is what Hostinger use. That’s partially why I got it running nicely.

Fast Velocity Minify Developers

Fast Velocity Minify Developers

Critical Path CSS Solutions:

Autoptimize have partnered with a service that offers autogenerated critical path CSS for a monthly fee. It isn’t much, only a few dollars. However, I stuck the companies website through a few testing tools and wasn’t impressed, but that doesn’t mean it won’t be useful for you.

It might only be a few dollars per month, but when LiteSpeed Cache is free, why would you bother? LiteSpeed’s version is also much simpler to configure.

The more tools you can combine under one plugin – as long as you use them all – the better.

So how should I inline my critical rendering path CSS?

Ideally go with my preferred option of inlining your CSS. It’s by far the easiest. You can go about your normal WordPress business without any fear of your site breaking, once you’ve got it configured correctly.

Secondly, if you have to go down the Critical CSS path route, use LiteSpeed Cache’s automatic critical path css genration. It’s working well for me on my test site.

Thirdly, to do everything yourself. Here’s what you need to do:

  1. You need to use Pegasaas’s critical path CSS generator, or the one from earlier, then paste your CCSS for each page in a CSS input form. Most modern themes now include an extra-CSS box on each page. If not you can add one using the Simple CSS plugin. It’s important to do each page’s critical CSS on a page-by-page basis. (The downside is that every time you alter a page you’ll need to update this).
  2. Dequeue all your other CSS files. Then when you load a page, the critical CSS will load inline from the page’s HTML. Your other regular CSS files will load afterwards. This method won’t give you the least number of files, but what matters most is getting content on the screen as quickly as possible.
  3. You can still minify and aggregate your CSS files, but EXCLUDE the inline CSS from the aggregated files. Find the id of the CSS input box and exclude it from aggregation, by adding it to the ignore list. This will ensure your CCSS is inlined for speedy rendering. Then your secondary files can be aggregated to reduce requests. Adding this last bit will ensure the best of both worlds. Fast first render and reduced requests overall. However, if you’re struggling just do numbers 1 and 2.

For me the difference between Fast Velocity Minify and Autoptimize is none existent. They’re both amazing plugins from talented developers. If I have to be super critical, then I will say that there are a few strange choices regarding FVM.

It’s possible that this is down to the finer details being lost in translation from Spanish to English.

The inline option seems strange. I did take this up with Raul a while ago, as I asked why would you need to inline anything in the footer? Surely it’s better to inline in the head and then download the remaining files.

Autoptimize on the other hand seems to have more logical options, but I’m being picky here.

14. Server Info Tab

For finding out information regarding your origin server setup, the server info tab is where it’s at. There’s a treasure trove of information for tweaking and debugging.

Will you need it? Maybe not, but it’s still good to know it’s there for a rainy day.

Fast Velocity Minify Server Info
Fast Velocity Minify Server Info

15. Help Tab

This last section has a few useful links that you can use, but let’s be honest, we’re all that used to going to Google every time we need something, how often do such things get used?

Suppose, like the Server Info tab, it’s better they are there than not.

Fast Velocity Minify Help
Fast Velocity Minify Help

16. Fast Velocity Minify Summary

Now that we’ve covered all the good stuff, how do I rate Fast Velocity Minify? Well let me say outright: it’s a brilliant plugin, which is why I gave it a five-star review.

For a good while, I consistently struggled to imrpove upon my benchmark results when I switched to Autoptimize. Using a Tim Cooke catchphrase, it ensured the ‘stickiness’ of FVM was, well more sticky than its rival. That has since changed, as my skills have improved and also getting to know these plugins in finer detail.

When we are using such highly complex plugins with endless features, it’s only natural that it takes time to get to know them. We need to know how they interact with WordPress, our theme, plus our own ability.

The more difficult they are to optimize, the more rewarding when it all comes together.

So on my way out, before I turn off the lights. I’d like to say thank you Fast Velocity Minify. You genuinely played a big part in my love affair with speeding up WordPress webistes… and you still have a part to play. We’re only just getting to know one another, after all.

Hope you enjoyed the read. If you liked, disliked or have anything you’d like to add. Please say your piece in the comment section below.

Until next time. Bye for now.