Core Web Vitals Monitoring, Tracking & Reporting Software – Vital Signs Tracker

0:00Why We Built Vital Signs Tracker

Let me walk you through Vital Signs Tracker. This is the app that we have built to track Core Web Vitals data and site speed data. The reason why we built this is because the data Google gives us is based on either 28 day averages or monthly averages. If we make a change, it takes 28 days or a month to get some feedback on whether that change worked, or whether it's positive or whatever.

Their data is also very vague, because it's averages. It's based on a group of pages or sitewide, so it's not very specific or page specific. That's problematic, because then we can't draw insights from the data. We can't really draw pointy insights, which means we can't look at specific actions to fix the speed. We can look at broad actions, but not really pinpoint very precise actions. So we built this so we're picking up the same data as Google is picking up on speed, and we can run it on any period if we want.

0:46Reading The Report And Metrics

I've just pulled up this client site and we've run the report for the last seven days. It's very similar to other reports you might have seen around the web or the Core Web Vitals dashboard report. We have the sitewide data here. We also have this option: by default we don't include pages that are non-indexable, so if they have a robots noindex tag we don't include them, because typically those aren't included in Core Web Vitals data. You can include that if you want, which will change the metrics slightly. It's just reloading there. The metrics probably go up a little bit if we do that. I'll just turn that off again for the sake of the video.

In Core Web Vitals land, green is good, we're passing, yellow needs improvement, and red is bad. We're looking pretty good across the board here. We also track INP. INP is a new metric, and it will be a few months until it's live or being used, but we track that as well so we can prepare for that metric being released. We also track FID, CLS, FCP and time to first byte. We're looking really good on this site. This is one of our bigger corporate clients that we work with on an ongoing basis, so the speed is good.

1:55Country And Page By Page Breakdown

We have a country by country breakdown. Typically you will see some countries that are lower. This site is hosted in Australia and focused on Australian customers, so we don't really care about international traffic anyway. It's important to see, but it doesn't affect the speed, and there's international data too. What's really powerful here is the page by page breakdown. We can see what's going on at a page by page level, and you'll see there are some pages that are problematic.

The homepage here is just outside the passing zone for LCP, which is 2.5 seconds. It's 2.8 for the last seven days. We also track whether the page is indexable or not. Again, if it's not indexable the speed probably doesn't matter from a vitals perspective, but it does matter from a user perspective. You can also add notes and annotations. If you're working on something you can type in notes and save them. You can also search on pages here.

2:41Custom Tracking Strings That Bypass Speed Optimizations

One thing we do see, and this is something we're working on with this customer, is this. If you use custom tracking strings on particular traffic types, like AdWords traffic here or email marketing traffic, often those custom tracking strings will bypass all speed optimizations, if they're not mainstream tracking strings like UTM strings or Facebook strings. Those sessions will be slow. You can see here on this site there are some custom tracking strings: campaign equals is a custom campaign tracking string, and that's why it's slow. It's bypassing all their speed optimization, so those sessions are really slow.

That's bad because it's paid traffic, so the tool can unearth insights like that as well. Ordinarily that page is fine, that's the homepage, but paid traffic is bad, and that is why you saw before that it is failing on mobile overall. If we go back here, we're failing overall on mobile because those sessions are slow.

3:26Date Ranges, Scheduled Reports And Access

That's really the tool there. You can run the data on any date range. I've just done the last seven days, quick and dirty. There are also scheduled reports. Typically we schedule those reports for fortnightly or monthly depending on how often you want to get the data, and you can adjust that as well if you need weekly or whatever. That also enables you to keep on top of the site speed and track what's happening.

That's a walkthrough of the tool. We include a year of access with all the services, and then you can pay for it separately if you want to keep it after that. Typically, if you bought a service and something has gone wrong, it will be something like you've started using query strings on particular traffic types, like we saw here. You started doing mail outs and using a custom query string and it's blowing you up. Or you have a new content writer who's using massive images instead of compressed images or correctly sized images. Or something technical has gone wrong, or something's changed fundamentally with plugins or the site setup. Using this tool, you'll be able to pinpoint when it happened, where it's happening, what traffic types it's happening to and so forth. I think that all makes sense. If you need more information, let me know and I'm happy to come back to you.