I’m just getting started with ACF Blocks, which to an old-school PHP developer like me is a good way to start to free myself of the Classic Editor plugin.
So, in good old, modular fashion I have a blocks folder with lots of subfolders and they all have their CSS. But they’re beginning to build up. Lots of HTTP requests for tiny style files.
I know that eventually I can get Litespeed to do the heavy lifting and generate a new CSS file but I’m curious as to whether I’m using best practice or whether I should just reference one large CSS file from all blocks.
I know that only those files that are needed are loaded but that also makes caching tricky as every page on my site will have a different set of CSS files.
Opinions?
I struggled with this myself after migrating to using block.json (ACF v2 blocks). One of my issues was with visible cumulative layout shift due to Classic/Hybrid themes loading CSS in the footer. I posted about it Here.
I also tried moving all CSS to a single file as well, but that became inconvenient when reusing blocks. Currently I also use separate CSS/JS files within separate block folders which appears to be the new “norm” for building ACF blocks.
From what I can tell, the concerns you mention as well as issues I faced will continue until moving to an FSE block theme. There is some good information regarding filter options that are available that may be of benefit for asset loading Here.
I am not 100% certain, but I believe WP Rocket caching has the ability to filter out unused CSS to reduce the overall load. I may investigate this as a possible solution until I jump onboard to FSE block themes.
This is not specific to blocks or classic editor. For performance the best choice is to include local inline CSS for small chunks of CSS code that may or may not be needed when the page is generated.
I realize this is counter-intuitive for most of us old school developers and it took me a while to accept as well.
Multiple small CSS files == bad for performance
Large CSS with styles that are not used == bad for performance
Inline CSS == better for performance.
So in the same file where you are generating the HTML you just add <style> ..... </style>
. Even better if you do so in a way that only includes this once per page if the same code is called more than once.
I struggle with this too. In my usage, I’ve found the large css shared works better than multiple css, especially on well cached servers and personally I find it way easier/faster to develop this way but it’s really not the WordPress way. I’ve seen a few block plugins using the inline style tags just above the block. It appears like not the right thing to do though just in a web dev sense and perhaps could look pretty messy with media queries in there but I guess I may go down this route. Would this affect specifity at all?
How’s everyone’s experience with inline style tags
Plz know that using multiple CSS files for each block can lead to excessive HTTP requests and inefficient caching, especially if your blocks are modular and numerous. I would suggest you to consolidate your CSS into one larger file to reduce the number of requests and improve caching efficiency.
It simplifies maintenance and optimizes performance and ensures that necessary styles are readily available across your site without compromising speed. And tools like Litespeed for CSS generation can further streamline the process and enhance performance.
@jenniwilli I think that’s all very obvious but there are two things at play here; the interaction between the CSS that’s needed in Edit Page to display the blocks and the frontend CSS.
It would be relatively easy to develop in the traditional style with a central SCSS compiling to single CSS.
But how do you use that in the admin?
You must be logged in to reply to this topic.
Welcome to the Advanced Custom Fields community forum.
Browse through ideas, snippets of code, questions and answers between fellow ACF users
Helping others is a great way to earn karma, gain badges and help ACF development!
We use cookies to offer you a better browsing experience, analyze site traffic and personalize content. Read about how we use cookies and how you can control them in our Privacy Policy. If you continue to use this site, you consent to our use of cookies.