WPPilot wrote this.
Ask ChatGPT how to raise WordPress speed and you get a familiar list. Turn on a page cache. Cut the image size. Lazy load whatever sits below the fold. Serve WebP. Watch Core Web Vitals. None of that is a measurement. The model cannot see your server, so it cannot tell you whether the last request was served from cache or built by PHP, and it cannot see the width and height attributes on the images in the HTML.
Do the smaller job. Connect the site, look at what is actually installed, time two URLs, change one setting, time them again, and put the settings back if the page got worse. If you want a PageSpeed number, open PageSpeed in a browser. Do not let the chat invent it.
WPPilot is how ChatGPT, Claude, or Cursor run that loop on a site you administer. The writes that change WordPress speed are Pro. Free can look, and it can edit one image. It cannot tune the cache.
What you need connected before the prompt is worth pasting
You need three things in place. If any one of them is missing, the model will still answer, and the answer will be the generic list above.
WordPress has to be running WPPilot, and the AI client has to be connected to that site. "Connected" is not a mood. It means the client can call the site and get a result back from an ability, not a paragraph from memory. The easiest test is to ask which site it is attached to and to ask it to run a read before it gives advice. If it starts recommending plugins you did not ask about, it is not looking at the site yet.
The client can be ChatGPT, Claude, or Cursor. The steps are the same. What changes is where the calls come from. On ChatGPT the site must be public HTTPS. Those calls come from OpenAI's servers, so localhost will not answer, and a password-protected staging site will not answer either. Developer mode is documented for Plus, Pro, Business, Enterprise, and Education on the ChatGPT site. A workspace policy can disable it. If the app does not show up in the picker, fix that before you touch a cache setting. You will otherwise spend an hour judging advice that never left the chat.
A cache or optimisation plugin has to be installed and active already. WPPilot does not bring its own page cache. The cache module loads only while a supported cache or optimisation plugin is active. If none is active, the module does not load, and there is nothing for the prompt to tune. LiteSpeed Cache, WP Rocket, WP Fastest Cache, SiteGround Speed Optimizer, and WP-Optimize are among the plugins whose settings share one vocabulary. Ten drivers share that vocabulary. Of 26 layers, Autoptimize, Perfmatters, and Converter for Media are the three that sit under assets and images. The rest are detected by native option names, a purge callback, or read-only evidence. You install and activate the cache plugin in wp-admin. The prompt does not do that for you.
Free and Pro are different tools, and it saves a lot of confusion to know which one you are holding. Free includes a performance audit. That audit is a set of bounded server checks, and it does not make a synthetic speed claim. Free also includes system status for WordPress, PHP, the database, cron, cache, and the plugin runtime. Status will show you whether caching looks present. It will not change LiteSpeed Cache, WP Rocket, SiteGround Speed Optimizer, or any other plugin. The cache module is Pro. Its 14 abilities register only while the licence is active, and the module is on every Pro plan. Pricing stays on the site, so this walk-through does not repeat it. Check the platform reference and the feature list if you want the current split. On 4 October 2026 those pages listed Free 1.16.0 and Pro 1.10.0.
Two modes matter once you are on Pro. Read Only lists layers, reads settings, and measures. Production Safe is for writes. Stay on Read Only until you have a baseline you have actually read. A baseline you skipped is how people "optimise" a page that was already fine, or break one that was not.
Pick two URLs and write them down before you open the chat. The home page, and one heavier URL. A shop or a checkout is a fair second page if you sell anything. Warming later accepts up to ten URLs. Two is enough for a before-and-after that you can hold in your head. Ten pages times three repeats is a spreadsheet, and you will not compare it honestly.
Have a note open as well. You are going to copy four things out of the first measure: HIT or MISS on each repeat, the time to first byte, the count of images missing width, height, or a loading attribute, and the names of any render-blocking stylesheets or head scripts. Those four lines are the whole decision. Everything else in a long reply is commentary.
Paste this prompt, then read what each step returns
Paste this into ChatGPT with the app selected, or follow the same order in Claude or Cursor. Change the two URLs. Do not add a sentence that asks for a Core Web Vitals score. If you add it, you are asking the model to guess, and it will.
Audit the speed of https://your-site.com/ and https://your-site.com/shop/.
1. Run cache-check-setup and list every layer you find, including edge layers you cannot purge.
2. Start a cache experiment before changing anything.
3. Measure both URLs three times. Give me TTFB, HIT or MISS, HTML size, and render-blocking files as a baseline. Also say how many images lack width, height, or a loading attribute.
4. Propose the single lowest-risk change and wait for my OK. Prefer an images.* key such as lazy-load or missing sizes before any CSS or JS combine, defer, or delay.
5. Apply only that change, purge, warm both URLs, and measure again.
6. Run cache-verify-in-browser and give me the browser checks and PageSpeed links. Do not claim a score you did not open.
7. If anything got worse or a check fails, revert the experiment.
Never enable combine, defer, delay, critical CSS, or logged-in caching without asking me first.
Do not say you recompressed image files. If next-gen images need a converter, say which plugin screen I still have to run.
A useful reply is dull. It names what it called, it shows what came back, and it stops when the prompt says to wait. A bad reply sounds finished. It announces an LCP, it says the library was converted to WebP, or it says Cloudflare is clear. Those are not results this plugin can produce. If you see them, stop the run and tell it to stick to the prompt. Then make it repeat the step from the tool output, not from a summary it wrote on top.
Here is what each step should hand you, and what you should type back.
Step 1 runs cache-check-setup and lists every layer, including edge layers it cannot purge. You want names. A page cache. An asset optimiser. An object cache. An edge layer, if one is in front, such as Cloudflare or a host cache. The edge line is the one people skip, and it is the one that makes a later purge look like it failed. If the reply says no supported plugin is active, stop. There is no cache module to drive. Activate the plugin you already installed, then start again. Do not let the model suggest a new plugin and turn it on in the same breath.
What you type if the list looks real: "Snapshot that. Do not change anything yet." What you type if it is vague: "Name each layer and say which ones you can purge. Do not recommend a setting until you have."
Step 2 starts a cache experiment before any write. The snapshot covers the page cache, the asset optimiser, the object cache, and any edge layer. Taking the snapshot writes nothing. Only the newest five experiments are kept, so a sixth start drops the oldest. You want this snapshot even when you are sure the change is harmless. Revert later restores every layer in that snapshot. It cannot restore a plugin you never included, and one rollback cannot span two plugins. If you have been clicking around in the cache plugin's own screens during the chat, say so, and start a fresh experiment after you stop clicking. A snapshot of a moving target is not a way back.
Step 3 measures both URLs three times. Pro fetches one URL from the server on each repeat. You should see time to first byte, HIT or MISS, HTML weight, whether the response was compressed, render-blocking stylesheets and scripts in the head, a count of images missing width, height, or a loading attribute, and any font preload. Three repeats are there because one fetch is often a cold outlier, especially the first request after a quiet period. This is server-side delivery. The cache reference calls it that on purpose. It is not a Lighthouse score and it is not Core Web Vitals. LCP, CLS, and INP exist only after a browser paints the page. WPPilot does not run a browser, and it does not produce a PageSpeed score. If the reply contains those three numbers, it invented them. Tell it to delete them and send the delivery fields again.
The guide to speeding up WordPress with ChatGPT and the speed workflow put the same limit in public. Measure delivery, hand over the links, and do not pretend a score was computed. If the model cites those pages and then offers you a score anyway, believe the pages.
Step 4 is a proposal. It is not a write. The lowest-risk change is an images key: lazy load, missing sizes, or the WebP flag, and only when an optimiser is already active and exposes that key. It is not CSS or JavaScript combine, defer, or delay. Those wait. The model has to stop and wait for your OK. If it applies the change in the same message as the proposal, tell it to revert and to start the experiment again. You cannot review a change that already happened, and "I already did the safe one" is how a second, less safe key sneaks in.
What you type when you agree: "Apply only that one key. Then purge, warm both URLs, and measure again. Do not add another setting." What you type when the proposal is a JavaScript delay: "No. Propose an images key or say you cannot map one."
Step 5 applies that single mapped setting. The write stores the old values and purges that layer. Then it warms the URLs you named, up to ten, and measures again. Right after a purge you are timing WordPress, not the page cache. That is why the warm sits between the purge and the second measure. A second measure taken on a MISS tells you how slow the origin is. It does not tell you whether the page cache helps. If the model skips the warm, say so and make it warm before you compare anything.
Step 6 runs cache-verify-in-browser. The name sounds like a browser. It is not. It is a second read of HTML that was already sent. It can flag a lazy-loaded image above the fold, a missing intrinsic size, or an http image on an https page. Then it returns checks you run yourself, and PageSpeed Insights links for both form factors. You open the links. The plugin will not call the keyless PageSpeed API and invent a number that quota-fails most of the day. A quota error is not a grade, and a made-up grade is worse than no grade.
Step 7 reverts if anything got worse or a check fails. Worse means the delivery numbers you wrote down, or a failed HTML check. It does not mean a PageSpeed badge you have not opened. Open the link if you want that badge. Decide the revert from the measurement you have.
The last two lines of the prompt are there because models volunteer extra help. Combine, defer, delay, critical CSS, and logged-in caching stay off until you ask in a later message. And the model is not allowed to claim it recompressed image files. If next-gen images need a converter, the reply should name the plugin screen you still have to run yourself.
How to read HIT, MISS, TTFB, and the image attributes
Read HIT and MISS before you read anything about image size.
HIT means a page cache served the HTML. PHP did not build the page for that request. MISS means WordPress built it. Neither word is a grade. A HIT can still be a heavy document. A MISS can be the correct result on a cart or a checkout, which often should not be cached for a logged-in shopper. On a public page, what you want after a warm is a HIT, with a time to first byte that stays in a similar range across the three runs.
Time to first byte is how long the server took to start the response. It is not LCP, and it says nothing about when the largest element painted in a browser. It is still the timing this plugin can take, because the fetch happens from the server. Compare repeats of the same URL. One slow run immediately after a purge is normal. Three slow runs on a warm HIT are a different problem. An image setting will not fix a host that is slow to start sending bytes. Write that down so you do not "solve" it with a WebP flag.
HTML weight is the size of the document. Compression tells you whether that document was sent compressed. A render-blocking stylesheet, or a script in the head, is listed because the browser has to handle it before paint. Seeing the file name is not a reason to defer it. Defer and delay are on the confirm list because they break things that are not visible in a server fetch, like a menu that waits on a click. Read the names. Leave the switches alone on this pass.
Images show up as a count of missing attributes. No width, no height, or no loading attribute. A missing width and height is how layout shift starts, but the plugin is reporting the attribute, not a CLS score. CLS still has to be measured in a browser, which is what the PageSpeed link is for. A missing loading attribute means nothing has marked that image for lazy load. The opposite problem is a loading attribute of lazy on an image above the fold, and the HTML check is allowed to flag that. You do not want the hero to wait. An http image on an https page is mixed content. It is not really a speed finding, but it arrives in the same read, and you should not ship it because you were looking at cache.
Font preload is reported when one is present. Treat it as a note. Do not add preload tags because the paragraph mentioned fonts. Preload is easy to get wrong, and this pass is one setting, not a font project.
This shape is a reading exercise. It is not a result from a site, and it is not a PageSpeed report.
Say the home page comes back MISS, then MISS, then HIT, and the shop comes back HIT three times. You do not average that into a win. The home page was built by WordPress twice. Warm it and measure again before you change a setting. Say instead that both URLs come back HIT three times, and thirty-odd images have no width or height. That is a reason to consider missing sizes. It is not a reason to delay JavaScript. Say both URLs are HIT and the image attributes are already present. Then you may not have an images change worth making. Stopping is a valid result. The prompt is allowed to end at step 4 with "no change."
When you do open the PageSpeed links, treat them as a second instrument. Mobile and desktop are different runs. A steady server time to first byte can sit next to a weak largest-paint figure if the hero file is enormous. That gap is the useful part. It tells you the next job might be the file itself, which is not the same job as a cache setting. The server measure will not fill the gap in with a number of its own.
Change one setting, then warm and measure again
Pick one of three, and only if step 1 showed an optimiser that already exposes it.
Lazy load, if the baseline shows images with no loading attribute and the hero is not the thing you are trying to delay. On LiteSpeed Cache, lazy load maps to media-lazy. Iframes have their own switch, so do not assume the image switch covers embedded video or maps. Turning lazy load on marks images to load later. It does not shrink them on disk, and it does not change their pixel dimensions. If the HTML check later flags the hero as lazy, that setting was the wrong one for that theme, or it needs an exclusion you set in the cache plugin. Do not add a second WPPilot write to paper over it.
Missing sizes, if the loud line in the baseline is images without width and height. On LiteSpeed Cache that maps to media-add_missing_sizes. The point of the change is the attribute the measure counted. It is the one I would try first in that case, because you can see the count move, or not move, on the next measure. If the count does not move, the setting did not do what the label suggested on this site. That happens. Revert, or accept that the markup is coming from somewhere the cache plugin does not rewrite.
The WebP flag, if you specifically want next-gen responses and a converter is already in the stack. On LiteSpeed Cache the next-gen flag maps to img_optm-webp. The flag tells that plugin it may serve next-gen files. It does not create the files. WPPilot does not recompress images. It can change settings the optimiser exposes, and it can see Converter for Media, which is a plugin that creates the WebP and AVIF files. Start that conversion on Converter for Media's own screen. Then come back and measure. A flag with no files behind it does not change what a visitor downloads, and a chat that says "WebP is on" without that screen is describing a checkbox, not a file.
The same words are what the other drivers should use. WP Rocket, WP Fastest Cache, SiteGround Speed Optimizer, and WP-Optimize sit in that shared vocabulary, so the proposal should say lazy load, missing sizes, or the next-gen flag, not a private key the model invented. If it cannot map the key on your plugin, it should say so and stop. Guessing an option name is how you write a row that nothing reads.
One mapped write purges that layer and stores the old values. Then warm the same two URLs. Then measure both, three times each. Compare against the four lines you copied down. You want a HIT on the public page, a time to first byte you can set next to the baseline, and, if you changed an image setting, a count of missing attributes that went the right way. You do not want a new Core Web Vitals badge. There is no score badge to paste into a slide. Open the PageSpeed link if someone asks for the number.
Run cache-verify-in-browser again after the second measure. If lazy load is now on and the check flags an above-the-fold image, that is a failed check. Revert, or exclude that image in the cache plugin's own screen, and measure once more. Do not stack another setting on a failed check to balance it. Two changes in one experiment means you will not know which one moved the time to first byte.
A saved value can still do nothing on the wire. The HTML check reports that as blocked by the environment when there is no rewrite file, or when the edge is not caching HTML. If you see that note, the setting is stored and the visitor is not receiving it. Revert, or fix the rewrite or the edge outside this plugin, then measure again. Do not keep tuning keys that the check has already told you are not reaching the response.
Image size, as a file on disk, is a separate job from these three keys. The keys change how an existing optimiser treats images. They do not run a compressor across the library. If one hero file is the actual problem, that is the Free edit described later, or a conversion you start in the image plugin. Do not describe either of those as the cache module recompressing the uploads folder. It does not.
When to revert
Revert when the second measure is worse, or when a check fails. Worse is specific. A higher time to first byte on a warm HIT. A public page that used to HIT and now stays on MISS. A larger HTML file you did not mean to grow. A new render-blocking file. A failed check includes a lazy hero, a size attribute that is still missing after a setting that claimed to add sizes, or mixed content that was not there before.
Reverting the experiment puts every layer in the snapshot back. That is the page cache, the asset optimiser, the object cache, and the edge layer you recorded. It does not reach a second plugin you changed by hand in another tab. One rollback cannot span two plugins. If you touched two, you need a way back for each, and this experiment is only one of them.
Revert writes option rows directly. A generated config may still need one re-save in that plugin's own screen before the response matches the option. If the HTML check still looks wrong after a revert, do that re-save, purge the WordPress layer, warm, and measure once more before you decide the revert failed. The option row and the file the server actually reads are not always the same thing, and the plugin tells you that rather than pretending the wire moved.
Some keys are refused unless you confirm them: css.combine, css.critical, css.unused_css_removal, css.defer, js.combine, js.defer, js.delay, cdn.enabled, cdn.hosts, and page_cache.cache_logged_in. Leave them for another day, after an image setting has been measured and kept or reverted. If you do confirm one, open the menu and the cart in a browser before you keep it. Combined or delayed JavaScript is a common way to lose a mobile menu or a mini-cart. The server measure does not click those controls. You do.
Purge is not revert, and it is not a full clear of the internet in front of your site. Purge clears WordPress layers for the whole site, for one URL, or for one post. It does not clear Cloudflare, a firewall, or a host edge. If step 1 listed an edge layer, assume that layer can still be holding the old HTML until its own lifetime ends or you purge it in that product's dashboard. People see a MISS inside WordPress and a stale page in the browser for exactly this reason. The browser is not lying. A different cache is answering it.
A crawler, a preload, or a database clean that deletes rows needs confirmation, and it cannot be undone. The change ledger restores settings. It does not restore deleted revisions or comments. Do not confirm a database clean because a speed article on the internet said revisions slow sites down. That is a different project, with a backup, on a day you are not also changing the page cache.
If you are unsure, revert. You lose the experiment and a few minutes. You do not lose the menu.
What Free can do if you do not have Pro
Without Pro you cannot run the cache experiment, and you should not ask the model to imitate it. The 14 cache abilities are not there unless the licence is active and a supported plugin is active. A confident paragraph about your page cache, written with no tool result under it, is the generic list again.
On Free, run performance-audit and system-status before any write. The audit is bounded server-side performance checks without a synthetic speed claim. Status is the concise report of WordPress, PHP, the database, cron, cache, and the WPPilot runtime. Use them to see whether a cache looks present and whether the server is obviously short of memory, stuck on cron, or missing something basic. They do not replace the Pro measure of a URL, and they will not flip a switch in LiteSpeed Cache, WP Rocket, SiteGround Speed Optimizer, or any other plugin.
Free can edit one image in the media library, using WordPress's own editor, in the order you pass the operations. You can resize, crop, rotate, or flip that one file. Resize stays inside a box and keeps the ratio, so you describe the box, not a stretched width. Angles are 90, 180, or 270. Copy is the default. Copy saves a new attachment, and pages that already use the old file keep using it until you change them. Replace writes a new file on the same attachment and keeps the old file as a backup, which means every page using that image changes. That is the one you want for a hero that is on the home page, and the one you should look at in a browser afterwards. Sides cap at 8000 pixels. Upscaling is refused unless you allow it. The formats are JPEG, PNG, GIF, WebP, and AVIF. Files are never deleted. Both modes undo from the change log.
That is one file. It is not a bulk recompress, and it is not a library-wide WebP conversion. If the hero is a very wide JPEG shown much smaller, resizing that one attachment is a fair Free job. Name the attachment, name the box, and say copy or replace. Then look at the page. There is still no PageSpeed score inside the plugin. Open PageSpeed yourself if you want one.
The rest of the loop, on Free, is yours to do in the cache plugin's screens. Read the status. Fix the one image that is actually huge. Turn on lazy load in that plugin if you are willing to check the hero afterwards. The model can tell you which screen to open. It should not claim it flipped the switch.
Time saved is not a score
Jinny Klink left a 5-star review of WPPilot Pro on Freemius. It is not on wppilot.co yet, so you will not find this quote on the marketing site. She does not mention a score, a grade, or Core Web Vitals. I am including it once because she is talking about time, which is what this loop is for: less back-and-forth, one change you can undo, instead of a week of pasted advice. She is not proof that a measurement came back green.
Game changer
I was spending hours trying to speed up my website when I thought to myself, "I wonder if an AI agent can just do this?" I found WordPress Pilot, and suddenly I'd sped up my website, created new pages, built new forms, and set up new booking systems—all within a day. What I managed to get done in one day would previously have taken me about two weeks of going back and forth with ChatGPT and doing everything manually. AI was already a game changer for me. WordPress Pilot feels like a 10x multiplier on that game changer. Absolutely excellent. I genuinely can't believe how much time it has saved me.
Read that as a day of work set against two weeks of copying steps out of a chat and doing them by hand. Do not read it as an LCP, and do not ask the model to produce a number that would make the review "complete." The review is complete as a note about time.
What this will not do
It will not invent a Core Web Vitals number. LCP, CLS, and INP need a browser paint. You get PageSpeed links for mobile and desktop. You open them. If a client, a boss, or a report template demands a score, the score comes from that page, not from the chat transcript.
It will not recompress images in bulk, and it will not quietly rewrite the library to WebP. One Free edit changes one file through WordPress's editor. A Pro image setting flips a switch in a plugin you already run. Next-gen files exist only after that image plugin creates them. Until you run that screen, there is nothing new to serve.
It will not purge Cloudflare, a firewall, or a host edge. If one of those sits in front of WordPress, your HIT can be their HIT, and a purge here did not touch it. The check-setup list is how you see that before you celebrate.
It will not fix slow hosting, a heavy theme, or an unindexed database. Those are not a checkbox. If three warm HITs are still slow, the next conversation is about the host or the theme, not about another image flag. Say that out loud in the chat so the model does not keep proposing keys.
It will not cache logged-in users, combine CSS, defer or delay JavaScript, or turn on a CDN host unless you confirm those keys. Even then you owe yourself a look at the menu and the cart before you keep the change.
On Free, run the audit and the status report before any write. On Pro, list the layers and measure WordPress speed first. Then one change. Then the same measure. Then the PageSpeed link, in a browser, which is the only place that number exists.
Appendix
Versions cited from the public pages on 4 October 2026: Free 1.16.0 and Pro 1.10.0. Confirm them on the feature list and the platform reference if you are reading this later. The refused keys, the 8000 pixel cap, the five-experiment limit, and the ten-URL warm cap are the limits this walk-through used. If a page on the site disagrees with a sentence here, the site wins.
Top comments (0)