Bricks Builder Speed: The Defaults to Change, the Settings to Leave Alone, and the Hero That Lazy Loads

Inside a Bricks page: what loads, and when

Bricks is a theme that contains its own visual builder, so there is no second plugin stacking its assets on top. Every page gets two files for certain: the main frontend stylesheet, enqueued as bricks-frontend, and the main script, bricks-scripts. Everything else is conditional. According to the Bricks Academy, sliders (Swiper and Splide), the PhotoSwipe lightbox, Leaflet maps, Isotope masonry, animations, icon fonts such as Font Awesome 6, Ionicons and Themify, and the date picker are registered and only loaded on pages that use them.

The CSS story is where the defaults matter. By default, Bricks outputs its generated styles inline: page and template settings, element styles, global CSS, theme styles, color palettes and global class CSS, all inside the HTML. The frontend stylesheet uses CSS cascade layers (frontend-layer.min.css). Switch the CSS loading method to External files and Bricks writes minified per-page files to wp-content/uploads/bricks/css/ and swaps in a lighter base stylesheet, frontend-light-layer.min.css. Inline styles are always current but never cached. External files are cached by browsers and CDNs, provided the uploads folder is writable.

Fonts come from Google's CDN unless you act. The Font Manager can download a Google Font and convert it into a custom font stored on your site, and custom fonts are served with font-display: swap, with WOFF2 files listed first when available. Images, background images and videos are lazy loaded by default, with a 300 pixel offset. That last default is the one that catches people, as the vitals section below explains. For the rest of the product, see our Bricks Builder review.

Every switch under Bricks > Settings > Performance

Bricks documents each option on this panel, which makes the job unusually concrete. Here is what each one does and the choice we make on a typical business site, checked against the Bricks Academy in October 2026.

Two rows deserve a warning. The Webfont Loader option hides the page's content until the fonts arrive. That prevents a flash of unstyled text, and it also delays the moment anything paints, which is the opposite of what LCP rewards. And Cache query loops only persists between page loads if the server runs an object cache such as Redis or Memcached; Bricks says to disable it if loops start showing stale results. The panel also carries Disable class chaining and a legacy cascade layer switch. Neither is a speed setting, and Bricks strongly discourages turning cascade layers off.

Where Bricks sites gain their weight

Bricks writes what you build. That is its strength and the source of most slow Bricks sites we see: the builder adds little of its own, so the weight comes from decisions made in the canvas and from the plugins around it.

• Every Google Font variant, downloaded. The Font Manager's Download from Google fetches all unicode-range variants, an issue still open on the Bricks forum at our check. Edit the downloaded font and keep only the subsets and weights the site uses.
• A slider in the hero. Swiper or Splide only load where used, and the home page is exactly where they get used. The first slide becomes the LCP element and waits for the script.
• Icon fonts for six icons. One Font Awesome icon pulls in the library's CSS and font files. SVG icons cost nothing beyond their own markup.
• Nesting for convenience. Section, container, block, div: each is an element. Bricks advertises clean, semantic HTML and a smaller DOM, but a designer who wraps everything three times gets three wrappers.
• Heavy query loops on uncached pages. A loop that pulls related products, meta fields and terms runs in PHP on every request that misses the page cache.
• Plugins that bring jQuery back. Bricks' front end is vanilla JavaScript. WooCommerce extensions, form plugins and sliders added later often load jQuery anyway.

None of these is a Bricks defect. They are the cost of a tool that trusts its user. The comparison with lighter themes is in GeneratePress vs Bricks, and the comparison with the builder most Bricks users left is in Bricks vs Elementor.

A Bricks performance pass, in order

Run this on a staging copy. Bricks makes that free: local and staging sites do not count against any license limit. Given the regressions reported after 2.4, including images that stopped loading, staging is not optional.

1. 1

   Measure four templates

   Home, a page, a single post or product, and an archive. Note the LCP element and its timing in PageSpeed Insights, plus field data where Google has enough visits.

2. 2

   Move CSS to external files

   Bricks > Settings > Performance > CSS loading method: External files. Click Regenerate CSS files so Bricks creates the folder and files. If styles go missing with your cache plugin, Bricks says to revert to Inline styles and report it.

3. 3

   Download and trim fonts

   In the Font Manager, download each Google Font, then edit its variations down to the weights and unicode ranges you use. Switch typography controls to the custom versions and set Disable Google Fonts on.

4. 4

   Preload one font, not five

   Enable Preload custom fonts. Set the family and weight together in the typography controls for headline text so Bricks can match it. Bricks itself warns that preloading too many files hurts.

