xSpeed Cache is officially live! Get 50% OFF during Launch Week — Lifetime starts at just $79Lifetime from $79 — 50% OFF, Launch Week! See Plans →

See Plans →
Features
xSpeed Hub Pricing Docs Blog Scan
Appearance
Get Plugin

Run and track PageSpeed tests with Manus

Tracking PageSpeed scores with Manus means handing the general agent a whole PageSpeed review: it reads stored history through xSpeed Hub, retests within a limit you set and writes up the findings, or runs the history part as a scheduled task.

list_sitesget_score_historyrun_speed_testget_benchmark_historyrun_benchmark

Last updated: October 2026

Example session · Manus

You: Use xSpeed Hub to review PageSpeed on all my sites. Retest at most two, mobile only, and write it up.

list_sites read-only
→ 4 sites: shop, blog, docs, landing

get_score_history(site: shop) read-only
→ latest mobile 52, previous 60; LCP 4.4 s

get_score_history(site: blog) read-only
→ latest mobile 67, previous 66

get_score_history(site: docs) read-only
→ latest mobile 74, previous 75

get_score_history(site: landing) read-only
→ latest mobile 58, previous 64; TBT 390 ms

Manus: Two sites dropped: shop by eight points and landing by six. Retesting both uses your cap of two, mobile, about two minutes each from the shared allowance. Start both?

You: Yes, both.

run_speed_test(site: shop, strategy: mobile) uses quota
→ mobile score 53, LCP 4.3 s, saved to the Hub report history

run_speed_test(site: landing, strategy: mobile) uses quota
→ mobile score 63, TBT 300 ms, saved to the Hub report history

Manus: shop's drop holds at 53, driven by LCP. landing came back to 63, so its dip was mostly noise. Both are in the summary with run dates, and blog and docs are listed as unchanged.

01

How Manus handles this

Manus is built for the task you would hand to an assistant: review PageSpeed across all my sites and write me a one-page summary. Name xSpeed Hub in the task, so Manus uses the custom MCP server you added under Settings, Integrations. It lists your sites, reads get_score_history for each one and compares the newest mobile and desktop runs with the previous ones, with score, LCP, CLS and TBT. Then it writes the summary as a document, which is what Manus adds over a chat answer.

Set a limit on fresh tests in the task itself. run_speed_test is a PageSpeed Insights run from the Hub, one site and one device per call, up to about two minutes each, and every run spends a shared allowance. A review of ten sites on both devices would be twenty runs, so write something like "retest at most three sites, mobile only". The fresh results go to the Hub's own report history on the Reports tab, and get_score_history may not show them. If you want a cache check alongside, run_benchmark can time every site cached and uncached in one call, with no Lighthouse score.

For a weekly version, use a Manus scheduled task. It runs unattended on a timetable and can use the Hub server, but the Hub does not run PageSpeed tests on a timer, so the scheduled task should read history and report rather than test. Keep the retest step for a task you start and can watch.

02

Set up Manus once

Already connected? Skip to the prompts. Alternatives and troubleshooting are on the Manus guide.

1Put 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.

2Copy the connection token from xSpeed Hub

Sign in at app.xspeedcache.com as the workspace owner, open Connect AI and copy the connection token. If Manus will only report, turn on Read-only everywhere so the Hub refuses every write tool on that token.

Text
xSpeed Hub  >  Connect AI  >  connection token

3Add xSpeed Hub as a custom MCP server

In Manus, open Settings, then Integrations, then Custom MCP Servers, and click Add Server. Name it xSpeed Hub, enter this as the server URL, and enter the connection token as the Bearer token in the authentication field.

Text
https://app.xspeedcache.com/xspeed/mcp

4Let Manus test it, then name it in a task

Manus checks that it can reach the server and read its list of tools. Then start a task that names xSpeed Hub, so Manus uses this server.

Text
Use xSpeed Hub to list my sites and tell me which ones have page caching turned off.
1 / 4

