# Raise a WordPress site's PageSpeed score with OpenCode

> Raising a WordPress PageSpeed score with OpenCode means asking it in your terminal to preview and then apply an xSpeed optimization pass through xSpeed Hub, under the permission rules you set.

Page: https://xspeedcache.com/agent/opencode/optimize-site/
Last updated: October 2026

OpenCode keeps its permissions in config, with three answers for each tool: ask, allow or deny. Most permissions default to allow, so this job needs rules before the first run. The tools are named with the server first, such as xspeedhub_optimize_site, and the last matching rule wins. You put an ask rule on xspeedhub_* first, then allow rules for the get_ and list_ reads, so list_sites and list_modules run freely and optimize_site stays on ask. Then you type the goal, such as raising the score on the client site, and OpenCode calls list_sites and optimize_site with dry_run on. The ask rule stops it at the preview, you approve, and you get the plan with nothing changed on the site.

Read it, then tell OpenCode to apply the plan. The permission prompt appears again, and this is the call that changes the site. The pass applies each setting one at a time, checks the page after every change, and undoes anything that breaks it, for up to two minutes per site. You get the applied list, the undone list with reasons, and the unfixable list.

Two habits help. First, ask for the level in the prompt: safe, standard or aggressive, with aggressive reserved for a staging copy because it includes settings known to break some themes. Second, take the verify step seriously. The Hub gives OpenCode a list of verify_urls and tells it to look at the pages before saying the pass went well. The plugin cannot run JavaScript, so open those pages in a browser with the console visible.

## Set up OpenCode once

### 1. Put your sites in xSpeed Hub

Sign in at app.xspeedcache.com with Google or email; the Hub is free and has no site cap. Then connect each WordPress site from its own dashboard: click Connect Hub in the xSpeed Cache top bar, then Connect via xSpeed Hub. Each site needs the free xSpeed Cache plugin.

### 2. Add xSpeed Hub to your config

Put this block in your global config, or in opencode.json at a project root to scope it to that project. OpenCode reads both JSON and JSONC. No other field is needed: when the Hub answers 401, OpenCode starts the OAuth flow and registers itself through dynamic client registration.

File: `~/.config/opencode/opencode.json`

```jsonc
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "xspeedhub": {
      "type": "remote",
      "url": "https://app.xspeedcache.com/xspeed/mcp"
    }
  }
}
```

### 3. Sign in with opencode mcp auth

Run this once. It opens a browser page on xSpeed Hub where you sign in and approve access. There is no token to paste; OpenCode stores the credentials it receives. Run opencode mcp list to see the server and its auth status, and opencode mcp debug xspeedhub if the connection fails.

```bash
opencode mcp auth xspeedhub
```

Full setup: https://xspeedcache.com/agent/opencode/

### Before you send a prompt that changes something

Reads change nothing on your sites, though contact_support emails xSpeed support. Writes run once your connection allows them, so your client's approval prompt and a read-only connection (the token's Read-only everywhere switch, or a Viewer sign-in) are the gates that matter. OpenCode checks MCP tools against its permission rules under the prefixed name, such as xspeedhub_purge_cache, and most permissions default to allow. With no rule of yours in place, a Hub write tool runs without a prompt. Add rules to change that: "xspeedhub_*": "ask" first, then "xspeedhub_get_*": "allow" and "xspeedhub_list_*": "allow", because the last matching rule wins. A deny rule holds even under opencode --auto, which approves everything that is not denied. The Hub itself has no confirmation step, so these rules and read-only access are the gates. For read-only access, send the connection token with Read-only everywhere on, or sign in as a Viewer member.

## Prompts

- Using xSpeed Hub, preview an optimization for the client site at the standard level and stop after the plan.
- Use xSpeed Hub to apply the plan to client at the safe level, then give me the verify URLs.
- Use only xSpeed Hub read tools to tell me which modules the client site has and whether Critical CSS is available.

