Bricks Performance Checklist Before Launch

Bricks sites can be fast out of the box — until someone enables every animation, loads five icon fonts, and forgets to defer third-party scripts. Performance is not a plugin you install at the end. It is a set of decisions you make while building templates, enqueuing assets, and writing query loops.

Use this checklist before handoff. It is written for Bricks + child-theme setups that load CSS and JS in chunks rather than one giant stylesheet. If your site still ships a single 200KB CSS file for every URL, fix that pattern before chasing micro-optimizations.

Theme and asset hygiene

Load CSS and JS only where used. A FAQ accordion script does not belong on a pricing page that has no FAQ. A hero mortar-joint effect should not load on blog archives. Register everything; enqueue on demand based on template markers or detected classes.

• Load CSS/JS chunks only where used
• Self-host critical fonts; subset when possible
• Prefer SVG icons over icon fonts
• Gate motion with prefers-reduced-motion
• Avoid shipping unused Google Font weights
• Remove unused Bricks elements that leave heavy wrappers

@media (prefers-reduced-motion: reduce) {
  *,
  *::before,
  *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}

Keep reduced-motion rules in a base stylesheet that loads site-wide. Using !important here is intentional so section chunks cannot accidentally reintroduce motion for users who opted out.

Fonts without the tax

Display fonts are worth the request when they define the brand. They are not worth four weights plus italics you never use. Self-host body fonts when you can control caching and subsetting. Preload only the critical face used above the fold. Do not preload every weight just in case.

Watch for double-loading: a child theme @font-face plus a Google Fonts enqueue for the same family is a common Bricks-site footgun. Pick one delivery path and document it in the theme README.

Query loop discipline

Unbounded loops on archives kill TTFB. Cap posts per page, avoid nested loops that hit meta on every row, and cache expensive relationship lookups. On related-posts modules, exclude the current post and limit to a small count.

$q = new WP_Query([
  'post_type' => 'post',
  'posts_per_page' => 9,
  'no_found_rows' => true,
  'ignore_sticky_posts' => true,
  'update_post_meta_cache' => false,
  'update_post_term_cache' => false,
]);

Turn meta and term caches back on when the loop card actually needs them. The flags above are for tight loops that only print title and permalink. Measure before micro-optimizing — speculative flags without a profile are cargo cult.

Images and media

Serve correctly sized images. A 2400px photograph inside a 400px card wastes bandwidth on mobile. Use srcset, modern formats where your host supports them, and lazy loading below the fold. Featured images on blog cards should have a consistent aspect ratio so the grid does not reflow as images arrive.

Background images in CSS bypass some of WordPress’s responsive image helpers. Prefer img elements for content images and reserve CSS backgrounds for true decorative planes. Compress screenshots used in blog posts; design blog imagery is often the heaviest asset on an otherwise lean article.

Scripts and third parties

Chat widgets, heatmaps, and tag managers love to nominate themselves as render-blocking. Load them after interaction or on idle when business constraints allow. Never let a marketing pixel block first paint on a service landing page.

Inside Bricks, prefer CSS for hover and simple reveals. Interactions that run JavaScript on every scroll need throttling and a reduced-motion escape hatch. If a library is only used on one landing page, do not register it globally in functions.php.

Caching and host reality

Page cache, object cache, and a CDN cover different layers. Bricks dynamic content and personalized bits can bust page cache if misconfigured. Know which templates are fully cacheable. Staging should mirror production caching closely enough that works on staging means something.

After deploys, purge deliberately. A child theme CSS bump that keeps an old hash in HTML is a classic support ticket. Version your enqueued assets with filemtime or an explicit theme version.

Pre-launch verification

• Lighthouse or WebPageTest on home, one service page, blog archive, and single post
• Throttle CPU and network once — lab scores alone lie
• Confirm CLS around fonts, images, and late-injected banners
• Check that reduced-motion disables decorative animation
• Confirm unused Bricks elements are not leaving empty wrappers with expensive styles
• Retest after enabling cache and CDN, not only on a cold staging box

Target honest goals: strong Core Web Vitals where scope allows, not mythical 100/100 screenshots used as marketing claims. Fix real bottlenecks — oversized images, runaway queries, and unnecessary JS — before chasing vanity points.

Performance is a design constraint. When the system loads only what each template needs, Bricks stays lean. When everything loads everywhere, no amount of caching poetry will save the experience.