FCP metrics depend on what you put above the fold, it’s not something you can optimize with PHP.
You can reduce all metrics by having a fast time to first byte and using a fast cdn.
A cache plugin may help, but it’s ultimately the response time of your server.
Nevertheless, loading css first and js later is already what FVM is doing, so there is nothing new on that post, other than the critical path css.
I don’t think you understand what is involved on rendering the Critical path css.
It’s not only about generating and adding the critical path… it depends on what you have above the fold.
If you use a slider plugin that requires js to render it, the critical path will not help the FCP in any way, since it only happens after JavaScript finishes loading.
The critical path css would be useful only, if your site has nothing made with javascript above the fold and if you had a very large css file.
In those cases, you could generate the critical path css, and if you were to remove all scripts and css files from the page, the content above the fold, would need to look exactly like if you never removed the css and js files… that is what critical path css is.
But critical path, varies on screen size… it’s not something you generate and reuse for all screens and sizes, or for all pages.
The benefit of using critical path css is negligible, if you have a normal css file and your content above the fold doesn’t require javascript to render.
If your css is small, then there is an option to inline it as well, so there is no render blocking.
With FVM adding a preload header, followed by a render blocking css file served from a good cdn (with brotli 11 precompression for example), your styles will load without render blocking, or within a few ms.
If you have a high FCP, LCP or CLS… it’s most likely because of how you designed the site, not a matter of optimization.
Just using revolution slider for example, can decrease your mobile scores by 50+ points on pagespeed insights, and I can 99% guarantee, that no amount of deferring css and adding critical path css is going to fix it.
LCP won’t happen until at least jquery and revolution slider scripts finish downloading and executing.
With a slider above the fold, that content only finishes after all scripts execute.
Since you also need to defer scripts, that means it will only finish after everything else.
There are services to generate a critical path css.
WP Rocket does it… but in many hosts, it creates a lot of issues.
For example, they will send a request to a remote api.
That api will take a few minutes to fetch your page and generate the critical path css (which won’t be accurate anyway for most sites using javascript above the fold).
After that, it sends the information back to your site.
Your site then needs to purge the cache and update it.
If your server has some sort of cache, it may not work, break your site layout or take hours to show.
Every time you change a page, it repeats this again.
It’s very inefficient and useless in most cases.
If you care about that level of micro optimization, you need to hire a developer for that.
You must visualize the site with only the critical path css code (no js/css files) and see if it looks exactly the same, as the normal site with all scripts and styles.
If it’s different… you are just telling google that you have a critical path and the metric may not trigger (it will eventually) but your site is effectively slower, since it has more code.
It’s also likely you will see a FOUC effect, where your site initially looks disfigured until all that async css actually finishes (especially in slow connectivity).
So no, this is not something you can do automatically on wordpress.
We could do it up to a certain level if this was nodejs… but what you want, it’s a manual process on wordpress, unless you don’t need javascript to render your layout.
Since there is no way to know, without using some visual comparison api to test all that, this is not something I am going to invest my time on.