## Example session

```
You: Preview an optimization for the client site with xSpeed Hub. Standard level.
  → list_sites [read-only]: 7 sites; client is client.example.com
  → optimize_site(site: client, aggressiveness: standard, dry_run: true) [dry run]: plan: 5 settings to apply (CSS minify, defer JS, lazy-load images, compression, browser cache), nothing changed
Agent: The plan has five steps: CSS minify, script deferral, lazy-loading, compression and browser caching. Nothing has changed. Apply it to client?
You: Yes, apply it.
  → optimize_site(site: client, aggressiveness: standard) [changes site]: applied 4, undone 1 (a menu script broke), unfixable: hotlinked logo images
Agent: Four settings are on and one was undone because it broke the menu. Hotlinked logos are on the unfixable list. Open the home page and the main menu in a browser and check the console.
```

## How it works

1. **See where the site stands**: The agent reads get_score_history for the last stored scores and list_modules for which modules exist on that site and what state they are in. Neither changes anything.
2. **Preview with dry_run**: optimize_site with dry_run: true returns the plan: each change and its tier, what would be skipped (already on, or needing a higher aggressiveness) and what it cannot fix. Nothing is applied. The tool description tells the agent to prefer this before the first real run on a site you have not optimized before.
3. **Apply it**: optimize_site without dry_run applies the plan. aggressiveness is safe (removals and server-side changes only), standard (the default) or aggressive, which includes settings known to break some themes and should be opted into deliberately. A run can take up to about 2 minutes per site.
4. **Look at the site afterwards**: When changes were applied, the result carries verify_urls and a note. The site checks its own HTML and reverts anything that breaks it, but it cannot run JavaScript, so verified: true does not prove the page works in a browser. The Hub tells the agent to open those URLs and check the page renders and the console is clean, or to tell you which URLs to check.
5. **Reach for a number only if you named one**: target_score (1 to 100, Pro sites only) turns one pass into repeated rounds toward that score, up to max_rounds, with 3 as the most per site. Each round is a real PageSpeed measurement and up to about 2 minutes. The result says why it stopped, and diminishing returns means what is left is outside what caching can reach.
6. **Critical CSS on Pro sites**: generate_critical_css generates above-the-fold CSS so the first screen can paint without waiting for the full stylesheets. It needs the Pro Critical CSS module on that site, and the site answers with an unknown-tool error without it. Pages are rebuilt with it on their next build, so the agent purges the cache afterwards.

## Reference

| | |
| --- | --- |
| Main tool | optimize_site (write): measure, apply one setting at a time, verify, undo what breaks, re-measure |
| Preview | dry_run: true returns the plan and changes nothing |
| aggressiveness | safe, standard (default) or aggressive |
| Every site at once | site: "all" or a list of handles, one result per site, sites run one after another; the Hub's confirm-once instruction does not name optimize_site, so your client's prompt is the gate |
| Time | Up to about 2 minutes per site |
| target_score | 1 to 100; needs Pro on the site; without it the site runs one pass and says so |
| max_rounds | Up to 3 per site; only sent along with target_score; 12 rounds in total per call |
| Wide fan-out with a target | Each site gets fewer rounds, and the result carries a note saying so |
| Result fields | applied, skipped, reverted, unfixable, score, verified, rounds; verify_urls after a run that changed something |
| Already tuned site | Returns "everything is already on" plus what it cannot fix; that is an answer, not a failure |
| Critical CSS | generate_critical_css (write), Pro Critical CSS module required; purge_cache afterwards |
| Read-only connection | optimize_site and generate_critical_css are refused; dry_run is still a write call, so it is refused too. Applies to the connection token with Read-only everywhere on and to a Viewer sign-in, not to other OAuth sign-ins |

## Rules

