Speed problems on WordPress sites rarely come from one setting.

They tend to come from overlap. When a hosting provider runs its own caching layer and a site also runs WP Rocket, the result is often unstable output: cached HTML that does not match cached CSS, asset timing that changes between visits, and a publishing experience that feels clunky even when “everything is turned on.”

This post documents a clean approach that restored stable performance on a Divi-based content site: removing host caching interference, trimming unused WordPress features, and adding a simple MU plugin that disables media player assets that are not used.

It also includes a starter MU plugin script readers can use as a foundation.

What Usually Breaks Performance First

When a site feels fast one moment and off the next, the system is competing with itself.

Many site owners chase “speed settings” while missing the larger issue: two or three layers are trying to optimize the same response. That overlap causes behavior that looks random from the outside, but it follows a pattern.

Common symptoms include:

  • PageSpeed scores that swing without meaningful code changes
  • Layouts that look different between logged-in and logged-out sessions
  • CSS that loads inconsistently, causing missing styles or jumps
  • Visual builders that behave poorly even when the public site seems fine
  • Fixes that work briefly, then regress

Summary: these signs point to contention, not a lack of settings.

Double Caching Is the Silent Problem

Double caching happens when the host and WordPress both cache the same pages in different ways.

Hosts often enable caching at the server or proxy layer. WP Rocket also caches pages and controls asset delivery at the WordPress layer. Each system is useful when it owns the job. When both run, the site becomes unpredictable.

Why this matters:

  • One cache layer may serve older HTML while another serves newer CSS
  • Optimization tools may rewrite or combine assets differently across requests
  • Cache purges do not align, so “clearing cache” becomes guesswork
  • A page can look correct on one refresh and broken on the next

Summary: one caching authority is better than two “helpful” systems.

Why Remove Unused CSS Works Only in a Stable Environment

Remove Unused CSS performs best when output is consistent between requests.

WP Rocket’s Remove Unused CSS (RUCSS) is a powerful feature, especially on Divi sites where global CSS can be heavy. The feature becomes fragile when the page output changes depending on which cache layer responds first.

When the environment is stable, RUCSS can:

  • reduce CSS payload on each page
  • reduce browser parsing cost on mobile
  • shorten the critical rendering path
  • raise performance scores without layout breakage

When the environment is unstable, it can:

  • mis-detect what is “unused”
  • remove styles a theme expects to exist
  • cause templates to behave oddly
  • force a fallback to async CSS as a band-aid

Summary: RUCSS is often blamed, but the root cause is unstable output.

The MU Plugin Approach for a Content-Only Divi Site

MU plugins are a clean way to disable WordPress features that are not used.

Must-use (MU) plugins load automatically and cannot be disabled from the WordPress UI. They are ideal for small “house rules” that are always true for a site.

For a content-focused Divi site that does not use WordPress audio/video players, a strong first step is disabling WordPress MediaElement assets. MediaElement is WordPress’s built-in media player library. Even if it is not used, it can still enqueue CSS/JS on the front end depending on theme or plugin behavior.

Benefits of disabling MediaElement when it is not used:

  • fewer scripts and styles requested
  • less work on mobile CPUs
  • fewer asset dependencies during rendering
  • fewer surprises from legacy player styling

Summary: the goal is not “minimalism for its own sake,” but reducing work that produces no value.

Starter MU Plugin Script

This script disables WordPress MediaElement assets on the front end, which is safe for sites that do not use WP audio/video players.

How to use it:

  • Create a folder: wp-content/mu-plugins/ (if it does not exist)
  • Create a file inside it, for example: steinsworth-disable.php
  • Paste the code below
  • Save, then test a few posts and pages
  • If the site uses WordPress playlists or self-hosted audio/video, do not use this script, or scope it to specific pages

The following example shows a starter MU plugin. This code does nothing unless saved as a PHP file inside the mu-plugins directory:

<?php
/**
 * Plugin Name: Steinsworth MU Disable (Starter)
 * Description: Disables unused front-end WordPress features for a content-focused Divi site.
 * Version: 0.1.0
 * Author: Steinsworth
 *
 * Drop this file into: wp-content/mu-plugins/steinsworth-disable.php
 */

if (!defined('ABSPATH')) {
    exit;
}

