What Agencies Should Know About Web Vitals

Adam Silverstein

Web Vitals for WordPress overview: bit.ly/web-vitals-links

Read the transcript

Jan Koch  01:42

Welcome, everybody. Thanks for joining me at the WP agency summit. I’m here with Adam Silverstein, who is a WordPress Core Committer. And he’s also working on the developer relations for Google. And Adam has really exciting content for you today because he’s going to talk about web vitals. And I’m super excited to dive into this. Thanks for making the time to come on, Adam.

Adam Silverstein  02:04

Sure. I’m super excited to be here. Thanks for inviting me. I’m excited about this format. And have you asked me questions? Excited about the topic. Excited about WordPress, agencies. All the above.

Jan Koch  02:16

Absolutely. Can you give us an introduction about who you are and what you’re doing in the WordPress space?

Adam Silverstein  02:22

Sure. So for many years, I was an independent developer, building websites for small businesses. About seven years ago, I joined 10 up, which is a really large agency in the WordPress space, and worked quite extensively building like enterprise-level sites, all kinds of sites that get millions of page views a day, kind of a whole another level of using WordPress. And then, about a year ago, I joined Google on the Developer Relations team. All along, I’ve been super involved in WordPress Core itself, something about eight years ago, someone told me I should get involved in the core, make a plugin, try to improve my WordPress skills. I was already programming but I didn’t have kind of the WordPress approach, I guess, to coding. So that was a big part of why I got involved. And then I just got hooked on it. And helped build the rewrite of the revisions for WordPress, 3.6. And then just got more and more involved in the core. And now I spend a regular part of my week working on tickets, trying to improve things that are like long term projects, working on Gutenberg. So I’m super involved in the kind of like, keeping WordPress, you know, growing, especially the JavaScript parts, I’ve been helping lead the JavaScript team meetings for the last couple of years. And those are sort of we’re trying to work on improving JavaScript and WordPress for itself, improving our build process, trying to come into the modern age, and so forth.

Jan Koch  03:47

That is super exciting. And to me, to be totally honest, I have yet not contributed to WordPress core. And I think it’s a little bit over my head. So I’m not that deep into development. I can write my own plugins, but not like core level functionality.

Adam Silverstein  04:05

There are many ways to contribute other than code. 

Jan Koch  04:08

That’s true. Yeah. 

Adam Silverstein  04:09

Yeah. And even running something like this that you’re doing is helping contribute to the ecosystem, you know. So you are contributing, maybe not directly to Core. 

Jan Koch  04:19

Yeah. Not in the nerdy way that I would like to.

Adam Silverstein  04:27

It’s a great learning experience, you know, like when you really like it if you start as a developer like I did work in a sort of on top of WordPress, and then you actually get into the Core and understanding how it works internally. It’s really empowering actually. It’s kind of a leap to take that and to start to dig in and they’ll build stuff. But once you take that leap, it’s, it’s really quite empowering because then you start to realize, okay, I’ve got this problem. Maybe this is a problem in the core, I’m gonna go look at that code and see how does this work and then actually sort of understand what’s going on.

Jan Koch  05:00

Yeah, I totally agree with you. And I think that’s something that most agency owners if they are writing code themselves, or that developers should at least consider doing from time to time because it just helps to debug and it helps with smoother project delivery. Can you give us a glimpse into what we are going to learn today?

Adam Silverstein  05:20

Yeah. So web vitals is what I’m going to be talking about. And this is an initiative from Google to try to measure user experience on the web. And I’m going to talk about that and how we can think about it from a WordPress perspective. So it’s quite a bit deeper than just raw speed. I think in the past, we’ve thought about, like, how can I make my site faster, which is important. But these metrics really try to get at how the users experience using your website. So it’s quite a bit more than speed? Are they interactive? Are they jumping around while they’re loading? And so these are metrics that Google has developed to try to actually be able to measure how people experience a website, which admittedly is a challenging thing to do. Yes, so that’s the goal of what these are. So I’m going to describe them and how they’re used, and also how we can kind of monitor them in WordPress, and hopefully improve them. So some of it’s kind of about the vitals themselves. And some of it’s about how it relates to WordPress.

Jan Koch  06:17

That is super cool. So I would like to hand the control over to you so that you can start your presentation. And then we can dive right into that.

Adam Silverstein  06:28

Yep. Let me do my screen sharing here. It’s a full screen. Are you seeing that up? Let me just get my notes visible here. This is fine. I like doing this life here. I recently did one where I was added to record the whole presentation ahead of time. And I found that so challenging because I had to be perfect. I like it to be a little bit more lively. So let’s dig in. So as I mentioned, web vitals is an initiative from Google to try to measure user experience. I think there’s a lot of different measurements that we’ve used as developers overtime to try to define what a fast experience is. This is really trying to get into what good user experience is. So you’ll see that it’s not just about speed. And I do have links, you’ll see there are links all throughout the slides, I will have one link at the end, that’s like a short link that you can go to. It will have all the links in one place, just so you know. So you don’t have to record these links as we go. One important note about these web vitals is that Google does plan to revisit these on an annual cadence. And typically, I think we’re going to like in the summer is when we announced these. So I would expect by next summer for there to be some refinements. Perhaps new metrics. We’re not exactly sure. But the idea here is that these are not kind of set in stone finalists is the way it’s going to be forever. But this is something where we’re going to keep trying to improve how we’re measuring user experience on the web, this is the first shot at it, essentially. And we know that it’s not perfect, and we’re going to improve it over time.

Jan Koch  08:01

That makes total sense, because also the way we experience and we use the web changes, so just make sense to refactor that. Yeah.

Adam Silverstein  08:11

