Overview
Summary
Most “performance” toggles in WordPress page builders or SEO plugins are actually just “Code Cleaning” or “Security through Obscurity.” They rarely make a site feel “faster” to a human, but they do reduce the bloat in your and slightly improve how bots crawl your site.
Performance & Speed
These tweaks reduce what WordPress loads on every page request — scripts, stylesheets, and server calls that exist for legacy reasons or features you’re not using. Each one is independent; enable only what applies to your setup.
| Feature | Sub-Category | Why it exists & how it helps | How it works | What you’ll notice |
|---|---|---|---|---|
| Disable Emojis | Scripts & Styles, Asset Bloat | WordPress ships with a custom emoji system — a JavaScript file, an inline stylesheet, and a DNS prefetch to s.w.org — that replaces standard browser emoji with its own rendered versions. Every modern operating system and browser renders emoji natively, so this entire system is redundant on almost every site. | Seven remove_action() calls strip the emoji script and stylesheet from wp_head, the admin, RSS feeds, and outgoing email. A filter removes wpemoji from TinyMCE. A wp_resource_hints filter kills the DNS prefetch to s.w.org. | One fewer JS file, one fewer inline <style> block, and one fewer DNS lookup in your page source. Emoji still display — your OS renders them instead. |
| Remove jQuery Migrate | Scripts, Asset Bloat | jQuery Migrate is a compatibility shim that lets old jQuery 1.x code run on modern jQuery versions. WordPress bundles it for backwards compatibility. On a Breakdance-built site using modern plugins, it is dead weight — roughly 9 KB loaded on every page for zero benefit. | Hooks into wp_default_scripts and removes jquery-migrate from jQuery’s dependency array. Frontend only — the admin is untouched so the editor still works correctly. | One fewer JS download for every visitor. If something breaks after enabling this, a plugin on the site depends on deprecated jQuery behaviour and needs updating separately. |
| Slow Down Heartbeat | Server CPU | WordPress “pulses” every 15 seconds via AJAX to /wp-admin/admin-ajax.php to power autosave, post locking, and dashboard widgets. On the frontend this has no value — there’s nothing to autosave or lock — and each pulse is a full PHP execution cycle on your server. | A heartbeat_settings filter slows the admin pulse from 15 seconds to 60 seconds. A wp_deregister_script('heartbeat') call at init priority 1 disables it entirely on the frontend. | Reduced background server load. In a browser network tab on the frontend you’ll no longer see regular POST requests to admin-ajax.php. |
| Remove Query Strings from CSS/JS | Caching | WordPress appends version numbers to asset URLs — style.css?ver=6.4.1 — so browsers fetch a fresh file when the version changes. Some older CDNs and proxy caches treat the query string as a unique URL and refuse to cache the file at all, meaning every visitor downloads it fresh every time. | script_loader_src and style_loader_src filters at priority 15 strip the ?ver= parameter using remove_query_arg(). The files themselves are unchanged — only the URL is cleaned. | Asset URLs in your page source lose their ?ver= suffix. Cache hit rates improve on sites behind older CDN configurations. Note: LiteSpeed Cache handles cache-busting via its own mechanism, so this is safe to enable alongside it. |
| Disable Outbound Embeds | Page Weight, Iframes | WordPress automatically converts raw pasted URLs (YouTube, Twitter/X, Vimeo, etc.) into embedded players. This triggers an oEmbed HTTP request at page load and pulls in third-party iframes and scripts. When Breakdance controls your embeds, or you want pasted URLs to stay as plain links, this is unnecessary overhead. | Removes autoembed and run_shortcode from the the_content filter. Disables oEmbed auto-discovery. Removes the oembed_dataparse filter. This affects outbound embeds on your pages — it does not affect whether other sites can embed your content (see Disable Inbound Embeds for that). | Pasted URLs in post content render as plain links instead of players. Any existing embedded players built via Breakdance are unaffected. |
| Remove Google Fonts | Scripts & Styles, Asset Bloat | Google Fonts loads an external stylesheet from fonts.googleapis.com which then triggers a separate request to fonts.gstatic.com for the actual font files. This adds two cross-origin requests to every page load, introduces a render-blocking dependency, and sends visitor data to Google. When you self-host fonts, these requests serve no purpose. | Dequeues and strips all fonts.googleapis.com stylesheet links from the page — including Breakdance’s own font handle. Use when you self-host fonts via @font-face or no longer need Google Fonts loaded by your theme or page builder. | No fonts.googleapis.com requests in your network tab. For self-hosted fonts, add woff2 preload tags in Asset Preloading → Font Preload so the browser fetches them early. LiteSpeed Cache: set Remove Google Fonts → ON and Load Google Fonts Asynchronously → OFF to prevent LiteSpeed re-injecting the request via its own pipeline. See the full font optimisation guide for the complete Breakdance + LiteSpeed setup. |
Security & Hardening
These tweaks reduce your site’s attack surface and limit what information is publicly visible. These don’t make the site faster for a human. None of them replace a security plugin or proper access controls — they remove legacy entry points and unnecessary disclosures that make automated scanning easier.
| Feature | Sub-Category | Why it exists & how it helps | How it works | What you’ll notice |
|---|---|---|---|---|
| Disable XML-RPC | Security, Attack Surface | XML-RPC (/xmlrpc.php) is a legacy remote API from the early 2000s that lets external apps post content and manage your site. It’s a common target for brute-force attacks and DDoS amplification — a single request can attempt hundreds of username/password combinations. Almost no modern site needs it. The main exception is Jetpack, which uses XML-RPC to connect to WordPress.com. | The xmlrpc_enabled filter returns false, disabling the endpoint. A wp_headers filter removes the X-Pingback response header that advertises the endpoint’s existence to scanners.Also removes the X-Pingback response header and blocks all XML-RPC POST requests before processing — this covers pingback abuse without needing a separate toggle. | Requests to /xmlrpc.php return a 403. The X-Pingback header disappears from HTTP responses. If you use Jetpack, disable this tweak — Jetpack requires XML-RPC to function. |
| Restrict REST API to Logged-In Users | Security, Access Control | The WordPress REST API is publicly accessible by default — anyone can query your posts, users, and content structure without logging in. This makes it easy to enumerate usernames, map your content, and probe for vulnerabilities. Restricting it to logged-in users closes this off while keeping the API fully functional for the admin, editor, and any authenticated integrations. | A rest_authentication_errors filter returns a WP_Error 401 response for all unauthenticated REST requests. A whitelist keeps specific routes public — WooCommerce endpoints (/wp-json/wc/) and Brighter Websites integration endpoints remain accessible without login. | Unauthenticated requests to /wp-json/wp/v2/ return a 401 error. Any external tool or automation that hits your REST API without credentials will stop working — check Make.com webhooks, form plugins, and third-party integrations before enabling on a live site. |
| Restrict REST API Users Endpoint | Security, Access Control | Even with the REST API otherwise locked down, the /wp/v2/users endpoint can expose admin usernames to anyone who knows to ask for it — and automated scanners do. This is a targeted fix: remove just the users endpoint for public requests, without touching the rest of the API. Unlike the broader “Restrict to Logged-In Users” toggle, this one won’t break automations that use other REST endpoints without credentials. | A rest_endpoints filter removes /wp/v2/users and /wp/v2/users/{id} from the available routes, but only when the request is unauthenticated. Logged-in users and authenticated API calls still have full access. | A public request to /wp-json/wp/v2/users returns a 404. Logged-in requests work normally. Can be used alone for minimal disruption, or alongside “Restrict REST API to Logged-In Users” for full coverage. |
Other settings in this category
Remove X-Powered-By – strips the X-Powered-By: PHP/8.x server response header that exposes your PHP version. On LiteSpeed/CyberPanel this is best handled at the server level rather than PHP/htaccess – CyberPanel has a toggle for it under server configuration.
This is the recommended approach rather than a WordPress tweak. If you do want it at the wp/site level: header_remove('X-Powered-By') via an init hook, but LiteSpeed may re-add it at the server level anyway making the PHP-level removal pointless.
Cloudflare can handle this automatically too. Cloudflare strips the X-Powered-By header at the edge before the response reaches the visitor. It’s part of their default behaviour, no configuration needed on your part. Visitors never see it regardless of what your server sends.
Verify it’s already gone the following curl/grep will return nothing.
curl -I https://yourdomain.com.au | grep -i "x-powered"Recommendation: Implement at CDN or server-level setting in CyberPanel rather than a WordPress tweak — it’s more reliable there and you likely already have it configured.
SEO & Metadata Code Cleanup
WordPress adds several <link> tags and HTTP headers to every page that made sense in the early 2000s but serve no purpose on a modern site. These don’t necessarily make the site “faster,” or hurt SEO directly, but they add noise to your page source, advertise internal structure to crawlers, and occasionally confuse technical audits or can make it harder for search engines to understand what’s important. These tweaks remove them cleanly.
| Feature | Sub-Category | Why it exists & how it helps | How it works | What you’ll notice |
|---|---|---|---|---|
| Remove RSD Link | Head Bloat, Code Cleanup | Really Simple Discovery (RSD) is a 2002-era protocol that lets desktop blogging apps like MarsEdit discover your site’s API endpoints automatically. If you’re not using a desktop blog editor to publish posts, this tag has no purpose. It also exposes your XML-RPC endpoint URL — which pairs badly with leaving XML-RPC enabled. | A single remove_action('wp_head', 'rsd_link') call. | <link rel="EditURI" ...> disappears from your page <head>. No SEO or user-facing impact. |
| Remove Windows Live Writer Link | Head Bloat, Code Cleanup | Windows Live Writer was a Microsoft desktop blogging app, discontinued in 2017. WordPress still outputs a manifest link for it on every page. No modern tool uses this tag. | A single remove_action('wp_head', 'wlwmanifest_link') call. | <link rel="wlwmanifest" ...> disappears from your page <head>. No SEO or user-facing impact. |
| Remove WordPress Version Tag | Fingerprinting, Security, Code Cleanup | WordPress outputs <meta name="generator" content="WordPress 6.x.x"> on every page. This makes it trivial for automated scanners to identify your exact WordPress version and match it against known vulnerabilities. Removing it is a minor but easy hardening step — security through obscurity isn’t a defence on its own, but there’s no reason to advertise. | remove_action('wp_head', 'wp_generator'). Note: the version number also appears in RSS feeds and some ?ver= query strings — this tweak covers only the meta tag. Pair with “Remove Query Strings” for more coverage. | The <meta name="generator"> tag disappears from your page source. RSS feeds and API responses are unaffected. |
| Remove Shortlink Tag | Head Bloat, Code Cleanup | WordPress adds a <link rel="shortlink"> tag and a Link: HTTP header to every page, pointing to a URL like /?p=123. This exposes your internal post IDs and adds clutter with no SEO or user benefit. Shortlink services like bit.ly replaced this pattern long ago. | Removes both the wp_head action that outputs the <link> tag and the wp_headers filter that adds the HTTP Link: header. | <link rel="shortlink" href="/?p=123"> disappears from your page source and the Link: header disappears from HTTP responses. |
| Remove REST API Discovery Links | Head Bloat, Code Cleanup | WordPress adds two discovery links to every page: one advertising your REST API URL (https://api.w.org/) and one exposing the internal post ID of the current page as a JSON link. These advertise your API location and content structure to any crawler that reads your source. If you’re restricting the REST API to logged-in users, these discovery links serve no purpose — they’re pointing to a door you’ve already locked. | Removes both <link rel="https://api.w.org/"> and the per-page <link rel="alternate" type="application/json"> from <head>. | Two <link> tags disappear from your page source. Best used alongside “Restrict REST API to Logged-In Users” — if the API is locked, remove the signpost too. |
| Disable Inbound Embeds | Code Cleanup, Discovery Leakage | By default, WordPress allows other sites to discover and embed your content using oEmbed — the same system you use to embed YouTube videos. This adds discovery <link> tags to your <head>, a REST API route, and a host script. For most service business sites, there’s no reason to allow this. Disabling it cleans up your page source and removes a minor discovery surface. It has zero effect on embeds you use on your own pages — YouTube, Vimeo, etc. still work. | At init priority 9999: removes the REST oEmbed route via remove_action('rest_api_init', 'wp_oembed_register_route'), removes the two <head> discovery tags, and removes the embed.js host script. Outbound oEmbed (fetching embeds from other sites) is unaffected. | Two <link> tags and one <script> reference disappear from your page source. Other sites can no longer auto-embed your content via oEmbed. No visible change for your visitors. |
Other settings you may find in other tools in this category
(What SCOS doesnt do yet)
Remove hentry Class — hentry is a Microformats class WordPress adds to post wrappers. Google used to read it for structured data but deprecated it. It can now trigger “Unparseable structured data” warnings in Search Console when it conflicts with your custom schema. Worth adding.
Relational Links — remove_action('wp_head', 'adjacent_posts_rel_link_wp_head') — removes the <link rel="prev"> and <link rel="next"> tags. Google officially dropped support for these as pagination signals in 2019. Pure head noise now.
Disable RSS Links — remove_action('wp_head', 'feed_links') and remove_action('wp_head', 'feed_links_extra') — removes the RSS/Atom discovery links from <head>. If no blog, no value.
Cross Tool Conflict Management
The “Litespeed” & “Breakdance” Problem
When two tools try to do the same thing, you usually get one of three results. Often you wont notice the impact, even if there is one.
| Outcome | What Happens | Impact |
|---|---|---|
| Redundant (Safe) | Both tools try to “Unset” a variable. The first one wins, the second one finds nothing to do. (e.g., Removing WP Version). | None |
| Conflict (Error) | One tool moves a file, the second tool looks for that file to optimize it, can’t find it, and throws a PHP Warning. (e.g., Minifying CSS) | Low/Med Errors in logs. |
| Logical Overlap (Performance) | If Litespeed Cache is “Optimizing Heartbeat” and another plugin “Disables” it, the plugin that will likely win is the one that prevents the script from even triggering, whereas Litespeed might just be trying to buffer the response | Med Performance |
Conflict/Overlap – what tool “wins” decisions when multiple tools run the same setting.
| Tweak | Likely also in… | Decision guide |
|---|---|---|
| Disable Emojis | SEOPress, Perfmatters, WP Rocket, LiteSpeed | Pick one. If LiteSpeed is handling it, disable yours. Check with “View Source” — if emoji-release script is gone, it’s working. |
| Remove Query Strings | WP Rocket, LiteSpeed, Perfmatters | Can conflict. CDNs + caching plugins often handle this better with extra logic. Disable yours if your caching plugin covers it. |
| Optimize Heartbeat | WP Rocket (“Heartbeat” tab), Perfmatters | Same filter, last one registered wins. Your code doesn’t kill it on admin, WP Rocket gives more granular control. You may want to defer to WP Rocket if active. |
| Disable XML-RPC | Wordfence, iThemes Security | Wordfence has extra logic (rate limiting the file directly). If Wordfence is active, it wins — disable yours to avoid double filtering. |
| Disable REST API | Wordfence, iThemes Security | Your code has Brighter-specific whitelist logic that generic plugins won’t have — your code should be the winner here. |
| Remove WP Version | SEOPress, Yoast SEO (via options), security plugins | Low conflict risk, remove_action is idempotent. Safe to leave both on. |
Example: Heartbeat Control
- SCOS Software: uses a PHP filter to change the frequency or
wp_deregister_script. - Litespeed: Can do the same, but it often does it via the
.htaccesslevel or its own optimization engine. - Verdict: Turn it on in ONE place. SCOS software is “closer to the code.” and may be better for performance – but If you enable both, you aren’t “double-saving” energy; you’re just making the server run two checks to perform one action.
“Breakdance” Settings Strategy
Since Tools like SCOS Site Essentials, Breakdance, Litespeed Cache, SEOPress and similar often have a massive overlap, you should centralize these settings.
Many popular & highly regarded tools are configured so they can work across many different plugin stacks. so they often run code that you don’t specifically need because the tool needs to support many different configurations.
Everything in SCOS is designed to work specifically WITH Breakdance + WP Litespeed Cache more efficiently. While it may work along side other page builders, seo tools and caching plugins, this is the stack it has been designed for.
Advice: If you use Breakdance + SCOS,
Use performance Settings from SCOS Performance WP Tweaks (not Breakdance).
Advice: If you use Breakdance + SEOPress (non-scoss)
Use performance Settings from Breakdance. Breakdance handles the “Frontend” (what the user sees) very efficiently. If you use SEOPress for these, it adds a tiny bit of PHP overhead to “filter” them out after the fact.
Troubleshooting
The known gotchas & What could break
oEmbeds – other links/codes on your website
Before you disable oEmbed, make sure you don’t plan on pasting a YouTube link into a text block and having it automatically turn into a video. That is exactly what that toggle breaks.
Disable REST API
Be careful with “Disable REST API for Non-Logged Users.” * Breakdance uses the REST API for its builder and some dynamic elements.
- Contact Form plugins (like Contact Form 7) often use it for submissions.
- Search features sometimes rely on it.
If disabling it make sure you add/allows exceptions for specific endpoints those plugins need, otherwise, your forms might “spin” forever and never send.