Most slow Bricks Builder sites aren't slow because of Bricks. Bricks outputs lean HTML. When a Bricks site fails Core Web Vitals, the cause is usually an oversized or lazy-loaded hero image, third-party scripts or slow hosting, with a few default Bricks settings making it worse. Fix things in this order: server response and caching first, then LCP (hero image and fonts), then CLS (reserved space), then INP (scripts and animations).
I've built several sites on Bricks, including the Ravens Ait venue website, the Taxocity tax services website and the Aura Clips agency site. I also wrote Geo Targeting for Bricks Builder, a WordPress.org plugin that shows or hides Bricks elements by visitor country, so I know how Bricks renders elements. This is the order I work through when a Bricks site is slow.
What scores does a Bricks site need to pass?
A Bricks Builder page passes Core Web Vitals when LCP is 2.5 seconds or less, INP is 200 milliseconds or less and CLS is 0.1 or less. Google's Web Vitals guidance measures these at the 75th percentile of real page loads, split into mobile and desktop.
That 75th percentile is the bit people miss. Your laptop on office Wi-Fi isn't the test. A mid-range phone on mobile data is. That's why plenty of Bricks sites that feel quick in the builder still fail on mobile.
Is Bricks Builder actually slow?
No. Bricks writes cleaner markup than most older page builders, and its settings let you remove things WordPress loads by default. A Cardiff agency's Bricks speed guide comes to the same conclusion: hosting, image sizes and plugin count matter more than the builder.
Where Bricks sites go wrong is the build. Containers nested six levels deep. A hero image set as a CSS background. Every element animated. The Google Fonts call never switched off. You can fix all of that without a rebuild. If you're on Elementor and thinking of switching for speed, I've written about that decision in Elementor to Bricks migration.
How do I find out which metric is failing?
Run the page through PageSpeed Insights and read the field data at the top. That section tells you which of LCP, INP or CLS fails, and it's what decides whether you pass. The Lighthouse score underneath is a lab test on a simulated phone. It's useful for finding causes, but it can't measure INP, so web.dev suggests Total Blocking Time as the lab stand-in.
Test each template type, not just the home page. On a Bricks site one template can drive dozens of pages. Ravens Ait, for example, has 20+ event pages. When pages like that share a template, a problem in the template shows up on every one of them, and one fix covers the lot.
If the report reads like a wall of jargon, paste it into my free Page Speed Fix Planner. It shows which Core Web Vitals pass or fail, what's causing each one, and ranks the fixes by impact and effort.
Which problems come from Bricks and which don't?
Only a few speed problems come from Bricks itself: lazy-loading the hero, inline CSS and the Google Fonts call. You can change those settings in minutes. Images, third-party scripts and hosting are where the big gains are, and that's where most of the time and budget goes.
| Problem | Where it comes from | Metric it hurts | Fix |
|---|---|---|---|
| Hero image lazy-loaded | Bricks default | LCP | Set the hero image to load eagerly |
| Hero set as a CSS background | How the section was built | LCP | Use an Image element with object-fit: cover |
| Google Fonts from Google's CDN | Bricks setting | LCP, CLS | Self-host, turn on Disable Google Fonts, preload |
| Inline CSS on every page | Bricks setting (default) | LCP on repeat visits | Switch CSS loading method to external files |
| Emoji, embed and jQuery migrate scripts | WordPress defaults, toggled in Bricks | Small LCP and INP cost | Disable in Bricks > Settings > Performance |
| Oversized images | Content uploads | LCP | Resize, convert to WebP or AVIF |
| Chat, HubSpot, GTM tags, pixels | Third-party scripts | INP, LCP | Load only where needed, trim tags |
| Slow server response | Hosting, no page cache | LCP | Page caching, better hosting |
| Cookie banners, promo bars | Plugins and third parties | CLS | Overlay them or reserve space |
How do I fix LCP on a Bricks site?
Get server response fast, then make the hero an eager-loaded, correctly sized Image element and self-host your fonts. LCP is the metric most Bricks sites fail, and the hero section is nearly always the reason. Here's the order I go in.
Check server response first. If the first byte is slow, nothing else here helps much; as WPMade puts it, slow hosting ruins Core Web Vitals however clean the build is. Get page caching working, at host level or with a plugin like LiteSpeed Cache, and host near your visitors.
Make the hero image load eagerly. The Bricks settings documentation says Bricks applies native lazy loading to images by default. That's fine below the fold and wrong for the hero. Set the hero image's loading attribute to eager, as this Bricks optimisation write-up recommends. Don't turn lazy loading off for the whole site.
Stop using a background image for the hero. The browser only finds a CSS background image after it has downloaded and parsed the stylesheet, so your biggest image starts loading late. An Image element set to cover the section looks identical, and the browser sees it in the HTML straight away. If the design really needs a background, preload that file.
Resize and compress. Serve the hero at the size it actually displays, in WebP or AVIF. Bricks lets you set a different image per breakpoint, so phones can get a smaller file. I built Under1MB to compress and convert images in the browser for exactly this job.
Sort out fonts. Bricks loads Google Fonts from Google's CDN unless you turn on Disable Google Fonts. Upload the fonts under Bricks > Custom Fonts, disable the Google call and turn on Preload custom fonts.
Avoid the Webfont Loader option
Bricks documents that its Webfont Loader (JS) method hides site content until fonts have loaded. You trade a brief flash of unstyled text for a slower LCP. Self-host and preload fonts instead.
Switch CSS to external files. By default Bricks writes page CSS inline. With external files, browsers and CDNs can cache it. After you change breakpoints, click Regenerate CSS files. Then check menus and maps, because the Bricks forum has bug reports about mega menu styles and map elements breaking with this setting.
How do I fix CLS on a Bricks site?
Reserve space for everything that loads late: embeds, sliders, banners, popups and web fonts. CLS measures how much the page jumps around while it loads. Bricks image elements normally output dimensions, which helps. The shifts tend to come from content that doesn't.
- Images and embeds without a size. SVG logos, images in code elements, YouTube iframes and map embeds often have no width and height. Set an aspect ratio on the wrapper.
- Font swaps. When a web font replaces the fallback, text reflows. Self-hosting and preloading shorten that window, and a fallback font with similar proportions makes the jump smaller.
- Bars and popups injected late. Cookie banners, promo bars and newsletter popups that push content down are classic CLS causes. Overlay them instead of inserting them above the content.
- Sliders and carousels. If a slider only gets its height once JavaScript runs, everything below it jumps. Give the slider container a minimum height for each breakpoint.
- Sticky headers that change height. A header that shrinks on scroll and isn't fixed-positioned moves the whole page. Make it fixed and reserve its height.
How do I fix INP on a Bricks site?
Cut third-party scripts, animations and DOM size. Bricks ships little JavaScript of its own, so INP problems almost always come from what's been added on top. INP measures how quickly the page responds when someone taps or clicks.
Audit third-party scripts. Venue and booking sites pile these up: HubSpot forms, Stripe, GA4, Tag Manager, review widgets, chat, ad pixels. Ravens Ait uses HubSpot forms and Stripe bookings, and the business needs both. So ripping scripts out isn't the answer. Load each one only on the pages that use it, and after user interaction where that's safe.
Trim Tag Manager. The Aura Clips site runs GA4 through Google Tag Manager. That's a sensible setup, but containers grow over time and every tag adds work on the main thread. Delete the tags nobody looks at any more.
Keep lead capture light. On Taxocity, every lead is saved to a Google Sheet. Where it fits, a native form that sends entries to a sheet can mean one less embedded third-party form script on the page.
Tone down interactions and animations. Bricks interactions and GSAP scroll effects on every element add up. As this Bricks animation guide points out, GSAP itself is efficient. The trouble is how much you ask it to do. Animate transform and opacity only, and on fewer elements.
Shrink the DOM. Deep nesting, mega menus with hundreds of nodes and query loops that render 100 posts all slow down every interaction. Paginate the loops.
Turn off what you don't use. Under Bricks > Settings > Performance you can disable emojis, oEmbed and jQuery migrate. The documentation explains when each is safe to switch off.
What order should I fix things in?
Six steps: measure each template, fix the server, fix the LCP element, apply Bricks settings, stop layout shifts, then cut script work and retest.
- 1
Measure per template
Run PageSpeed Insights on the home page and one page from each Bricks template. Note which metric fails in the field data.
- 2
Fix the server
Get page caching working before you touch anything else.
- 3
Fix the LCP element
Make the hero an eager-loaded, correctly sized Image element. Self-host and preload your fonts.
- 4
Apply Bricks settings
Switch CSS to external files and disable Google Fonts, emojis, embeds and jQuery migrate where safe. Then regenerate CSS.
- 5
Stop layout shifts
Reserve space for images, embeds, sliders, banners and popups.
- 6
Cut script work
Load third-party scripts only where needed, trim Tag Manager and tone down animations. Then retest forms, payments and tracking.
The last step is the one people skip. Delaying scripts can quietly break a HubSpot form or a Stripe checkout, and a green score is no use if bookings stop coming in. Do the work on a staging copy and test every form and payment flow before it goes live.
How much does fixing Core Web Vitals on Bricks cost?
Published rates in the guides linked below put WordPress speed work at about $150–$400 for settings-level fixes, $300–$1,200 for code-level work and $500–$2,000 for WooCommerce stores. I couldn't find much pricing specific to Bricks, so general WordPress rates are the fairest benchmark. One detailed guide breaks rates down by scope, and two other providers publish flat or hourly prices:
| Scope | Typical market range | Source |
|---|---|---|
| Settings-level optimisation | $150–$400 | Fysal Yaqoob |
| Code-level optimisation | $300–$1,200 | Fysal Yaqoob |
| WooCommerce speed work | $500–$2,000 | Fysal Yaqoob |
| Flat-fee optimisation pass | $299 | WP Site Kept |
| Hourly specialist | $40 an hour | Online Media Masters |
The price moves with how many templates need work, how many third-party scripts the business depends on, whether you need a hosting move, whether WooCommerce is involved and whether the hero design itself has to change. My post on WordPress speed optimisation cost goes into more detail. Be wary of anyone promising a guaranteed lab score. A Lighthouse number tells you nothing about field data, and the quickest way to fake one is to delay every script, which can break your forms.
How long until Google sees the improvement?
Lab scores change the moment you deploy. Google's field data takes up to 28 days to catch up, because PageSpeed Insights and Search Console report on real visitors over the previous 28 days. Once your field data shows a pass, start validation in the Search Console Core Web Vitals report.
What should I ask a developer before hiring for Bricks speed work?
- Will you measure field data before and after, for each template, not just the home page?
- Which fixes are Bricks settings, and which are images, scripts or hosting?
- How will you test forms, Stripe payments and analytics after changing how scripts load?
- Will you work on staging first?
- Will you remove plugins, or just add another optimisation plugin on top?
If your site is on Elementor or a classic theme, read how to fix Core Web Vitals on WordPress instead.
What's the next step?
Run your home page and one page from each template through PageSpeed Insights, then paste the report into the Page Speed Fix Planner for a ranked fix list. If you'd rather hand it over, my Technical SEO and Core Web Vitals service covers Bricks sites end to end, or book a 20-minute call and send me the URL.
