Performance.In build

Table sizes, row counts, and where the weight actually is.

No row is deleted before this succeeds.

Past the retention you set, keeping the most recent.

Only rows already past their own expiry.

Comments already flagged, posts already in the bin past the window.

Metadata pointing at posts and users that no longer exist.

Optimise the tables and report the space saved in megabytes, not percentages.

Count the images, their file sizes and which pages use them. If nothing is over the threshold you set, it exits here and compresses nothing.

Read the compression plugin's own settings and confirm it stores an untouched original for every file. If originals are switched off, the run stops here.

Ordered by the traffic the page gets, not by file size alone. One batch at a time, with the quota checked before each batch.

Fetch each one and confirm it still decodes and still has the dimensions the page expects.

Any file that fails that request is put back from its original in the same run, and the plugin's own bulk restore stays available for every other file.

What the library weighed before, what it weighs now, and which pages got lighter. In megabytes, not percentages.

Which compression plugin is installed, whether it can write WebP and AVIF, and whether delivery is already on. If it is on and working, it exits here.

The exact delivery options and any rewrite rule as they stand, so putting them back is precise rather than a guess. Nothing changes until that record exists.

One format at a time. WebP first, because every current browser reads it, then AVIF behind it.

Once with an AVIF accept header, once with a WebP one and once with neither. Three different responses with the right content type is the pass.

If any browser gets a broken image or the wrong content type, delivery returns to exactly what step two recorded, inside the same run.

Which formats are served to which browsers, and what the homepage hero now weighs against what it weighed.

Read the rendered pages for image tags carrying no width or height attribute. If there are none, it exits here and edits no post.

The post ID and the current revision for each one, so every edit can be traced back. Nothing is edited until that list exists.

Read the real size from the file itself and write it into the tag. One post at a time, through post revisions.

The image that paints first should never be lazy loaded. It finds that image per template and removes the attribute there only.

Every edit is a post revision, so any post goes back to the version it had before this run from the WordPress editor, without us.

Load the changed templates again in headless Chrome with mobile processor and network throttling, and report cumulative layout shift before and after. That is a lab figure from our network, not what your visitors recorded.

Headless Chrome loads one page per template and records every stylesheet the browser waits for before it paints anything. If nothing blocks, it exits here.

A full page screenshot of every template, plus the current optimisation settings, so the comparison later is against something real. Nothing changes until both exist.

The rules the visible part of the page uses go into the head. One template at a time, never all of them at once.

The remaining stylesheets load after the paint instead of holding it up.

Screenshot each template again. Anything that moved by more than a hair is a failure, not a win.

The change is removed and the settings recorded in step two are restored, for that template only, immediately.

First contentful paint per template, before and after, measured in headless Chrome with mobile processor and network throttling. A lab figure, and labelled as one.

Headless Chrome records which CSS rules the page actually uses while it paints.

A 300KB stylesheet from a slider plugin on a page with no slider is the finding. The total byte count is not.

A rule unused on this page may still be used by a hover state, a form error or a mobile menu. It says which ones it cannot prove.

A heavy file on the homepage costs more than a heavier one on a page nobody visits.

Which plugin to stop loading where, written in the words of the optimisation plugin you already have. It changes nothing on the site.

Read the registered scripts through the connector, with their handles, their dependencies and where each loads. If everything is already deferred, it exits here.

The existing defer and delay settings exactly as they are, so putting them back is one action. Nothing changes until that record exists.

Analytics, chat widgets and social embeds first. One handle at a time, never a bulk switch.

Homepage, a service page and the contact form, with the browser console read for errors. A deferred script that breaks a form is worse than a slow one.

That handle returns to what step two recorded, in the same run, without waiting for you.

Which handles are deferred now, and time to interactive on the homepage before and after, measured in headless Chrome with mobile throttling.

Which font files load on the homepage, from where, and whether text is hidden while they arrive. If the display rule is set and the first font is already preloaded, it exits here.

The theme's font options and any preload tag already in the head, written down before either changes.

Text shows in a fallback face straight away and swaps when the real font arrives, rather than showing nothing for three seconds.

Only the weight the heading uses on the first screen. Preloading everything has the same effect as preloading nothing.

Removing the preload tag and restoring the display rule recorded in step two puts the head back exactly as it was. Two settings, and no theme file was edited.

Load the homepage in headless Chrome with slow network throttling, confirm the headline is readable before the font file finishes, and report the difference.