Full Manus setup, sign-in options and FAQ

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. Manus's custom MCP documentation describes no per-tool approval setting for a custom server, and its scheduled tasks offer a skip confirmations option that lets Manus act without asking each time. xSpeed Hub has no confirmation step of its own, so a write runs as soon as Manus calls it and your connection allows writes. The Hub tells the agent to confirm the target site and to ask once before a write that touches every site, but that is an instruction. The firm stop is the token: with Read-only everywhere on, the Hub refuses every write tool. Keep it on for scheduled work, and leave skip confirmations off for any task that may write.

03

What do I ask?

Three prompts written for Manus. More for this job are below.

Prompt for Manus
Use xSpeed Hub to review PageSpeed across all my sites, retest at most three on mobile, and write a one-page summary.
Prompt for Manus
With xSpeed Hub, build a table of the latest mobile and desktop scores per site, with the date of each run.
Prompt for Manus
Every Monday at 8:00, use xSpeed Hub to read the PageSpeed history for every site and report drops. Do not run tests.
04

What happens, step by step

PageSpeed Insights is Google's Lighthouse audit, and its score and Core Web Vitals are the numbers most people mean by "my speed". Through xSpeed Hub an agent can read the scores a site has already stored, run a new PageSpeed test on mobile or desktop, and read or run a separate benchmark of cached against uncached response time. The three answer different questions, and the Hub tells the agent which to use for each.

01

Read before you test

get_score_history returns the stored PageSpeed Insights and GTmetrix runs for a site: the score per run, with LCP, FCP, CLS, TBT, Speed Index and TTFB, mobile and desktop. It starts nothing. The Hub tells the agent to use it whenever you ask what your score is, or whether it improved, because a new test spends a shared allowance.

02

Run a new test when you need one

run_speed_test runs a real PageSpeed Insights audit on the site from the Hub and returns the score, the Core Web Vitals and the top opportunities. strategy is mobile (the default) or desktop, and one call tests one of them. It can take up to about 2 minutes, so the agent should say it is running before it calls.

03

Test the other device

Mobile and desktop scores differ, often by a lot. For both, the agent makes two calls, one per strategy. A failure is reported with its reason: PageSpeed not configured, quota reached, a timeout, or a site the audit cannot reach.

04

Measure the cache on its own

run_benchmark times the home page with the cache bypassed and again served from cache, and returns the response times. It is a read tool, and it accepts site: "all" for every site. It does not return a Lighthouse score, so the agent must not use it to answer a PageSpeed question.

05

Compare over time

get_benchmark_history returns past benchmark runs, uncached against cached, together with the settings changes on the same timeline, which is how you answer "did that change help?". For PageSpeed scores over time, use get_score_history.

05

Reference

Read stored scoresget_score_history (read): PageSpeed Insights and GTmetrix runs, starts nothing
Metrics per runScore, LCP, FCP, CLS, TBT, Speed Index, TTFB, for mobile and desktop
Run a new testrun_speed_test (write, uses the shared allowance): one PageSpeed Insights run per call
strategymobile (default) or desktop
DurationUp to about 2 minutes per run
Why a test is a writeIt spends a shared PageSpeed allowance and stores a report; it changes nothing on the site
Read-only accessA connection token with Read-only everywhere on, or a Viewer member's sign-in: run_speed_test is refused; get_score_history, run_benchmark and get_benchmark_history still work. An OAuth sign-in gets the scopes the client asks for
Benchmarkrun_benchmark (read): cached against uncached response time for the home page, no Lighthouse score
Benchmark historyget_benchmark_history (read): past runs plus settings changes on the same timeline
SchedulingThe Hub does not schedule PageSpeed tests itself; its daily pass only reads reports the plugin already stored
Where a new test is storedIn the Hub's own report history, the one the Hub dashboard shows
06