Yeah, so you can think of web vitals in this three sort of pillars are these three buckets? The loading bucket is you know, what’s happening? The users are wondering is the page going to load, they’re waiting for something to happen. The next bucket is interactivity, is the page responsive? So when the page is started to load, you can see the content, can you actually interact with it? Can you click on a link? Can you scroll down? Can you open a tab? If the browser is busy trying to crunch scripts and render the page, you’re gonna have that kind of janky thing where you can’t interact. So that’s what that second bucket is about. And the last bucket is about visual stability. So this is the idea of things that sort of pop into the display while you’re looking at it and shift things around. And we’ve all had this experience. Kind of read some content, and then something pops in above and the content shuts down, we’ll have to scroll to get back to the content we’re reading. It’s very frustrating as users. So in the ideal world, your content is 100%, stable. It loads and it stays where it loaded to that will be a perfect score, I guess. So in these three buckets are measured using these three measurements, largest contentful, paint for loading, first input delay for interactivity, and cumulative layout shift for visual stability. And for each of these metrics, you can see there’s a threshold that indicates what is considered a good, a needs improvement, or a core score. And for each of these thresholds, your goal as a website owner should have to be to have 75% of your page loads hit this good part of the spectrum. And the reason we’re saying 75%, and not like everything is that we understand that page loads are not equal, right? Every time someone visits your page, something different is going to be happening. They may be on a lower power device, a slower speed connection, perhaps a million people hitting your page right at that moment, so your servers going to be slower. There are all kinds of factors that can complicate a particular page load. So these metrics aim to sort of like get at what is the 75th percentile? What are most of your users experiencing? And by now, we probably have a lot of questions. So I just want to point out that there again, there’ll be links with all these details at the end. And there are articles, my colleagues maintain this awesome site for developers, if you’re not familiar with it, web.dev and there’s links for each of these core web vitals and goes into great detail. Also an interesting article about this kind of the science behind how the vitals were developed, and also why that 75th percentile threshold was chosen. So there’s really tons of details out there. At the top, you’ll see it says real user measurement, rum metrics, and each one talk about that briefly. So when we test our site, you know, often we use tools like Chrome Dev Tools, or we use PageSpeed Insights or other tools that will, you know, you’ll or gt metrics or whatever you’re using to like, hit your site and measure how fast it is. And those measurements are not really real-world measurements. They’re just what we call lab measurements. They’re limited in scope, right? You’re just testing how the site responds to a computer essentially loading the page. And it’s not the same as actual users interacting with your site. For all the reasons I mentioned before, like bandwidth, device constraints, what’s going on with the server at the time. So what you really ideally would be basing your decisions on is not the measurements that you can do from one moment to the next by running your site through lab tests, but rather actually based on real users and how they’re interacting with your site. So I’m going to come back to this point a couple more times. But I just want to point out that there is a difference between how real users experience your site in the wild versus the field data versus what we call lab data, which is sort of how you measure your site when you’re running it locally, or you’re testing it on your server using a testing tool. Alright, so I’m we’re gonna jump into each of the metrics here and talk about them. I like to start with a cumulative layout tip because I think it’s the easiest for everyone to understand. This is the amount of stuff that shifts around on the page over the time of your interaction with the page. So it’s not just on the initial load. But even as you’re scrolling around, if stuff is still jacking around, that will add to your cumulative layout tip. Hence the word cumulative at the beginning. I love this slide. Because it just illustrates like cumulatively, our trips gone absolutely wrong. The user is trying to click no back, no go back. And then right before they click, something pops in on top, and they wind up clicking submit their order, and you can just tell, they’re just frustrated. You know, it’s an exaggeration. I don’t think people actually have this experience all the time but it sort of shows you how bad the cumulative layout shift can cause things to get, and why we want this stable experience. And on a smaller level, this happens, like when just when you’re reading content, and an ad pops in, and then you have to scroll again to try to get back to your content. It’s very frustrating. It’s not good user experience.

Jan Koch  13:00

And this could also be with like images, right? lazy loading images, lazy loading iframes, and stuff like that.

Adam Silverstein  13:08

Exactly. Yep. And that’s the advice that I’m getting too, right here. You know, when the thing that you’re going to that’s going to solve this problem for you is making sure that every element on your page has a predefined size for. So for images, that’s making sure that images have width and height. So if you upgrade to WordPress 5.5, that’s built-in. That’s something we actually reintroduced in 5.5. That was missing since about 5.0 and that will let the kind of the browser of reserve the space for the image before they have any information before they’ve actually loaded the image itself. That way, when the image loads, the content doesn’t shift around. And like you said, The same applies to any kind of dynamic content. So ads. Any kind of JavaScript widgets like a form or a poll, something that you know, pops in a sort of after the initial page load,. Those are the things that you really need to pay attention to. And later, we’ll see some debugging tools where you can actually figure out what element is causing your CLS if you’re not clear on that. Now, one thing to note is that if the content is shifting around below the fold below where the user hasn’t reached, yet, that’s not a problem. That’s not going to contribute to your CLS. So a good example of that is like a discussion forum that’s at the bottom of your post that is in an iframe, and it expands, but it’s very likely that’s going to happen well before the user reaches that. Or with lazy loading images, I mean, probably those should be defined. But anything that’s kind of lazy loading below the fold, as long as it’s loading before the user reaches the content, it’s not a problem. But for stuff that is going to be in the fold, make sure that you have that space defined for the item. And if it’s something like an ad where you don’t know the size, if it’s going to be, it could be several different sizes, just reserve enough space for each for all the sizes and the smaller ads can have some whitespace around them, and that usually will work really well. So we have some considerations here but that’s basically how you’re going to try to address CLS is making sure that everything has a defined width and height. This is just a nice image for a minute or two relapse, because often when I’m giving talks, I get excited. And I just rush through them. And I don’t drink any water or anything.

