Raul P.

sorry about that, fixed now.

Sorry the late reply.

From what I see, there are a few errors on your site with scripts and styles loading from an alternative url. I suggest you take a look at google chrome console log for seeing those errors.

It also seems the site was not adjusted properly when migrating from staging or dev to the main domain. There are references like this:
https://secureservercdn.net/198.71.233.46/bz5.abc.myftpupload.com/wp-includes/js/jquery/jquery.min.js?ver=3.6.0&time=1665071547
URL should match your domain, ideally.

The scripts errors as well, when FVM attempts to minify them, it may break the layout.
This is because it stops executing when it finds the error and for example if the image are lazy loaded and require scripts to load, then it may not load them at all because execution is halted.

Sort all errors shown on console log first, and then FVM should work, I think.

I believe this should be sorted out on the latest 3.3.0 update, please test. Thanks for reporting.

I believe this should be sorted out on the latest 3.3.0 update, please test. Thanks for reporting.

It appears to be from the uncode theme, perhaps some customization done, or an intended update. The file names are static, but the query string is changing on every pageview.

Take a look via google chrome dev tools, under the network tab.
For example, these files (https://i.imgur.com/Y5fohtZ.png)

/wp-content/themes/uncode/library/js/init.js?ver=375711253
/wp-content/themes/uncode/library/js/plugins.js?ver=375711253
/wp-content/themes/uncode/library/js/app.js?ver=375711253

the query string (375711253) change on every pageview (just refresh and you can see it). https://i.imgur.com/65rE5re.png

—

The query string changing will not only prevent any minification from doing the intended optimization for these files (the minification always sees a different, new file) but it also prevents browser caching for those files (even without minification).

I suggest checking with your dev or perhaps the theme author (if it’s the original theme) on why they need dynamic query strings on those static files. Version numbers should be ideally tied to the plugin/theme version, not some random or other digit.

Thanks

Sorry to hear that. Can you share your url so I can take a quick look?
Nothing really changed regarding the logic of the minification, so I am just curious how it could happen.
Thanks

It’s as shown on the help section… database will (only) grow if you are minifying files with dynamic content, or with dynamic file names. If the content is dynamic and changing on every pageview, its minified as unique and stored, as it should. In that case, you will get a new minified file on every uncached pageview.

The options allow you to exclude them and have the plugin minify only the regular static files. Dynamic content cannot be minified, else it would minify on every page and slow things down.

During optimization with FVM you need to understand how optimization works and manually decide what to do with that type of content. It’s not plug and play, it’s a manual optimization plugin.

Thanks

• This reply was modified 2 years, 2 months ago by Raul P..

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

The purpose of the buffer is to capture the page and apply the optimization, hence it starts as late as possible, after the template loads on the (MAX) (latest) hook priority.

If you set it to zero and it works, that means the other plugin hooks somewhere between 0 and PHP_INT_MAX.

PHP_INT_MAX is the highest number possible, depending on your server.
Usually 2147483647 in 32 bit systems and 9223372036854775807 in 64 bit systems.

From a quick search, that plugin resorts to the buffer when the theme does not support overwriting the titles, and there is an option to disable that here:
https://aioseo.com/docs/aioseo_disable_title_rewrites/

You can try or wait until I have some time to investigate this conflict (and meanwhile you can use zero by editing the plugin… but watch out if the update breaks things again)

What is your site url, and do you see any reference to fvm minified files when you “view source” in incognito mode (google chrome).

And when you search for fbq( on the same source, did it change from the original (before enabling fvm) in any way?

The way you are explaining means, either FVM is not processing the page at all (no changes, so no delay) or the server (or some other cache plugin) cached the page before FVM could be executed.

Is there any error on the server logs?
Did you change the theme or add other plugins?
From which version did you update FVM?

Wordpress hooks run in order, so if some other code is stopping execution earlier (could be an error, or some ob_start() buffer), FVM may not have the chance to execute.

FVM executes on the template_redirect hook at the last position.

Thanks

Hi,

I see the fvmuag function on the link provided, however, I also see you are using wp rocket with the delay js option enabled.

The JS Enabled option delays scripts, so things only get defined after you interact with the page. Since the font optimization expects them to be already defined on page load (before interaction) it throws the error.

You need to exclude fvmuag on wp rocket delay js options.

However, if wp rocket is working fine for you, then probably you don’t need FVM.
FVM is for fine tuning of scripts and styles (manual) so those functions of wp rocket will interfere with it.

That means your server is overloaded, or has a very slow cpu speed and and as a result, it could not process the minification within 30 seconds.

Since there is also a server limit to cut a process if it doesn’t finish processing before 30 seconds, the server kills the process with a fatal error.

FVM minification usually only needs up to 1 second, and this only happens once per file found, unless you have dynamic file names (should be excluded), extremely large scripts and css files or a very large amount of scripts.

I would suggest you to try another server with more resources.

You can try not to merge css or js too, just doing individual minification, as that would be lighter.

Please try the latest update. Thanks

This is a bug specific of FVM on cloudways when we try to purge the cache.
An update will follow today to fix this, sorry about that.

I was going to suggest enqueuing the files as an action to wp_enqueue_scripts, not plugins_loaded, as per the docs example at https://developer.www.ads-software.com/reference/functions/wp_enqueue_style/
Nevertheless, it should work as long as it shows up on the page.

You are correct, as you realized on FVM3 styles are processed automatically, while scripts are a manual process where you choose what you want to defer (to prevent conflicts right after installing) or you could just add / and then exclude what you don’t want, ie: jquery for example.

On FVM 4 I am planning to add both manual and automatic optimization as well, but this will still require manual settings to prevent breaking things.

Thanks