Performance is one of the most important factors when it comes to user experience on your website, and this June, it’s going to play an even more important role. Google Core Web Vitals have been developed as a scientific way to measure performance and user experience, and this year, Google plans to begin factoring Core Web Vitals scores into search ranking. 

To ensure page ranking, user experience, and performance remain optimal, enterprise organizations will need to be building and optimizing their sites for real users. 

Join experts from WordPress VIP, Google, and Gold Agency Partner XWP as we take a deep dive into Core Web Vitals and see what changes enterprise organizations can make to their web development and design strategies to build high-performing websites that delight users and move the needle forward. 

Transcript

Leo Postovoit (00:00:00):

All righty. Thank you all for joining us today for optimizing for Core Web Vitals. This is a webinar bringing together three awesome organizations WordPress VIP, Google and XWP. And we’re super excited today to bring you all together, and to chat about some of the actionable things that you can take to improve your website’s and to focus on what we can do to help with page speed and Core Web Vitals in the wild. So today, we’ve got six awesome folks, that I’d love to talk through and be able to introduce you to because we’re all doing awesome things in the world of performance and helping sites grow in the larger ecosystem. And I want to introduce you to some of my awesome friends here. So, first things first, I’m Leo Postovoit, I’m head of partnerships and product strategy, at XWP. I’ll pass over to Mike.

Mike Crantea (00:00:50):

Hey, I’m Mike Crantea, I’m a principal frontend engineer at XWP. I have a big focus on performance for at least the past seven years, combined with WordPress, and I’m happy to be here with you. Passing it over to Katherine.

Katherine Rudik (00:01:05):

Hi everyone, My name is Katherine Rudik. I work at different partnerships team at Google. I’m joined here today by two of my colleagues really happy to be here and passing it over to Melissa.

Melissa Mitchell (00:01:17):

Hi, I’m Melissa. I am a web ecosystem consultant here at Google. Which basically means my day-to-day work is helping people improve the Core Web Vitals and I love to talk about these. So, I’m happy to be here. And I will pass this over to Adam.

Adam Silverstein (00:01:32):

Hey everyone, I am Adam from the web developer relations team at Google. And I focus on making the open web a better place and specifically work quite a bit in WordPress and WordPress core. So, I will pass it over to Sérgio.

Sérgio Gomes (00:01:49):

Hey everyone, I’m Sérgio. I work at Automattic in as a performance engineer improving performance across all our products and WordPress core as well.

Leo Postovoit (00:02:02):

Awesome. Yeah. So the folks here all bringing together a bunch of awesome ideas, a bunch of awesome initiatives and a bunch of awesome things you can bring back to your teams. But I want to briefly mention a little bit about XWP. This is us putting together, what we’d like to say is the leading performance agency in the larger ecosystem. XWP builds a better web at enterprise scale, we help sites have a variety of different types and shapes, be able to ultimately grow into where they want to go.

Leo Postovoit (00:02:30):

And we really do think that enterprise, media and technology companies should have performance world-class solutions across the board. And we oftentimes are using the plugins and often has built-out, some of the plugins we’ll talk about today. And we do recommend WordPress VIP as a reliable WordPress platform for you and your growing business. And just a little bit about us as well, in terms of our portfolio, we’ve done quite a few awesome projects across the ecosystem working with incredible brands. Like Rolling Stone and Heavy, working on a variety of awesome projects with really, really interesting media technology companies across the world.

Leo Postovoit (00:03:02):

But enough about us, let’s talk about performance. Yeah, what is performance? Well, performance is a really, really big open ended question. So, we’d like to think about this as a sort of four pillar type approach. Performance isn’t just a single thing regarding page speed. So, some of the folks today I know, attending are in the world of marketing, there’s a whole competition around performance marketing, sometimes we might be measuring performance through the lens of conversion. So, for example, if you bought an e-commerce site, you look primarily at sales.

Leo Postovoit (00:03:34):

Potentially, if you have a SaaS product, maybe thinking about this in terms of retention, like what is our customer base over a long period? But primarily as we get into it, we really look at just one key aspect to that is page speed, page speed because it’s not necessarily the only thing you can do but rather, the first thing you should be doing. It’s a great way to make a huge impact on all of these other metrics and really should be the first thing you should do to be able to grow your site. So, we have a couple different approaches that I will talk about in terms of benchmarking and understanding where you are today, and being able to improve from where you want to be able to get to.

Leo Postovoit (00:04:08):

And as a whole, our strong recommendation is to start with page speed as a key area of growth, and be able to move in that direction and continue to improve your page speed over the long-term. And as a whole, you probably have seen dozens, and dozens of names, and numbers and things have changed over the years, especially if you’ve been tracking performance as these things go. And we recommend trying to narrow the actual numbers that you use and to focus on primarily just a couple of key areas to be able to measure how you’re doing. You might end up using other metrics along the way but these tend to be really, really great places to consider.

Leo Postovoit (00:04:44):

So, in the upper section here, time to first byte refers to the initial response back from a server, oftentimes closely relates to your hosting environment, oftentimes closely relates to your back end performance and very time interactive, which is how long it takes your device to be able to process all those files. Time to first byte impacts all the other metrics and time to interactive, ultimately is a combination of everything else since that has spread out. The challenge is the in between, when we actually have to describe the difference between time to first byte and all of the time interactive, there’s literally 100, no 200 different ways to be able to measure out this.

Leo Postovoit (00:05:21):

And what we found is that it doesn’t really consider user experience. So, a couple years ago, Google announced the Chrome Dev Summit 2019 or 2018, I believe 2018. A bunch of these metrics that were really interesting that people were curious about this. And suddenly this makes sense, we really do need to consider what stability looks like, need to consider the actual impact and delay. We want to be able to consider the things that are going to be useful for users. And so, these three metrics LCP, FID and CLS are referred to as the Core Web Vitals. So, this is now the focus that we recommend, if you haven’t been focusing on this last couple of years to integrate into your process.

