Topic: GenerateBlocks CSS on External File

osaopaulo
May 22, 2026 at 2:19 am
Hello there!

I am trying to remove all CSS code from inline to external files, for better caching reasons. On GB settings page, I’ve set the CSS print method to external, but I see that many of my pages and posts have the styles inlined nonetheless…

I’ve tried this piece of code found on this topic:
```
add_filter( 'generateblocks_css_inline_length', function() {
    return 1;
} );
add_filter( 'generateblocks_css_print_method', function( $method ) {
    $saved_method = generateblocks_get_option( 'css_print_method' );

    if ( is_single() ) {
        $method = $saved_method;
    }

    return $method;
}, 20 );
```
But got no results from this code.

Is there any bug preventing GB to print all CSS to an external file?

Thanks!
George
May 22, 2026 at 3:16 am
Hello,

The snippet you’re using won’t help here — it’s designed for single posts, not other page types.

The root cause depends on what kind of pages you’re seeing the inline CSS on:
- Archives (category, tag, date, author pages): These don’t have a numeric page ID, which GB needs to generate an external filename. Inline is the fallback and there’s currently no workaround for this.
- Single posts: External files are disabled by default to avoid generating thousands of files. The is_single() snippet addresses this, but only if it’s actually being applied — double-check it’s loading (no syntax errors, correct hook, etc.).
- Everything else (standard pages, CPTs): Should respect the External File setting as long as the CSS exceeds the 500-character threshold.
One other thing worth knowing: as of GB 2.x, the CSS is pre-generated and minified at build time, so the performance difference between inline and external is negligible. The external file setting is more of a delivery preference than a meaningful performance lever in GB 2.

What types of pages are you seeing the inline CSS on specifically?
osaopaulo
May 22, 2026 at 4:17 am

Hi, George!

I am trying to make all CSS be loaded as an external file, in all page types (pages, posts, CPTs, archives, etc…).

The code that I presented should at least make the inlined CSS go away on my single posts, which was not true.. it did nothing as I added it to my functions.php (caches cleared and everything).

I can see that on some of my standard pages GB is respecting my decision to print the CSS to an external file, but on some other pages it does not; here is an example: https://radio9dejulho.com.br/historia/ ; this page has more than a thousand characters of inlined CSS.

About the CSS being pre-generated:
1) “Generating your CSS in external files is better for overall performance.” This line found in the settings page is incorrect then?
2) Even though it is claimed that it does not make any difference, it is only true in the case one does not cache its resources, no? ie, if I set .css files to be cached (either by the browser or by a CDN) and .html files to not be cached at all, the difference in performance would not be negligible, right?
George
May 22, 2026 at 4:31 am
Hello,

The /historia/page is a standard page, so the external file setting should be working there — the fact that it isn’t is worth investigating. A few things to check:
1. Is the GB CSS directory writable? GB needs write access to wp-content/uploads/generateblocks/ to create external files. If that directory is missing or permissions are wrong, it silently falls back to inline.
2. Try hitting “Regenerate CSS Files” under GenerateBlocks > Settings, then visit the page logged out. If the directory is writable, this should force file generation.
3. The snippet — can you confirm exactly where you added it? It needs to run on the front end, not just in the admin. If it’s in a plugin like Code Snippets, make sure it’s set to run everywhere, not just admin.
On your caching points — you’re right on both counts:
1. The settings page note is accurate. Pre-generated CSS is fast either way, but an external file can be cached by the browser and CDN separately from the HTML, which is a real performance win in a proper caching setup.
2. Yes, if your HTML is uncached but your CSS files are cached by the browser or CDN, external files give you a meaningful advantage. The “negligible difference” comment applies to server-side generation time only, not delivery.
osaopaulo
May 22, 2026 at 5:20 am

About your questions:

1. I can confirm that the GB directory is writable: 0755 permission on it; it has indeed several other css files there, generated today.
2. Already hit the : “Regenerate CSS Files”; the css file of this partucular page is not (re)created.
3. I’ve put the snippet on my functions.php file. Not using any plugin to add code snippets.

Also, I’ve found that some other standard pages are not respecting the GB setting: /contato/ and /privacidade/ are some examples of standard pages having the generateblocks-inline-css. Can confirm also that no post is respecting the setting, even though the code snippet is implemented as above.
George
May 22, 2026 at 6:35 am

