CrUX / PSI

Hi DJM,

Thanks for the detailed write-up, and sorry for the runaround. You found a genuine bug, so this was really useful.

I just pushed 1.5.1, which fixes it. It should show up in your Plugins screen within the next little while (or you can hit “Check for updates”). Here’s what was going on:

First, the buttons themselves. On the settings screen the “Measure Core Web Vitals” and “Run PageSpeed audit” buttons weren’t wired up correctly, so clicking them did nothing at all — no spinner, no error, which is why you just kept seeing “No data yet” / “No audit yet”. That’s what 1.5.1 fixes.

Second, what the two tools need once they work:

• PageSpeed audit is a lab test, so it runs on any site regardless of traffic. After you update it should return a score for all three blogs. I also changed one thing: if the key you created was only enabled for the Chrome UX Report, PageSpeed would reject it, so it now quietly falls back to running without a key (which Google allows at low volume).
• Core Web Vitals pulls real-world data from Google’s Chrome UX Report, and Google only has that for sites with enough Chrome traffic. Smaller or newer blogs often aren’t in that dataset yet, so you’ll see a “no field data for this origin” message. That’s expected, not a problem with your key. The Smart LCP / real-user data you already see is measured by the plugin itself, which is why that keeps working either way. In 1.5.1 that message now shows up in the panel instead of staying invisible.

So once you’re on 1.5.1: PageSpeed should light up for all three; Core Web Vitals will depend on whether Google has field data for each origin.

And yes, that “enable the API” button on Google’s docs page spins for a lot of people. Since you already made the key by hand, you’re past that part.

Thanks again for taking the time,
Gunjan

Hi DJM,

Good news, both of those trace back to the same thing, and it’s the API key rather than the plugin.

The “Requests from referer <empty> are blocked” message means your key has its Application restriction set to “HTTP referrers (websites)”. That kind of restriction only works for calls made from a browser, which send a referer header. The plugin asks Google from your server (WordPress → Google), and a server request sends no referer, so Google blocks it.

Two ways to fix it:

1. Easiest: Google Cloud Console → APIs & Services → Credentials → your key → Application restrictions → set it to “None”. To keep the key safe, use API restrictions instead: under “Restrict key”, limit it to just the Chrome UX Report API and the PageSpeed Insights API. Then the key can only call those two, which is the protection that actually matters here.
2. Or update to 1.5.4 (just released). It now sends your site’s URL as the referer with each request, so if you’d rather keep the referrer restriction, add your domain to the allowed list (e.g. https://yoursite.com/*) and it’ll go through.

The PageSpeed “quota exceeded” is the same root cause in disguise. When the key got blocked, the plugin fell back to a keyless request, and keyless PageSpeed uses Google’s shared public pool, which is almost always maxed out. That’s why it hit you on the very first try. Once your key is accepted, PageSpeed uses your own quota and that message goes away. 1.5.4 also makes the plugin show the real key error in that case instead of the confusing shared-quota one.

So sort the key restriction (option 1 is quickest) and both buttons should come to life.

Cheers,
Gunjan

Hi DJM,

Done, and thanks for the nudge, it’s a good idea. I just shipped 1.6.0, which puts a FetchPriority widget right on your main WordPress dashboard with both the Core Web Vitals report and the PageSpeed audit in it. Update the plugin and you’ll find it under Dashboard (drag it wherever you like, or use Screen Options at the top if it’s hidden). It runs off the same API key you already set up.

Glad the referer fix sorted the earlier errors too.

Cheers,
Gunjan