Leo Postovoit (00:05:59):

And today, we’re going to talk a little bit about how all this comes together. And so, we’re first going to start with the business impact to Core Web Vitals, we have Katherine and Melissa from Google to unpack and instruct a little bit about the financial impact this can have in your organization. And some of the clear key things that can help to grow within all these things for what you can do. Second, we’ve got Sérgio and Adam. Sérgio from WordPress VIP and Adam Google to talk a little bit about some of the awesome initiatives that WordPress core and WordPress VIP have taken on to be able to help you grow across the board.

Leo Postovoit (00:06:29):

And really, really useful because, again, like you can go and engineer a feature on your own, or you can leverage these things that are free there. They cost nothing to be able to integrate or plugin, just the cost of your time and maintaining your WordPress site. And then finally, Mike and I will be talking briefly regarding how you need to be approaching Core Web Vitals from engineering standpoint, how you should be incorporating this into your process over the long-term.

Leo Postovoit (00:06:52):

And what you can do to be able to take this back to your organization and ideally grow for the world. To gets to a point where your users are seeing a fast website in a consistent basis and avoiding these kinds of headaches over the long period. So with that, I’m going to hand it over to Melissa and Katherine to talk about the business impact of Core Web Vitals.

Katherine Rudik (00:07:13):

Perfect. Thanks, Leo. So, we are going to be talking more about why Core Web Vitals are important, why they’re important for different roles within your business. And to start it off. Let’s move on to our first slide. And Melissa, can you tell us a little bit more about why Google created Core Web Vitals? Especially given that there are a lot of different metrics out there created by Google and created by our partners on the web to measure performance and understand performance? What was the goal of creating Core Web Vitals?

Melissa Mitchell (00:07:47):

Yes. Thank you. And as you said, there are a bunch of tools and there are a bunch of metrics. And at Google, we don’t really think that site owners should have to be performance gurus to understand that their site is providing a quality experience. And so, the goal of Core Web Vitals is to simplify their performance landscape, so as you can focus on metrics that matter most to users. They also include recommended thresholds to help developers understand when their experiences are good or when they need improvement. Currently the Core Web Vitals consists of three different aspects. The first aspect is loading, and we’re measuring this with largest contentful paint, which is abbreviated LCP.

Melissa Mitchell (00:08:27):

It is a good measure of how fast the most important content on the page is loading. The next aspect is interactivity, and the metric we’re using to represent this is first input delay, which is abbreviated FID, or sometimes people pronounce it FID. And this measures how ready the pages for the user to interact when they go to first interact with your content. And then the last pillar is visual stability. And the metric that we’re using here is cumulative layout shift, or abbreviated CLS. And this is measuring how much the site jumps around on the user as they’re using this. And as we do this, we have very different aspects of the performance and the loading that relates to the user experience. And we can measure these from real user experiences, which helps us know how we’re doing.

Melissa Mitchell (00:09:20):

In addition, the Core Web Vitals will be updated annually, so that we can give a good balance between keeping up with the latest, and greatest, and what we understand about the user experience and measuring it, but also providing consistency, and the ability to plan for website owners and businesses. So with that, and the question that comes up all the time, and so Katherine, maybe you can address this is, who should be looking into these Core Web Vitals, are these only for developers?

Katherine Rudik (00:09:48):

Yep, I think that’s a really good question, Melissa. Because usually we think like Core Web Vitals are only for developers, but that’s not the case. Because interestingly, no matter who you are and what role you play in the organization, Core Web Vitals and performance in general will be impacting to you. So, let’s take a look closer, as a user the Core Web Vitals and performance really defined, the experience that you will be seeing on a website. As a product manager is really important for you not to overlook these metrics because otherwise, you risk having a disruptive user journey and a disruptive experience in the product that you are building.

Katherine Rudik (00:10:24):

Because for example, you’re thinking of a user journey, but then the website is just not loading or everything is jumping around and it’s not something that you planned initially. So, it’s really important to pay attention and take Core Web Vitals as one of the aspects of building your product. As a developer, the Core Web Vitals provides you with the metrics and understanding that you are building a product that users will love. And that creates the leeway for users to become loyal customers. So, you really understand that you’re doing a meaningful job and meaningful work to create good products.

Katherine Rudik (00:11:01):

But really, at the end, it all boils down to revenue. Because for example, if you are an executive and you overlook Core Web Vitals and performance, you might be missing out on important user engagement. For example, users that dropped off when the website was loading. And this engagement may be critical for your business, for your business growth. So, we’re rarely understand that different stakeholders within a company have different goals, if they don’t look at a higher level. But Core Web Vitals and performance in general can bring all of them on the same page and focus on optimizing user experience, which in turn will create users that come back to your website that, become your loyal customers, become returning customers.

Katherine Rudik (00:11:48):

And this will result in business growth. So, whoever you are in the organization, whichever role you play, it’s important for you to pay attention to performance. And Core Web Vitals gives you an easy way to measure and to understand where your website is at the moment in terms of performance. So, actually, something that we’ve I think mentioned is that Core Web Vitals is not only a set of metrics, but it’s a set of thresholds that gives you an understanding of whether the performance is good or bad. So Melissa, can you tell us a little bit more about how these thresholds are determined that define whether an experience is a good or a bad one?

Melissa Mitchell (00:12:30):

I’d love to, this is actually really fascinating to me. So, Google used human perception and human computer interaction research to identify what are high quality experiences. So, in the first study here, they found that site delays decreased satisfaction and intent to return. On unfamiliar sites, two seconds of delay was enough to cause most users to drop. And so, in business peak unfamiliar sites. This is your new user acquisition channel, right? And then on familiar sites, so your loyal customers, there was only a delay of just four seconds.

Melissa Mitchell (00:13:07):