Jan Koch  15:09

That sounds very familiar,

Adam Silverstein  15:12

Because it’s been standing like this for generations or if it’s about to fall over because it’s just delicately balanced. But this is what I found for stability. Okay, the largest contentful paint. So this one gets at, when does the user experience the pages as having loaded, and the way that we measure that is by checking for the largest element on the page. And when that element has fully rendered the pages is the largest contentful paint is completed. And this is different than how I think we’ve measured in the past, like first contentful paint. Like when does the browser first start painting content? Well, that’s one piece of information. But for a user, for their experience of when the page feels like it’s loaded, it’s probably going to be when that largest thing loads. So in this filmstrip, here, the green element that’s highlighted showing the largest element that’s loaded in each frame, and then in the final frame, where it says, LCP, you can see that large sort of banner image at the top is loaded, and that is the largest element. And that’s very typical for page loads on mobile and desktop that you’ll have a large hero image or banner image that often is the largest contentful paint item. So that is definitely something you’re going to need to pay attention to.

Jan Koch  16:20

Is that including the background images too? Like when we have a full width, full height background image. Is that the largest content?

Adam Silverstein  16:29

It could be? I think it could be yes. It depends on again, like how quickly it loads. It could be I don’t know. I think it would be yes. If it takes up a lot of space, I think it would be counted as it. But you probably actually have to test it in like testing tools to see how it’s considered. But I would expect that it would be. So the thing that I’m going to say about optimizing your LCD is it is really critical that that big image that you’re serving be as optimized as possible. You know, WordPress does optimize images automatically. It creates several different sizes. However, if you spend a little bit of time trying to optimize your image manually, you’ll find that oftentimes, you can achieve 235 times the compression levels that are automatic, you know, created by the compression on WordPress, and with no visible degradation of the image. So that’s going to be a much faster page load. I’m not saying you have to do this for every image on your site, but definitely, it will have big images at the top of your homepage or your banner image for your site. And for your pages, spend some time optimizing those to really make them look good. My team, there’s a YouTube video here where they do like a deep dive into the different formats. There’s a new format that’s out called Avast that was just recently blogged about on web.dev that is amazingly strong at compression. There are issues with browser compatibility, right. If you’re using a newer format, it may not be supported by older browsers or all browsers. So typically, there’s a fallback, there’s a way that you can add both of those image formats into the tag, you would supply both images, essentially, the better-compressed one for the newer browsers, and the older format for the rest of the browsers, it can take some extra work. Obviously, it’s this is a lot of extra work for you. And you’re probably not going to do it on every single post that you do. But if you have really high profile posts or your homepage, and you really want to try to improve this LCP, that’s one of the areas you can focus on is trying to optimize your images. One other point, we talked about lazy loading earlier. So in WordPress, 5.5. wordpress automatically adds the load equals lazy attribute images. And what it does is this tells the browser’s, hey, you can load these images more lazily so that it doesn’t spend a bunch of bandwidth trying to load all those images that are down below the viewport that the user can’t even see yet, while it’s trying to load all the scripts that it needs to generate what you’re actually trying to say. So it increases the browser’s efficiency. One problem, though, is that if the image is already in the viewport, and you label it as lazy, the browser will actually take a little more time before it tries to get that image. And therefore it could actually negatively impact your LCP and I haven’t actually, like studied things as well. But this is like sort of a known issue with the current browser implementation of lazy loading. Like ideally, the browser’s would be smart enough to recognize, hey, this image is already in the viewport, I’m just going to ignore that lazy tag and eagerly load this image. But that’s actually not the case right now. So for the current time, if you really want to optimize that LCP, you may need to remove those lazy tags from images that were the viewport. And typically, this would be like your theme outputs, this image. It’s not typically it’s not an image that’s in the content. It’s your featured image. And so your theme is outputting it so you would be adding code into your theme. I’ve got a link here and I’ll have all links at the end. That will show you how you remove that text. There’s a filter in WordPress that lets you kind of opt-out for that image. And then the last point is using an image CDN, there’s specialized CD ends that just focus on images. The big ones have a WordPress plugin. So they’re really trivial to integrate into your WordPress. They will load images, kind of at an edge server that’s closer to your end-users. So the images are delivered faster. They’re cached there. A lot of them also provide like image optimization or resizing on the fly, which can be super helpful. Yeah, so definitely look at an image CDN. If you’re at the point where you have a lot of traffic in, and you really want to improve your speeds.

Jan Koch  20:25

Yeah. Do you have any advice on implementing sliders in WordPress, because that’s obviously quite likely the largest content on the page, and they get a really bad rap for speed and stuff like that. I would love to hear your thoughts.

Adam Silverstein  20:39

Yeah, I mean, I guess probably try to just try to keep them as simple as possible. I think, in my memory of this, and I haven’t built any sliders in the last couple of years. But my memory of this would have been building them is that they’re typically something that site owners really want, but in actuality, don’t perform very well. In other words, for most users, they never reach the second or third slide. They scroll past it.

Jan Koch  21:04

Yeah, it’s real.

Adam Silverstein  21:05

So I guess my question would be like, do you really need a slider? And like, what are you? But, why are you like, what’s the decision about using a slider because obviously, you’re loading these other large images that are not even displayed. If you have most users scrolling past that content before they even see that second or third image. And they’re typically large images. You’ve wasted a lot of bandwidth essentially, for most users. So I would first question your whole point of having a slider. Like why do you need to have a slider? I know they’re attractive, and people like that part of it? I’ve seen some, you know, yeah. So I don’t think there’s a great as you are basically loading multiple images into the slot where one spot, one image could go. I mean, obviously, you can use lazy loading on the subsequent images. But you need to be careful about that. You don’t want to have people scrolling to a blank and then loading an image. That’s a bad experience. So I think in general, I guess I would say, my advice would be to try to avoid sliders if you can and try to feature images in a different way. Maybe you show one of the images from your slider each time the page loads, but the next time it loads, it’s a different one. Used to make testing figure out which one is the most effective. Don’t just I think a lot of times people are putting several things up there that they can’t decide which is the most important.

