Most WordPress sites have a lot going on;
Plugin’s have their own styles
If you’re using a page builder, that has it’s own CSS
The theme you have installed has it’s own CSS
Traditionally each of the above will have their own main.css — a file that includes all styling for that particular functionality. Sometimes there’s more than one, but usually there’s a single file.
The problem is, you rarely need all styling at any one moment — a page that only has a paragraph and heading does not need the styles for testimonials, sliders, image galleries etc.
In the past, you might have split your styling into components like this anyway e.g. testimonial styles were named .testimonial-element h2 and so on.
But with the rise of https://tailwindcss.com/ and other utlility-first frameworks, this isn’t easily replicated (at least, not in the same way).
FEAR – when a component is removed or it is undergos major changes, there is a developer-fear that you might remove styles that are in use somewhere else. This is less of a problem with utility-first frameworks like Tailwind, but it still requires consideration.
Separate your components into folders e.g. /testimonial
Inside each folder, include your components and parts testimonial-heading.php testimonial-card.php
Set up your framework config e.g. tailwind.config.js so that a component-specific css file e.g. testimonial.css is generated alongside the single global.css file
Load your (now, much smaller) global.css everywhere, but only load your component one testimonial.css as and when the component is used on your site, example:
if (has_block('acf/testimonial')) {
wp_enqueue_style('testimonial');
}
Ultimately we’re doing this for 2 reasons;
It improves site speed/performance, which has a direct impact on a) pagespeed and SEO rankings and b) a customers experience with the site
It makes managing and maintaining CSS/components easier — see FEAR above; since your styling is directly attached to components, it means that there is no need to consider if removing/changing a class will cause issues elsewhere on the site.
A personal reflection on artificial intelligence, creativity, and work—exploring fear, ethics, and why the human journey behind art still matters in the age of A.I.
Read more ->
Learn why committing compiled CSS and JavaScript to Git creates merge conflicts, deployment risk, and unreliable builds — and how to manage build artifacts safely with CI/CD.
Read more ->
Most deployment problems aren’t caused by code — they’re caused by the pipeline. Learn how better CI/CD pipelines reduce risk and create predictable, stable releases.
Read more ->