Another study, which is different and I find this one also fascinating, is this researchers put in a visual feedback delay on a button to see when things started to be perceivable. And they noticed that a delay going from 70 milliseconds to 100 milliseconds was perceivable to users. And to me that’s miniscule. But even more interesting is when they increased from 100 milliseconds to 150 milliseconds, people started to rate the quality of the button significantly lower. So, as your input delays start to increase above 100 milliseconds, that’s when that experience starts to degrade.

Melissa Mitchell (00:13:45):

And so these types of studies are what went into determining where those thresholds should be. In addition to doing this, Google also evaluated millions of page impressions and found that new sites which were able to meet these excellent Core Web Vitals thresholds had a 22% lower abandonment rate. And with all of this said, Katherine, would she be able to explain a little bit more about how we’re not just looking at what the user experiences, but how we’re assuring that these are actually feasible goals for site owners?

Katherine Rudik (00:14:18):

Yes, this is actually a really important challenge for Google. And we really look into it and do a lot of research around it. So for example, in an ideal world, we would like the LCP, the largest contentful paint to be zero milliseconds for all of the sites. But in the real world, we understand that there are delays due to network connection, due to different devices that the user is using to access the website. So, zero milliseconds would not be an appropriate good threshold for all of the websites out there. And so to determine the right thresholds that work for websites and work for the real user, we evaluate the possible Core Web Vitals thresholds. And verify them using something that’s called the Chrome User Experience Report.

Katherine Rudik (00:15:07):

This is a public database of aggregated anonymised data, which you can also access, and look up information of how real world users are experiencing websites all over the world from different devices and what the real world looks like. So, to confirm that these thresholds for Core Web Vitals are achievable, we require that at least 10% of origins that are found and from user experience report currently meet the good threshold of Core Web Vitals. So, we make sure that the existing content of the web is able to meet these thresholds.

Katherine Rudik (00:15:46):

Similarly, we look into the poor threshold for Core Web Vitals evaluate the lowest performing 10 to 30% of origins, and classify them as origins that are poor in Core Web Vitals. So, it’s all based on real data, and on real data of loading times that are happening on the web right now. I think it’s also interesting to see how these thresholds are met, and how Core Web Vitals are improved for actual partners that we have a chance to work with. And with that, Melissa, can you maybe share a couple of success cases of partners that we’ve worked on Core Web Vitals with?

Melissa Mitchell (00:16:31):

Of course, so on the screen right now, we have a couple of examples that were highlighted at I/O this year, in a talk called the business impact of Core Web Vitals. If you haven’t watched it yet, I strongly recommend going and looking at it. And there are many more examples in there. But for this particular slide, the first one we have is GEDI, which is an Italian news company. And what they did is they use CSS aspect ratios to improve their CLS scores. In addition to tackle their LCP, they deferred third party scripts, and they split their CDN keys to keep their time to first byte lower. From these results, and when they achieved both the improvement in CLS and LCP they saw an 8% decrease in the bounce rate on their mobile pages.

Melissa Mitchell (00:17:15):

A second example is from Lazada, which is an e-commerce platform in Singapore. What they did is they leveraged Lighthouseto identify low hanging fruit and quick wins, such as JavaScript and CSS what was currently blocking the initial render, and also image optimizations. Concretely, they were able to use next generation formats like WebP, and defer non-critical images. When they implemented this with removing some of that render blocking JavaScript and CSS, they were able to improve the largest contentful paint by three times. And this led to a nearly 17%, better mobile conversion rate.

Melissa Mitchell (00:17:54):

And the last example on here is from GYAO, which is a Japanese media platform. They also started to use next gen WebP images. And they started to preload their hero image to make that the priority. In addition to dynamically importing the above the fold content, this led to about a three times better LCP and they eventually saw 108% more click ad click-through rates. And so, these are some fantastic examples of how focusing on these Core Web Vitals can help improve your business.

Katherine Rudik (00:18:29):

I think that’s a really good point to finish off our part of the presentation and lead you to the link below on the slide, which has a lot of other success cases of actual partners on the web. And also a lot of different talking points on how to convince different roles within your organization to take a look at Core Web Vitals and performance in general. And with that, I will be handing it over to our next speakers, Adam and Sérgio. Thank you very much, everyone.

Sérgio Gomes (00:19:03):

Hey everyone. So, when talking about Core Web Vitals and performance in general, we need to start at the server level. So, the server is the bedrock of performance for your site. And if your server is slow, then everything else will have to make up for it somehow, or at least try to. So that’s why I’d like to give you a little introduction to the architecture on WordPress VIP, and how that can help to ensure performance for your website. Now, none of this is probably new information to at least most of you. But it’s helpful to see how it fits into the wider context of Core Web Vitals and performance in general.

Sérgio Gomes (00:19:48):

So, at the most basic level, a site needs to be able to respond quickly to users requests and it needs to be able to do this reliably and consistently. And in order to do this, the approach that WordPress VIP has taken is to use a container infrastructure. Now, containers and if you can move on to the next slide, please. Containers are useful in two main aspects. So on the one hand, they provide for strong isolation in that all sites are isolated from each other and thus don’t cause an impact in each other’s performance. But beyond that, containers are also very flexible, so you can easily add and remove them. And that’s, for example, how WordPress VIP responds to changes in user demand where more users come in or fewer users come in, by spinning up and spinning down containers.

Sérgio Gomes (00:20:48):

Now, of course, having a container-based infrastructure is only the beginning, you need to be able to optimize what goes inside of these containers. And in the case of WordPress VIP, that’s WordPress. So, since we know exactly what’s going into these containers, we’re actually able to optimize things down to the hardware level. And what I mean by this is that, if you could show the next slide please, is that if a PHP web server, and a database server and cache server have very different requirements. For example, concurrency needs are different, storage needs are different, bandwidth needs are different. And so we’re actually able to go in and optimize, choose the best hardware for each of these subsystems given that we know that we’re going to be serving WordPress. And given that we know the different subsystems in WordPress, the different requirements that they have.

Sérgio Gomes (00:21:50):

