Some of the FV Player users recently experienced issues with the last version – their videos were not playing. The reason was that there were bigger changes in our code and their websites used poorly configured CDN.
While CDN speeds up your site you must understand how it works to avoid issues and too much optimization which you don’t understand. Just make sure that you don’t remove query string versions – read on!
Don’t remove query string versions
Normally the FV Player script looks like this in your site HTML:
https://foliovision.com/site/wp-content/plugins/fv-wordpress-flowplayer/flowplayer/fv-flowplayer.min.js?ver=6.1.1
Site speed is important and everybody wants to speed up their website. So people use tools to test the load time of their websites and some of these tools (such as GT Metrix) suggest:
This results in:
https://foliovision.com/site/wp-content/plugins/fv-wordpress-flowplayer/flowplayer/fv-flowplayer.min.js
What that means is any browser which comes to your site will download that script, cache it and hold on to it for as much as a year (the exact time depends on the Expires HTTP header, which is in general set high for static website resources as CSS or JavaScript).
So then once the user comes back to your site a week later he will keep using the old script from his first visit. And it doesn’t matter that FV Player just introduced some new amazing feature, it just won’t be made available to him – until the user reloads the page at last.
If the query string would be kept in place, the version number in the query string would tell the browser that it’s time to download the script again as there are changes to it. Same can be achieved using the Etag, but then the browser must still request that file from the server to be able to see if the file has changed or not.
The paid WordPress caching plugin WP Rocket does this properly – the plugin lets you get rid of query strings but encodes the version number into the file URL. So if you have to do this (for a little benefit of making sure the “some proxy caching servers” are able to cache your JS/CSS) WP Rocket does a good job at it.
How CDN makes this worse
If your site also uses CDN and you are stripping the version strings from query arguments it will hold on to the old script version as well. So the user tries to reload the script but still gets the old version back.
So it’s important to make sure your CDN understands that these version numbers are in the query part of URL for a reason. Make sure you set:
- Bunny CDN – enable Caching -> General -> Vary Cache -> URL Query String
- KeyCDN – disable “Ignore Query String”
- StackPath – enable “Query String – Treat as separate cacheable item”
- Cloudflare - ”Caching Level” needs to be set to “Standard”
- CloudFront – “Query String Forwarding and Caching” set to “Forward all, cache based on whitelist” and enter “ver” for whitelist
Conclusion
Site speed testing tools such as GTmetrix make a lot of suggestions about how to speed up the website, but sometimes it seems they just add as many warnings as they can to appear as really powerful tools.
I’ve seen sites optimized to almost full Google Page Speed score which were still slow.
In the end, the only thing that really helps is reducing the number of items to a reasonable amount and mainly reducing the size of your CSS and JS – that will give you fastest initial page load time. Get ready to use a plugin such as Plugin Load Filter to selectively disable plugins for sections of websites where they are not needed.
If you ask how are you supposed to speed up your site, then we recommend using WP Rocket‘s Files optimization (Minification & Concatenation) feature. It will reduce the amount of JS and CSS files by 75% or so – all of these files will be grouped into a couple of files.
The downside is that really have to check for JavaScript errors on your website and exclude the scripts which are causing the issues, which is not an easy process – see their documentation - Resolving Issues with File Optimization.
As this plugin is paid, we are looking for a free alternative. We don’t mind paying for software, but we would like to see an open source solution.
Autoptimize is another powerful plugin which combines all the JS into a single file and all the CSS into a single file. It also does so without any errors, you can just install it and it’s done. However during our speed testing, we found that it doesn’t actually make the site load faster on mobile – a single big JS file is slower to load as a couple of JS files as browser can’t use the multiple connections to download it. That’s why we like WP Rocket more.
Both plugins name the minified CSS and JS files in a way that cleaning the minified cache results with a new file name and in every browser knows how to grab a fresh file.
Martin Viceník
Martin graduated as an engineer in Computer Science from Slovak Technical University in Bratislava. He grew up in Liptovský Mikuláš in northern Slovakia next to the beautiful Tatra mountains. He is the developer behind our FV Player.
Thanks this has been really helpful.
Hi Lisa,
thanks for stopping by and letting us know.
We’re glad you found it helpful!
Cheers, Sanela
The big question is:
Should I make a fine-tuned website the way ONE plugin developer wants it to be or should I remove the plugin and go for one that doesn’t cause errors with a fine-tuned website?
Hello Ray,
removing the query string versions can cause issues with any plugin that load its CSS or JavaScript files in front-end. Imagine that you are using some plugin called Amazin Plugin at version 1.1. It does certain things in your site front end. It loads /wp-content/plugins/amazin-plugin/js/script.js?ver=1.1 script to do so.
If you configure your website to strip the query string versions it will be stuck with loading /wp-content/plugins/amazin-plugin/js/script.js. And then when version 2.0 is out and it brings amazing new feautures your site visitors won’t get these as their web browsers will keep hanging to the old /wp-content/plugins/amazin-plugin/js/script.js file which they have already cached. Normally your site would load /wp-content/plugins/amazin-plugin/js/script.js?ver=2.0 and everything would be fine – the web browser would see the difference in URL and fetch the new file.
If you want to remove the query string versions, you need to do it properly. For example WP Rocket does it properly – it makes the query string versions part of the file URL. So then GT Metrix doesn’t complain about it.
Any way, I really think this claim that removing the query string versions will speed up the site is bogus – GT Metrix says that if stops “Most proxies, most notably Squid up through version 3.0” from caching these files.
Squid version 3.0 is deprecated since March 2010, is anybody still using it?
And what is the worst thing that can hapepn if you don’t don’t remove the query string versions? The proxy will have to fetch it again. It will still be properly cached in the browser. Or does it break the browser caching routine too?
What would help is if GT Metrix wouldn’t be making these claims, it would save us this article and this discussion.
Thanks, Martin
WP Rocket: The worst plugin for me. It instantly destroyed my website, even with all options deactivated. Even with all plugins tested against each other. It only went back to normal after completely removing WP Rocket.
A live website with a complicated structure of plugins and layout isn’t compatible with WP Rocket.
Hello Ray,
we do have objections against WP Rocket, but it’s nothing so critical as you described. In general we have found their support to be useful.
It doesn’t matter if you use WP Rocket or not, other plugins give you asynchronous loading of CSS/JS and critical CSS too. That actually matters, unlike removing the query string versions (which WP Rocket seems to do properly by the way).
Thanks, Martin
To make it more clear – you said:
We are not asking you to fine tune your website. It’s GT Metrix who is asking you to remove the query string versions. We are saying – don’t do it, it’s not worth the trouble.
To optimize your website just:
WP Rocket does a great job at it. Although the cache purging could be more effective.
Thanks! Martin