The setting trap
If you treat Bricks as a “get out of jail free” card for performance, you have already lost. Most developers switch to Bricks to escape the bloat of Elementor or Divi, but they bring their bad habits with them. A clean builder is just a tool. If you don’t configure it properly, you are still shipping a bulky site. It just has a different name in the source code.
Performance is a deliberate Choice. Bricks gives you the keys to the kingdom with its granular settings, but those switches do nothing if they stay in their factory positions. I have walked into projects where a developer complained about a 65 mobile score while loading three different icon libraries and a dozen unnecessary global scripts.
Core Web Vitals isn’t a game of adding more optimization plugins. It is a game of aggressive subtraction. You don’t need a heavy fancy cache plugin to mask a bad build. You need a lean DOM and a narrow asset list.
A high PageSpeed score is earned in the settings panel, not the plugin repository.
It starts with acknowledging that “default” is rarely “optimal.” If you aren’t touching the toggles, you aren’t developing. You are just dragging and dropping into a different kind of mess. Let’s look at how to actually strip this builder down to its fastest possible form.
Managing the DOM
Bricks is famous for having a clean DOM, but a developer can still mess it up by nesting containers 6 levels deep. Just because you can put a block inside a div inside a container inside a section doesn’t mean you should. I’ve seen builds where a simple card layout had 12 nested elements.
Excessive nesting is the silent killer of interaction to next paint scores.
Browser engines struggle to calculate the layout when the tree is too complex. Keep it flat. If you can achieve a layout using CSS Grid on a single container, do that instead of using 4 nested divs with “Flex” settings. It takes 10 minutes longer to build it properly with Grid, but the performance payoff is permanent.
“Why is my mobile score so low?” is the question I hear most often. Usually, the answer is an oversized image in the hero section. Bricks makes it easy to set different images for different breakpoints. Use it. Never serve a 2000px wide hero image to a 390px wide iPhone.
I make it a rule to use WebP for everything. If a client sends a 5MB PNG, I don’t just upload it and hope for the best. I run it through an optimizer and convert it before it ever touches the WordPress media library. And yes, that includes the icons. Using SVG for icons instead of an icon font library like FontAwesome is a non-negotiable step. Loading a 150kb font file just to show a “search” magnifying glass and a “facebook” logo is objectively bad practice.
The CSS strategy
External files versus inline CSS is an old debate, but for Bricks, the answer is usually “External Files.” When you set Bricks to output CSS to external files, the browser can cache those files. If you keep everything inline, that CSS has to be downloaded every single time a user clicks a new page.
However, there is a catch. Sometimes the external file is too big. This is where the “Post CSS” feature in Bricks comes in. It only loads the CSS required for the specific elements on that page. It is a massive improvement over the old way of doing things.
What I find is that people often forget to regenerate these CSS files after making global changes. You spend 2hrs tweaking the site, look at the front end, and it looks like a broken mess. Or worse, it looks fine to you because you are logged in, but the visitors are seeing the old, bloated cached version.
Rethink how you use “Global Classes” too. Over-reliance on global classes can lead to a massive global CSS file that slows down every page on the site. If a style is truly unique to one section on the homepage, don’t make it a global class. Keep it localized.
Real world caching
You can have the cleanest Bricks build in the world, but if your hosting is slow, your Time to First Byte (TTFB) will ruin your Core Web Vitals. I stopped using cheap shared hosting 2yrs ago. If the server takes 800ms just to respond, you have already lost the battle for a 90+ score.
I prefer a stack that includes a high-quality object cache like Redis. Bricks handles database queries well, but WordPress itself is still “heavy.” Redis takes the load off the database, which helps with the “Initial Server Response Time” metric.
Once the server is fast, look at your scripts. Bricks allows you to disable scripts for elements you aren’t using, like scripts for the “Accordion” or “Tabs” elements. If your page is just a landing page with text and images, why are those scripts loading? Go to the settings and turn them off.
The most common bottle-neck I see is third-party scripts. A client says, “We need 4 different tracking pixels and a live chat widget.” You add them, and suddenly your 98 score drops to 45. There is no way around this other than delay-loading those scripts. I use a “Delay Execution” strategy for anything that isn’t required for the initial paint. The chat widget doesn’t need to load until the user scrolls or moves their mouse.
The final check
The job isn’t done when the site looks good in the builder. The builder is a lie. It doesn’t show you the real-world performance because it loads its own heavy scripts to make the editing possible. You have to test the front end, logged out, in an incognito window.
I always check the “Avoid enormous network payloads” warning in Lighthouse. If I see it, I know I’ve been lazy with image compression or script management. Most of the time, the fix is just resizing an image that I thought was “Small enough.” It rarely is.
Running a site through PageSpeed Insights is one thing, but you should also use the “Search Console” to see how real users are experiencing the site. Laboratory data is a guess. Field data is the truth. If your field data is failing, it doesn’t matter what your local test says. You have to optimize for the slowest device your audience actually uses.
Building with Bricks is a choice to be a better developer. It gives you the tools to be fast, but it doesn’t do the work for you. You have to be intentional. You have to be disciplined. You have to care about the code that is actually being output.
When you get it right, the results are obvious. A site that loads in under 1 second feels like a different product entirely. It feels professional. Clients notice it even if they don’t know what a LCP score is. They just know it “Feels fast.” That is the goal.
Stop looking for a single plugin to fix everything. Start by turning off the junk you don’t need in the settings. Flatten your DOM. Optimize your images before you upload them. Host your fonts locally. Use a fast server. If you do those 5 things, you are already ahead of 90% of the other sites on the web. The rest is just fine-tuning.