So, by optimizing each of these subsystems individually, we’re able to optimize time to first byte. And as mentioned earlier, time to first byte is the first and most fundamental of all of the metrics, at least for all timing metrics, given that it’s the one that all the other ones build upon. If your time to first byte is slow, then you’re going to have to try to make up for it on all the other metrics including Core Web Vitals or just contentful paint. But of course, having a single fast WordPress server isn’t enough. So, since we’re talking about trying to hit very low response times here, in order to hit the thresholds for Core Web Vitals, we actually start perfectly running into fundamental issues such as how quickly a signal can travel across the network.

Sérgio Gomes (00:22:48):

And for that, if you could show that slide please. The way of solving this problem is by having a global network of data centers, which can serve content as close to your users as possible and as quickly as possible. So in this case, in WordPress VIP, the results are cached at the edge. And these caches are actually even customizable if you have any specific needs in terms of user segmentation, for example. So, it’s important to note that having good performance everywhere is important since Core Web Vitals metrics are measured globally. This means that if you have a large cluster of users in a particular region where performance is low, that could actually have an impact on search ranking across the entire world. Because everything is measured globally, which is why it’s so important to make sure that all of your users are getting good performance.

Sérgio Gomes (00:23:48):

So, with all of these aspects, we’re actually able to provide a fairly low time to first byte in that requests that hit the cache register immediately and locally, requests that don’t hit the cache. They actually hit a WordPress server that has been optimized as much as possible to provide that quick response. And all of this scales automatically according to user demands. So with that in mind, and now that we’ve discussed the infrastructure and how it can provide a foundation for good performance, we should discuss what will run on top of this infrastructure, namely WordPress. And on that note, I’d like to discuss some recent improvements to WordPress core. And I’ll hand it over to Adam because he’s actually been directly involved in these as a contributor to WordPress for a very long time.

Adam Silverstein (00:24:47):

Great. Thank you, Sérgio. So, I’m going to talk a little bit about some WordPress core improvements. And just to kind of give an overview, the team that I work on we’re very interested in proving the core platform as a way of kind of lifting the whole web up. The goal is to make the platform itself performant and try to give you the right choices from the get go. And there’s a lot of room for improvement. But there are some things we have done in the last couple years that I want to talk about. So, go to the next slide, please. This was a really huge one, the lazy loading of images, and now iframes and 5.7.

Adam Silverstein (00:25:26):

Images by default would load very eagerly, a lot of us probably built a custom JavaScript-based solutions to deal with this issue and defer the loading of things that were downloaded on the page. But eventually, this actually was such a big problem that it became a web standard and lazy loading was actually built into the Chrome web browser. And the WordPress project decided to adopt it. So, we built this into WordPress and now images that can load later, will load later, the browser’s kind of take care of it automatically. We don’t have to load that extra JavaScript. And actually WordPress adopting it actually led to Firefox adopting it.

Adam Silverstein (00:26:02):

So, this is one of the ways that WordPress itself can kind of lift up the ecosystem by adopting these great standards. And of course, lazy loading of images is going to help with overall speed. And that is going to affect the performance of the page load. But these kinds of improvements, like they spread across the ecosystem. So that’s what to me is so exciting about them is they’re not just affecting like a single page, but they’ll affect everyone who uses WordPress. Next slide, please. Another big improvement we made in images was adding back the height and width dimensions to images so that the browser’s know how much space to reserve for the images before they load. Unfortunately, we dropped this in WordPress 5.0, with the introduction of Gutenberg, and it took us a few versions to get it back.

Adam Silverstein (00:26:45):

So, you may have content out there that doesn’t have image sizes. But now we’ve added it back dynamically through the content filter. And that is going to obviously help with layout shift, which is a huge problem with dynamic content, it can be a huge problem. And finally, the last thing we’re working on right now is adding WebP support. If you’re on VIP, you probably already have WebP support because of the way their image CDN works, where it’s going to serve those optimized images for your users automatically. But for everyone else using WordPress, adding WebP support means that now people will be able to upload WebP images instead of JPEG images and get a much faster experience for their users. These images are on average, 30% smaller for the same quality.

Adam Silverstein (00:27:32):

So, it’s a huge win for users. And if you’re not already using WebP for sure, check that out. It’s broadly compatible with all browsers accept IE11, which brings us to this slide. So recently, WordPress announced that we are dropping support for IE11 and that’s going to start with the WP Admin Pages. So, we’ll be dropping support, for example, in Gutenberg for being able to use it with IE11. And that’s going to make our bundles much smaller because we don’t have to support all that extra JavaScript that supports all the features that IE11 doesn’t quite support, and we have to sort of polyfill those to make them work. So, dropping IE11 support is huge for WordPress and I think means it’s time for people to consider also dropping it for their front end.

Adam Silverstein (00:28:17):

So, if you have bundles that have JavaScript in them that are there for IE11 only, that’s a good thing to consider letting go of now. And yeah, that’s it for new things for WordPress core, I guess we’ll go to the next slide.

Sérgio Gomes (00:28:35):

Right. So for you, as a developer, a lot of this is probably really tricky to wrap your whole head around and get to task with all of these different aspects of improving performance on your site. But we wanted to give you a few quick resources that could help you get started in all this and talk about first of all, a few couple of plugins that you might find useful. So, recently there was a new plugin launched by the Jetpack team called Jetpack boost. And the idea behind this plugin is to automate some of the trickier aspects of optimizing performance on your website. So, two features that can have a nice impact on performance as an example, are critical CSS generation, and deferring non-critical JavaScript.

Sérgio Gomes (00:29:30):

So, in the case of critical CSS generation, what this plugin does is it tries to determine which parts of the CSS on your site are critical for that first render making sure that the user gets something on their screen as quickly as possible. And it just takes everything else and delays that until the site has had the opportunity to actually show something to the user. And that can have a nice impact on metrics like largest contentful paint. Similarly, deferring non-critical JavaScript will do something similar for JavaScript in that it prevents large scripts which have to be downloaded, and parsed, and compiled and executed before anything is even rendered on the user’s screen, that’s usually not necessary. And so Jetpack tools will try to identify which scripts are not needed as part of the critical path, move them out of the critical path for you, so that everything could render a bit more quickly.