- Run dry_run first. optimize_site changes live site settings as soon as your connection allows writes. The tool description tells the agent to preview first on a site that has not been optimized, but that is guidance, so your client's approval prompt and a read-only connection (the connection token with Read-only everywhere on, or a Viewer sign-in) are the real gates.
- Keep aggressive for a deliberate choice. It includes settings known to break some themes, and the agent should say so before using it.
- After a run that changed something, open the pages in verify_urls. The HTML checks cannot run JavaScript, so a page can pass them and still be broken in a browser. Do not call a run safe because verified is true.
- Relay the unfixable list. When a site is already tuned, the honest answer is that caching is done and the rest is page weight, hotlinked images or DOM size. The agent should not retry the tool or claim a gain it did not make.
- Only ask for target_score when you want the site driven to a number. Each round costs a real PageSpeed measurement, and a plain "make it faster" is one pass.

## Good to know with OpenCode

OpenCode starts from permissive defaults, so with no rule of yours the preview and the real pass both run without a prompt, and the Hub runs a write as soon as your connection allows it. Put the ask rule on xspeedhub_* before the allow rules for the reads, because the last matching rule wins. An allow rule on optimize_site skips the prompt for the preview and the real pass alike. If you only want to look in a given session, set optimize_site to deny, which holds even under opencode --auto, or use a read-only connection (the connection token with Read-only everywhere on, or a Viewer sign-in), which makes the Hub refuse the preview as well.

## More prompts for this job

They work in any client connected to xSpeed Hub.

- Ask xSpeed Hub to preview what optimize_site would change on shop with a safe pass. Do not apply anything.
- Use xSpeed Hub to optimize the blog site with the standard pass, then give me the pages to check by hand.
- With xSpeed Hub, get docs to a mobile PageSpeed score of 90 if you can, and tell me why it stopped if it does not get there.
- Use xSpeed Hub to show me what optimize_site would do on every site, as a dry run, and list which sites have the most left to change.
- Use xSpeed Hub to generate critical CSS for shop, then purge the cache so the pages are rebuilt with it.
- With xSpeed Hub, optimize shop, then compare the new PageSpeed score with the last stored one.
- Using xSpeed Hub, what could optimize_site not fix on the shop site?

## Frequently asked questions

### How should I set OpenCode permissions for xSpeed optimization?

OpenCode allows most tools by default, so add rules. Set every tool whose name starts with xspeedhub_ to ask first, then add allow rules for the names that start with xspeedhub_get_ and xspeedhub_list_, because the last matching rule wins. The dry run and the real pass use the same tool, so the one ask rule on optimize_site covers both.

### Can I stop OpenCode from optimizing a site while still letting it look?

Yes. Set xspeedhub_optimize_site to deny, which holds even under opencode --auto, or use a read-only connection (the connection token with Read-only everywhere on, or a Viewer sign-in), which refuses every write tool. Reads such as get_score_history and list_modules keep working either way.

### What does optimize_site actually do?

It measures the site, applies the recommended xSpeed settings one at a time, checks that the page still renders after each change, and undoes any change that breaks it. It then reports what was applied, skipped and reverted, and what it could not fix. It reaches caching and asset delivery only.

### Should I run a dry run first?

Yes, especially on a site you have not optimized before. dry_run: true returns the plan, what would be skipped and what cannot be fixed, and changes nothing. The tool description tells the agent to prefer it, but nothing forces it, so say so in your prompt if you want a preview.

### Can I tell it to get my site to a score of 90?

Yes, with target_score, on a site that has xSpeed Pro. It repeats measure, apply and re-measure for up to 3 rounds per site and stops early when rounds stop helping, saying why. On a Free site the score target is ignored and you get a single pass with a note that no iterative tuner is installed.

### Why did it say everything is already on?

That is a real answer. The settings it can apply were already enabled, so there was nothing to change. The result also lists what it could not fix, such as page weight, images hosted on another domain or DOM size, and those need changes outside a caching plugin.

### Does the agent check that my pages still work?