Jan Koch  21:40

Yeah, and oftentimes, where I would see sliders used from my customers is on eCommerce websites. I mean, when you’re showcasing various products, and bestsellers and stuff like that. That could actually be a use case. But then again, those product images usually don’t need to be really big. So they don’t impact the loading speed as much, I would say.

Adam Silverstein  22:47

Right, yeah and maybe like a little gallery view where you have one large image and thumbnails could work as well.

Jan Koch  22:54

Yeah true

Adam Silverstein  22:58

A lot of times these discussions are trade-offs. So if it’s really important to have the slider, maybe that’s going to affect your LCP, but maybe that’s okay because it’s really important for your business reasons to have the slider. The perfect webpage for performance is like a blank HTML page that just says, Hello world. Right, it’s gonna be so fast. Right user experience but it doesn’t do anything. It doesn’t serve any purpose. So that doesn’t help. So yeah, there’s always going to be a trade-off between, what you’re choosing and every time you add something that’s going to affect your speed. So you have to understand what the pros and cons, I guess when you’re making those decisions. But there’s probably no simple, great solution to the slider conundrum. This is just another time to remind me to take a little sip of my coffee.

Jan Koch  23:51

Because coffee helps with relaxing.

Adam Silverstein  23:54

Yes, especially when I’m on stage. And I get, a little more relaxed in my home here. But it’s good to have those little breaks in there. Otherwise, I’ll just blaze through all these. So first input delay, this is the last one. This one measures the time from when a user starts interacting with your webpage and when the browser actually responds to that interaction. And again, this is really important to understand this is a real-world user metric. This is not something you can measure in the lab, it actually has to do with actual users who visit your site. And when they interact with the page, the page may not be fully loaded. May still be in the loading process. And then the user starts interacting with it while the browser’s still busy trying to load scripts, paint the screen, it can’t respond right away. So eventually it responds. The amount of time that it takes that’s your first input delay. So just as a quick aside, for lab measurements, we can’t really measure this because, again, it takes user interaction. That’s what we’re measuring. What we can measure is called total blocking time. And this is often used as a kind of a stand-in for first input delay. So total blocking time is basically if the main thread becomes blocked for long enough to prevent user input, how long is it blocked for? So that’s kind of similar. But it is measurable in the lab because on a typical page load, the thread will become locked or blocked by all the work it has to do for a certain amount of time. That’s kind of what you can measure. But it doesn’t really measure user interactions, because it doesn’t take into account when the users actually start interacting with your page. How does that take place? So first input delay in WordPress. A lot of this advice I’m giving you sort of applies to any website, but I’m trying to sort of put it in the WordPress context. So in terms of what’s going to prevent the user from interacting with your site, well, it’s the stuff that’s loading, and it’s the stuff that the browser has to crunch or process. So a lot of that can be just CSS scripts, JavaScript. Any JavaScript that it’s loading. So really try to look at your site, if you want to improve this and figure out what do I need here. Do I need all of these plugins enabled? Are there plugins that are really bloating my site up that I don’t need? A great strategy with WordPress and anytime we have problems, we typically do this, you disable all your plugins. Enable one plugin. Again, check the total blocking time, which is a kind of a proxy for fit. Enable another plugin one by one. Maybe you’re going to find that there’s one plugin that really negatively impacts your first input delay, and consider whether that’s the best choice for you. Maybe there’s another plugin that does the same thing that doesn’t have the same problem. Maybe you really don’t need that feature, it’s a chance for you to sort of audit what you do have. Another thing is there are plugins that will kind of concatenate all of the scripts into a single load. And this could help your first input delay. And it’s worth at least trying that. It often will just increase the third with the browser can get all the data that it needs. If you do have scripts that are still on the page that you need to add on your own, separately from being part of the larger bundle load, you can add an async tag to those if they don’t have other dependencies. And this tells the browser to just delay or sort of lazy load this script, I don’t need it right away. Let me do everything else first. And there is no direct support for that in WordPress. But there is some code with a filter that I provided a link to, that you can use to add this a sync tack. Caching is obviously going to help with first input delay, because the more quickly the browser can get all the data it needs, the more quickly you can get to the point where it can handle your input. So browser caching happens at all different levels. It happens at the WordPress level with like an object cache or page cache. It happens at the CDN level, what we’re talking about where your content gets cached at the edge. It even happens in the browser itself. So any kind of Javascript app that you have running, it’s loading stuff from the server. Make sure that’s cached. So there’s a lot of different ways that caching can apply from a coding perspective. And it can help with the first input delay. From an end-user perspective, it just means making sure that whatever caching you have available to you, you have it innate. So make sure you have a caching plugin installed on your WordPress. 

Jan Koch  28:06

And also, what I like to add to that is when you have the caching installed, make sure to check the hit rate of your cache because you might find that even though caching is installed, I’m seeing this on my CDN right now, I have a 42.3% hit rate for my cache which probably needs some work on my end to get it to like 70 or 80%.

Adam Silverstein  28:30

So why does that happen? Is it because your content is changing? Or you’re not caching things long enough? Or you’re not sure yet?

Jan Koch  28:37

I am not sure yet. So what I’m doing with this, I’m looking at the stats for the WP agency summit right now. And what I’m doing is I have this static website set up for the landing page. So I have everything in WordPress, and then I convert it to static for the landing page. And I would assume that something in the CDN configuration isn’t set up properly yet to improve the cash rate.