Adam Silverstein (00:30:33):

Great. I’m going to talk about a few other plugins. So, the AMP plugin is a really powerful way to transform your WordPress site into a high performance site with basically just enabling it. It has grown tremendously, if you haven’t looked at AMP in the last couple of years, I would definitely consider looking at it again. In the case of like the new spec project for example, we have sites that are running in pure AMP, where they’re not using that paired mode, where AMP for mobile, but AMP is actually fully capable of running your entire site. One of the really cool things that was added to the plug in and the AMP plugin actually relates to the boost plugin, which is CSS tree shaking.

Adam Silverstein (00:31:11):

So of course, part of AMP is this limited environment, this guardrails that are put up, you can’t use custom JavaScript, you’re very limited in terms of how much CSS you can use. And one of the really nice optimizations of the AMP plugin provides is it takes all the CSS that your site in cues, and it figures out what CSS is actually used on the page at tree stakes that down to just the CSS that you actually need. So, it’s got some built-in optimizations like that, that are really amazing for just delivering amazing performance. And even like in the new spec project, where we have both AMP and non-AMP sites and a lot of work has been put into the performance of those non-AMP sites. The AMP sites still consistently performed better because of those guardrails and the kind of constrained environment that amp provides.

Adam Silverstein (00:31:57):

Google Site Kit is an amazing plugin that connects your WordPress site with all of Google’s services. The big ones that we’re connecting to right now, our Analytics, AdSense, Search Console, Tag Manager, Optimize, there’s other ones coming, oh and PageSpeed Insights. So, once you get this hooked up, you go through a simple setup flow process, you’ll get the reporting information, like the Lighthouse data, right in your WordPress dashboard, which is really nice. You can get Analytics data on posts or your whole site, right there. And Search Console data also built-in and handles verification. So, it’s a really simple way to connect to all of the Google services with your site.

Adam Silverstein (00:32:39):

And then the last one, just to mention briefly, is the PWA plugin, which is, PWA of course, are the offline apps that you can install on your phone or on desktop. And the idea is bringing this capability into WordPress enables fast loading offline via service worker. So, there’s a lot of capabilities that are in the PWA platform that aren’t quite in WordPress. And these are things that we’re working on in that plugin. Next slide. Okay. And to talk a little bit about the two different types of data that you will get when you’re trying to look at your Core Web Vitals. And I think it’s a little difficult to understand why these are so different.

Adam Silverstein (00:33:22):

So, just to touch briefly, lab data is the data that you run, when you run a report, whether it’s running it in Lighthouse or some other tool that’s going to hit your website and try to gauge the performance at that time. Right that or if even if you’re running it like in Chrome DevTools, that is lab data. You’re testing it under those circumstances, and that will vary tremendously. It can depend on where you’re accessing the data from, it can depend on the load at the time that you’re accessing it, the network conditions. Lab data tends to go up and down but it is really useful for measuring and debugging changes that you’re making to your site. So, let’s say you’ve added a new plug in to your site, you want to gauge the performance, you can check the lab data before and after. And especially if you run the report several times, you can see actual effects of making changes in your site at that time.

Adam Silverstein (00:34:13):

Field data or RUM real user metric data is probably the more insightful and valuable data as a site owner because it tells you how actual users are experiencing your site. And people mentioned before the Chrome User Experience database, this is a database that’s available in BigQuery that you can run reports against, you can build a dashboard against it. And if your site has data in there, it’s a great way to just see the real world data over time that people, how people are experiencing your site. And this could be affected by for example, where the majority of your users are in the world. What time of day your users access your site typically, are they always visiting on the weekend, are there traffics like all kinds of things can affect field data that you would necessarily think about and how you build your site should be determined by how your users are going to experience your site.

Adam Silverstein (00:35:06):

If you’re in a market where people have lower bandwidth and lower powered devices, you need to take that into account when you’re building out your site. And one final point on field data is that if you do not have field data in the Chrome User Experience database, you can collect your own field data. There’s a really nice script that’s on web.dev, that’s a JavaScript thing that you put on your site, and in a very lightweight way, collects real user data and sends that off to your analytics provider, which you can then later run reports on. So, that’s it on lab data and field data. So there’s more and Sérgio, do you want to take this one?

Sérgio Gomes (00:35:46):

Sure. I think it’s just a matter of explaining a little bit about, how this is just the beginning, both from Google’s point of view and from Automattic’s point of view. And that these things aren’t set in stone, the metrics will keep changing, as has already happened in the past. I mean, CLS has gone through multiple changes in order to try to measure as accurately as possible, the delay shift experience that users are going through. And on the Automattic side of things and WordPress VIP specifically, we obviously have teams continuously working on infrastructure, trying to improve all of our infrastructure. I mean, just last week, we push a change, which managed to shave off a few milliseconds from secure connections to try to improve time to first byte to users.

Sérgio Gomes (00:36:38):

And obviously will continue to work both on WordPress core and all of the Automattic products like Jetpack and new plugins like Jetpack Boost, which are specific for optimizing performance. I don’t know if you have anything to add?

Adam Silverstein (00:36:55):

Yeah, I’ll just add on the WordPress core side that I hope to see some of these improvements like even that CSS optimization that’s in the Boost plugin, I could see something like that arriving in WordPress core. I think there’s a huge opportunity for us to improve script loading in WordPress core. And this is something we haven’t really looked at carefully. But we do orchestrate all script loads through an API, we just don’t do any optimization to that in core. There are a lot of opportunities in core also newer image formats like AVI and JPEG Excel, which are exciting. So, there’s a lot of opportunities for the platform to grow and improve kind of what you get out of the box with WordPress and also try to help people make better choices as they’re building out their sites.

