Web Vitals for WordPress overview: bit.ly/web-vitals-links
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
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
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
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
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
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
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
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.