Adam Silverstein  28:59

Yeah, it can be complicated, but at least you’re paying attention to it and working on it. I mean, I’m excited to hear about the static h2, because that’s another approach that I see a lot of people in the WordPress ecosystem, you know, checking out now, and does really solve a lot of that kind of problems of the SLOs having to generate the page, it doesn’t really address a lot of this kind of user experience issues, because they have a lot more to do with not the speed with which the page is delivered. Although somewhat, more with sort of how the page is constructed, and how people will experience the page because of that. And that’s what I was saying before these metrics really do try to get a little bit beyond just the raw speed measurements that we’ve used in the past. And try to get more into these measurements that reflect how a user will feel or experience when they use your site. And I think sort of our North still our North Star. Our goal is, you know, we all have, and it’s true on computers too. But if you think about apps on your phone, whether it’s a WordPress app or a ride-hailing app, You know, you click on the icon, it loads instantly. Switching from one page to another is instantaneous. Everything responds immediately. Like, ideally, our websites would be as stable and instantaneous and responsive as apps are. And there’s no reason they shouldn’t be. So that’s kind of where we’re trying to head with this ecosystem. And this way of measuring things hopefully gives us insight into are we improving, or not. So that’s the goal. Yeah. So like that. My last point on fit in WordPress is to try the AMP WP plugin. I’m gonna talk a little bit more about amp WP in a minute. But the amp is a technology that was originally designed for mobile pages. Now it works across mobile and desktop. And it is basically a platform for building highly performant sites, it has all these guardrails that limit what you can put into the code of your site. And because of those guardrails, it has this sort of excellent results of great web vitals scores. Not always perfect, but often really good. And as WordPress users, we have this amazing first-party supportive plugin in the Amp WP plugin that makes it really straightforward to go from a WordPress theme to an AMP output. And at least to try it, because you can enable the plugin and try it and see what kind of results you get. If it doesn’t work for you you can see. I’m gonna talk about a little bit more in a minute. But we’ll get there. Amp is definitely something to consider. Another pretty slide, I’m gonna skip past that. Just so we can get on to the web, how do you monitor these things? Right, so now you know all about the web vitals, what do you do with that information? So all of the tools that Google provides, you probably are familiar with a lot of these, all of them now include web vitals in their metrics, so everything from like a house, all the way down to the Chrome extension Search Console, we’re gonna talk about the chrome user experience report, which is super interesting, which is prox, and then dev tools. All these things now have the vitals built into them. And again, there’s a link there that explains all of them, we’re gonna run through them a little bit. Dev Tools is if you’re a developer, you probably spend a lot of time in Chrome Dev Tools, it’s a really fantastic tool for debugging what’s happening on your page. And in the performance section, there are new features for core web vitals, so you’ll see an experienced line, you can click on the layout shift and see which item has shifted and how much it contributed to your cumulative layout shift. There is a total blocking time indicator at the bottom of the page, so you can see what your total blocking time is, again, improving your total blocking time will tend to improve your first input delay. And then finally, your LCP you can click on this LCP tag in the timings bar. And it will highlight what the element was on the page that was considered the largest contentful paint. So write in dev tools, really great way to just analyze page loads, as you’re experiencing. PageSpeed Insights, you’re probably familiar with this tool, you can go on the web, and drop a URL into it, and it will hit that URL, and it will give you back data about the site. The data that it gives you is amazingly detailed. It has recommendations for everything that it finds that can be improved. And not only are there recommendations, but there are WordPress specific recommendations, which I think is super cool. This is maintained, by the way as an open-source project. It’s called the WordPress Stack Pack. So developers please can contribute to this. The idea here is to give site owners like actionable feedback. Things they can do on their WordPress site to actually improve these specific scores. If you look at the scores, you’ll see that it provides both field data and lab data. So the lab data is generated when you put the URL in, it runs against your site, the data center loads your site. It does a mobile load a desktop load? I think it does some stuff with throttling as well to test over different speeds. And then it gives you the report. The field data comes from the Chrome user experience report. And this is not available for all websites. It’s available for I don’t know 6 million under 10 million sites origin. So if your site has enough traffic, it will be in the chrome user experience database. If it doesn’t, unfortunately, it will not be. However, you can still collect real user metrics and I’ll get to that. But this data is collected by Chrome users who’ve opted into sharing their data. So as these Chrome users visit your site, performance data is collected and then sent back to the open-source Crux database. And then from there, we can generate this data. So what you’re seeing here is actual field data about how users have experienced your site in the field. And this can be very significant right? If your site sells high-end luxury goods, likely your web, your users are affluent, and they have high-end phones and high-speed internet connections. If you’re in a developing market where that’s not the case, you might find that your users typically come in over 3g connections or they’re using low power devices that don’t have the kind of performance that we’re used to on our iPhones or even low powered computers at home. They don’t have the kind of desktop performance that we’re used to. In those conditions, your site, the way people experience, your site is going to be super different than how you might experience it as a developer home on your MacBook Pro. So this is actually really important to understand that these are when we’re talking about real user metrics, these are actual users revisiting your site, how are those users experiencing your site? And you, as a site builder, as a site owner need to cater your content and your development to that user, right? You can’t build a site that’s gonna work great for other people who don’t visit your site. You want to build a site that works great with your users. So that’s why I keep saying like user metrics are so important. But this is a super powerful tool, PageSpeed Insights, and it is a great way to just do a regular check on your site and see how you’re doing. It’s publicly available. So you can also check your competitor sites. You can check anyone sees a site that you think is really great, how do they score? So it’s a pretty interesting tool to use. Lighthouse is kind of a tool that does these analyses, it’s built into dev tools as well. But it’s also available as a node script, there is a lighthouse ci, which is a GitHub action, you can install that. So that if you have a project that you can build from PR, you can test your lighthouse scores for each PR. There’s also a browser extension. So you can install that and see your scores as you go around to different sites. There’s also a Chrome extension that’s specific for web vitals. This is just a fun one. Because when you install it, on every site you visit, you get to see the web vitals, the largest layout tip is pretty fun, because of it. It keeps changing as you use the site. It’s a little distracting, I’ll admit, but it works great for local development. So it’s just nice to have if it’s something you’re really trying to pay attention to. And this is probably my favorite, my favorite one. This is the web vitals JavaScript library, we do hope to actually incorporate this into the psych kit at some point in the future. But right now, it’s something you wouldn’t need to manually add to your site. What this does, it’s a tiny little bit of JavaScript, very lightweight. As visitors come to your site, it measures their performance experience using browser API’s, timing API’s that are available in the browser. And then as they leave your site, it sends that data off to your analytics provider. So this could be Google Analytics or any analytics provider, it just kind of raw event data that it sends off. And then you can later sync that data. Yeah. So you can use that data to run reports. And what’s so cool about this is real-world user data, right? This is real user metrics, actual visitors to your site. And it’s very lightweight. So it’s not going to affect their experience, but you’re actually going to measure their experience. So you’re going to collect data about your users over time. So it’ll get put into your analytics, then you can build a report on that and see, how has your score changed over time, maybe you added something, remove something from your site, change themes, did something upgrade, you can see how those changes affect your scores, writing your analytics.

