Introducing PageSpeed.ONE Tester Version 4.2: More URLs, Third-party JS, INP, More Slack and Teams Channels

Martin MichálekMartin Michálek2/28/20245 minutes reading

We are delighted to announce the release of the latest version of pagespeed.one, our tool for web speed monitoring.

What new features does version 4.2 bring? Let’s take a closer look at the main highlights.

Ability to Insert More URLs

In the default settings, you can monitor 5 URLs of your website and 4 additional domains, such as competitors, within a single test suite.

This usually suffices for most users, as we closely monitor only the main type pages, and many operators do not have more than one domain.

However, some of you have expressed interest in monitoring a larger number of URLs and domains, so we've worked on this feature. Now, for a small additional fee, it's possible.

Up to 10 URLs, in case we have a large number of unique web templates. Up to 10 URLs, in case we have a large number of unique web templates.

New Metric: "Total JS Third-party Blocking Time"

We often encounter developers blaming poor web performance on third-party JavaScript – analytics, personalization tools, chats, and other components inserted via GTM. But that's not always the case.

To assess the impact of third parties on web speed, you can now compare the total blocking time (the TBT metric) with the third-party blocking time (known as 3PBT):

Impact of total JavaScript blocking time and third parties. The total JavaScript blocking time for this website is huge, but third parties do not significantly contribute.

Introducing INP to Core Web Vitals

As you probably know, from March 12, Google will replace the FID metric with a brand new one – Interaction to Next Paint (INP) – in web speed evaluations.

We've already adjusted all relevant dashboards. We believe the INP metric is far superior for measuring interaction delays, so we are completely removing FID from reports.

INP is high and some interactions will be very slow. This will need some tuning, INP is high and some interactions will be very, very slow.

It's worth noting that INP can only be measured on real users, which is why the metric is available only in reports from the Chrome UX Report.

In synthetic data, you can focus on the auxiliary metric TBT (Total Blocking Time), optimizing it in conjunction with output to Trace and tuning in Chrome DevTools to help with INP adjustments.

Settings: More Slack/Teams Channels

In Settings, we are adding another feature our users have requested – the ability to send notifications to more than one channel within Slack or Teams.

It's common (and appropriate) for people from different companies, such as marketing or development, to access one team's reports in pagespeed.one/app. That's why we prioritized work on this new feature.

Watchdog: Shortening the First Interval to 5 Days

Our web speed monitoring collects all synthetic data in one place and reports changes if they occur. It is a crucial tool for the cornerstone of web speed optimization – metrics monitoring.

Beautifully stable results and the Watchdog barely has anything to monitor. Beautifully stable results and the Watchdog barely has anything to monitor. The first rule of speed, however, says: Monitor, because you never know…

The Watchdog typically gathers data for 14 days to set a new baseline, but for new clients of our tester, it now manages with just five days. Simply so you can see the monitoring outputs a little sooner.

All of the above are new features for users of PLUS tests.

Let’s also look at smaller or less user-centric updates that we are releasing with version 4.2.

Tidbits: New Features, Bug Fixes, and Other Technical Updates

  • Demo project – if you're curious about what PLUS tests look like inside, you can check out the demonstration sample with the Mall.cz test.
  • We added information about test run times in Settings so you can avoid collisions with any processes running on your sites.
  • We added better X-axis labels in the UI graphs so you can more easily identify what you're looking at.
  • We caught bugs such as the one with the erroneous CrUX data label in the Domains report.
  • We tweaked the issue with email notifications that sometimes arrived without images.
  • We added information to the graphs about why values in annual graphs cannot be clicked.
  • We made a significant technological leap and upgraded Next.js to version 14.
  • A large but internal task was the ability to impersonate and the admin bar, to better manage what you see in your tests.
  • We resolved an issue with AWS that around February 24 caused an unexpected increase in JavaScript metrics. We now know we cannot allow AWS to test on AMD processors.

What's Next?

There is a lot in store for version 4.3:

  • We are preparing a separate website for documentation and a "wiki" around web speed.
  • In the Watchdog, we are dealing with the "oscillation around the limit" issue, where we can refine reporting.
  • We’d like to improve the onboarding process for new users.
  • Finally, we want to start experimenting with our own recommendations, which we plan to gradually integrate into the tester based on consulting experience.

Do you have a wish or tip for improving the speed tester? Write to us at info@pagespeed.cz.

The first step towards a faster web? Monitoring, for instance, with the help of our PLUS tests.