Support for the web-vitals framework

[metmarkosaric]

"Not sure if it’s something that fits in with Plausible but it would be a nice addition to have a Web Vitals card in the dashboard that shows you stats (maybe over time?) about your web-vitality stats.

Link to framework: https://github.com/GoogleChrome/web-vitals/"

(imported from the old roadmap)

[danyork]

Given Google's May 2020 announcement that "Core Web Vitals" will be part of calculating search engine result rank "sometime in 2021", it would be great if Plausible could help web site operators with more info: https://webmasters.googleblog.com/2020/05/evaluating-page-experience.html

(It's not 100% clear to me that any of these new "page experience" ranking factors are measurable without the long term data Google may be collecting from users.)

[websocket98765]

Another link that may be helpful: https://nextjs.org/blog/next-9-4#integrated-web-vitals-reporting You could use NextJS to set up a demo quickly and generate vitals to send to Plausible.

It would be interesting to see:

• global avg load times (& over time if possible)
• global avg per page (& over time if possible)
• If user location is available, that would be a cool to see load times per country. But the first two are most useful.
  Many cool possibilities to drill into it.

[metmarkosaric]

Got three more votes for web vitals tracking over the last 24 hours or so. Google has announced that web vitals will become a part of their ranking algorithm from May this year.

[Vigasaurus]

I'd love to get some context in what exactly the implementation of this should look like. Should it be how Google Analytics does it such that the dashboard has the capability to show it over time, with data received over an API, but it doesn't gather it itself? Or should we be providing a script for people to gather the data themselves that automatically sends the result? Or should Plausible be running a Cron to calculate it for every site that has it enabled?

I can see significant drawbacks with every solution, from the lack of support, to the fact that only Chromium browsers can use most of the Vitals libraries, or that a Cron would be very heavy and would strain the infrastructure heavily.

[danyork]

Google's announcement in November 2020 that web vitals will be a new ranking factor in May 2021: https://developers.google.com/search/blog/2020/11/timing-for-page-experience

My understanding is that two of the elements - Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS) - can be "lab-measured", while the third, First Input Delay (FID), relies on data collected by Google. However, Total Blocking Time (TBT) is seen as a lab-approximation of FID. That is how the WebPageTest folks have implemented Core Web Vitals measurements: https://webpagetest.org (more at https://www.webpagetest.org/forums/showthread.php?tid=16122 )

[metmarkosaric]

Web-vitals library is a "tiny" 1kb for Google standards but that would more than double our script if included so that's out of the question as a default and at best could be an optional feature only.

This is a Google initiative and Core Web Vitals is now a report in Google's Search Console. We already have a Search Console integration and many of our users have it enabled that so I wonder if there's a way to pull the Web Vitals data from there at the same time as the search keyword?

And then present the key data in an interesting new report as part of our dashboard. It would be cool if we focus this new report more on speed and page weight in general rather than on web vitals alone: Data transfer/CO2 emissions and whether the server is powered by renewable energy or not.

[mrchrisadams]

hey folks, I worked with the folks at sitespeed to implement their sustainable web plugin work tracking datatransfer co2/green figures, and I've just finished a call with another developer, @LittleBigThing, where we were talking about how to contribute something like this into plausible.

I don't want to hijack this thread tho - would creating a new discussion make sense or would it be better to file an issue instead to explore some more?

[ukutaht]

Happy to continue in this thread for now. Once there are more concrete plans we can break off coherent chunks of work from this thread into new issues/discussions if needed.

[ukutaht]

I haven't looked at it super deep yet. The big argument seems to be whether to use lab data or field data.

It would be fairly natural to just measure web vitals on each tracking request and send results back to Plausible. It would fit neatly into the current product. However, like @metmarkosaric says it would double our script size and ironically add load time to the page that's trying to reduce it.

To add to that, my understanding is that Chrome is already capturing field data for web vitals and it can be accessed publicly.
It is also my understanding that lab data can easily be obtained from Lighthouse/Pagespeed Insights or by writing our own background job that takes lab measurements.

This leads me to an idea I've had: there could be a lot of value in crawling our customers' sites periodically. We could capture a bunch of data while crawling the site: web vitals, page weight, broken links, accessibility issues, incorrect HTML syntax, on-page SEO reports etc. Basically what in programming is known as static analysis. There are lots of tools for these things but few that you can set up to monitor your site over time. This could even be a standalone product from analytics.

These static metrics don't need to be measured a million times a day if the page gets a million hits. It's enough to crawl once per day and save the results in our database.

The only concern with that is what @Vigasaurus brought up

Cron would be very heavy and would strain the infrastructure heavily.

I think it could be an issue if it's not well-designed. Our cloud instance has over 10k sites, if each site has 10 pages on average we'll be crawling 100,000 pages per day. Not crazy but not trivial either. I think there's a ton of prior art in making crawling efficient.

If it ends up being too heavy we can make it an optional (paid) extra in our cloud version. When you're self-hosting, you're likely using Plausible on a handful of sites anyways, so crawling wouldn't be prohibitively expensive.

[Vigasaurus]

Those are all great points, and I personally do think doing mostly lab tests is better for everyone involved. When you talk about that static analysis however do you mean just cURLing the site and doing analysis, or actually running it through a puppeteer or similar?

I wonder if it could be easier to just rely on Google to run the audits - with something like PageSpeed or the hosted version of Lighthouse - just to effectively keep the load off the infrastructure, a major problem here is that potentially you're stuck with an older version of Lighthouse doing it this way.

Past that, I suppose having the feature to have Plausible gather the data could definitely be a paid feature could work, - just to ensure that the infra strain is offset by the revenue.

