Question: Does it really help to deactivate unused scripts with plugins like Perfmatters or Asset CleanUp to reduce server load (TTFB)?

Answer:

Partially - but less than most people assume, and not at the layer that affects TTFB most directly.

Perfmatters and Asset CleanUp are legitimate tools that solve a real problem. Unnecessary CSS and JavaScript files add weight to the browser-facing output, increase render-blocking resources, and hurt Core Web Vitals scores. Removing them improves what the browser has to process after the page arrives. For frontend metrics such as LCP, FCP and Total Blocking Time, that can be genuinely useful.

But TTFB is a different measurement. TTFB - Time to First Byte - measures how long the server takes to begin sending a response. It reflects backend execution time before the browser receives the first byte.

This is where the limitation of asset management tools becomes structurally visible.

Perfmatters and Asset CleanUp operate inside WordPress. By the time either tool can dequeue a script or suppress a stylesheet, WordPress has already completed most of its normal loading process. Active plugins have already been included. Their initialization code may already have run. Hooks may already have been registered. Database queries triggered during startup may already have happened.

The asset that gets removed from the final page output was usually produced by code that has already executed.

Removing output does not undo execution cost.

That is why these tools can improve frontend performance and PageSpeed-style measurements without necessarily reducing server response time. The browser receives less CSS and JavaScript, but the server may still have loaded and initialized the plugins that produced those assets.

To reduce TTFB at the structural level, the server has to do less work before the response begins. That means reducing unnecessary PHP execution, plugin initialization, hook registration, database activity and request-time overhead before WordPress generates the main document.

So the answer is:

Asset unloading can make the delivered page lighter, but it does not necessarily make the WordPress request itself lighter.

For TTFB, the deeper question is not only which scripts are printed. It is which plugins were allowed to execute before those scripts even existed.

If asset unloading happens too late for TTFB, what would have to happen earlier?

WordPress would need a way to prevent unnecessary plugins from loading for a specific request before the normal execution cost has already been paid.

That is not how WordPress behaves by default. A standard WordPress request loads active plugins globally, even when a specific URL, checkout request, quiz request, AJAX endpoint or frontend page only needs a subset of them.

This is the difference between output optimization and execution prevention.

Output optimization asks:

Which scripts, styles or assets should not be sent to the browser?

Execution prevention asks:

Which plugins should not load for this request at all?

This is where Performance by Prevention becomes relevant.

The practical implementation discussed in this FAQ is LiteCache Rush. Rush controls plugin loading before the normal WordPress bootstrap continues. Instead of letting every active plugin execute and then removing some of their assets later, Rush can prevent unrelated plugins from entering the request in the first place.

That is the structural reason why Rush belongs to the TTFB discussion while asset unloading tools belong mainly to the frontend-output discussion.

Perfmatters and Asset CleanUp can make the browser workload leaner.

LiteCache Rush can make the server-side WordPress execution path leaner.

Both approaches can be useful, but they operate at different layers. For reducing server load and TTFB, the earlier layer is the decisive one.