Hi there, thank you for your message.
The code you referred turns out to be legacy code from FVM 2 (and as you wrote), the purpose was to exclude certain scripts from specific tests (pagespeed insights, gtmetrix and webpagetest.org).
It was a feature that existed as an option on wp-admin (disabled by default), for developers to test the impact of the “specified scripts”, fonts, or ajax requests on performance, but without impacting real user experience.
My original purpose for having this available, was so that users could test for example, the impact on performance after adding a new plugin, and in case it was significant, decide not to use it or to replace it. The conditional exclusion existed, so that while they test this, it wouldn’t affect the live site (a lot of people test stuff on the main site).
Furthermore, FVM scripts optimization works by having someone (usually a dev) specifying which scripts or paths are to be optimized (minify, defer, or delay) and if you do not specify them, it simply ignores all scripts by default (nothing is processed).
For example, CSS font awesome files were starting to be included on a lot of themes and plugins a few years ago, and that had a big impact in performance. I allowed 3 options for font-awesome on FVM 2, looking like this: https://i.imgur.com/3pqgvVq.png
By default, it deduplicated and merge (or inline) font-awesome css files. Optionally, it allowed you to load them async with loadCSS (link preloading was not widely supported at that time) and additionally, it allowed you to async + exclude it from the tests. In other words, you could test how it performs with or without it, without actually removing it for the regular users.
For scripts, there was a dedicated setting to enable this, looking like this: https://i.imgur.com/QktIYPS.png
Note that you could already choose to defer the specified scripts (the normal optimization method), however a lot of scripts from themes and plugins were not compatible with defer or async, so this option allowed you to see what would be the performance increase “if” you could defer all scripts, again, without affecting the normal users. That way, you could decide if the effort of replacing a plugin or theme was worth it for performance purposes.
The other option was for specified, ignored scripts, for example, a tracking code such as googletagmanager, google analytics, etc, or when using broad match for defer, ie: ‘/themes/’ you could want to exclude 1 or 2 files that were not compatible with defer.
You could measure the impact on this, by testing with forced defer for the tests, which would then tell you, if you should spend time refactoring the file to support defer or not.
Fast forward some time, and I realized that some developers were actually using this to cheat on the tests for their clients, so I felt compelled to make the decision on FVM 3 (already late 2020) to remove this feature, which was met by a lot of protests of angry developers when their clients started complaining that their scores went down.
I tried at that time, to explain that having a good score was not the same as having good web vitals metrics, but eventually I gave up on that, as some people cared more about the test results than the actual performance.
After FVM 3 release, I am basically just maintaining it and doing small bug fixes when reported, as I have to focus on other things. I have removed that function and fixed a couple of bugs that were pending on version 3.2.9 and pushed an update, so thank you for referring this to me.
Kind regards
