Hakeemify Debloater

Descripció

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=; 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=<an administrator>
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=<an administrator> [--type=checkout] [--deep]
wp debloater diagnosis [<id>]

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.