Skip to main content

Performance Suggestion — Per-Page CSS Generation & Critical CSS Inlining to Reduce Render-Blocking

Alan H

Hi Brizy team,

I've been doing deep performance troubleshooting on my site (built on Brizy Cloud, Lifetime Pro plan) and wanted to share some specific, technical feedback rather than just a general "my site is slow" report. I think this could meaningfully help Performance scores from Pagespeed Insights across the platform, and not just my site.

The Core Issue

Running Google PageSpeed Insights repeatedly, the single largest render-blocking bottleneck on my page is:

 
becdn.net
  .../css/main.base.min.css   —   1,650 ms

This appears to be Brizy's core/global stylesheet, loaded in full on every page regardless of which elements or styles that specific page actually uses. I confirmed this isn't unique to my site as a lot of Brizy's own showcase & demo sites show the same pattern and land in a similar mobile PageSpeed range (~55–65), with the same file flagged as render-blocking.

I understand Bunny CDN is already handling delivery efficiently and I think (and you probably already know) this isn't a CDN/delivery speed issue, it's a file size and render-blocking issue. A CDN delivers a large file quickly; it can't make the browser start painting before that file is fully downloaded and parsed. The fix needs to happen at the CSS generation step, before it ever reaches the CDN.

Suggested Fix #1 — Per-Page CSS Filtering

Rather than shipping one universal main.base.min.css to every page, generate a page-specific stylesheet at publish time containing only the CSS classes that page's element tree actually references.

Since Brizy's builder already has the full JSON/element structure for each page in order to render it, this seems like it would primarily be a filtering step added to the existing publish pipeline, rather than requiring new data collection. Even without going further (see Fix #2), this alone should meaningfully cut the file size, and also the download & parse time on pages that don't use every style rule in the global sheet.

Suggested Fix #2 - Critical CSS Inlining + Deferred Loading

Beyond per-page filtering, split each page's CSS into two tiers:

  • Critical CSS - only the rules needed to render the first viewport (hero/header/nav) — inlined directly into the <head> as a <style> block, so it arrives with the initial HTML with zero additional network request
  • Deferred CSS - everything else on the page, loaded non-render-blocking via the standard preload-and-swap pattern:
 
html
  <link rel="preload" href="deferred.css" as="style" onload="this.rel='stylesheet'">

Of course we already do this with WordPress caching plugins (WP Rocket, LiteSpeed Cache) and static site generators (Next.js, Astro) and its why my WordPress version of the same content I tested scored significantly higher on mobile PageSpeed than the Brizy Cloud version.

Related, Smaller Suggestion — Auto fetchpriority="high" on LCP Images

Separately: Lighthouse also flagged that the hero/LCP image on my page was missing a fetchpriority="high" hint. I had to work around this manually using a <link rel="preload" imagesrcset="..."> tag via Header Code Injection, which dropped my LCP from 13.7s to 5.7s. Since the builder already knows which image is the largest element in the first viewport, it seems like this could be applied automatically at publish time without requiring users to hand-code a workaround.

Why I'm Raising This

I've already implemented what I can from my side - deferred/click-to-load YouTube and Map embeds, image preloading, removing duplicate hidden mobile/desktop elements — and moved my mobile score from the 50s into the mid-70s. But the render-blocking core CSS appears to be a hard architectural ceiling that isn't fixable from within the builder, and it affects every Brizy Cloud site, and not just mine.

I'm not sure if any of this will be helpful for your team to consider building on, but I'm just putting it out there to raise the platform's potential if possible.

Thanks for listening and maybe considering, 
Alan H.

0

Comments

1 comment

Date Votes
  • Ariel H.
    • Edited

    Hi Alan,

    Thank you for taking the time to write a detailed feedback. We appreciate the effort you put into investigating the performance concerns and sharing your findings and suggestions.

    I've shared your feedback internally with our team as a feature improvement request so it can be considered for future versions of Brizy Cloud.

    Thank you again for your feedback and for helping us improve Brizy Cloud.

    Kind regards,
    Ariel H.

    0

Please sign in to leave a comment.

Didn't find what you were looking for?

Ask a Question