Which caching plugin or host layer is active, and what the response headers actually say. If pages already come back from cache, it exits here and changes nothing.

Every exclusion, every expiry and every cookie rule as it stands today. Nothing is switched on until that record exists.

Cart, checkout, account and anything behind a login. This happens before caching is turned on, not after somebody complains.

One layer at a time, with an expiry the site's publishing rhythm can live with.

Request the same address signed out and signed in, and confirm the two responses differ and carry the right cache headers.

If a signed in request comes back with somebody else's page, caching goes off and every rule returns to what step two recorded, immediately.

Which pages are cached, which are excluded, and the server response time before and after, measured server to server from our network.

Ask the connector whether Redis or Memcached is reachable and which PHP extension is present. If neither is there, it exits here and installs nothing.

Whether a drop-in already exists and what is in it, so it can be put back byte for byte. Nothing is written until that record exists.

One file, the one the host's own documentation names, and nothing else.

Load the critical pages and read the error log through the connector. A misconfigured object cache shows up as a white screen, not as a slow page.

Deleting the drop-in returns the site to the database exactly as it was. That happens on its own the moment a page errors.

How many queries are answered from cache, and the server response time before and after, measured server to server from our network.

Which host answers for images, stylesheets and scripts today, and whether a CDN already sits in front. If one does, it exits here.

The site address, the content address and any rewrite rule already in place. Nothing is repointed until that record exists.

Images, stylesheets and scripts. Not the HTML, and never the admin.

Fetch each type from the edge and from the origin and confirm they match byte for byte and carry the same content type.

One setting goes back to what step two recorded and every file is served from the origin again within minutes.

Cross-origin fonts and any file still requested over plain HTTP, because both fail quietly and only in some browsers.

What is on the edge, what is not, and the time to first byte for a static file from three regions.

Every table by size, row count and overhead, with the plugin that owns it named. If nothing is over the threshold, it exits here.

Only those tables, not the whole database. No row moves before this succeeds.

Scheduled action history, session rows, redirect logs and analytics tables, and only past the age you set.

Optimise the trimmed tables so the deleted rows give their space back to the disk instead of sitting there as a gap.

The backup from step two restores any single table on its own, without touching the rest of the database.

Which tables shrank, by how much, and which one will need this again next month.

The total size, and the twenty heaviest rows with the plugin that wrote each one. Under the threshold, it exits here.

Option name, current value and current autoload flag, written out before a single flag moves.

Expired transients and rows left behind by plugins that are no longer installed. The flag changes. The value is never deleted.

A heavy option belonging to an active plugin is not junk. It is listed for you and nothing happens to it without your word.

Every flag returns from the step two export in one action, and no value was ever removed to restore.

Load the homepage, the admin dashboard and one form, then report the new autoload weight against the old one.

How often admin-ajax is called, from which screen, and by which plugin. If the rate is already low, it exits here.

The existing heartbeat settings, so every one of them can be put back exactly.

The dashboard and the post list. The editor keeps its interval, because that is what holds your post lock and saves your drafts.

A plugin hitting admin-ajax on its own schedule is rate limited rather than blocked, because blocking it breaks its screen.

One setting returns every interval to what step two recorded. No plugin is deactivated and no plugin file is edited at any point.

Open a post, save a draft, confirm the lock and the autosave still work, then report the request rate before and after.

Version, memory limit, maximum execution time, upload limit, and whether opcache is on and how full it is.

How many requests the site can serve at once before they queue. Read from the host's own limits where the connector can see them, and reported as unknown where it cannot.

Server response time hour by hour, so you can see whether it climbs at the same time every day. This is time to first byte measured server to server from our network, not a page speed figure.

Memory, workers, execution time or the database. One of them is the one that hurts and the rest are noise.

Which host setting to change or which plan tier to move to, with the number that says why. It changes nothing on the server.

Homepage, a service page, a post, an archive and the checkout. The failure is nearly always in the template rather than the page.

The Chrome User Experience Report through the PageSpeed Insights API, which is what real Chrome users on real phones recorded over the last twenty eight days. Where a page has too little traffic to report, it says so instead of filling the gap.

The same API's Lighthouse run, on a simulated mobile processor and connection. That is a lab figure and it is labelled as one everywhere it appears.

Which image, font or block of script is holding up the largest paint, and which element is moving the layout. A selector, not a score out of a hundred.

A template that got worse is a finding. A template that has always been slow is a project, and the two need different conversations.

Ordered by the traffic the template carries. It changes nothing on the site.