Adam Silverstein (00:37:35):

So, giving people more feedback. Another example was someone suggested adding a Lighthouse report in your Gutenberg preview. So, you could immediately see like the performance of your page, even before you publish it. There’s a lot of opportunities and I would love to hear from people attending this webinar today, just directly about any suggestions they have for core, because I’m very interested in improving the platform.

Leo Postovoit (00:38:04):

That was awesome. I really appreciate all the effort the folks at Google and VIP have put into supporting us and creating some awesome content surrounding a lot of information around setting the scene or how you should approach Core Web Vitals, how you approach performance. And I really have to say, Adam, it’s really cool to see at least things ship in WordPress core, I’m so impressed to see that every single time one of these things gets shipped [inaudible 00:38:31] major impacts on page speed performance. And it really does make a difference. So, as we look at how XWP comes together into the fold, as I said, at the top of the call, we are one of the leading agencies focusing on page speed performance, but the singular the leaders of page speed as a whole. We look at the scalability and reliability of the platform and application core that [inaudible 00:38:54] about.

Leo Postovoit (00:38:54):

And the thing is though, as a whole, we really need to unpack and extract how these things come together. And it starts with a good snapshot. And the challenge is I’m sure some of you here and attending our webinar have seen is that there are dozens and dozens of tools. And the first time you start to get into it all, we find that it’s overwhelming. And there’re different ways to slice the data. The challenge when keeping things measurable is you need to ultimately try to consolidate and focus on the things that are useful. So, here we’ve got CrUX, we’ve got Lighthouse, we’ve got GTmetrix, we’ve got Pingdom, we’ve got WebPageTest. All these different tools can ultimately guide you down the right direction… Oh, on Google PageSpeed Insights as well. Really great tool for using Lighthouse at a lab data point.

Leo Postovoit (00:39:42):

At the end of the day though, what we found is that focusing on real user metrics and growing their experience over time is that critical experience that’s going to be useful for you. So, what we say is don’t get overwhelmed by all the tools, don’t be chasing after everything directly. Ask this question about what you can do over time to slowly grow into this. And as Whole, we believe there are really clear actionable steps you can take to be able to attain better performance for all your users. And so, I’m about to hand it over to Mike who’s going to walk through some of the tools we use for measuring performance and managing, tracking and why understanding the current state of your website is critical. We feel strongly that you must give users what they want, and really what they need, whether it’s an editorial content workflow or fast pages with little content that blocks the critical rendering path. It’s a whole mindset that we think is critical for your organization to adopt.

Leo Postovoit (00:40:30):

And finally, we strongly believe that performance is a mindset that you have to treat as a long-term goal. We don’t recommend that you just do a one time performance project and a one off sort of experience just to make your site a little bit faster for Lighthouse scores. What you really want to do is to integrate good page speed and good performance as a whole concept as part of your hygiene to everything that you do for every coach engine that you push. You notice a weird look into your own data you should investigate. If you’re adding a new script, you should test it, you’re going through redesign obviously, definitely want to make sure you understand, and measure that impact the session before and after. So as a whole, we think that this is a critical thing that we really believe that your organization can take and embed into how you work as a whole. So, now hand it over to Mike.

Mike Crantea (00:41:13):

Thank you. The first question that you need to ask yourself, do you understand the current state of your website’s performance? Taking note of the current state is critical for being able to assess whether changes improve the current situation. Many lab tools provide different suggestions for possible fixes. We recommend picking one main lab testing tool like PageSpeed Insights or some automated one’s like Collibra, which run Lighthouse under the hood and sticking with it. In the end, users and the real user metrics are the ones confirming the job well done. And that is where Google Search Console provides the needed confirmation. Follow the grades, but aim for results.

Mike Crantea (00:41:53):

Give your users what they need. We need to acknowledge that the privilege of using the newest devices in the process connections is often the cause for the lack of action. It’s our responsibility to grow empathy for the visitors, delivered content before the participants, deliver a delightful experience before loading marketing technology. Always put the user’s needs first, give them the content, the product they came for quickly. If you fail at this critical task, nothing else matters. And third, treat performance as a long-term goal. If you’d be given the choice to remove a barrier in the way of your customers, would you do it? Would you remove it? Minimizing cognitive load blurs the barrier between what feels artificial and what feels real.

Mike Crantea (00:42:40):

Proactive, ongoing monitoring helps to keep the barriers raised, strive to maintain a real and genuine approach and appearance in the digital world. The web vitals are based on user research and what feels natural. And the hard part is the research already is completed so you don’t have to go and discuss with neuroscientists. You can only focus on getting the results. The fifth step is adopt a performance budget mindset, budgeting for a good user experience gives the balance tilted in the right direction. Be conscious, bandwidth and processing power are limited resources. Even more limited than that is the user attention where something has milliseconds matter. If you’re not mindful of this users will bounce.

Mike Crantea (00:43:32):

Think less, distractions is more conversions. You need to decide what’s important for the user experience. Browsers can make that decision for you. Your initial content load is most important, users bounce if it’s too slow. You’ll see a clear downturn if it’s four and then if they put down right. Once that is done, split the remaining budget in analytics, ad tech and marketing. And here’s the tip, grow empathy in your teams, entice your engineers to test using devices closer to the mid-range to guide setting the performance budget limits. And now I will share with you some goals strategies to implement for page speed improvements. I will start with first contentful paint. And this is the base to be able to have a decent largest contentful paint, if this one is bad the other one would be just as well.

Mike Crantea (00:44:29):

Make your initial rendering not rely on JavaScript, I would stress even to move to the end and defer all of the scripts. This reduces early bandwidth contention and allows whatever’s remaining of the bandwidth to be used for what’s needed for the initial render. To benefit from the TCP acceleration delivered the critical assets like the main style sheet above the fold Web Fonts from the same domain. VIP already does that the CDN is based into your primary domain. Loading these from a different one comes with a significant cost. Because you have to account for a new SSL handshake, that’s a couple of natural round trips. And you have to go again to the TCP slow start with that new connection. That means the data will start flowing slowly and more rapidly.

