Hakeemify Debloater

Most optimisation plugins ask you to trust a switch. Debloater asks you to read a finding. It scans your site, records what it found, and shows you each change it could make: what the change does, what it might break, how confident it is, and how to get back. Nothing is applied until you confirm it, and every apply takes a recovery point first. After applying, it checks your site, and if the check finds a page broken it puts everything back. What it does Scans, and records facts. Which core features are loading, how many revisions and expired transients you have, what your autoloaded options weigh, which of your plugins do the same job, and what your admin shows. Each scan is stored with the facts it read. Explains every finding. Each finding names the facts it came from, so you can disagree with it and leave it alone. Scores each area separately, and says what it covers. The Debloat Score is three scores out of 100 — Database, Admin and Assets — and they are not averaged into one number. None is a speed measurement. Each counts what your site has that Debloater offers to change, and not what WordPress does out of the box: a fresh install scores 100. Something it reports but cannot change for you, such as two plugins doing the same job or XML-RPC being on, is listed as a finding and costs nothing. Each finding that costs points says how many. When everything left in an area is behind deleting data — which Fix Safe Issues never does — the score says what is left and offers to review deleting it. If any check in an area could not run, that area is shown as not scored, with the reason, rather than as clean. Reads your admin as you. Findings about the admin come from a request the scan makes to your dashboard, signed in as the person scanning, and describe what that person sees. The dashboard has 30 seconds to answer a scan started from the dashboard, and 120 seconds from WP-CLI. From WP-CLI, run the scan with --user=<an administrator>; without it, the admin is not read and the scan says so. Plans before it acts. You get a preview: every change, its risk level, what it touches, and the recovery point that will be taken. The same scan and the same profile always produce the same plan. Takes a recovery point first. Before anything changes, the current configuration is captured. Before rows are deleted, the rows themselves are captured, and the deletion does not run unless that capture completed. Verifies, then rolls back if it has to. After applying, Debloater requests your front page, a post, your dashboard and your REST API, and if one of them fails, it puts everything back and tells you what failed. It also requests the login page, and warns rather than rolling back if that looks wrong. When you apply from the dashboard, it also asks a fresh request whether each change loaded, and puts everything back if one did not. From WP-CLI the same checks run as the administrator you name with --user=<an administrator>, and a failure puts everything back there too. Without --user, or on a site that cannot make requests to itself, these checks cannot run; the change stays, and Debloater reports which checks could not run. Diagnoses a request. Pick a page — the home page, a post, the shop, the cart, the checkout, the dashboard, or any address on your site — and Debloater requests it once with its profiler switched on. It records how long the request took, its peak memory, how many database queries it ran and how long they took, and how long it waited on other servers, and turns what crossed a threshold into findings: a slow or repeated query pattern, a plugin with a large share of the time, a request that waited on other servers. Every finding says what it could not observe. A diagnosis changes nothing, is one request rather than a speed score, and is never added to the Debloat Score. If a cache answered the request instead of your site, it says so and records no figures. The most recent 20 diagnoses are kept. Connects what it measured to what it can change. A diagnosis of a page records the scripts and stylesheets it printed. Where one of Debloater's changes removes something it printed — the emoji script, jQuery Migrate, the cart-fragments script off the shop — the finding names that change and says whether it is offered on your site, decided from your last scan exactly as every other change is. Review it, apply it the usual way, then diagnose the same page again to see the observed change. Adds nothing to a page when nothing is selected. With no changes selected, a front-end page loads none of Debloater's change handlers and makes no query to Debloater's own data. Three profiles

• Safe — changes rated safe or low risk. This is what the "Fix Safe Issues" button applies.
• Performance — Safe, plus changes rated medium risk.
• Maximum — every change rated safe to high risk.