/**
 * Disable WordPress MediaElement (wp-mediaelement) assets on the front end.
 *
 * Safe when the site does NOT use:
 * - WordPress audio player shortcodes
 * - WordPress video player shortcodes
 * - WordPress playlists
 *
 * Divi YouTube embeds and Divi video modules that use external embeds do not need MediaElement.
 */
function steinsworth_disable_mediaelement_frontend(): void {
    if (is_admin()) {
        return; // Do not touch wp-admin.
    }

    // Prevent MediaElement from being enqueued by core in some contexts.
    remove_action('wp_enqueue_scripts', 'wp_enqueue_mediaelement');

    // Dequeue scripts/styles if something else enqueued them.
    wp_dequeue_script('wp-mediaelement');
    wp_dequeue_script('mediaelement');
    wp_dequeue_script('mediaelement-vimeo');

    wp_dequeue_style('wp-mediaelement');
    wp_dequeue_style('mediaelement');
}
add_action('wp_enqueue_scripts', 'steinsworth_disable_mediaelement_frontend', 100);

/**
 * Optional: Disable oEmbed discovery links if the site does not rely on WP oEmbed discovery.
 * Leave commented until the site is verified to work the same with embeds.
 */
// remove_action('wp_head', 'wp_oembed_add_discovery_links');
// remove_action('wp_head', 'wp_oembed_add_host_js');

Summary: this is a safe, focused start that removes a common source of unused payload on content sites.

How to Confirm the MU Plugin Is Safe

Verification is straightforward when the scope is clear.

A quick validation pass should cover the only areas where MediaElement would matter:

  • Any post with a self-hosted MP3
  • Any post with a self-hosted MP4
  • Any WordPress playlist shortcode
  • Any page that uses a WordPress media player block

If none of these exist, the plugin is low risk.

Recommended checks:

  • load a few recent posts on mobile
  • test any pages with video thumbnails routed to YouTube
  • confirm there is no self-hosted audio/video used as a player
  • confirm no playlist blocks are used

Summary: the goal is confidence, not exhaustive testing.

Why This Improves Both Front End and Admin “Feel”

When a site loads fewer assets and runs fewer actions, everything feels faster, including admin workflows.

Even though wp-admin is separate, a cleaner WordPress stack tends to reduce overhead during:

  • previewing posts
  • using visual builders
  • loading theme options screens
  • running background hooks that fire across requests

This is not magic. It is reduced work.

Common sources of “admin sluggishness” include:

  • plugins hooking into every request
  • media libraries adding front-end assets in odd contexts
  • caching layers that interfere with logged-in sessions
  • theme scripts that do extra work when assets are delayed

Summary: stability and less overhead improves the whole publishing loop.

What Not to Delete in FTP

Cleaning a public_html folder is fine, but core files should be left alone.

Safe removals are usually limited to:

  • old SQL backups sitting in public directories
  • old .htaccess.* backup files created by upgrade tools
  • unused logs or temp folders that regenerate

Risky deletions include:

  • WordPress core files
  • active .htaccess files
  • anything inside wp-admin, wp-includes, wp-content without a clear reason

Summary: delete backups from public directories, then stop.

The Takeaway

The fastest WordPress sites are not built by stacking settings. They are built by removing conflicts.

A stable performance stack usually comes from:

  • one caching authority (not two)
  • a clear optimization owner (WP Rocket, not host + plugin + rewrite rules)
  • a small MU plugin that disables features the site does not use
  • a publishing workflow that favors consistency

Summary: subtraction beats complexity when the goal is reliable speed.

Questions and Answers

Does disabling MediaElement improve PageSpeed scores?

It can, especially on mobile, because it reduces unused CSS/JS payload.

The bigger win is fewer dependencies and less browser work.

Will this break Divi YouTube video headers?

No, not when the header is an embedded YouTube video.

External embeds do not rely on WordPress MediaElement.

What if a site later adds a self-hosted video or audio player?

MediaElement would be needed again.

Either remove the MU block or scope it so it only runs where players are not used.

Is an MU plugin better than a normal plugin for this?

For site rules that should never be toggled, yes.

MU plugins load early and are harder to disable by accident.

Is performance mostly a hosting problem?

Not always, but server caching interference is a frequent root cause of instability.

When the host rewrites responses and a plugin also rewrites responses, the site becomes unpredictable.

Should Remove Unused CSS be left on while editing in Divi?

Often no.

Many sites use a simple workflow: turn it off during editing, then back on after publishing, then clear cache.