Using PageSpeed results to prioritise prospects is a clever angle: a one-page report with a shareable link gives agencies concrete proof to open a conversation. Tracking Core Web Vitals across client portfolios with regression alerts then covers the work after the deal.
Thank you, Tsutsu. That's how many agencies start with it: the free check gives them something specific to send a prospect, and the monitoring takes over once the site is a client. Good luck with WeProcess as well.
The page-type labels are the part I would use first. We run a job board where the same job page template lives in a dozen language folders, so one slow change to that template shows up as a dozen failing URLs that all need the same fix. Right now we run PageSpeed checks from a small script once a week and eyeball the list. Does the classification group pages by template across /en/, /de/ and the rest, so a regression is counted once per page type rather than once per URL?
Thanks for the first review, and for such a specific question. Almost: we strip language folders when we classify, so the same template under /en/ and /de/ gets the same page type. Each URL is still tested and alerted on separately, though — a slow job template across a dozen locales still shows as a dozen budget hits, not one regression with the URLs nested under it. Grouping regressions once per template across languages is a good idea for multilingual sites, and I've added it to our list. In the meantime, filtering by page type at least puts those failures in one place.
Thanks, the page-type filter already beats our weekly list, since today we sort it by hand. One thing that would make it work for us: do budget alerts let you mute the copies of the same URL path in other language folders, or does every locale send its own alert when the template slows down?
Every locale still alerts on its own. There is no mute for the same path under /en/, /de/, and so on. The digest is one email per site per run, and page-type filter groups the copies for triage, but each language URL still counts as its own budget hit. Collapsing those into one alert is on the list with the template grouping we mentioned earlier. Temporary fix: only monitor /en URLs.
@Apogee Clear, thanks. Watching /en/ plus one Cyrillic locale is probably enough for us, since those pages pull in different fonts and that is where we have actually seen the same template score differently. Do you see that across clients too, non-Latin locales lagging on an identical template?
@spinhire Good choice on /en/ plus one Cyrillic locale. Honestly, we don't have enough data across clients yet to say whether non-Latin locales lag on the same template, so I don't want to give you a number I can't back up. What we can do today: Watcher treats /en/ and /ru/ (or any language folder) as the same page type, but tests and alerts on each URL separately, so a gap between the two shows up side by side in the report. Comparing locales for the same template in one view is on our roadmap. If you'd like to try it, you can create a free account here: https://apogeewatcher.com/?ref=uneed.best&ref_type=adv&utm_source=uneed.best&utm_medium=referral. You can then add the /en/ page and the Cyrillic one and choose how you want them monitored. I'd be glad to hear whether the gap turns out to be fonts, text length or something else.
