Most optimisation plugins ask you to trust a switch. Debloater asks you to read\na finding.<\/p>\n\n
It scans your site, records what it found, and shows you each change it could\nmake: what the change does, what it might break, how confident it is, and how\nto get back. Nothing is applied until you confirm it, and every apply takes a\nrecovery point first. After applying, it checks your site, and if the check\nfinds a page broken it puts everything back.<\/p>\n\n
Scans, and records facts.<\/strong> Which core features are loading, how many\nrevisions and expired transients you have, what your autoloaded options weigh,\nwhich of your plugins do the same job, and what your admin shows. Each scan is\nstored with the facts it read.<\/p>\n\n Explains every finding.<\/strong> Each finding names the facts it came from, so you\ncan disagree with it and leave it alone.<\/p>\n\n Scores each area separately, and says what it covers.<\/strong> The Debloat Score\nis three scores out of 100 \u2014 Database, Admin and Assets \u2014 and they are not\naveraged into one number. None is a speed measurement. Each counts what your\nsite has that Debloater offers to change, and not what WordPress does out of\nthe box: a fresh install scores 100. Something it reports but cannot change for\nyou, such as two plugins doing the same job or XML-RPC being on, is listed as a\nfinding and costs nothing. Each finding that costs points says how many. When\neverything left in an area is behind deleting data \u2014 which Fix Safe Issues never\ndoes \u2014 the score says what is left and offers to review deleting it. If any\ncheck in an area could not run, that area is shown as not scored, with the\nreason, rather than as clean.<\/p>\n\n Reads your admin as you.<\/strong> Findings about the admin come from a request the\nscan makes to your dashboard, signed in as the person scanning, and describe\nwhat that person sees. The dashboard has 30 seconds to answer a scan started\nfrom the dashboard, and 120 seconds from WP-CLI. From WP-CLI, run the scan with\n --user=; without it, the admin is not read and the scan\nsays so.<\/p>\n\n Plans before it acts.<\/strong> You get a preview: every change, its risk level, what\nit touches, and the recovery point that will be taken. The same scan and the\nsame profile always produce the same plan.<\/p>\n\n Takes a recovery point first.<\/strong> Before anything changes, the current\nconfiguration is captured. Before rows are deleted, the rows themselves are\ncaptured, and the deletion does not run unless that capture completed.<\/p>\n\n Verifies, then rolls back if it has to.<\/strong> After applying, Debloater requests\nyour front page, a post, your dashboard and your REST API, and if one of them\nfails, it puts everything back and tells you what failed. It also requests the\nlogin page, and warns rather than rolling back if that looks wrong. When you\napply from the dashboard, it also asks a fresh request whether each change\nloaded, and puts everything back if one did not. From WP-CLI the same checks run\nas the administrator you name with Diagnoses a request.<\/strong> Pick a page \u2014 the home page, a post, the shop, the\ncart, the checkout, the dashboard, or any address on your site \u2014 and Debloater\nrequests it once with its profiler switched on. It records how long the request\ntook, its peak memory, how many database queries it ran and how long they took,\nand how long it waited on other servers, and turns what crossed a threshold\ninto findings: a slow or repeated query pattern, a plugin with a large share of\nthe time, a request that waited on other servers. Every finding says what it\ncould not observe. A diagnosis changes nothing, is one request rather than a\nspeed score, and is never added to the Debloat Score. If a cache answered the\nrequest instead of your site, it says so and records no figures. The most\nrecent 20 diagnoses are kept.<\/p>\n\n Connects what it measured to what it can change.<\/strong> A diagnosis of a page\nrecords the scripts and stylesheets it printed. Where one of Debloater's\nchanges removes something it printed \u2014 the emoji script, jQuery Migrate, the\ncart-fragments script off the shop \u2014 the finding names that change and says\nwhether it is offered on your site, decided from your last scan exactly as\nevery other change is. Review it, apply it the usual way, then diagnose the same\npage again to see the observed change.<\/p>\n\n Adds nothing to a page when nothing is selected.<\/strong> With no changes selected,\na front-end page loads none of Debloater's change handlers and makes no query\nto Debloater's own data.<\/p>\n\n Every change carries a declared risk. Debloater raises it one level when\nsomething on your site depends on what the change touches, and on any host it\ndoes not recognise (it recognises WP Engine, Kinsta, SiteGround and LiteSpeed\nservers). On an unrecognised host that means the front-end changes are rated\nhigh, so Performance leaves them out and only Maximum includes them. The host\ndoes not raise a database change that deletes nothing \u2014 clearing expired\ntransients, or stopping large options from loading on every request \u2014 because\nnothing a host does changes what those rows are. Nor does it raise a change\nwhose finding already read what the host did: the revision limit, which the\nscan reads as it is actually in effect. When a change is left out of a plan\nbecause its risk was raised, the preview says why.<\/p>\n\n Stopping the Dashicons icon font from loading for visitors is rated on evidence.\nThe scan reads the pages it fetched as a visitor, and the stylesheets they load\nfrom your site, for any use of the font. If none uses it, the change is low risk\nand Fix Safe Issues can include it; if any does, or a stylesheet could not be\nread, it is medium, and the finding says which. Pages outside the sample, and\nicons added by JavaScript after a page loads, are not seen.<\/p>\n\n None of the three profiles includes a change that deletes rows or a change to\nthe admin. Those are chosen one at a time, from their findings.<\/p>\n\n Twenty-six changes at present, across WordPress core (emoji scripts, embeds,\nthe generator tag, RSD and shortlink headers, jQuery Migrate, heartbeat\ninterval, revision limits, self-pingbacks, Dashicons for guests), the admin\n(dashboard widgets, the welcome panel, the news widget, plugin notices), the\ndatabase (expired transients, auto-drafts, orphaned meta, old revisions, spam\ncomments, trash, autoloaded options), WooCommerce (cart fragments and block\nstyles loaded only where they are needed, admin analytics, marketplace\nsuggestions) and Elementor (Google Fonts).<\/p>\n\n--user=<an administrator><\/code>, and a failure\nputs everything back there too. Without --user<\/code>, or on a site that cannot make\nrequests to itself, these checks cannot run; the change stays, and Debloater\nreports which checks could not run.<\/p>\n\nThree profiles<\/h4>\n\n
\n
What it can change<\/h4>\n\n
What it will not do<\/h4>\n\n
\n
External services<\/h4>\n\n