PR A – Guard in enqueue.php

Avoid frontend I/O on first paint: guard SCSS compiler in enqueue.php

This PR prevents unnecessary filesystem work on frontend requests when the SCSS compiler is disabled. Currently, scss-compiler.php is always loaded and bootscore_compile_scss() is called; the disable check runs later inside the compiler, after glob()/filemtime() scans have already happened. This can delay first paint.

Changes

Add a guard in inc/enqueue.php to check BOOTSCORE_SCSS_DISABLE_COMPILER (and the bootscore/scss/disable_compiler filter) before requiring/triggering the compiler.

Impact

• With the compiler disabled, there is zero runtime overhead on the critical render path.
• No behavior change when the compiler is enabled.

Verification

• With BOOTSCORE_SCSS_DISABLE_COMPILER=true: no compiler load, assets/css/main.css enqueues directly.
• Without the define: compilation works as before.

Backward compatibility: Fully backward compatible.

PR B – Early return in scss-compiler.php

Fast-path disable: early return in scss-compiler.php before FS checks

This PR moves the disable check to the top of BootscoreScssCompiler::compile(). Previously, the check happened only after building modified-checks (glob()/filemtime()), causing unnecessary I/O even when the compiler was disabled.

Changes

• Add an early if (apply_filters('bootscore/scss/disable_compiler', …)) return; at the very start of compile().

Impact

• When disabled, the compiler skips all filesystem scans, improving first paint (especially first uncached hit).

Verification

• With BOOTSCORE_SCSS_DISABLE_COMPILER=true: compile() exits immediately; no SCSS checks/scans.
• Without the define: compilation behavior unchanged.

Backward compatibility: No breaking changes; defensive early return only.

Why?

Performance

Eliminate SCSS compiler overhead when disabled by guarding in enqueue.php or early-returning in the compiler.

On this repo we had already some discussions/reports about perfomance issues and I ran into the same issue since version 6.2.x. When you had compiled already your SCSS before deploying, there is no need to run the scss-compiler all the time on each pageload. This has a particularly negative effect on the pageload on systems with slow file systems, because here scss-compiler is running at the frontend all the time.

When do you want add some CSS issues, for sure you can everytime enable the scss-compiler. But when you let run a website with this theme without doing any CSS changes constantly, you just can disable it in wp-config.php with define('BOOTSCORE_SCSS_DISABLE_COMPILER', true); and my guards are preventing all the checks, which are only needed, when the scss-compiler is running. For sure - the possibility for disabling it isn't new. The constant was available all the time but it was just placed to late into the code, so the side effects were slowing down the installation.