The short answer
Most slow Bricks sites share the same four causes, in roughly this order: hosting, images, fonts, and third-party scripts. The builder is rarely the bottleneck. Measure first with PageSpeed Insights, fix the checklist below from the top down, and ignore anything sold to you as a one-click 100 score: a lab score is not the experience your visitors have.
Site speed attracts more snake oil than any other corner of WordPress. Plugins that promise a perfect score, stacked on plugins that promise it harder, on advice written to sell both. Meanwhile the actual fixes are boring, mostly free, and short enough to fit in one checklist. Here it is, in the order that moves the needle.
What should you measure before touching anything?
Run your homepage and your two or three most-visited pages through PageSpeed Insights, on mobile, and read the field data at the top (what real visitors experienced over the last 28 days) before the lab score below it. Field data is the ground truth; the lab run is a simulation that exists to help you debug. The three numbers that matter are Google's Core Web Vitals:
| Metric | Plain-English meaning | Good (per Google) |
|---|---|---|
| LCP | How fast the main content shows up | 2.5 s or less |
| CLS | How much the layout jumps while loading | 0.1 or less |
| INP | How fast the page reacts to taps and clicks | 200 ms or less |
Everything below exists to move those three numbers for real visitors. A page can score 100 in the lab and still feel sluggish in hand, and the reverse is just as common.
Is your hosting doing its share?
Before the browser can render anything, your server has to answer, and no front-end trick can compensate for a server that thinks for a full second first. Three checks:
- Full-page caching is on. Either from your host or from one reputable caching plugin. A cached page skips PHP and the database entirely for most visits, which is the single biggest server-side win WordPress has to offer.
- PHP is current. Recent PHP versions are meaningfully faster; your hosting panel usually makes this a dropdown.
- The plan fits the traffic. If the time-to-first-byte in your measurements stays high with caching on, you are paying for less server than you need, and no plugin fixes that.
Are images costing you the LCP?
On most marketing pages the largest content is an image, which makes images the usual owner of your LCP. The rules are mechanical:
- Give the hero priority, never lazy-load it. Lazy-loading exists for images below the fold. Applied to the hero, it delays the exact pixel Google is timing.
- Always set dimensions. An image without reserved space pushes the layout when it arrives, and that shove is CLS.
- Serve modern formats at honest sizes. WebP or AVIF, sized near their display size. A 2400-pixel photo in a 800-pixel column is bandwidth spent on nothing.
How many fonts are you really shipping?
Every family and every weight is a download, and text waits on it. Two families and three or four weights cover almost any design. Set font-display: swap so text renders immediately in a fallback instead of hiding while fonts load, and self-host the files rather than pulling them from a third-party server the visitor must connect to separately.
What are your plugins and embeds loading behind your back?
Each active plugin can add its own CSS and JavaScript to every page, needed there or not, and third-party embeds are heavier still: a map, a chat widget, and a video player can outweigh your entire site. Two habits keep this honest:
- Audit twice a year. Deactivate what the site no longer uses. The fastest script is the one that never loads.
- Load heavy embeds on interaction. Show a static preview image, and load the real map or player when the visitor clicks it. They get the content; the page stops paying for it up front.
Does page structure or animation matter as much as people say?
Less than hosting and images, but it is not nothing. A page built from hundreds of deeply nested containers gives the browser more work on every render, so flat, intentional sections age better than div-in-div-in-div improvisation. As for motion: animations are blamed for slowness far more often than they cause it, and the real story is specific enough that we gave it its own guide. The short version is that transform and opacity effects are nearly free, and effects that animate layout or run heavy scripts on every page are not.
Watch out
The snake oil list, for the record: chasing a lab score of 100, stacking multiple optimization plugins, deferring every script on the site until something breaks, and buying a bigger plan to fix a problem nobody measured. Every one of these has cost real sites real money without moving what visitors feel.
Bottom line
Speed work is measurement plus four boring fixes: hosting that answers quickly, images that respect the LCP, fonts on a diet, and scripts that earn their place. Do them in that order, re-measure with field data, and stop when the Core Web Vitals are green on the pages that matter. Past that point, time spent polishing a lab score is time the site's content needed more.
FAQ
Questions about this topic
Is Bricks Builder slow?
The builder itself is rarely the problem: Bricks is known for lean output, and a fresh Bricks page is light. Slow Bricks sites are usually slow for the same reasons any WordPress site is: underpowered hosting, oversized images, too many fonts, and third-party scripts. Measure before blaming the builder.
How fast is fast enough?
Google publishes the thresholds: main content visible within 2.5 seconds (LCP), layout shift under 0.1 (CLS), and interaction response under 200 milliseconds (INP), each measured for real visitors at the 75th percentile. Meet those on your important pages and further chasing buys you little.
Which caching plugin should I use?
Any one reputable full-page caching plugin, or the caching your host provides, and only one of them. The specific brand matters far less than having page caching on, and stacking several optimization plugins on top of each other causes more breakage than speed.
Do I need a CDN?
If your visitors are spread across countries, yes: a CDN serves your files from a location near each visitor, which cuts latency you cannot fix any other way. For a strictly local audience on decent hosting it is a smaller win, but rarely a harmful one.