Jan Koch  37:56

That’s something I have to implement into the WP agency summit website right after we finished this call.

Adam Silverstein  38:02

Yeah, check it out, oh, there’s a just link here. That’s like a mini plugin. It just literally drops the JavaScript. And it depends on you already having Google Analytics configured. So my little justice is designed for Google Analytics. As you’ll see, it just follows like ga dot sends an event. But this is a great library for you to add to yours, especially if your site isn’t already in the proxy database, and you’re not already getting that data from the Chrome user experience report. This is a great way for you to collect real user data plus, it’s you own the data, right? So it’s going to be in your own analytics store. And then you can, you can use it however you want. So I think it’s super powerful. And we do hope to add this to the psych kit. So if you’re not up to add, you know, code to your site yourself, for many plugins, we will have that at some point. So I mentioned this a couple of times in the Chrome user experience report, they built this awesome new dashboard recently. So if you’re in the database, there’s also an API for it. But if you’re in the database, you can put your site URL and it will build this dashboard for you. It shows you your web vitals, it shows you you can click through to all the different web vitals, including ones that are not in this core thing that I’m talking about, but all the different vitals and then it actually has them over time. So if you’ve been in the database for a while, it will show you over time how your vitals have changed, and where you’re falling in those percentages. So this is a suit and it just built this dashboard for you based on the URL. So if you have a site that gets a good amount of traffic, and you’re in the crux database worth trying. If you try it and it doesn’t work, then you’ll know yours not in the database. Search Console, you’re probably familiar with Search Console, this is where you go to find out how you’re doing in search, how people are finding you. It now also includes the web vitals crux field data. So if you do have that crux data, you’ll see how your pages are performing in Search Console. And what’s nice about the search console is it’s broken down by URL group. So you can go in and see all the URLs that are poor performing or that are needs improvement, rated. And that way you can kind of recognize groups may be of a certain category of content that needs improvement. So that can be super useful. All right, so now we’re gonna get into some WordPress specific tools, anything in there that you want to ask me about before Jan?

Jan Koch  40:12

I’m just blown away really, I think that there’s so much that we could talk about. But what is super cool to see is how driven Google is to make this as accessible as possible for developers, and also for WordPress users in general. And seeing that field data incorporated into those reports is something I didn’t realize before that it’s actually not just lab data. And you can very important point with this, because I don’t remember how many times I’ve seen gt metrics split out vastly different results for loading parameters based on how busy their server was even not even based on how busy my server was.

Adam Silverstein  40:53

Right? The casting server itself.

Jan Koch  40:55

Yeah, so this is really good to know, for everybody who’s watching this is do your diligence when testing for these metrics?

Adam Silverstein  41:05

Yeah, the whole difference between the lab and the real user metrics, and when you’re able to test it by running tests against your site has become a kind of stronger and stronger in my mind over time. Especially when you’re trying to test things like ads. I’ve done a lot of work on trying to test ad performance. And that is super challenging because ads are typically customized to the user. So when a machine loads them, it’s very different than when a user loads the page. And I think, in the past, I think it’s been super challenging to figure out how you measure that user visit. So this is super exciting to me to see that it’s actually now enabled by browsers. But the API is in the browsers, right? So that’s a big part of it is having these API’s in the browsers that let you measure these timing points. Super with a super lightweight approach. And then and then having the script to send it back. But yeah, you’re right. There’s been a huge effort by multiple teams at Google to launch this effort. It’s not just the work that went into defining what these web vitals were, but also incorporating them into all of our toolings. And I think that you know, the final part that’s going to come out of this that Google has announced is that these will eventually become part of our search signal metrics. So this is, we’ve talked about how HTTPS can improve your site. How a good mobile site, will improve your search rankings. We’ve also announced that these core web vitals will go into, your search ranking. I’m not going to talk about that. And I don’t have direct knowledge about that. But we have publicly announced that and said that we will give six months’ notice before making those changes. But you can expect that by working on these, this ultimately will not only improve your user’s experience but should help your search engine performance.

Jan Koch  42:46

Yeah, I think that is common sense. Because in the end, what’s Google trying to do Google is trying to deliver results that please Google users. So it just, in that case, you x is a mess of point?

Adam Silverstein  43:01