Hello,

Could you check if there are any caching/CDN mechanisms that need to be cleared?
osaopaulo
May 22, 2026 at 8:12 am

Yes, all caching have been cleared (page, browser, object cache and even opcache; don’t have a cdn for this site). The problem persists.
George
May 23, 2026 at 1:38 pm

Hello,

Is it possible to have access to the site so I could have a look? Please use the private section of your reply to post them. You can also install the Temporary Login Without Password plugin and send us a login link without using a password. Again, please, use the private area of your reply to send those details.
osaopaulo
May 25, 2026 at 12:40 am

Yeah! Sure. Link to access my site in the private information area.
George
May 25, 2026 at 4:20 am

After digging into the source of /historia/ directly, I can see that the page content itself doesn’t contain any GenerateBlocks blocks — it’s built with standard WordPress blocks (headings, paragraphs, lists). The inline CSS you’re seeing in generateblocks-inline-css is coming from your GB-built header and footer elements, not from the page content.

GB’s external file setting only applies to page-specific block CSS. Global elements like your site header and footer will always output their styles inline, as they’re shared across all pages and not tied to a single page ID.

So on a page like /historia/, there’s nothing for GB to write to an external file for the page content — which is expected behavior.

Could you point me to one of the pages that has GB blocks in the content area itself? That would be a better test case to confirm whether the external file setting is working correctly for your site.
osaopaulo
May 26, 2026 at 12:39 am

https://radio9dejulho.com.br/familia-dos-amigos/

This one have GB blocks. I can see a css file that contains GB blocks styles, named styles-88.css.
But it does not have a generateblocks-inline-css though. Everything is inside the before mentioned css file.
George
May 26, 2026 at 4:12 am

Hello,

It seems everything is working as expected.

On pages with GB blocks in the content (like /familia-dos-amigos/), GB generates a per-page external file (style-88.css) that bundles everything together — the page content block styles and the global Element styles for the header and footer.

On pages without GB content blocks (like /historia/), no per-page file is generated, so the global Element styles fall back to inline output instead. This is expected behaviour, not a bug.

Your external file setting is doing its job correctly.
osaopaulo
May 26, 2026 at 8:29 am

Hi, George!
Thanks for taking the time to investigate it.

One question though: what prevents GB to actually fully fulfill the setting to print css styles to an external file?

Now, with the intendend behaviour, it seems to me that the setting is actually misleading, as it does not, in fact, print the css to an external file, but only sometimes, only when it feels so. Maybe not a bug, but if sure does feel like one..
George
May 27, 2026 at 4:24 am

Hello,

GB only generates a per-page external CSS file when it detects GB blocks in the page content. On pages with only core WordPress blocks, that detection doesn’t trigger, so the global Element styles (header/footer) fall back to inline. This is by design in the current architecture, not a bug.

I have a potential workaround that I’ve tested locally and confirmed works, but I want to run it by our lead developer before recommending it to make sure there are no unintended side effects. I should have an answer for you shortly.
George
May 28, 2026 at 5:23 am

Hello,

After consulting with our lead developer, here’s the full picture:

GB only generates a per-page external CSS file when it detects GB blocks in the page content. On pages with only core WordPress blocks, that detection doesn’t trigger — so Element styles (like your header and footer) fall back to inline. This is intentional behavior in the current architecture.

There’s an additional reason why the Element styles are output inline even on pages that do have GB content blocks: Elements are conditionally displayed, so their styles are intentionally kept inline alongside the main GB stylesheet rather than bundled into an external file.

I investigated a potential workaround, but our lead developer advised against it — the approach would write unnecessary data to the database and ultimately wouldn’t solve the problem as Element styles are designed to be inline regardless.

As of now, there isn’t a supported way to move Element styles to an external file. This is a current limitation rather than a bug, and it’s something that may be addressed in a future update.
osaopaulo
May 30, 2026 at 2:51 am

Hi, George!

What a bummer… hoping that the team will tackle this limitation in the future!

In any case, thanks for taking the time to investigate this issue.

Viewing 16 posts - 1 through 16 (of 17 total)

1 2 →

You must be logged in to reply to this topic.