Step one
Find The Sitemap
It checks the paths sitemaps are normally published at until it finds one. When a site hides its sitemap or blocks the request, you paste the sitemap URL in yourself and the run continues from there.
Site-level PageSpeed, not page-level PageSpeed. It samples across a site's templates and reports an average you can put in front of a client.
PageSpeed Sampler measures a whole site instead of one URL. You give it a domain. It finds the site's sitemap by checking the paths sitemaps usually live at, pulls the URL list, groups those URLs by collection, which is the first segment of the path, then samples up to ten URLs per collection and one hundred in total. Home, about and contact are forced into every sample, because those are the pages people check first.
Every sampled URL is then measured on its own, on both the mobile and the desktop strategy, and the results are averaged and reported in the interface. What comes out is a performance number for the site plus a breakdown per collection, which is as close to a per-template reading as you can get from the outside.
It is front end only. No account, no backend, nothing stored. You run it, you read it, you leave.
Google PageSpeed Insights measures one URL at a time. Nobody has a performance problem on one URL. The problem lives in a template: the product page, the blog post, the location page, each of them rendering thousands of URLs that share the same weaknesses. Testing the homepage tells you about the homepage, and the homepage is usually the most optimized page on the site.
Sampling across templates and averaging is the only way to see template-level performance from outside a codebase, and doing it by hand costs an afternoon. This does it in a few minutes, which is the difference between a number you have and a number you meant to get.
Four situations account for almost every run I make of it.
Four steps, all of them in the browser, all of them inside a single sweep.
Step one
It checks the paths sitemaps are normally published at until it finds one. When a site hides its sitemap or blocks the request, you paste the sitemap URL in yourself and the run continues from there.
Step two
URLs are bucketed by the first segment of their path, so /blog/, /products/ and /locations/ become the collections the whole report is built around. A collection is the closest public proxy for a template.
Step three
Up to ten URLs per collection and one hundred per run, with home, about and contact forced in. The caps exist because a sweep that takes twenty minutes does not get used during pitch preparation.
Step four
Every sampled URL is measured individually on both the mobile and the desktop strategy, then averaged into a site-level number and a per-collection number that can be read against each other.
Two engineering notes worth stating: sitemap requests are blocked by CORS on plenty of sites, so they are routed through a chain of public proxies, and when every one of those fails the tool asks you to paste the sitemap URL directly. Speed of a full sweep, with all settings, limits and competitors in play, is treated as a feature rather than an optimization, because fast matters here as much as correct.
Anyone. No account, no signup, no stored data, no email address. It is the most open thing I have built, deliberately, because the number it produces is most useful to the person who has not hired me yet.
It is also the piece of this collection I would most like other people to link to, so it is built to be run once by a stranger and understood without any explanation from me.
It is live, it is public, and there is nothing to sign up for.
Status and access
There is not much to it, which is the point.
Stack
A site-level performance number tells you which template is costing you. Deciding what to do about it, in what order, against what else is competing for the same engineering time, is the work. That is what an engagement is for.