Yep yeah, it’s a win-win if we want our users to be happy and find good results. And we want to, therefore, help web developers, achieve those good results. And that’s, why I’m here today talking to the WordPress community about these web titles is because WordPress is a really big part of the open web, right? 35%. Now, so we know as Google, we have to pay attention to WordPress and help WordPress make good decisions about web standards. So that kind of push the ecosystem forwards and lazy loading images is a great example of this. My team worked on this extensively and getting this into WordPress core. It was something that the Chrome browser had already implemented. But Firefox and Safari were sorts of questioning whether they were going to support it once they saw that WordPress was adopting the standard. And it’s a great standard that improves the web for everyone. Then they adopted it as well. Right. So WordPress is a big enough entity that we can sort of influence by and we did the same thing when we adopted source set years ago. So by adopting these best practices, we can help sort of move the ecosystem forward. And that’s sort of very much why I’m here talking about web vitals is trying to get WordPress site owners excited about improving these metrics, both for their users and for the web as a whole.

Jan Koch  44:18

Yeah. And in the end to improve their bottom line too, because that’s what it boils down to. Yeah.

Adam Silverstein  44:24

Yeah. Yep. And I talked a little bit about that in one of my last slides on these tools here about monetization because it’s something that I’m like I said, I mentioned ads before, it’s something I definitely pay attention to. So okay, tools set site kit is near and dear to my heart. This is a project that I work on. I’ve worked on for several years now. This is Google’s official plugin for WordPress. You install it in WordPress, and it brings in Google services right into your WordPress. Right now, it’s focused on bringing in reporting data. So it has things like search console and analytics data right in your WordPress dashboard. It also includes PageSpeed and experience information. So this is the PageSpeed Insights API data. And it will give you mobile and desktop performance reports. And both the lab and the field data if it’s available. And you can also get this report for any specific URL on your site. So if you have a specific page and you want to check it, you can go to the details of that page. And you’ll see this PageSpeed and experience report. So I think what’s really cool about this is that it’s built right into WordPress, right? It’s the same information that’s available in these other tools. But you don’t have to keep going out to check them. You’re going to just log into WordPress, and you can see the information right there. So that’s pretty cool. And I did mention, we do hope to add the ability to measure your real user metrics, your visitor’s metrics, and send those off to the analytics account. Since we already have analytics support it already makes, it makes a lot of sense to integrate that. We just haven’t quite gotten there yet. But we do plan to integrate that web vitals collection as well. I mentioned the AMP for WP plugin before they just released the 2.0 version. This is a super powerful plugin. And it’s worth at least checking out. I know that amp has a sort of mixed reputation in the developer community. I remember as a developer several years ago, begrudging the amount of work that I had to do to create an AMP version of a site that we had already spent hundreds of hours building an HTML version of. And then we had to do that because building that amp version meant we could be in the carousel. So a lot has changed since then, Google has announced that you no longer have to be an AMP site to be on the carousel. I don’t know if those changes live yet. But in the near future, as long as your site needs this SEO, these web vitals metrics, you’ll be eligible for that carousel, amp, or not. So that’s a pretty significant change. And it sort of levels the playing field for the amp. It means that in order for the amp to be in that carousel, those sites also have to meet these four web vitals and not all amp sites do. It’s not as if the amp is a magic bullet. It is magic. But it does not solve every problem, you can still create sites that are slow using an amp. But what’s so powerful about this amp WP plugin is that it takes your WordPress site, and you build everything in WordPress, just like you’re used to. And you flip this on and it essentially outputs your site in the HTML format. If you’re using themes, like the core themes, and as plugins that are compatible, oftentimes, what you get when you try the AMP plugin is very similar, if not the same as what you get with the regular site. If you can get the same output and the same functionality, what you’re going to see is the performance is going to be way better because of the guardrails that it provides. So it’s a huge win to turn it on. It’s not always the case, sometimes there are features that don’t work, there are plugins that are not compatible. There’s code output by your theme, maybe that’s not AMP compatible. So sometimes it does require work. A lot of times, people in the past have chosen to use this AMP paired mode where their desktop site will be served with regular HTML, and their mobile site will be served with amp, which is one of the potential solutions. But I definitely encourage you to check this plugin out. It’s grown a lot in the last several years, and especially the support for the huge number of plugins in the WordPress ecosystem. So a lot of compatibility issues have been solved with other plugins. And it’s worth trying to just, you can just turn it on, see how your site looks. And check the performance after you turn it on. See how your site performance is affected by enabling it. If you find that it causes problems, disable it, but it is definitely worth a try. And, you know, AMP is essentially has grown into a platform, it’s a development platform. And what’s cool about this plugin is it acts as a bridge between WordPress and WordPress templating to the AMP platform.

Jan Koch  48:28

Yeah, and I think it’s also important not just to see how well it works with the website, but how your users perceive it. Like it measures the analytics for the mobile users, and then see how does pay in time on page increase? How does the bounce rate behave? Stuff like that. Because that also impacts the performance of your website? 

Adam Silverstein  48:51

Right. Yes, and I mean, I think I use it like an assumption here that I’ve been the unstated assumption is that by improving user experience, you’re also going to improve engagement, you’re going to improve all of those metrics that you talked about. The results that you want. You’re going to improve your sales, your newsletter signups. Whatever it is that your goals are for your users, however, you’re trying to engage them, when they have a better experience on your site, the end result should be that you will achieve those goals. And so these are all tools that help you towards those goals. If the tools don’t help, then don’t use them. Every site has a unique perspective and experience, a unique set of users. So not every tool is right for every user. But you’re absolutely right. What we’re talking about is sort of like the details of what you want to pay attention to. But in the end, you’re really you want to pay attention to what the results are if you’re achieving your goals. And this talk is not focused on that. But it’s super important that you have a way of measuring those goals and are paying attention to that as well. Absolutely. 