Mike Crantea (00:45:20):

Next, keep the GCM HTML under 50 kilobytes such that it increases the likelihood to fit within the first network round trip. You would be amazed to notice that going from 50 kilobytes to something like 70 kilobytes over the HTML file does increase the time by some times as much as a third of a second on a 3G connection. Sometimes it’s a little effort to go just below the threshold and ensure a faster site. And now I am going to share into some strategies that are helpful for pages that have hero images and improving the largest contentful paint. Everything above helps for the pages that have the text being the largest and now here’s for the images. Use a responsive image preload hint early in the head. If the browser does not see the image tag early in the first HTML response, it cannot cue that download as early as possible.

Mike Crantea (00:46:23):

Ensure the meta viewport declaration prevents it. If this is incorrectly positioned, it might happen that the responsive image preload might pick the wrong image and create a cost of loading second time same image when the image is discovered later on in the page. The hero images for mobile should not be larger than 200 kilobytes. Try to have some sense on the fact that those bytes traveled to lots of radio waves to get on the mobile phones. Also, the main image should be eagerly loaded, don’t lazy load the featured images because that will have a significantly negative impact on the largest contentful paint. Even with delivering the media from the same domain like the VIP is doing with their photon optimizations coming up from the same domain, the bandwidth still has its limitation and sometimes balancing needs to be done between the size of the CSS and that featured image.

Mike Crantea (00:47:21):

And you might need to do more, maybe you need to split the CSS in two pieces above the fold and below the fold in order to allow more bandwidth to be available early for what’s needed for this above the fold mobile experience. Also, sometimes subsetting the Web Fonts or swapping them by some web safe alternatives can help free more bandwidth early on for the CSS and hero image critical combo. Next, delayed the non-render critical network request until after the LCP happens, don’t crowd the network early on, because that will only delay this first initial pain of looking at a blank screen. And now moving on to the next one’s, cumulative layout shift. There’s been lots and lots of coverage towards this new metric in the media, but there’s a common pattern.

Mike Crantea (00:48:17):

It’s always the unknown, the unknown size elements, the images always add width and height attributes. Now this is part of WordPress core, but you need to pay attention on whether you’ve missed adding the widths and heights on some areas that are not part of the editorial content. For the ads work with advertising partners to pre-allocate spaces for ads early if they’re dynamically allocated, that might mean adding a snippet of JavaScript that would be run early to prepare the blank spots. You should apply minimum heights on the ads rappers accounting for their biggest dimensions when you’re having dynamically size that. And for fonts, there’s some trickery you can use some false font style matcher to find a match or fallback website font. It’s very unpleasant to start reading content in the fallback plan, and then have things shipped around and you would lose your reading spot.

Mike Crantea (00:49:21):

By matching the sizes of the fallback and the real final one, you would maintain the good user experience. Don’t forget to disable this find unit adjustments when detecting the web font is ready to go live using font face observer. And now for the most difficult part. The embeds, measure and pre-allocate spaces for third party embeds. Something simple to recommend but also much harder to do. The popular embed providers don’t have an API to discover their size, which leaves a significant gap requiring creativity in measuring them ahead of placing them on a page. And that’s the only way to completely alleviate their negative impact. And in this way, inside of the administrative interface, there’s probably things that can be done to make bits that have media or to have their measurements done ahead of time. Maybe the editors would fill them in, hey, this big, so it alleviates that.

Mike Crantea (00:50:31):

And now we’re moving into first input delay. This is not a very often problem but when it is, it’s probably the trickiest to fix. For this strategy, performance tracing in the Chrome DevTools should be your friend. This has evolved a lot over time, and you get a lot more data. And it can sometimes be confusing because of how much it is. You should start by fixing what you have control over. And that’s probably the most difficult part. You can use strategies like code splitting of your JavaScript, predictive loading or using either landfill urgent strategies and delivering modern JS to modern browsers, in order to help improve the scripts that you have control over. Also, sometimes there’s too much going on to be able to make sense of a performance trace, and you cannot identify which things in your own code are causing a problem.

Mike Crantea (00:51:33):

The useful strategy is removing the third parties and discovering whether the first party scripts are actually the ones introducing long running or blocking tasks. Once these are solved introduce the third parties one by one and note their total blocking time costs. But that is the lab metric you can measure with Google PageSpeed Insights or Lighthouse. So that informed decisions can be made about their utilization and the cost they come with. Give feedback, provide feedback to the third party provider when it’s decided to be discarded due to performance reasons, as that will hopefully instill better behaviors and eventually earn your trust once more to get their spot on your website.

Mike Crantea (00:52:17):

And the last thing, delay the loading of script intensive third parties for periods of low CPU utilization, you might discover that if the CPU is not overwhelmed by doing 15 different tasks, their impact on the interactivity website might be minimized. Okay, and now I’m handing over to Leo.

Leo Postovoit (00:52:45):

Yeah. So, I really appreciate all of the information you’ve shared Mike, I think that’s an incredible way to look at slicing up some of the core elements of Core Web Vitals and also performance as a whole. Regardless of Core Web Vitals being your main litmus test, which has become ours as at first step up over the last two years, these are very much the same techniques that we were using underneath the hood. We really do care about trying to remove that critical render path, because it really does make a difference. The challenges, you need to ultimately unpack and get these things on what it’s going to use of your organization. And so we recommend at a high level, starting with a snapshot to understand that current set of performance. So, the questions we ask are, have you actually reviewed your current system? Have you gone through and run tests on PageSpeed Insights, your search console? Do you understand what your users actually look like in the wild?

Leo Postovoit (00:53:32):