In general, my biggest concern across the board is how well an implementation can play with how fast Plausible has been growing and the infra, consequently - and I really don't think Puppeteer would play that nicely with said load on the infra.

[ukutaht]

When you talk about that static analysis however do you mean just cURLing the site and doing analysis, or actually running it through a puppeteer or similar?

I think you need to run a full browser to get even web vitals for example. It needs to parse JS, download images, render the page to measure layout shift, etc.

I wonder if it could be easier to just rely on Google to run the audits

Agreed. If there are public APIs we can leverage here instead of building out our own crawler, the better.

just to ensure that the infra strain is offset by the revenue.

Yeah that's the idea. New features that add a bunch of load on our servers should be offset by revenue.

In general, my biggest concern across the board is how well an implementation can play with how fast Plausible has been growing and the infra, consequently - and I really don't think Puppeteer would play that nicely with said load on the infra.

Yeah hopefully there are public APIs that work for this purpose so we don't need to build out our own crawling infra (at least initially)

[mrchrisadams]

If you're looking at incorporating the web vitals into stats, then it may be worth looking at the monthly data dumps created with for HTTP Archive, which collect lots of information like HARfiles for popular sites.

They discussed merging in relatively recently, so I would expect it to be available in the monthly datasets they release.

HTTPArchive/almanac.httparchive.org#952

Fetching individual urls

AFAIK, you can fetch web vitals stats in bulk from bigquery, but the same figures are available via the Google PageSpeed API:

https://developers.google.com/speed/docs/insights/rest/v5/pagespeedapi/runpagespeed

An example API call for fetching web vitals stats

Below is a link to a sample API call for the plausible website, including a bunch of web vitals stats.

https://pagespeedonline.googleapis.com/pagespeedonline/v5/runPagespeed?url=http://plausible.io

I think the checks are the same as the ones you see if you run a check at the link below:

https://web.dev/measure/

[ukutaht]

Thanks @mrchrisadams.

I would be very happy to get a PageSpeed report for our sites, measured daily. I also like that sitespeed.io is an open source solution that we could host ourselves. And they also seem to include co2 calculations etc.

Would you have time to hop on a call soon, Chris?

[mrchrisadams]

Sure. I'd love to. Week beginning next monday would be ideal. Uku, I've emailed you to find a time.

Another way to run sitespeed

I haven't worked on it in a while, but when we looked at how we'd do this, because it wasn't time sensitive, we experimented with seeing how much work we could offload onto the trillion dollar companies offering free CI to create these kinds of datasets.

Below is a repo where we use github actions to git-scrape a website, and store the collected results in git, and the generated report microsite as a downloadable build artefact. For the repo, and change the url to check, and every day it'll run checks for the URL.

https://github.com/thegreenwebfoundation/greenspeed

The longer term vision was to create something like kind of internet health dataset, by allowing anyone running these checks to add them to a shared open repository - partly inspired by Mozilla's own work on the internet health report, and partly inspired by the work on the HTTPArchive. This is because from our point of view at least, there's more to having a healthy internet than web-vitals. But that's another discussion for another day :)

[MarcoGlauser]

I have been reading/experimenting a lot with web vitals lately and I would offer a different approach. Since lab results (for us at least) are not very stable and differ from actual data from clients, we only use them very sparingly.

I think the easiest way to get started would be to add a numerical metric event similar to the goal conversion event. That way, every developer can track their own metrics and decide whether they want to use the web vital framework or lab data.
And once the api is there, you can also build on it and add an opinionated web vitals tracking implementation.

[diakonos]

A competing tool Panelbear offers performance monitoring which splits metrics into Frontend, Backend, and Network categories. From what I can tell, it leverages the Navigation Timing API which is still experimental. In addition to measuring Core Web Vitals, I think it'd be helpful to have visibility on the Backend and Network metrics as well.

[huksley]

Also got interested in it. I use NextJS and it have reportWebVitals overridable method [1]. Would be great to just simply use plausible(...) in it to feed data to Plausible.

Data example:

Object { name: "FCP", startTime: 2446, value: 2446, label: "web-vital" }
Object { name: "FID", startTime: 11337, value: 7, label: "web-vital" }
Object { name: "Next.js-hydration", startTime: 2279, value: 19, label: "custom" }
Object { name: "Next.js-render", startTime: 15394, value: 31, label: "custom" }
Object { name: "Next.js-route-change-to-render", startTime: 32242, value: 1027, label: "custom" }
Object { name: "TTFB", startTime: 0, value: 1771, label: "web-vital" }

Could this be sent to plausible using custom props in Plausible custom goals [2]?

[1] https://nextjs.org/docs/advanced-features/measuring-performance
[2] https://plausible.io/docs/custom-event-goals

[angelovdev]

Being such an important factor for user experience and SEO, I think the lack of support for it might be stopping people from moving from GAnalytics to Plausible and it would be great if it can get added. I also use Next.js.

[Lucent]

I'm don't believe search console data imports or page speed tools would add any real value in the context of web vitals. For navel gazing, they're fine, but when you get a warning your LCP slipped above 2.5s, what's needed is real field data that can be filtered. An average of the last month of data in aggregate (search console) is not remotely actionable. Neither is a tool like PageSpeed Insight's instant benchmark that shows an LCP of 0.5s while those in Brazil or with Chromebooks are actually at 4s.

Ideally, Plausible would have an event endpoint that could accept and graph data to plot from the optional, 1KB web-vitals library. Then, we'd apply filters just like Plausible's dashboard to instantly find the source of our problems. Is it tablets, mobile, a specific country, an OS, some combination thereof? This is Google's version that allows segmenting from Analytics data: https://web-vitals-report.web.app/