Rules worth keeping

  • Check the history first. Ask for stored scores before starting a test, and run a new one only when you want a fresh measurement or something changed.
  • Never answer a PageSpeed or Lighthouse question with run_benchmark. It times your own cache and carries no score.
  • run_speed_test changes nothing on your site, but the Hub classes it a write because it spends a shared allowance. A connection token with Read-only everywhere on, or a Viewer sign-in, refuses it. An OAuth sign-in gets the scopes the client asks for, so there your client's approval prompt is the gate.
  • Lab scores move a few points between runs of the same page. The agent should compare like with like, same site, same strategy, and not report one run's difference as a trend.
  • A new test does not run on a timer. If you want a regular test, the agent has to be started by something else, such as a scheduled job in your client, and a scheduled run that spends the allowance should be one you are comfortable leaving unattended.

Good to know with Manus

Manus describes no per-tool approval setting for a custom MCP server, and xSpeed Hub has no confirmation step of its own, so once Manus decides a retest is useful, run_speed_test runs as soon as your connection allows writes. The limit you write in the task is the main control in a live run. Scheduled tasks need more care: Manus offers a skip confirmations option there that lets it act without asking, so leave it off, use the Test run option with the same history-only prompt, and send the scheduled task through a connection token with Read-only everywhere on. The Hub then refuses run_speed_test while get_score_history and run_benchmark still work. The token reaches every site in the workspace, so keep it out of task text and rotate it on the Connect AI page if it leaks.

07

More prompts for this job

They work in any client connected to xSpeed Hub.

Prompt
Using xSpeed Hub, what is the mobile PageSpeed score for shop? Check the stored history before you run anything.
Prompt
Use xSpeed Hub to run a new mobile PageSpeed test on blog and tell me the score, LCP and the top opportunities.
Prompt
With xSpeed Hub, test shop on desktop and mobile and tell me which one is worse.
Prompt
Using xSpeed Hub, has the PageSpeed score on docs improved over the last few runs?
Prompt
Use xSpeed Hub to benchmark the cache on every site and tell me which one saves the least time.
Prompt
Did turning on minification on shop help? Use xSpeed Hub to compare the benchmark history around that change.
Prompt
My PageSpeed test failed on staging. Use xSpeed Hub to tell me why.
08

Frequently asked questions

It can call run_speed_test if the connection allows writes, but a scheduled task runs unattended and each test spends the shared allowance. The Hub does not schedule tests itself. Keep scheduled tasks to get_score_history and send them through a token with Read-only everywhere on.

Put a number in the task, such as retest at most two sites on mobile. Manus describes no per-tool approval for a custom server and the Hub has no confirmation step, so the task text and a read-only token are the controls you have.

run_speed_test runs a real PageSpeed Insights audit and returns a Lighthouse score with Core Web Vitals. run_benchmark measures how fast your own cache answers compared with an uncached request for the home page, and returns no Lighthouse score. Use the first for "what is my PageSpeed score" and the second for "is my caching working".

A single run can take up to about 2 minutes, so the agent should tell you it has started before it calls. One call tests one device, mobile or desktop, so checking both takes two calls.

Yes. get_score_history reads the stored PageSpeed Insights and GTmetrix runs for the site and starts nothing. The Hub tells the agent to read it first whenever you ask what your score is, because a new test spends a shared allowance.

No. The Hub does not schedule PageSpeed tests itself. Its daily pass re-verifies sites, snapshots cache status and pulls the PageSpeed and GTmetrix reports the plugin has already stored, and it can alert on a score regression. If you want regular new tests, they have to be started by a client that can run scheduled jobs.

It does not change your site. The Hub classes run_speed_test as a write because it spends a shared PageSpeed allowance and stores a report, and a read-only connection (the connection token with Read-only everywhere on, or a Viewer sign-in) should not be able to cost the owner anything. Such a connection can still read stored scores with get_score_history.

09

Keep going

Track PageSpeed scores with other agents

More with Manus

Documentation

From the blog

Track PageSpeed scores, from Manus.

xSpeed Hub is free and has no site cap. Connect your sites once and ask from the agent you already use.