I don’t think that this is something I can fix by just looking at the frontend, that’s why I asked to contact me directly.
However, looking at the code, the PHP code is indeed there, but this could be for some other reason other than to be opened directly. It could be cached somewhere that you cannot purge, especially if you use disk caching or opcache.
The issue however, is that I have replicated a fresh install and used the same exact path for that php file and it didn’t get merged.
Can you check if the php file itself doesn’t have any invisible character before <?php ? (I only check for <?php if it’s in the beginning of the string)
I can add a more broad check, but I would need to test it myself before the next release update, so again, you can contact me directly.
—
In regard of your other questions:
a) You do not need to restore a backup. You can simply add .php to the JS ignore settings and they will be left alone until we can sort it out.
b) You need to understand that jQuery is not meant to be in the footer. If it can be in the footer, it means it can be deferred. If it cannot be deferred due to inline code dependencies, it has to go in the header so it’s available when the body starts.
If you put jquery in the footer, it’s still render blocking… hope you understand that, it’s just render blocking a while later.
Looking at your site, the only jquery dependency I see happens to be in the footer, for the cookie check. But then, your jquery would need to come before this for it to work, so it’s not exactly in the footer, but rather in the body.
For your case, you can copy the recommended settings for the render blocking scripts and leave that option empty. You can then copy it to the defer section, so in this case, you can defer jquery so it doesn’t get render blocking.
However, because you still have a jquery reference in inline scripts, you also now need to add jQuery( to the inline dependencies option, so that whenever an inline script has the snippet jQuery( it will be wrapped around with a function to make it also deferred and load after jquery (which is now being deferred).
Finally, if you render block jquery on the header because it’s ignored, yes, it will affect your scores. However, if you merge it in the header section, the resulting file it will have a preload header which will allow it to be downloaded before it’s render blocking.
Of course, your compression level may be slowing down the time to first byte, and that is why it shows up as render blocking. But if you were the merge jquery in the header, and add for example, a propper cdn like bunnycdn.com … it will most likely, not show up as render blocking anymore, or at least, it won’t affect your scores because it will be under 100ms (dependending on the server, layout, etc).
FVM allows you to fine tune all these settings, and I have no idea why on your site, it’s merging of PHP files. I can find out, but I need proper access.
I will add an option to bypass file merging from the disk and instead, make the requests via http. But merging scripts via http is going to be slower, even if we cache them after the first request, because you have a lot of files to merge.
I’ll also add another extra check to try and detect more accurately the .php files, but like I said, I cannot replicate it on any of my test setups.
I will do what I can to apply any fixes on FVM and get it to work, but if you are serious about speed optimization, you can also check my profile and hire me for a more complete optimization.
Even with the full potential from FVM, there is still plenty of stuff you can do to optimize it further… but this has to be audited, not just by installing a bunch of plugins.
I finished looking at the frontend, so you can now do whatever you wish to do.
