TamRank runs your pages through Google’s PageSpeed Insights API and brings the result back into WordPress, so you can test a page and read what is slowing it down without leaving the editor. PageSpeed testing is a PRO feature and it needs a free Google API key, which is a one-time setup. This page covers both.
In short
- Get a free API key from the Google Cloud Console.
- Paste it under TamRank → Settings → PageSpeed and validate it.
- Run a test on any page, for mobile or desktop.
- Work down the opportunities, largest saving first.
Setting up your API key, once
Google’s API is free to use, with limits generous enough that a normal site will not come close to them. The key is yours, tied to your own Google project, which is why TamRank cannot supply one for you.
- Open the Google Cloud Console and create a project, or pick an existing one.
- Go to APIs & Services → Library, search for PageSpeed Insights API, and enable it.
- Go to APIs & Services → Credentials and choose Create credentials → API key.
- Copy the key.
- In WordPress, go to TamRank → Settings → PageSpeed, paste it, and click Validate.
Validate before you move on. It confirms the key works and that the API is enabled on that project, which is the step people skip and then spend twenty minutes debugging.
Running a test
Open a post or page and find the TamRank PageSpeed panel. Choose Mobile or Desktop and run the test. It takes somewhere between ten and thirty seconds, because Google is genuinely loading your page to measure it.
Test mobile first. Google indexes and ranks on the mobile version of your site, mobile scores are almost always the worse of the two, and a desktop score can look reassuring while the version that counts is struggling.
Two limits to know about, both there to keep you inside Google’s fair-use terms:
- tests are capped at 10 per hour
- results are cached for 24 hours, so testing the same page again returns the stored result until the cache expires or you clear it
That caching is a feature rather than an obstacle. It stops you burning your hourly allowance re-testing the same page and reading noise as progress.
Reading the result
You get a performance score out of 100, your Core Web Vitals, and a list of opportunities.
The score bands are Google’s own: 90 to 100 is good, 50 to 89 needs work, and below 50 is poor. The number is a weighted summary of the underlying measurements, which is why it can swing several points between two runs of an unchanged page. Do not read a five-point movement as a change.
The Core Web Vitals underneath are the part worth your attention: LCP for loading, INP for responsiveness, CLS for visual stability. Each is explained in Core Web Vitals, explained.
The opportunities list is sorted by estimated saving, so the top of the list is where the time is. On WordPress sites it is usually the same handful: images that are too large or in the wrong format, offscreen images loading immediately, render-blocking CSS and JavaScript, unused code from plugins, and text served without compression.
Tip: fix the cause, not the score
A performance score is a summary of a single simulated load, and it is easy to become attached to it. Two things keep it in proportion.
First, what Google actually uses for ranking is field data, the experience of real visitors over the past 28 days, not this test. A fix shows up here immediately and in the field data weeks later. Second, the opportunities are estimates of what you could save, not promises, and the last ten points of a score routinely cost more effort than the first forty.
Test, fix the top two or three opportunities, get your Core Web Vitals into the green, and stop. A page at 78 that loads its content quickly is doing better by your visitors than an afternoon spent chasing 95.
Troubleshooting
My key will not validate. Almost always the PageSpeed Insights API is not enabled on that Google Cloud project, or the key has a restriction on it. Enable the API, and check any key restrictions you added.
I have hit the rate limit. Ten tests per hour. Wait, or spend the remaining tests on different pages rather than repeats of one.
My results are not changing after a fix. Results are cached for 24 hours. Clear the cached result and run again.
My score is different every time. Normal. Each test is a real load over a real network. Judge trends, not single runs.
The test cannot reach my page. Google has to load the URL from outside. Pages behind a login, on staging, or blocked by a firewall cannot be tested.
Frequently asked questions
Is PageSpeed testing free?
It is a PRO feature in TamRank. Google’s API itself is free, and you supply your own key.
Why do I need my own API key?
The key belongs to your Google project and its quota. Getting one is free and takes a few minutes.
Should I test mobile or desktop?
Mobile. That is the version Google ranks on.
Do these scores affect my ranking directly?
The score does not. The Core Web Vitals underneath it do, measured from real visitors rather than from this test.
How often should I test?
After a change worth measuring. Repeated testing of an unchanged page just returns the cached result.
Related
- What the metrics mean: Core Web Vitals, explained
- The most common fix: Image optimization: WebP and alt text
- Where Speed shows up: Understanding your dashboard
- Back to Documentation