5. 5

   Rescue the hero from lazy loading

   Bricks lazy loads images by default. Give the hero image a custom attribute of loading set to eager, a workaround shared on the Bricks forum, and avoid making the hero a lazy-loaded background.

6. 6

   Flip the cleanup switches

   Disable emojis, embeds and jQuery migrate. Check the browser console on forms and the cart afterward in case an old plugin relied on migrate.

7. 7

   Swap heavy elements above the fold

   Replace a hero slider with one image, replace icon fonts with SVG, and flatten wrappers that exist only for spacing.

8. 8

   Cache pages, then loops

   Enable page caching at the host or in one plugin. If the host offers Redis or Memcached, turn on Cache query loops. Re-measure the same four templates the same way.

When CSS changes stop appearing after step two, the per-page files need regenerating; Bricks CSS not updating has the routine. If the builder itself will not open after an update, start with Bricks builder not loading.

Core Web Vitals on Bricks: the three traps

LCP: lazy loading the image that matters most

Lazy loading covers images, background images and videos, which is excellent below the fold and harmful at the top. A lazy hero waits until layout runs and the browser decides it is near the viewport. A long-standing request on the Bricks forum asks for automatic eager loading of above-the-fold images, which tells you it is not automatic yet. Set the hero to eager, size it for its largest display, and keep it a real image element. Text-led heroes have their own trap: the Webfont Loader setting hides text until fonts load. The generic causes are in WordPress theme slow LCP.

CLS: the header template and font swaps

Bricks headers are templates of type Header, built like any page, which means they shift like any page. A logo image without width and height, a header that changes height when it becomes sticky, and a menu that rewraps when a swapped font arrives are the usual sources. Default breakpoints sit at 992, 768 and 478 pixels and custom breakpoints can be enabled under Bricks > Settings > General; test the header at each, not just at desktop and phone. More causes are in WordPress theme layout shift (CLS).

INP: the Nav (Nestable) toggle and interactions

The Nav (Nestable) element sets its own mobile breakpoint and reuses the desktop markup for the mobile menu, which keeps the menu light. Remove its toggle and nothing shows at the mobile breakpoint; staff marked that behavior as intended. Responsiveness problems come from elsewhere: interactions that run on scroll, third-party tags and plugins that queue work on the main thread. If a caching plugin delays JavaScript until first interaction, exclude bricks-scripts so the first tap on the toggle does not wait. Menu failures are covered in Bricks mobile menu not working.

The limits Bricks cannot code its way past

Bricks makes confident claims. Its performance page says sites earn top A grades in Lighthouse and GTmetrix out of the box and shows a 98 percent performance score beside 100s for SEO, accessibility and best practices. Those are the vendor's results on the vendor's page. A real site with a store, a form plugin and an analytics tag will produce its own numbers, and those are the ones Google uses.

• PHP on every uncached request. Bricks renders pages in PHP. Logged-in visitors, carts, checkouts and account pages usually skip the page cache, so server speed shows through.
• Everything that is not Bricks. WooCommerce's own scripts, form plugins, review widgets and tag managers load on their own terms.
• Release cadence. Bricks ships fast. The 2.4 cycle brought reports of images not loading, CSS Sync removing custom CSS and the dynamic data parser hanging on CSS-like strings. A setting that was right last month needs checking after each update.
• Database growth. Query loops are only as quick as the queries underneath them, and Cache query loops depends on an object cache your host may not offer.

When the fastest WordPress builder is still the bottleneck

For a brochure site built by someone fluent in Bricks, a tuned build is a sound place to stop, and we say so. Next.js earns its higher build cost when the slow parts are structural: pages that cannot be cached, data that lives outside WordPress posts, or a lead or sales funnel where milliseconds show up in revenue. Next.js prerenders pages at build time and refreshes them on a schedule with incremental static regeneration, serves them from a CDN, self-hosts fonts through next/font, resizes images with next/image, and uses React Server Components so most of the page ships no JavaScript. It needs a developer for layout changes, which Bricks owners usually have already.

Bricks users find the move shorter than most: global classes and variables become design tokens, components become React components, query loops become data queries. The side-by-side is Bricks vs Next.js, the three-way is Bricks vs Elementor vs Next.js, and the plan is Bricks to Next.js, with every URL kept or redirected. For the mechanics behind each metric, read WordPress vs Next.js: LCP, CLS and INP. Athena CMS gives clients plain fields in place of the canvas, and Argus watches for pages that slow down.

Bricks gets WordPress close to the line. It cannot move the line.

Staying on Bricks? Our theme speed optimization service runs this pass on staging and documents every switch, and our Bricks developers handle the template work. License questions are in Bricks pricing, and the WordPress themes section and performance guides, including lightweight WordPress themes, put Bricks in context. A free site audit tells you which path fits.