Second, after you’ve done that, you should ask the question simply to yourself. Have you actually met the industry best practices specials? So, if you go to web.dev/webvitals, there’s a great page that describes exactly what this thresholds are for Core Web Vitals, these are the greens. And we also recommend studying a little bit further with time to interactive, so being the entire experience being loaded, and time to first byte. So, as Sérgio mentioned, just a few minutes ago, VIP has done a really great job, WordPress VIP has done a really great job to improve server performance, infrastructure and distribution level. We think it’s critical for you to be able to measure this as well. If you have really, really high positive or spite, you’re going to have high everything else as well. This is because every time that server is making a response, that initial response takes a really long time to process.

Leo Postovoit (00:54:15):

And then finally, I think the key elements part Mike, to the work that we’ve done together here is really about that performance budget and that long-term mindset that you want to apply. So, you need to have a proactive plan to be able to respond to this. And every time you’re working through to get to make this happen. It’s all working together. And I should actually ask, have you answer a question really quick? I see. [inaudible 00:54:36] mentioned this exact pop up. He said, “What happens when you can’t control YouTube Analytics? At the end of the day how does someone actually consider this over the long-term?” So for example, some of our favorite customers, we’re going to work with an XWP, this is one that comes up quite a bit. How does this actually come together when we integrate performance as a mindset when you have to decide which customer?

Mike Crantea (00:54:58):

I would say that putting the first ones first, like the things that website provides experience at one point. Analytic is not having a big performance problem, because there are a lot of scripting being done is little. So, it’s your choice on whether you want to load that early or a little bit later. As with YouTube, that’s one of the best examples that can be shared with because there’s an implementation of YouTube facets. That means you only get a preview of the video, and the video player only gets loaded when you stop and requested. So, there are solutions for some of the embeds. While for others, there isn’t an alternative other than delay their moment when they’re loading until they come into the viewport. So, that’s the recommendation.

Leo Postovoit (00:56:01):

And I think that does a really good job of rounding out the conversation. We are right at the top of the hour. So, we don’t have too much time for questions. But there’s quite a few that I’ve been answering here in the chat as well. I think we can probably get away with. I’m trying to select which one we should answer. So yeah, I think there was quite a few good suggestions around WordPress core. So, I saw David had written a long question regarding or a couple things here, talking about the user experience path. So, what happens when… And I guess maybe, Adam, you can take this one or even Sérgio as well, because there’s probably different ways that this is tackled. So, when a user uploads a really large image, how do we make sure that users and it doesn’t get served to users in the wild? So, what do we do as developers as people maintaining sites, how do we optimize for what actually gets rendered on the page?

Adam Silverstein (00:56:59):

Yeah, I mean, just real quickly. Core does automatically resize your image into multiple sizes, those sizes are defined by developer. So, by the theme or possibly by plugins, but typically by the theme. And ads typically at source set, so that you get correct image sizes served at different media breakpoints. And one thing we are looking at for the future is doing automatic image conversion. So, that would be where you upload, say a JPEG image and instead of just having those sub sizes be all JPEGs. They would be WebP images, for example, which would make your site faster, you wouldn’t have to do anything. That’s kind of an experimental feature we’re launching in 5.8. But that could potentially become part of core as well.

Leo Postovoit (00:57:38):

And Sérgio, do you want to talk a bit about how VIP optimizes images in CDN [inaudible 00:57:43]. You’re on mute.

Sérgio Gomes (00:57:53):

Sorry, I guess I missed the spacebar. Sorry, these questions are a little bit difficult to answer from a generic point of view, because obviously, this depends a lot on the details of your site. And where those images are coming from. Are they part of the theme? Are they something that is part of the like photon infrastructure and all that. But in general, I guess the only thing I can say is that both core, and Automattic and WordPress VIP are moving towards making all of these automatic conversions, and resizing, and all that as easily as possible. But it is down to the specifics of which image you’re looking at on your site for a specific solution.

Leo Postovoit (00:58:38):

And I think the other big part of this too, as well as whatever your hosting stack is like, oftentimes, you’re leveraging really awesome hosting partners and really awesome infrastructure partners. So for example, I’ve seen lots of really great examples where we use CloudFlare, on top of the VIP to get even further to have local delivery. Sometimes your instance is going to be different depending on where users are. And if you see that you have slow traffic where your actual users location infrastructure might actually be a concern. So, it gets into the nitty gritty of real interesting performance work, which sounds interesting. I have another question here, we maybe able to squeeze one more. And I think we probably run about that from there. So probably, I guess this might get a Mike. We have large clients whose sites are still hindered in Lighthouse reports due to a third party scripts for example, Google backbencher. Are there optimizations we can do to maximize the score and keep GTI. So, how to use UTM performance mindset?

Mike Crantea (00:59:32):

By removing the possibility to influence negatively the performance from people that are not technical and that can happen by one, limiting the access to Google Tag Manager to someone that understands the performance impact of the scripts that are being added. And measuring before and after you add a script and its performance impact that it has. And Third there are options in the Google Tag Manager which allow you not to eagerly load those scripts very soon. So, when you include a new script, let’s say from a marketing element, you can select the dilemma or delay that, hey, you should only load after this many seconds, because it doesn’t matter if you start tracking a user that would bounce out after two or three seconds. That’s not useful data to start with. So, it’s about taking responsibility. And giving the keys to the castle to someone that does not understand performance would only get your castle crumbling down for performance reasons.

Leo Postovoit (01:00:41):

Great answer. So, there’s a couple more questions as well, we’ll be following up in email the things that are here. We’ve also got a white paper coming out in the coming weeks as well that we’ll be tackling a little bit about these actual things we think are really useful. And again, I want to say thank you all. And I look forward to your thoughts and suggestions, a lot of really great energy in the questions here as well. I hope these are actionable tips that you can take back to your team and we look forward to seeing all these things come together as we progress. So thank you all for the time today, and thank you all panelists. Really do appreciate it.

Adam Silverstein (01:01:20):

Thanks, everyone. [crosstalk 01:01:21].