The site checks its own HTML after each change and reverts anything that breaks it, but it cannot run JavaScript. After a run that changed something, the Hub tells the agent to open the returned verify_urls and check the page renders and the console is clean, or to give you the URLs to check yourself.

### Does generate_critical_css work on a Free site?

No. It needs the Pro Critical CSS module on that site, and without it the site answers with an unknown-tool error. On a Pro site, purge the cache afterwards, because pages already cached were built without the critical CSS.

## Raise the PageSpeed score with other agents

[Claude Code](https://xspeedcache.com/agent/claude-code/optimize-site/) · [Claude](https://xspeedcache.com/agent/claude/optimize-site/) · [Claude Cowork](https://xspeedcache.com/agent/claude-cowork/optimize-site/) · [ChatGPT](https://xspeedcache.com/agent/chatgpt/optimize-site/) · [Codex](https://xspeedcache.com/agent/codex/optimize-site/) · [Cursor](https://xspeedcache.com/agent/cursor/optimize-site/) · [GitHub Copilot in VS Code](https://xspeedcache.com/agent/github-copilot/optimize-site/) · [Windsurf](https://xspeedcache.com/agent/windsurf/optimize-site/) · [Gemini CLI](https://xspeedcache.com/agent/gemini-cli/optimize-site/) · [Antigravity](https://xspeedcache.com/agent/antigravity/optimize-site/) · [Zed](https://xspeedcache.com/agent/zed/optimize-site/) · [Kiro](https://xspeedcache.com/agent/kiro/optimize-site/) · [OpenClaw](https://xspeedcache.com/agent/openclaw/optimize-site/) · [Hermes Agent](https://xspeedcache.com/agent/hermes-agent/optimize-site/) · [Grok Build](https://xspeedcache.com/agent/grok-build/optimize-site/) · [ChatGPT dots](https://xspeedcache.com/agent/chatgpt-dots/optimize-site/) · [Grok](https://xspeedcache.com/agent/grok/optimize-site/) · [Grok Bot](https://xspeedcache.com/agent/grok-bot/optimize-site/) · [Muse](https://xspeedcache.com/agent/muse/optimize-site/) · [Manus](https://xspeedcache.com/agent/manus/optimize-site/) · [Kimi Code](https://xspeedcache.com/agent/kimi/optimize-site/) · [Paperclip](https://xspeedcache.com/agent/paperclip/optimize-site/) · [NanoClaw](https://xspeedcache.com/agent/nanoclaw/optimize-site/)

## More with OpenCode

- [Purge the WordPress cache with OpenCode](https://xspeedcache.com/agent/opencode/purge-cache/)
- [Find out why WordPress pages are not cached with OpenCode](https://xspeedcache.com/agent/opencode/troubleshoot-cache/)
- [Scan a website for speed problems with OpenCode](https://xspeedcache.com/agent/opencode/speed-scan/)
- [Run and track PageSpeed tests with OpenCode](https://xspeedcache.com/agent/opencode/pagespeed-tests/)
- [Tune WordPress cache settings with OpenCode](https://xspeedcache.com/agent/opencode/cache-settings/)
- [Warm the WordPress cache with OpenCode](https://xspeedcache.com/agent/opencode/preload-cache/)
- [Set up the Redis object cache with OpenCode](https://xspeedcache.com/agent/opencode/object-cache/)
- [Manage Cloudflare caching with OpenCode](https://xspeedcache.com/agent/opencode/cloudflare/)
- [Manage every WordPress site at once with OpenCode](https://xspeedcache.com/agent/opencode/fleet/)

## Documentation

- How to generate Critical CSS: https://xspeedcache.com/docs/critical-css/
- Performance recommendations: https://xspeedcache.com/docs/performance-recommendations/
- How to run a speed test: https://xspeedcache.com/docs/external-score/
- Free vs Pro: what is included: https://xspeedcache.com/docs/free-vs-pro/