EXPLORE CLOUDWAYS
Experience lightning-fast loading times and seamless platform
View Demo > WordPress core’s performance team is building tools that make speed gains almost automatic. This Prepathon 2024 session covers Core Web Vitals, the Performance Lab plugins, and using AI for performance tuning.
🎙️ Speakers
▸ Adam Silverstein — Developer Relations Engineer, Google
▸ Brent Weaver (Host) — Director & Coach, UGURUS
✨ Key Takeaways
✦ FID was replaced by INP (Interaction to Next Paint), which measures the worst interaction across a page’s life, aiming for 200ms at the 75th percentile on mobile.
✦ INP problems only show up with real users in the field, so collect real user data, then use lab tools to reproduce and fix.
✦ Install the Performance Lab plugin to enable core features individually: Speculative Loading, Optimization Detective, Image Prioritizer, Embed Optimizer, and Modern Image Formats.
✦ Optimization Detective captures front-end data so WordPress finally knows the real LCP element per breakpoint and can prioritize the right image.
✦ Modern Image Formats converts uploads to AVIF or WebP with a picture-element fallback, with big savings, especially over PNGs.
✦ AI can digest huge PageSpeed and Lighthouse reports and attribute problems to specific plugins, but it sometimes gives outdated or wrong advice, so verify it.
Brent Weaver: Thanks everyone for participating in the Web Warrior quiz, can’t wait to announce those here in just a couple of days. So next up we’ve got an amazing presentation coming to you from Mr Adam Silverstein, he is a developer relations engineer at Google, he’s going to be talking about maximizing WordPress speed, essential performance hacks. He has been making the open web better through open source contributions, he is a lifelong programmer, lover of languages, and these days he’s mostly writing JavaScript. So Adam, I’m pumped, man, I’m pumped for your talk, welcome to the Cloudways Prepathon 2024 stage, it’s all yours, man.
Adam Silverstein: Thanks for having me. All right, I’m super happy to be here. I think I’ve got some slides that are going to come up, there they are, awesome. All right, so I’m going to jump in, I’ve got 45 minutes, hopefully I’ll finish a little early and leave some time for Q&A at the end. I’m going to cover three areas today, talk about what’s new in Core Web Vitals for 2024, I’m going to talk about what we’re working on in the WordPress core performance team, and then finally, because it is 2024, I’m going to talk about using AI to assist with performance tuning. And just a note that I’ll have a link to these slides at the end, so you’ll see there’s a lot of links throughout the slides, just don’t worry about copying those down, you’ll have access to the whole thing at the end.
So, Core Web Vitals. Hopefully everyone’s familiar with Core Web Vitals, it’s an initiative that’s been around for a while. It is essentially an attempt to move beyond the kind of raw speed metrics that we used to measure everything by, like Time to First Byte, still a valuable metric, but a way to look at performance as how users experience your site. And essentially trying to move from just raw speed to actually what do users experience when they visit your site, when they try to interact with your site. And so that’s where the three Core Web Vitals come from, and they aim to measure three areas of user experience: is the site loading, is it interactive when users try to click to open a calendar or add something to their cart, and is it stable, are there things popping in and out and shifting around so that when you try to interact with the page you misclick, and so forth, which can obviously be a frustrating experience.
So we had these three Core Web Vitals, LCP, FID and CLS, and this year we got rid of FID, First Input Delay, and we replaced it with INP, or Interaction to Next Paint. So I’m going to dig in a little bit more, but for all of these metrics, when we’re talking about a good experience, we’re aiming for a good experience for 75% of our users. Users will have a variety of experiences depending on the conditions at the time that they access your site, their device, the network and so forth, so what we’re aiming for here is the 75th percentile, an important note.
So what is Interaction to Next Paint? This is a measure of all of the interactions that happen during the life cycle of a page, clicking, tapping, and it measures all of those interactions and then reports on the worst ones, the slowest interactions that happen. So it helps you identify problem interactions that are happening on your site. So a good INP score is 200 milliseconds or less, anything over 500 milliseconds is considered poor, and everything in between is deemed needs improvement. So those are the sort of numbers that we’re aiming for, and again this is for the 75th percentile of users. And with INP we’re focused primarily on mobile, because desktop users tend to all have a good experience already, so you can focus your efforts for improving this metric on mobile users.
So what does INP capture? It captures these poor experiences that we’ve all had on the web, where we click on something and it doesn’t react, and we click again and then suddenly it reacts twice, instead of these good user experiences where you click and it’s very responsive instantly. And these poor experiences do impact business metrics, right, they affect user engagement, how likely users are to continue on the site, or whether they’ll add something to their cart or sign up for your newsletter, whatever your goals are. So this is the critical thing to understand, and a key insight of INP is that users spend 90% of their time on your website after the page has loaded, so it’s important to look at how they experience the site even after the page has loaded.
And why did we replace FID? Well, FID just wasn’t doing a good job of capturing these poor experiences. We all know they’re out there on the web, we’ve all had them, but FID, you know, all WordPress sites pretty much were passing FID, I think it’s like 99% now pass it, whereas when we look at INP we see that WordPress sites have a little bit more trouble passing, we’re now at about 80% pass rate, which isn’t bad but still some room to improve. So this means that the new metric is actually capturing more of the poor experiences that users are having.
So I’m just going to explain a little bit more about what exactly INP measures. So First Input Delay measured this part, the initial delay between when the user clicked and when the event handlers began to fire for that click. INP measures the entire interaction, so everything from the click all the way till the user is presented with an update, so that they know that the browser is actually responding to their input. And INP also measures all the interactions, whereas First Input Delay only measured the first interaction that happened on the page.
So the interaction is made up of these parts. The input delay, which is what we previously measured with First Input Delay, between the click and the event handlers firing, and there can be multiple event handlers here that are going to fire, and this input delay can be long if the main thread is busy with other JavaScript tasks. Then we have the processing time of handling all of the event handlers, and this can be long if the event handlers are poorly written. A good event handler will yield back to the main thread early on and allow the browser to continue to the presentation display so the user knows something’s happening, a poor event handler will sort of hang the main thread. So there is a way to fix processing time, and that is yielding back to the main thread. And finally, a presentation delay, this is the amount of time it takes for the browser to actually display an update to the user. So you’ve clicked on something and you’re going to expand an area, if you have an overly complex DOM or a really elaborate CSS tree, the browser has to figure out how to render everything, that can take some time, especially on a lower power device.
There’s all kinds of tools out there to measure INP, all of the tools that you may have used already for performance measurement include INP data. There’s also tools that are specific for collecting real user metrics, because this metric is something that only happens in the field with real users, it’s very difficult to measure in the lab because it requires actual interactions. Once you figure out that you have a poor interaction somewhere on your site, and you’ve figured out where that interaction is, you can use lab testing to try to improve that, you can use browser throttling and tools and you can test changes to see how they’re impacting your interaction, and you can work on it that way, but you really do want to see the improvements in the field. So the basic process is similar to any performance debugging, you’re going to repeat, you know, make small changes, test to see if it fixed it, and then repeat that process. There’s some great articles that have been written this year, I’ve got links here on the page so you’ll get those at the end, but in the interest of time I’m going to move on to my next topic, which is the work of the WordPress core performance team.
So most of this work that I’m talking about you can check out by downloading the Performance Lab plugin. This plugin is our sort of master plugin that enables all of the features that I’m going to talk about that are also released as individual plugins. So just install Performance Lab and then you can enable each of the features that I talk about individually in there. It also includes some site checks that will tell you if you need to, for example, enable more modern image formats, or various things that might be missing or set up wrong performance-wise on your site, in the site health section of WordPress.
So here are some of the things we’re working on in the Performance Lab. One really cool thing is called Speculative Loading, this is a way of providing instant navigations once users reach your site. It leverages the new Speculation Rules API that’s available in Chrome and Edge browsers so far, it is being proposed as a standard though, so hopefully we’ll see this across browsers. And essentially with the API we’ve chosen to use the sort of conservative mode, where as users hover over links we pre-render those links in the background, then if the user clicks on the link the page will load instantly because it’s already there, it’s like switching tabs essentially, the page is already there. Of course on mobile you don’t have hover events, so you’re not actually starting the pre-render until the user taps, but still you might get a couple hundred milliseconds of a faster load time than if you wait till they release their finger, which is when typically navigation would start. And you can also fine-tune this, so if you know that you have a big blue button that people are very likely to click in the middle of your page, your call to action button, you can add that to be pre-rendered automatically even without a hover. Now there’s a tradeoff here when we’re doing pre-rendering, we’re very likely actually to pre-render pages that the user will never visit, so there is a cost associated with that, the tradeoff is that the users who do visit the links that you’ve pre-rendered are going to get this instant amazingly fast experience.
The next plugin or feature that I want to talk about is Optimization Detective, and this is a really amazing effort to capture front-end data to inform back-end rendering, with performance in mind. So what this plugin does is it has a little bit of JavaScript that runs on the front end and it captures metrics about the page at different breakpoints, so it can, for example, record what the LCP element is at different breakpoints, or what elements are in the viewport. And this is a critical capability, without something like this we simply don’t have any information about the viewport on the back end. So for example with lazy loading of images, WordPress tries to lazy load images that aren’t in the initial viewport, but we’re just making a guess in the back end, we don’t actually know which image is going to be an LCP image. We assume that if there’s a large image early in the content that’s likely to be the one, but we don’t know, so LCP element can be different on every breakpoint. So here’s wordpress.org looking at four different breakpoints, we see that four different elements are the LCP element. So by using this front-end Optimization Detective we can actually capture which element is the LCP element, record that into WordPress, and then the next time we render the page we can use that to prioritize the images properly.
Which brings us to the Image Prioritizer plugin. It leverages the Optimization Detective data to prioritize images more accurately than WordPress core currently can, so it adds fetchpriority high, it knows about the breakpoint so it can properly add breakpoint loading, it can preload background images, and it will essentially give us much higher accuracy in terms of which image we prioritize with fetchpriority high, and also which images we lazy load because we know they’re not in the viewport. So this is in a way a silver bullet, I guess, of LCP optimization, because we actually know what the LCP element is, which we currently do not know in WordPress.
So check this out, Embed Optimizer is another plugin that we’ve been working on, this is specifically for the embeds that you get if you, you know, paste like a YouTube URL into the editor, you’ll get this nice block that’s an embed. And those are now lazy loaded with this plugin, including the JavaScript that they enqueue, which can be quite heavy, and these embeds can be quite impactful on performance, because if they’re all loading while your page is loading there’s this contention for resources that’s happening, so by lazy loading them you just eliminate that problem. It also leverages the Optimization Detective data, so if you have Optimization Detective installed it knows which elements are in the viewport, so it can be more accurate about what gets lazy loaded. If you have an embed that’s in your initial viewport, you probably don’t want to lazy load that, you want it to load with a normal or high priority if it’s the LCP element. So that’s what Embed Optimizer does.
And Modern Image Formats is one I’m excited about, this plugin converts your uploaded images to a modern image format like AVIF if it’s available, or as a fallback WebP, which is available on about 99% of our servers. AVIF is something like 30% of servers that run WordPress support it, and you get a huge savings, almost 50%, and with WebP it’s more like 30% over JPEGs at the same quality. And if you’re using PNGs for transparent images, switching to these new formats is huge savings in space, and the reason for that is PNGs, which are typically used for transparencies where you have a transparent background, they only use lossless compression, whereas AVIF and WebP formats both support lossy compression with transparent backgrounds. So the plugin supports this natively, you can upload your PNGs and it will output AVIF or WebP as the fallback and you’ll get a huge savings.
We also have picture element support, and this is the best way to provide format fallback, so browsers that don’t support AVIF will fall back to the original format that you uploaded, the JPEG for example, and that’s by wrapping both of those formats in a single picture element that then the browsers can decide what the best image is, or what the image they can support inside that.
So I covered the top projects, and just a few others that I’m going to briefly mention. We’re working on client-side image processing in core, this is the ability to process images that you upload in the browser instead of relying on the server to do that processing. My colleague Pascal is going to give a talk about this during the Showcase Day at WordCamp US, so check that out if you’re there, but essentially this allows us to use features like AVIF without having to upgrade the WordPress server or have people migrate to a new server to get that feature. We sort of leapfrog the limitations of the server capabilities by moving to the browser, where we can run the same libraries using WebAssembly.
We have the Plugin Check plugin, which is a collaboration with the plugin review team, where we’re trying to build out a tool so plugin authors can check their plugins, including for performance tests. We’ve also been working on the Interactivity API, if you haven’t heard about it it’s a new API in WordPress for adding front-end interactivity, it’s very lean and we are trying to build performance into the API, this is essentially something that could replace the use of jQuery for example. And the final thing is our performance testing tools, the framework that we’ve built for performance in core, we have automated tests that run so we can see what’s happening with each commit, we have a whole bunch of tools that you can run, like CLI commands that you can run on your own, we also have GitHub Actions that you can integrate into your project to run performance tests. And all of these tools we’re making available, the idea is that, you know, the community also needs to be paying more attention and have the tools they need to test performance and build performant plugins.
And this brings me to the last section of my talk, using AI to address performance issues. And a little kind of warning here, this is all experimental, and, you know, take the advice that you get from LLMs with a grain of salt, you’ll see that there are some mistakes that they make. So this is just something that I’ve been playing around with and I wanted to share what I’ve been finding with everyone, and hopefully it will be useful.
So the basic approach that I’ve been using is first to define, with system instructions, a performance expert who’s a helpful assistant that’s going to analyze data for me and give me advice. Then I gather all the data about the site that I want to analyze, including a PageSpeed Insights JSON object, maybe the HTML of the site, a list of plugins, the list goes on and on, you can really upload a huge amount of information. Next I upload all that information to the LLM, and here you’ll see that I’ve tested with ChatGPT and Gemini, both of which under their paid accounts allow you to upload files, so you do that kind of first to start the process, and then you’re asking it to analyze and correlate data, and also you can ask it to drill down on specific problems and how to solve them.
So let’s see what that looks like. First, gathering the data with the PageSpeed Insights API, you can literally just put this in your browser with your URL at the end, and then save the JSON object to your hard drive, and that’s what you’ll upload to the AI. And for getting your plugin details I like this Export Plugin Details plugin, it just gives you a CSV list of all your plugins and versions and so forth. You can also upload the plugins themselves, although as far as I’ve tested, the LLMs do not support zip files, so you’ll need to upload like the whole folder of files if you want to include them.
So here we go, I started this session with ChatGPT, and the first thing I’m going to do is create a GPT, this is a model that has some specific instructions about being a helpful performance expert, and then I upload all of my files and I ask it simply to tell me what are the top three performance issues. And a little while later, it takes it a little while, it analyzes all the data and it comes back with this very succinct summary of what the top issues are, these are the top issues on the site that I was testing. So kudos, good job here, but more importantly it was able to take this huge amount of data, if you look at a PageSpeed Insights report, you look at a Lighthouse report, you’ll see there’s a lot of information there to digest and it can be overwhelming, and the LLM has helped here by just summarizing the very top points.
So now I’m going to continue and ask it what I should do to fix this problem. Obviously this slow server response time is a huge problem for me, and it recommends that I, you know, maybe look at WooCommerce, because it knows that’s a heavy plugin, and it also notices that I have five form plugins enabled on this site, which is not a very good idea, and maybe I should disable some of those. So that’s what I did. The next thing I did was ask it about scripts, so in this case I’m asking it about like blocking scripts, which are the worst problems, and again it’s able to both tell me which script is causing the problem as well as which plugin is enqueuing that script. So it’s actually telling me which plugin is causing the problem, which is very helpful, this is something that can be very difficult to figure out when you’re looking at performance traces or a Lighthouse report, you know, where is the problem coming from, the LLM does a good job of figuring this out.
Next I asked it for a fix, how do I fix this problem, it suggested lazy loading the embed, that’s a good idea, so I asked it for the code, that was the next step, I’m going to try out its fix. Unfortunately, here’s where things went a little wonky. So in the code snippet that it gave me, even though it’s functional, it’s using an outdated approach, it’s using JavaScript to do the lazy loading, so it enqueues this lazysizes script that’s no longer required. All modern browsers support native iframe lazy loading, so all we need to do is add loading=lazy to the iframe to lazy load it. So although this is a technique that will work, it’s actually outdated advice, and I think this brings up one of the challenges of using LLMs for performance advice, they’re great for digesting huge amounts of data and connecting the dots between different data sets, however sometimes they get things wrong, and as a novice user you may not know when you get advice that isn’t good advice. So a really nice improvement here would be references, right, a way to link out to something that shows where this best practice comes from, in this case this probably comes from some article that’s out of date, the wrong answer. So there’s definitely some room for improvement here, and I see this as a big challenge with using LLMs for performance, or really for anything, because you’re sort of trusting it to be an expert, but at the same time do you really trust it.
One other thing I really liked with ChatGPT is that after each response it gave me these little chips with suggested follow-up questions, so here it’s suggesting any other ways to improve performance, and that’s the whole idea here, it’s a conversation, you can keep asking questions and drilling down into problems that you’re having.
Next I tried Gemini. So in this case I created a Gem, this is like a GPT, the Gem is the system instructions that I’m giving Gemini to act as an expert, and one thing I liked here is that it actually exposes the full system instructions and lets me edit them. So I went in and I added some WordPress specific instructions, telling the LLM how to correlate the script paths that you find in a Lighthouse report with the plugin paths by the slug, so this is a way to sort of inform the LLM how it should do the analysis on the data that it’s about to get. Then I proceeded, I uploaded all the data just like I did with ChatGPT, and it came back with the same sort of response where it highlighted the top issue as being the slow server response time, so very good there so far. And now I’m going to ask it for a solution, how can I fix this problem, what plugins could be causing my problems, again it picked up on the fact that I had five form plugins installed and recommended that I deal with that situation. And so what I did then was I actually disabled all the plugins, turns out I didn’t need form plugins, so I disabled all the form plugins and I reran the Lighthouse report and I asked it to compare to the previous report. So this is another really useful feature of LLMs, is you can take this huge data set and then get a new version and ask for a comparison, and that’s exactly what Gemini did, it gave me a before and after comparison, and it gave me this nice little chart at the bottom. I really like that it gives you the export to Sheets button, this is super helpful to me because I can export this, each step that I do in my performance tuning process I’m going to save that data so I have a record of all the changes that I’ve made along the way.
And then I did some more optimizing, this time I optimized the main image on the page, which I had purposefully left oversized, and I made it the correct size so the dimensions matched the actual image, and I also changed it to being a WebP image which is obviously smaller. And after I made those changes I reran Lighthouse and I uploaded the file again and I asked it to compare, and again I got this great chart, and I made a huge impact here with this change. And the thing that I like most here is that right after this it told me that I’ve now fixed my LCP problem, you know, I’ve dramatically improved LCP, so it really honed in on what the results of this change were, which is really helpful to a user to know that they’ve had the right impact that they’re trying to make with the changes.
So this is using LLMs to kind of analyze data, right, this is something that I do over and over again at the performance table at the Google booth at WordCamps, is people come in and we look at their Lighthouse scores, maybe we do a Dev trace, maybe we look at the list of their plugins, the HTML of their website, and then we try to synthesize all of that data into some concrete recommendations, a few things that they can try to maybe improve their performance. And after doing that process over and over again I realized this could be a good task for an LLM, and it gave me an idea, which is maybe I could build a plugin for this.
So that’s exactly what I did. So this is my first time announcing this publicly, this is public though on my repo, so you could go check it out on GitHub, it’s the WP Performance Wizard, and essentially what this plugin does is all the things that I just showed you in the previous steps. So it has a set of system instructions that define it as a helpful performance expert, I’ve built a connector to Gemini so far but it’s open source, so please someone build the ChatGPT connector, it’s pretty simple to do. It collects data from a bunch of data sources, so far I’ve built in Lighthouse, HTML and plugin and theme data, and then it proceeds with a sort of conversational mode where it sends each data set off to the agent, and it also has some instructions for each data source about how to analyze that data, so things like, for example, how to correlate the plugins back to the Lighthouse data, that kind of thing. And then at the end it becomes interactive, so you can ask the follow-up questions and drill down on the information that you want.
And this is how it looks, so you go into WordPress tools, Performance Wizard, and you click Start Analysis, and it’s going to start this conversation. Now I’ve sped up this video, this actually takes several minutes to complete, because each time you hit the LLM there’s quite a bit of time for it to analyze all that data and get back to you, and also things like the PageSpeed Insights API take quite a while, but anyway this is the sped up response here. At the very end you get this nice summary of what the top recommendations are, it also includes testing instructions and so forth. This is kind of what some of the results look like, and you can see again that it’s doing this great job of correlating the problems to the plugins as well as to the specific Lighthouse audits that they face. Again, I’ve talked about this a little bit, but it does a great job with attribution, it detects duplicate plugins, it comes up with a testing strategy, so how you can test the fixes and see if they’re actually having the impact that you want, and it also identifies specific problems, so I created a plugin that enqueues seven different JavaScript libraries and it clearly identified that as the problem you’re having. But it also sometimes gets it completely wrong, like in one case where it recommended that I increase my LCP from 1.1 to the recommended 2.5 seconds, that’s exactly the opposite of good advice, the actual recommendation is to stay below 2.5 seconds. So, please contribute, like I said it’s open source, I have a lot of ideas for how this plugin could be improved and made more useful, made more accurate, I have issues open for most of these ideas already on the repo.
And that is my talk, thank you very much. The Bitly address is the slides, the QR code that is on your screen is a quick survey for you if you have a moment, just to answer the question, did you learn anything from this talk about performance in 2024. And I think I finished with a little bit of time left over for any questions that might have come up in Q&A.
Brent Weaver: Adam, love it, love it, lots of kudos for you in the chat. Let’s give a nice round of thank you for Adam’s amazing talk on essential performance hacks for WordPress speed. We’re going to now go to some time for questions, so if you want to make sure you mark that in the Q&A panel, we’ll be working through those questions that folks asked. So I’ll be looking at that and jumping back and forth to chat, we’ll start off here with this question from Pesh, what are the techniques effective for detecting and optimizing performance bottlenecks in web applications? I just pinned that up to the screen there for you, Adam. So I assume that is more about like, when you say web applications as opposed to like a website maybe.
Adam Silverstein: I guess I’m going to say the most important thing is collecting data, real user metrics, that’s something where it can really inform how users are experiencing your website or application. A lot of times we tend to test things out on our high-power development computers, that’s called lab testing, when sites get live or applications get live in the field, users have a very different experience, they might not have the same high-powered devices, they might be on iffy network connections. So I would say the first thing would be collect data, and then it’s similar to any type of performance tuning, where you identify where the worst problems are, you try to fix those problems, and then you repeat, you test to see if that made the impact that you want, and repeat that process over and over again until you’ve fixed your problems.
Brent Weaver: Here’s another one for you, from David, how to optimize YouTube video embeddings?
Adam Silverstein: That’s a great question. We do have the Embed Optimizer that aims to do that, we have an issue there to possibly replace YouTube embeds with the YouTube lite embed that was developed by Paul Irish, you can just search YouTube lite, you’ll find that you can use that as a substitute. One really big challenge with any way of substituting or optimizing the YouTube embeds is that on, I think it’s Safari mobile, when you do that type of lazy loading of the embed, it takes two clicks to start the video, not one click. I’m not explaining it exactly right, but there is a fundamental technical problem that even things like the YouTube lite embed has, where you don’t get that one play click that users are expecting. But I would say that if the optimization is the most important thing to you, I would definitely check out that YouTube lite and also the Embed Optimizer plugin.
Brent Weaver: Very cool, awesome recommendations. Let’s jump to this one here from Stash, go ahead and pin this one on the screen there. If I choose to use an external host for my images, do I need to convert them from JPEG to WebP format before uploading them to that host?
Adam Silverstein: Yeah, I think that depends on where you’re talking about hosting the images. With image CDN services, they typically will do that type of conversion automatically, so if you’re using an image CDN where your images get uploaded automatically, then when they get served up to users they’ll typically get served up in the best possible format. So the browsers actually announce which formats they support as part of their requests, and then the CDN can respond with either AVIF or WebP depending on what they support. If you’re talking about like uploading your files to S3 directly and then serving them from there or something like that, then yes, you would need to convert those, because WordPress will only do this conversion when you are uploading your images directly to WordPress.
Brent Weaver: Cruising through our questions here, Adam, there’s some good stuff in here, just want to get as many as we can in the time we have. This one’s coming in from Lindsay, still on the image topic, does using modern image formats help at all with other people stealing image photography from my website?
Adam Silverstein: That’s a great question, actually. You know, a couple years ago we tried to land WebP by default support in WordPress core, and what this would have done is essentially what the plugin that we have now does, so when you uploaded your JPEGs it would have automatically converted them to WebPs for serving on the front end, and then when end users visited your site it would have been WebP images. Now one of the problems with that, and the reason we didn’t wind up landing that feature, is that if users download those WebP images, they’re less useful in other places that aren’t the web, so for example Google Docs does not support WebP images. If you switch to AVIF images you’ll find even fewer places that you can use them because it’s a newer format. So in a way, switching to modern formats does help you with people stealing your images, because they become a little harder for people to use, they can still download them but now they’re in the AVIF format, they need to know how to convert that to JPEG, probably not a huge help, but it is interesting that for things like publishers for example, where they really don’t want people just copying images off their website, the sort of problem that we have with landing WebP is actually a benefit to them. So it helps a little bit, I guess, with my answer.
Brent Weaver: Going back in chat a little bit to some previous questions that were asked here, do INP captures always indicate direct engagements?
Adam Silverstein: They’re user interaction, so I think you’re asking, like, is it a direct interaction, yes, the answer is yes, that’s what it captures.
Brent Weaver: Cool, and then let’s see here, we probably have time for a few more questions still. What advantages does the high efficiency image format have over traditional formats like JPEG?
Adam Silverstein: So HEIF, or HEIC, is another sort of very similar format, I think HEIC is the one that’s the default output format for iPhones, so you may have come across this image format if you’ve looked at photos that you’ve synced to your computer that you took with an iPhone. If you upload them directly from your iPhone, Apple actually converts them to JPEGs. But this format, HEIF or HEIC, closely related, so I’m going to talk about HEIC because I know more about it, is not widely supported on the web, so it’s supported in Safari but no other browsers support it, so it’s not really a web safe image format. But we did recently land in WordPress core a feature where if you upload these HEIC images, instead of giving you an error, if the server actually supports HEIC, we’ll convert those for you automatically to JPEG. So the advantage, I guess, is there probably are some more technical advantages, but it has, you know, high dynamic color range, much better compression than JPEG, it probably has some other features that are lacking from JPEG that I’m forgetting now, but the challenge is that it’s not really a web format, and so you can’t really directly use it on your website unless you only have Safari visitors.
Brent Weaver: This question’s from earlier, on WP Rocket, whether WP Rocket has all of these plugins maybe that were mentioned earlier.
Adam Silverstein: WP Rocket has features that are similar, all of these features that I announced, they don’t use our plugins obviously, we do work closely with several of the optimization plugins including WP Rocket, we welcome their contributions because they know a lot about optimization, but yeah, they have similar features that we have in our plugin. So if you’re already using WP Rocket you probably have most of these features already, they’re not doing things exactly the same way that we do them, so you might get slightly different results, but in terms of the general approach, like Optimization Detective, they definitely are doing something like that, where they’re capturing metrics and using that to inform how they do the loading.
Brent Weaver: Yep. What metrics are most essential? I know you talked quite a bit about a lot of these, I’m not sure how much time we have for that question.
Adam Silverstein: I mean, you know, the ones that you’re failing on are the ones that are most essential for you, and that’s the whole point of these metrics really, is to help you capture data about poor experiences that users are having so that you can fix them, that’s really what these metrics are for. So it’s going to vary tremendously depending on your site, depending on where your users are, you might have a lot of large images, that might be, you know, you might need to pay attention to LCP, LCP might be your main thing, you might have a very interactive site where INP is the most important thing, so it really depends. There isn’t one answer to that, other than to say the Core Web Vitals are the top ones to pay attention to. I will say that, it kind of came up in my AI section, that Time to First Byte is a large problem in WordPress, we have a lot of sites with a slow Time to First Byte, if you can’t get your Time to First Byte down to a reasonable level, you know, your LCP is never going to be good, you’re never going to get good performance if you can’t get your Time to First Byte down. So that’s usually solvable with something like full page caching, however if you’re doing something like e-commerce that may not be a valid solution for you, so again it really varies tremendously depending on what your needs are, what your site is.
Brent Weaver: I’m going to take a little bit of a detour here on some of your core presentation, Adam, but I’d love to get your insight as a person at Google if you want to answer this question. He, Sha, is new in the IT field, can you guide him on where you could apply for some basic level jobs, or any career advice you have for people that are early in their IT web pro career?
Adam Silverstein: Yeah, I’ve done some mentoring with people early in their career, so I know how challenging it is, I think it’s a super challenging thing to get involved in. Any kind of job, you know, when you’re applying, you sort of have to sell yourself, so it’s really easy to try to tout up what you could do and then feel like you’re lying about it, you know, the impostor syndrome as they call it. I would say, for me personally, that’s all I can really share, is my own personal experience, one of the biggest things was getting involved in open source early on. I applied for a job at Automattic and I was denied because I wasn’t WordPress-y enough, and that led me to releasing a plugin and eventually getting involved in WordPress core and eventually becoming a core committer, which I’ve been doing now for, you know, over a decade. So that work that I did in open source in WordPress core was essentially my resume when I went to get my real job out there in the industry, I could point to all this work that I had done in WordPress core, I could point to the commits, I could point to the things that I landed. I think anything that you can get involved in, whether it’s WordPress or some other open source project, where you can, and I was donating my time I should say, but you get the experience of working with other people, of building code, of interacting, which is a critical part of being successful in tech. So I would say get involved in open source, get involved in WordPress core.
Brent Weaver: Adam, I love from that advice just the, like, taking the rejection of an opportunity and actually using that as feedback of like, okay, if I went and did this other stuff maybe that would help, and you obviously, it helped you immensely in your career. Maybe we have time for one more question here, we’re going to go from Dimitri, if we made a change to optimize Core Web Vitals, why can’t we see changes when we use the online Google PageSpeed tool?
Adam Silverstein: Okay, so there’s a couple things here. One is that, so if you’re talking about PageSpeed Insights, there’s two data sets that are returned, if you have field data, that is how users are actually experiencing your site in the field, that shows up first, the second section is the lab data, that is run directly against your site when you hit the API or load the page. So that one should change when you make changes, I will say there’s a lot of variability in those tests, so if you run them repeatedly you’ll get different numbers each time, so if the changes are small it may be difficult to pick up those types of changes. You could try our tooling, the tools that we’ve developed, like the WP-CLI commands that we have, one of the ways that we overcome that problem is that we run the tests repeatedly, like 50 times or 100 times, and we take the median value, so you should be able to sense differences when you make changes with those types of tools. For field data, for how users are experiencing your site, that is delayed, so if you make the change now it won’t appear into, you know, next month’s data set, so there’s that factor as well.
Brent Weaver: That is awesome, and that is all the time we have for questions, Adam. One last question here from the Cloudways team, how was your overall experience this year at the Cloudways Prepathon 2024?
Adam Silverstein: Great, great, I caught a couple of the talks earlier, and it was fun for me to prepare for this, I haven’t really talked about AI and performance yet publicly, even though I’ve been messing around with it a lot, so it was really fun to actually just prepare for it, and yeah, I really enjoyed it, thanks so much for having me.
Brent Weaver: Awesome, well Adam, thank you, let’s give another virtual round of applause, some shoutouts in chat, you know our speakers are suckers for those emojis and memes and all that good stuff, so let’s give Adam some love here at Prepathon. Lots of thank yous, awesome talks, all that good stuff. Adam, thank you so much for stopping by the Prepathon. Next up, stick with us, we’ve got one more session coming to you with our host Shelly Fagin, she is going to be hosting a panel, a round table on UI/UX mistakes to avoid for your client’s website, so if you’re building websites, if you’re launching web apps for your clients, these are going to be UI/UX mistakes, we’ve got some top experts coming in to join on this panel. So we’re not quite yet done with day one of Cloudways Prepathon 2024, so stick with us and we will be right back.
Answer a few questions, and we'll present you with a personalized tour of the Cloudways platform based on your answers.