Jan Koch  49:57

Yeah, we should probably spend another two hours on how to measure properly.

Adam Silverstein  50:03

Yeah, I mean, I’d love to learn about that. I know that you can set up goals in analytics, but I have pretty limited experience with what’s the best approach to how-to, you know, what you should be testing, essentially. I mean, I know there are basic tests. I want to have visitors hit a second page. More than one-page view or things like that, but, or I want them to complete this form. But there’s also way more sophisticated ways of building funnels and really paying attention to where your users are engaging or not. This is actually a good segue to the news pet project. So this is the project that I’ve been working on most closely. Most recently. It’s an open-source project. It’s an issue between the Google News Initiative and wordpress.com. Automattic, makers of wordpress.com and it is a platform for small news publishers, right. So it’s built on top of WordPress. And the idea is it’s an opinionated, best in class platform for small news publishers. So it is a tool. It’s a plugin that builds, loads other plugins in. Including things like sidekick, and the PWA plugins, you get an offline installable website, as well as custom themes and custom blocks. It is AMP first. So the goal for these sites is to be all AMP for both the desktop and the mobile versions, our guests are amp all the time. And I think it’s worth especially if you’re a coder, looking at the main plugins of this project, the theme, the blocks, and also sort of like ecosystem that it creates if you install it and see what it brings in. Because it’s trying to be the sort of best in class. It creates these beautiful layouts that people can create for their home pages, and still super high-performance sites that tend to hit the web vitals very well. But one thing that you mentioned just recently is like one of the things we’re working on right now is about kind of customization around monetization. So monetization is obviously really big for small news publishers. Advertising is part of that. However, I think, over time, publishers have seen that less of the revenues are coming from advertising these days than it used to. And they’re going to other sources, like the guardian with their sort of supported sponsored model, or subscriptions, or a paid newsletter. So there are all different models people are exploring and news pack is very much working to enable those at a technical level. One of the cool things that they’ve added recently, so they have like a campaign plugin that, will display like inline calls to action, where you can sign up, say, for a newsletter, or it could be a pop-up. But what’s interesting is how they’re integrating that with analytics data so that they can provide a customized experience. The idea being that if you visit the site for the first time, and you’re reading the news, you know, maybe you’re going to get a message that says, welcome to our site, please contribute. But the second time you come back, maybe it’s a more urgent message. And the third time you come back, it’s like an all-out like, Hey, we know you love us, and absolutely not. 

Jan Koch  53:04

So that is good to see.

Adam Silverstein  53:06

Yeah, yep. I mean, that’s, that is so powerful to think about being able to customize your content for your users. It’s a bit of a holy grail, I guess. And it’s cool to see that they’re doing it and they’re really trying to figure out how to do it in a performant way, which is, which is challenging. Because, you know, when you customize things, well, then that breaks caching. That’s one reason. So there’s a lot of reasons. But anyway, that is the end of my talk. I’m going to leave my slide on here just for a few minutes, maybe you’ll probably be able to share this link later, too, right? 

Jan Koch  53:37


Adam Silverstein  53:38

So I have this one link, that link has, all the links that I’ve given in my talk. Maybe I will stop sharing my content here.

Jan Koch  53:50

Fantastic, that was insane. That was so exciting. I mean, I’ve heard about web vitals, but I never really took the time to dive into it. So now seeing what web vitals all about. I’m super pumped to improve my own website. I know there’s a lot of work waiting for me. And in the meantime, I just checked the WP agency summit website and run that biters on that. And my question related to the background image, is that considered the largest content for paint? It is. 

Adam Silverstein  54:24

It is.

Jan Koch  54:25

It turned out that it is. Yeah

Adam Silverstein  54:27

Yeah. So maybe you can spend some time optimizing that. Oh, that. Check out that swish tool? If you haven’t, I’ll bet you’ll be able to make that image half the size.

Jan Koch  54:35

Yeah, I already did. I think it is like the full-screen images are like 90 kilobytes or something. So I’m not sure how much headway I have there. But I definitely give it a try.

Adam Silverstein  54:45

Right? Yeah, that’s actually pretty small, right? Yeah. And I remember back in the day when we were had like little we’re all building for modems. And we had little tiny thumbnail images. So it’s tough to make these decisions these days. It really does depend on who your users are. And you know, it’s trade-offs. 

Jan Koch  55:02

Yeah, it really is. Because on the one hand, you need to save the bandwidth to make the website load quickly. On the other hand, the devices that are loading the website get super crisp displays these days. So they will show every imperfection when you optimize their images too high.

Adam Silverstein  55:14

Right. So then it’s the question of like, does your site perform better for your goals? If it has a beautiful image? Or if it loads a little faster in the image is a little less beautiful? That’s it. That’s an AB test for you right there. But I do know which is the best result. Hey, just to let you know, I do have to hop in three minutes, because I have another meeting. So just.

Jan Koch  55:39

Yeah, I was just about to wrap up, because I want to be respectful of your time and you’ve shared so much value with us. I make sure to share the link so that people know how to get in touch with you. Thank you so much for coming to Adam. It was amazing.

Adam Silverstein  55:53

Great! It was super fun. I appreciate the questions and happy to follow up. Yep. if they have any follow up questions. My DMS is open and even my Twitter. So yeah, people can reach me anytime.

Jan Koch  56:06

Fantastic. Talk to you soon Adam. Bye.

Adam Silverstein  56:09

Okay! Thank you.

The WP Agency Summit Is Sponsored By

(Hint: Their logos link to their booths, which have fantastic giveaways!)

GET your free ticket to
wp agency summit

let 30+ World-Class Experts teach you how to scale your WP agency.

Learn How to Attract high-paying clients and building recurring revenue To Break Through Feast & Famine.