Every change carries a declared risk. Debloater raises it one level when something on your site depends on what the change touches, and on any host it does not recognise (it recognises WP Engine, Kinsta, SiteGround and LiteSpeed servers). On an unrecognised host that means the front-end changes are rated high, so Performance leaves them out and only Maximum includes them. The host does not raise a database change that deletes nothing — clearing expired transients, or stopping large options from loading on every request — because nothing a host does changes what those rows are. Nor does it raise a change whose finding already read what the host did: the revision limit, which the scan reads as it is actually in effect. When a change is left out of a plan because its risk was raised, the preview says why. Stopping the Dashicons icon font from loading for visitors is rated on evidence. The scan reads the pages it fetched as a visitor, and the stylesheets they load from your site, for any use of the font. If none uses it, the change is low risk and Fix Safe Issues can include it; if any does, or a stylesheet could not be read, it is medium, and the finding says which. Pages outside the sample, and icons added by JavaScript after a page loads, are not seen. None of the three profiles includes a change that deletes rows or a change to the admin. Those are chosen one at a time, from their findings. What it can change Twenty-six changes at present, across WordPress core (emoji scripts, embeds, the generator tag, RSD and shortlink headers, jQuery Migrate, heartbeat interval, revision limits, self-pingbacks, Dashicons for guests), the admin (dashboard widgets, the welcome panel, the news widget, plugin notices), the database (expired transients, auto-drafts, orphaned meta, old revisions, spam comments, trash, autoloaded options), WooCommerce (cart fragments and block styles loaded only where they are needed, admin analytics, marketplace suggestions) and Elementor (Google Fonts). What it will not do

• No admin notices and no dashboard widget.
• No telemetry, no analytics, no AI.
• No requests to other sites, except one optional request to wordpress.org described under "External services". The requests Debloater makes on its own are to your own site: to sample your pages and read your dashboard during a scan, to check your site after a change, and to request the page you ask it to diagnose.
• No blocking of requests to other servers. A diagnosis reports them; what to do about them is yours to decide.
• No claim that your site got faster. Debloater records before-and-after counts and leaves the conclusion to you.
• Recovery points, verification and rollback are all in this free plugin, and none of them needs a licence.

External services Plugin release dates, from wordpress.org. Only when a scan asks for it — wp debloater scan --check-plugin-updates, or the check_plugin_updates parameter of the REST scan endpoint; the dashboard never does — Debloater asks https://api.wordpress.org/plugins/info/1.2/ for the last-updated date of each installed plugin, one request per plugin, so it can tell you which look abandoned. Each request names the plugin's slug, and its user agent names this site's address. Nothing else about your site is sent. The dates are cached, and the choice is not remembered: the next scan does not ask unless told to. This is WordPress's own API; see the wordpress.org privacy notice. The rules Debloater reasons with ship inside the plugin and are never fetched. A newer set arrives when you update the plugin. Nothing else leaves your server. WP-CLI wp debloater scan --user= wp debloater findings wp debloater preview --profile=safe wp debloater apply --profile=safe --yes wp debloater rollback --yes wp debloater status wp debloater diagnose --user= [--type=checkout] [--deep] wp debloater diagnosis [] Exit codes: 0 applied and verified, 1 error, 2 rolled back, 3 applied with warnings. diagnose exits 0 when something was measured and 1 when nothing was.

0.10.0

• Diagnose a request: one page, requested once with a profiler on. Records request time, peak memory, database queries and their time, and time spent waiting on other servers, and reports what crossed a threshold as findings.
• Every diagnosis finding says what it could not observe. Diagnoses change nothing and are never part of the Debloat Score.
• A request answered by a cache is reported as such, with no figures, instead of as measurements of the page.
• New WP-CLI commands wp debloater diagnose and wp debloater diagnosis, and REST routes to run, list and read diagnoses.
• A diagnosis of a page names the Debloater change that removes what it printed, when there is one, and whether your last scan offers it. After applying, diagnose the same page again to see the observed change.
• The WooCommerce block styles change is no longer offered on stores where WooCommerce loads those styles on every page for its notices; it removed nothing there.

0.9.0

• Initial public release.
• Scans the site and records what it found: core features, the database, the admin as you see it, and the pages a visitor downloads.
• Explains every finding with the facts it came from, its risk and its confidence, and scores Database, Admin and Assets separately.
• Fix Safe Issues applies only low-risk changes that delete nothing. Every other change is reviewed and applied one at a time.
• Takes a recovery point before every change, checks the site afterwards, and puts everything back if a check fails, from the dashboard or from WP-CLI.
• Every step is also a WP-CLI command, including scan, preview, apply, verify and rollback.