Core Web Vitals

 [Music] 
 welcome to the decode podcast this is 
 the podcast where we talk all things 
 headless wordpress and modern web 
 development and we're back in your ears 
 this week for another fun-filled episode 
 this is an important one this episode is 
 on a topic that's 
 really critical for getting good 
 performance on the web and ultimately 
 delivering a really nice user experience 
 to your website visitors 
 so make sure you stick around i'm kellen 
 mace and i'm joined today as always by 
 my co-host will johnston how you doing 
 well 
 doing fine 
 let's talk uh core web vitals shall we 
 um so that's the uh subject that's the 
 topic on the docket today um you might 
 have heard this term if you're in the 
 web development space this is 
 a term popularized by google it's their 
 term for measuring um 
 overall performance on the web so in the 
 past you might remember 
 other terms like google used to 
 allow you to run audits from your 
 browser's developer tools where they 
 would measure things like 
 time to first bite 
 and then first 
 meaningful paint and things like that 
 but over time they've changed some of 
 those metrics and now they've come up 
 with what they think 
 are a new and better 
 metric for 
 web performance and it centers around 
 three things they call core the core web 
 vitals 
 yeah so something something i'll bring 
 up before that so maybe this is my 
 personal opinion or my it's clearly my 
 personal opinion but my personal 
 preference when i think of core web 
 vitals 
 uh 
 a small piece of me like rolls my eyes 
 and it's like hey core web vitals just 
 another marketing term that i don't have 
 to care about but 
 if that is you i would really encourage 
 you to to look deeply and i'm sure you 
 know most developers who are writing 
 these sites that really depend on uh 
 ranking high on on google or other 
 search engines do pay particular 
 attention to core web vitals but 
 the 
 uh the metrics behind corel vitals are 
 very important and it's not marketing 
 right it there is a lot of very useful 
 information about how to provide 
 uh not only an experience that will get 
 you ranked higher on search engines but 
 also just a better experience for the 
 end user so 
 it's a very it's a really interesting 
 subject if you're uh interested in 
 optimizing 
 web performance and 
 i i feel like for years uh since corey 
 vitals came came out the web has just 
 been getting so much 
 better from an end user perspective 
 and and i really do think some of these 
 metrics that people pay particular 
 attention to are the reason for that 
 yeah yeah yeah marketing buzzwords 
 notwithstanding i i appreciate you know 
 what the 
 intent is anyway behind core web vitals 
 particularly how nowadays they're more 
 focused on 
 the end user experience you know in the 
 past like i mentioned some of the 
 metrics that were measured when you ran 
 an audit like from your browser's dev 
 tools as i mentioned were things like 
 time to first byte and first meaningful 
 paint and so on 
 some of those have 
 all of those affect the user 
 in some ways whether indirectly or 
 directly however a website 
 uh 
 you know in that 
 day and age when those were the metrics 
 we were using a website could load like 
 lightning quick but then have a lot of 
 jank you know so so ads would pop in and 
 images would pop in and the content on 
 the page would like shift around 
 you know and provide a really bad user 
 experience 
 but it would score well in the dev tools 
 and google would would you know give it 
 give it preferential treatment in its 
 search rankings and so on so so i can 
 appreciate some of the metrics that 
 we'll get into in a minute here that 
 that say like those things aren't okay 
 anymore on the web we need you know the 
 page to be delivered and for the content 
 not to jump around and be disorienting 
 to to the user so things like that i can 
 appreciate 
 yeah i i think in general you want to 
 work with in the balance of the system 
 and 
 and you need to strike a balance between 
 what is good from a user experience 
 perspective and uh what is good to rank 
 on google and it seems like those are 
 kind of converging 
 but 
 um so that's a decision that you need to 
 make as a as a developer or a business 
 owner or 
 or whatever yeah so let's dig more into 
 the motivations right because as um 
 as you know a developer if you're 
 listening to this podcast you might ask 
 a question why should i care about this 
 sure optimizing performance is always 
 a good thing but is it really going to 
 affect the bottom line and my company or 
 you know some uh some of the things that 
 we're trying to achieve 
 and i think for me the three big ones 
 are number one user experience 
 uh as i mentioned if your page has a 
 very quick initial load but then it's 
 it's janky content is jumping around as 
 things are you know lazy loaded in or 
 async loaded or whatever 
 that's going to 
 disorient users and kind of turn them 
 off from using your site 
 second one is more conversions so if 
 your site you know the goal of it is to 
 have like some kind of lead capture to 
 you know get people interested in your 
 product and have them sign up for your 
 email list or maybe it's to make sales 
 an ecommerce site that kind of thing um 
 you can you just get more of them if you 
 score very highly on 
 core web vitals 
 and that leads into the reason for that 
 is um the third one on our list here is 
 that it has better seo right which isn't 
 a shock since google is the ones kind of 
 um 
 you know promoting this this term this 
 core web vitals term and and uh 
 encouraging people to strive to 
 hit high marks on these it's because it 
 benefits them of course right in their 
 their search engine engine so if you 
 play by their rules and you um you know 
 try to optimize your site to score well 
 in these core web vitals google in turn 
 will rate your site you know more highly 
 um your page rank will will ultimately 
 be higher as a result of that 
 so let's talk about uh what are the 
 metrics um so if you read the docs the 
 google has like there are many metrics 
 that you could use to 
 measure website performance but only 
 three of them they call the core web 
 bios so that's what our episode kind of 
 centers around and yeah so there 
 there will be a link in the description 
 but if you just go to web.dev vitals 
 you'll see the a write-up from 
 you know google about the different 
 metrics what each core with vital is 
 we'll go into it now but you can go to 
 that site and follow along 
 yep get the whole story 
 yeah so the three metrics then to name 
 them off the first one is largest 
 contentful paint 
 and that one is a measure of loading 
 performance more specifically it 
 measures the render time 
 of the largest image or the largest 
 block of text it measures when that is 
 actually visible 
 within the user's browser relative to 
 when the page started loading 
 yeah and this is an important uh 
 distinction here it measured the largest 
 uh block i mean it's images text i think 
 if there's even videos uh 
 are involved there but whatever the 
 largest piece of content is on your site 
 and when it when we mean text block 
 we're talking about like paragraphs the 
 largest content piece on your site it 
 measures how long it takes for that to 
 load i think two and a half seconds is 
 the 
 the target time right now obviously 
 those change year over year 
 based on you know how the web evolves 
 but 
 uh 
 but you need to focus on hey what is the 
 largest piece of content on every page 
 and optimize for loading that piece of 
 content as quickly as possible 
 that can really hurt if you have large 
 images or large you know background 
 videos or things like that so that's 
 something to keep in mind um 
 yeah and that's what the user would care 
 about right win can actually see the 
 text or see the image and then 
 start you know reading through it or 
 viewing it or whatever that may be so 
 it's definitely central to ux 
 the next one on the list is first input 
 delay and this is a measure of 
 interactivity 
 more specifically it measures the time 
 from when a user first interacts with 
 the page so this is if they click a link 
 or tap on a button or something like 
 that to the time when the browser is 
 actually able to begin processing 
 those event handlers um 
 you know tied to that that particular 
 event 
 and i think this one 
 i think this one wasn't as much of an 
 issue in the earlier days of the web 
 when most of the 
 work was done on the server 
 you know when the server was 
 uh was 
 the html document was rendered on the 
 server and then delivered to the user 
 it's like as soon as it was visible on 
 the page um 
 then there wasn't much to do after that 
 like clicking any links yeah they were 
 ready to go pretty much pretty much 
 instantaneously and there's very little 
 you know javascript and event handlers 
 going on but as the web has um has 
 evolved and gotten more complex and we 
 have javascript frameworks that that do 
 um 
 add lots of event listeners and handle 
 lots of events i think this this has 
 become an issue 
 yes yeah and actually and and something 
 to point out there too uh web vitals 
 the particular metrics at least the 2020 
 metrics that we care about are very much 
 focused on 
 once the 
 uh 
 you know content is downloaded 
 from that point on 
 the metrics are measured but 
 there is still the time you know the 
 response time from your server so time 
 to first byte uh those kinds of metrics 
 are still very important so we don't 
 want to forget about all those things 
 because the only thing that matters is 
 loading it's just once 
 all of the 
 files necessary files are downloaded 
 that's where these metrics start coming 
 into play and it's really focused on you 
 know 
 like largest contentful paint is a 
 loading based metric 
 um first input delay is like a 
 interactivity based metric 
 yeah and i would say there are a few 
 things more frustrating as a user 
 you know than if if you're on a website 
 and you see a button 
 um you click on that button and then one 
 two 
 and then an interaction happens right 
 you would immediately think 
 man this site is sluggish and bad and 
 like why does everything take so long 
 right as opposed to a snappy interaction 
 it's something that that reminds me of 
 uh back in the day i feel like now you 
 know 
 most of the front-end javascript that 
 you write especially using these modern 
 tools and frameworks 
 uh 
 is 
 asynchronous first you know like you'll 
 make a fetch request or something and 
 that's asynchronous there's no there's 
 like 
 not a synchronous way to do that 
 uh 
 i remember back when i started uh 
 getting into web development and at that 
 time there was 
 um jquery was like huge you know 
 everyone was using jquery for their 
 sites 
 and you could make jquery request xhr 
 you can make xhr requests synchronously 
 like just 
 block everything until this is done 
 and i remember i had a i mean it was 
 silly right silly at the time but 
 it was 
 difficult to reason about how to 
 properly do asynchronous programming at 
 that point we didn't have all the 
 features we have today like you know the 
 async keyword or even promises weren't 
 necessarily a thing at that time so it 
 was all like these call nested callbacks 
 um 
 and so 
 you know i 
 silly of me i was just like okay i have 
 this app i actually it was like an app 
 where i had a map and i was trying to 
 like put a bunch of pins on a map and uh 
 i was getting that data from a 
 request a rest request and i was just 
 like well i'll just 
 block the loading of everything until 
 that request comes back so you would 
 start up the application or that go to 
 the website and you would see just like 
 a white page until 
 until the request came back so it's like 
 and sometimes it would be slow and i you 
 know i wasn't worried i quickly 
 corrected that 
 but uh 
 but yeah if you're responding to some 
 button event or something and you're 
 doing 
 a lot of complex 
 uh synchronous processing that is really 
 going to hurt your score 
 on first input delay it can also 
 really degrade your user experience so 
 that's a big one that affects user 
 experience for sure 
 yeah 
 and the third one the last one we'll 
 cover in this list is cumulative layout 
 shift or cls this is a measure of visual 
 stability according to google so this is 
 a a measure of the largest 
 burst of layout shift 
 for every unexpected layout shift that 
 occurs during the entire life span of a 
 page 
 and so that less flip phrase is 
 important it's not just like on the 
 initial load it's even 
 throughout the whole life span of of the 
 page 
 um so this would be that website jank 
 that i had had referred to earlier um 
 and there's 
 uh this you know brings to mind uh this 
 meme i've i 
 you know have seen um 
 bouncing around the internet you know 
 the last last few years maybe you've 
 seen it too if you're listening out 
 there it's it's kind of humorous it's 
 like uh this picture of two buttons one 
 is like you know launched nuclear 
 nuclear missiles or something and the 
 bottom button says do not launch nuclear 
 missile missiles sweaty guy 
 yeah 
 so it's uh so that it's a web page right 
 the page initially loads and both the 
 buttons are visible and you see a mouse 
 like you come into view and hover over 
 the don't launch nuclear nuclear buttons 
 and the person like 
 clicks it but the moment they do that an 
 advertisement pops into view at the top 
 of the page and shifts all the content 
 down 
 and then and then so the guy ends up 
 accidentally clicking launch nuclear 
 missiles and then you see the mouse just 
 like 
 shake back and forth like 
 oh no you can just hear them yelling in 
 your head like what did i do right so 
 that would be that's a kind of a 
 humorous example but uh that kind of 
 stuff does happen where ads will pop in 
 content will will pop in and you know 
 shift around 
 disorienting for the user 
 yeah i'd say this is where uh some of 
 the 
 modern frameworks that take advantage of 
 server side rendering or static site 
 generation come in handy because they 
 can ship down uh basically a full built 
 site so that you have as little layout 
 shift as possible versus if your client 
 side rendering if think about if you're 
 if you're trying to render client side 
 and you might ship down and client-side 
 only you might ship down like 
 the header relies on a web request the 
 main content in the body relies on a 
 different web request the footer might 
 rely on a different rubber crest and 
 then maybe you have some sidebars or 
 something and all of these requests will 
 take a different amount of time 
 uh and you don't want to 
 just not render anything until you get 
 the data back because then your page 
 will just be unusable for you know a few 
 seconds maybe 
 and that 
 that can really degrade user performance 
 the um 
 and even when it comes to text content 
 it's even difficult to tell how large 
 it's going to be so it's not even like 
 you can render some 
 empty 
 div that just doesn't 
 need any content layout shift in the 
 future so that that can be difficult 
 with image it's a little bit easier or 
 images it's a little bit easier but 
 still there's there's a lot to take into 
 account there 
 yeah 
 so uh so with all that said now that we 
 know what the metrics are and why we 
 should care about them um 
 what tools exist out there for us to be 
 able to run a an audit on our site um 
 will what's on what's on your list how 
 do you usually measure this 
 it's funny there are plenty of tools 
 that have been developed over time i 
 uh 
 i guess my first interaction with 
 core web vitals i don't know if it was 
 even called corwed vitals at the time 
 but was going to the page speed insights 
 uh 
 website and just putting in my urls and 
 um 
 you know and clicking 
 to check it and the big thing 
 there and actually with these other 
 tools too is like you don't want to just 
 put in your home page 
 people can go to any page on your site 
 and every page on your site is unique uh 
 to search engines and to the user so 
 every page on your site can have a 
 different score 
 or you know a different ability to do 
 this but yeah i remember going to page 
 speed insights and 
 loading up my site and then 
 specifically when single page apps came 
 out i used page speed insights to 
 understand like hey how does google see 
 my site because yeah they're you know i 
 was like hey they're using their sync 
 crawler and i don't want it to just look 
 like you know five lines of 
 uh html with one div tag in the body and 
 that's it right so yeah 
 yeah so i was focused on that a lot yeah 
 yeah so since then things have gotten a 
 bit easier i think because they've baked 
 in uh the lighthouse audit tool into 
 chrome and other chromium-based browsers 
 so i think that's most commonly you know 
 how developers would would run these 
 kinds of audits so so it's pretty easy 
 you just pop open the browser dev tools 
 you go to the lighthouse 
 audits tab and then from there you can 
 choose to run either a desktop or a or a 
 mobile audit and the mobile is a bit 
 more stringent um you can dig into 
 google's documentation to see like what 
 exact exactly the differences are there 
 but 
 for mobile you have to be even more you 
 know optimized and even more performance 
 to to score well there because these 
 folks you know they're unlike a desktop 
 where you have 
 you know these days is becoming less 
 true but desktop you typically have more 
 power more resources and so on and 
 usually a stable internet connection on 
 mobile that's there's no guarantee is 
 this person their battery is at two 
 percent they have this really spotty 
 network connection right so if your site 
 isn't like 
 performing very well they'll have a 
 rough time using it 
 yeah luckily these tools are are 
 first of all they'll show you both 
 mobile and desktop but 
 tip i think most of them show you the 
 mobile score as default and then you can 
 go to the desktop score because the 
 mobile score is usually lower 
 and i know in the past i've been looking 
 at scores and it's like oh i have a 99 
 on desktop but a 70 on mobile or 
 something and that you know and their 
 you know mobile phones just render 
 things differently have um different 
 capabilities as compared to like very 
 powerful desktops 
 yeah so we've mentioned uh page speed in 
 insights will mention is still around 
 you could still use that the lighthouse 
 audit as i mentioned is probably the 
 most convenient it's baked right into 
 the browser and beyond that it's also 
 included in google's search console 
 there's also a standalone javascript 
 library it's called web vitals 
 that exists and it just ties into like 
 the browser's own navigator um object 
 and it's just kind of a javascript 
 wrapper for running those same web apis 
 for doing the the same audits so it's 
 kind of fun you could um even leverage 
 that library like in your own code if 
 you wanted to you know in your own 
 javascript code run an audit display the 
 score or something you could with this 
 library it also is packaged as a chrome 
 extension as well you could install and 
 run 
 another cool thing is it's possible to 
 run a lighthouse audit 
 as part of your continuous integration 
 pipeline so 
 yeah 
 github action right for that yeah yeah i 
 saw i've never done this but i did see 
 some people who had some github actions 
 i'm sure there's something for 
 circle ci and dra uh what is it 
 oh my gosh jenkins 
 and other continuous integration tools 
 uh 
 but i saw a github action for lighthouse 
 scores and the developer in in me kind 
 of uh 
 cringed for a second at that because i 
 was thinking like hey there might 
 there's some product owner somewhere who 
 is saying 
 if we don't hit these scores 
 uh the issue is not done or something 
 and so there's some developer just 
 sweating trying to get like one point in 
 their 
 uh 
 in their lighthouse score somewhere but 
 it can be a really useful tool so that's 
 something that i want to look into for 
 sure 
 yeah and actually the uh the web vitals 
 javascript library is new in in coreway 
 vitals with i think it's like 8.4 that's 
 coming out 
 so 
 so that might actually add a lot to some 
 of these continuous integration 
 pipelines as well 
 yeah that's cool yeah i can see that 
 being really beneficial i've heard of 
 teams having 
 uh what they refer to as a performance 
 budget you know they say like this is 
 this page which it has a lot of media 
 and a lot of interaction whatever we 
 know we're not going to get a hundred 
 percent because you know uh it has this 
 virtual map where users can pan around 
 it has to load a lot of resources so 
 like due to the nature of the page maybe 
 we can't get 100 but our performance 
 budget for this page 
 is 85 or whatever they've determined 
 right and then as the um 
 website you know 
 changes and evolves over time you know 
 they could do something like this ci 
 pipeline thing where they run an audit 
 and to say whatever changes are made to 
 the page if we're 85 and below 
 great you know let that go to production 
 that's fine otherwise it would flag 
 somebody if it's less than that you know 
 they'd flag it and say all right what's 
 being done is this a mission critical 
 feature that's going to push it below 
 our performance budget 
 and at that point they could choose to 
 reevaluate and maybe lower it if it's 
 worth you know the feature they're 
 implementing is is worth it for end 
 users or otherwise maybe optimize 
 something and fix it the other thing 
 i'll bring up is some of that automation 
 that you can could do around lighthouse 
 scores is actually good for 
 um not just ongoing maintenance and 
 stuff but just uh 
 lots of people will build a site and 
 then they optimize it 
 when that site is released and then they 
 don't think about it ever again 
 and maybe that's they had a 99 on day 
 one and now you know things have changed 
 in how the metrics are calculated 
 or that some dynamic content has 
 uh 
 you know 
 brought down your score a little bit 
 maybe somebody uploaded a really large 
 image or a video or whatever 
 um right so it's good to to have some 
 automation around lighthouse scores or 
 at least routinely 
 uh check your lighthouse scores 
 yep absolutely 
 yeah so next we'll talk about how to fix 
 these issues and core web vitals are so 
 um all-encompassing 
 uh many of them like there are there are 
 lots of different performance gains that 
 you could that you could get lots of 
 different um techniques you could employ 
 to achieve you know better performance 
 that ultimately results in these you 
 know metrics um going up yourself 
 getting a higher score but we've put 
 together a list here we think are are 
 some of the the most valuable or the 
 most common you know ones that you get a 
 lot of bang for your buck for so to 
 speak if you were to implement these 
 um so the first one we'll dive into is 
 having 
 your scripts any external scripts that 
 your page may load in doing that 
 asynchronously um so you can um 
 you can apply either async or defer 
 attributes on on scripts to enable this 
 uh in the 
 in the olden days um 
 several years ago it was common to just 
 like throw your scripts any blocking 
 scripts you just throw in the footer you 
 know so your user because because it 
 would execute things and render things 
 top down you know you know that well at 
 least the user has the above the fold 
 content they can see that at least and 
 if my you know page gets blocked um in 
 the footer while it's loading some 
 external script no big deal because 
 they're not there yet right 
 but these days thankfully we have even 
 more elegant ways of doing that where 
 you can you can have your script tags 
 even you know at the top of the page 
 like in the head where they probably 
 should belong but if you tack on either 
 async or defer attributes that tells the 
 browser don't wait for this don't make 
 it render blocking instead continue 
 processing the page and you can do this 
 you know when there are cpu cycles 
 available to to 
 get it yeah those attributes are 
 actually are really nice uh for me 
 because i know that 
 i always want to go and look in the head 
 to find your css links or your script 
 links or something and if you if they're 
 like embedded in the 
 uh 
 you know bottom of the body somewhere it 
 can be difficult to find them 
 absolutely yep so 
 you'll see this if you run a lighthouse 
 audit you know a very common thing to 
 see there is um remove render blocking 
 uh scripts or render blocking styles and 
 that's what it's referring to i mean 
 something is you know preventing the 
 browser from rendering the rest of the 
 page so you need to address that somehow 
 next one we had on here is bundle size 
 and this one 
 well as your suggestion we include many 
 of these are provided by modern 
 frameworks so what do they give us yeah 
 so 
 uh you know bundle size when when we say 
 bundle size we mean uh not just your js 
 bundle but any html or css now some of 
 the modern frameworks that's all those 
 things are kind of in one 
 but there are frameworks that still have 
 separate html from your javascript from 
 your css um i think now it's it's still 
 pretty common to see css separate from 
 uh from your javascript but generally 
 you want to reduce your bundle size and 
 given that you have multiple your your 
 site is going to have multiple pages 
 maybe not every page needs 
 all of the javascript that you have for 
 your whole site 
 so 
 modern frameworks and build tools like 
 you know webpack or 
 or different build tools can take 
 advantage of 
 two 
 main things there's code splitting and 
 that is understanding what javascript is 
 needed for 
 each page 
 this 
 frameworks like next js and gatsby 
 those are very good at allowing you to 
 do code splitting because you are 
 building the individual pages that does 
 not mean it's impossible to do that with 
 uh without those tools but they make it 
 easier 
 uh the other thing is tree shaking so 
 uh say you're using a library like 
 lowdash or 
 um or even you know 
 material ui right a large 
 component library 
 you want to be sure that you 
 only uh your final bundle size only 
 includes the code that you're using out 
 of those libraries and tree shaking has 
 come a long way 
 uh and now it's pretty much built into 
 the modern build stack 
 that people use but that is a big deal 
 you want to make sure that like just 
 because you're including 
 one function from a dependency doesn't 
 mean you have to include the entire 
 dependency 
 um 
 and then yeah and in the future uh 
 frameworks are coming out with a lot of 
 different concepts like the react we've 
 talked about this plenty of times on 
 this podcast 
 up to this point but react server 
 components just being able to define hey 
 this javascript is only used on the 
 server versus the front end 
 uh will be a huge a huge 
 thing going forward 
 with respect to bundle size but yeah all 
 of that is uh you can think like 
 there you gain two advantages out of 
 making a smaller bundle 
 one is it is quicker to get the data 
 from your server to your front end and 
 actually i guess three advantages 
 your users do not have to download as 
 much data 
 but the second one is 
 a browser can process your content 
 faster if it's smaller so it's it's 
 pretty 
 you know 
 pretty much a no-brainer there but but 
 yeah you want to be taking advantage of 
 all the latest and greatest tools for 
 optimizing your bundle size 
 yeah and i would say 
 for me this is one of the big 
 differentiators uh between 
 traditional monolithic wordpress 
 and choosing to decouple your friend 
 from your backend and going for a 
 headless wordpress approach 
 um i've for years and years i had 
 written traditional monolithic wordpress 
 sites and 
 um 
 and just know from being in that world 
 that there's this separation between you 
 know the theme api where you're doing 
 all of your templating you know where 
 that lives 
 and then where your styles live 
 typically you have like sas partials 
 in one part of the code base and then 
 separate from that you might have 
 javascript and 
 what's typically done is a build tool is 
 used to 
 concatenate and minify 
 you know a single css file that provides 
 the styles for your whole site 
 and likewise a single javascript file 
 that provides the interactivity for your 
 whole site you ship both of those down 
 whether or not the user actually needs 
 all of those tiles and all of those js 
 for the current route that they happen 
 to be on 
 and that's not entirely true you there 
 are ways of breaking it up you you know 
 if you know for certain that some 
 javascript is only needed for a 
 particular page on the on the site then 
 certainly you could have your ability to 
 break that out and then enqueue that 
 javascript file on only the page that's 
 you know that the page in question 
 uh but that that kind of you know 
 splitting out um you have to do manually 
 you have to do yourself you have to look 
 at where is this thing used what 
 templates being used where's the 
 javascript now i'm going to manually 
 tell the build tool to split out this 
 code and only load it on a certain page 
 so that kind of stuff that's what you 
 get for free with a lot of these modern 
 frameworks and the reason for that is 
 they're 
 they know where everything is being used 
 you know so if i'm using some component 
 based framework 
 uh in a component i'll have the markup 
 that it outputs uh the javascript code 
 that provides any interactivity there as 
 well 
 and then if i have 
 some kind of scoped css so if i'm 
 importing this the sas you know file 
 right right in that 
 same file or i'm using styled components 
 or emotion some css and js solution or 
 css modules whatever your you know 
 choice of styling is if it's scoped to 
 that component now all of a sudden my 
 build tool knows exactly you know which 
 pages that component belongs to it can 
 trace the whole component tree 
 so the end result is it can build these 
 very optimized bundles it knows if 
 somebody hits the slash about page 
 that person needs exactly you know this 
 um this javascript exactly these styles 
 for the the route that they're on if 
 they go somewhere else 
 then you know more requests would be 
 fired off to get the css gs for the next 
 page that they that they go to 
 so some of these um 
 some of these 
 uh 
 you know criticisms or or um 
 problems that you'll encounter when you 
 run lighthouse audits for you know 
 shipping more css than is needed for the 
 current page or js that is needed for 
 the current page um 
 can you know be alleviated or mitigated 
 in a lot of cases by some modern 
 frameworks 
 yeah so something specific or like a 
 concept that uh some of these modern 
 frameworks like a tailwind um 
 implement is uh like atomic css or i 
 think it's also called just in time for 
 css 
 um so for styling so that 
 that lets you 
 rather than the concept of 
 i have all this css now let me purge it 
 uh you know and like come up with a list 
 of unused classes that i purge 
 uh just in time css flips that around 
 and says i'm going to write my css and 
 then actually generate 
 uh based on or write my styles and 
 generate based on only the styles that 
 i've written so it saves a lot of 
 headache there but 
 the caveat with all with css in general 
 is if you are using something like a lot 
 of our viewers are building headless 
 wordpress sites uh wordpress has dynamic 
 content and you need to be careful 
 and make sure that you are going to 
 um 
 now you're going to ship all of this 
 using something like yeah all the styles 
 you need to be careful if you're using 
 something like a purge css 
 yeah so like uh like gutenberg content 
 would be a good example right you you 
 would want to make sure that you're 
 shipping all the um styles necessary to 
 style all you know possible gutenberg 
 blocks on every blog post page for 
 instance even though you know even 
 though 100 of the styles might not be 
 used on this particular blog post page 
 you know that's okay but 
 because that content can change from 
 page to page and you know that you'll 
 have the styles you know required for a 
 certain page you can kind of 
 yeah prune things down pretty 
 pretty closely even still 
 yeah so um 
 we should mention also we've done a 
 separate um episode on the podcast 
 called styling on the modern web that 
 was just two or three episodes ago i 
 believe so be sure to check that out if 
 you want more of a deep dive into like 
 how to optimize some of the styles 
 next up we have images 
 and there's 
 a lot there images are huge on the web 
 of course and 
 can be optimized like in a number of 
 ways 
 so one of the ones i want to talk about 
 first is serving responsive images so 
 wordpress just added support maybe five 
 years ago or so 
 four or five years ago for responsive 
 images using the source set attribute 
 src sec it used to be um if you included 
 like an inline image in your wordpress 
 blog post there would just be an image 
 tag with um 
 you know that pointed to a single 
 jpeg or single ping or whatever else and 
 every user who viewed that image you 
 know their browser would just obey that 
 image tag and get the image from uh the 
 the source you know url that was 
 specified there um 
 but with the advent of mobile devices in 
 particular that's very inefficient 
 because if a user is on a smartphone 
 with a very small screen 
 you know and your and your uh source 
 attribute for your image is pointing to 
 this image that's huge it's meant for 40 
 inch you know desktop monitors there's a 
 lot of inefficiency there right that 
 person doesn't need an image that that 
 big for their device so the web has 
 evolved since then and um now there's a 
 source set attribute on image tags where 
 you can specify 
 uh different versions of that image 
 depending on uh the widths 
 of the device that the browser that the 
 user is on so wordpress core you know 
 provides that the sourceset attribute 
 now 
 and as our listeners likely know 
 wordpress also whenever you add images 
 to the media library it will generate 
 different sizes of that image for you 
 that can be you know served up um for 
 different purposes the thumbnail 
 small medium large and so on so it's 
 possible to leverage all of those all 
 that functionality in uh the headless 
 decoupled world as well so you can query 
 for your image and get not only its 
 source but all of its 
 source set data all of its alternate 
 sizes and the urls to the other sizes 
 and then on your in your front end 
 application you can 
 build up that image tag providing all 
 those other sizes as well so that 
 results in 
 uh very quick 
 loads for images particularly on mobile 
 as i mentioned where you only need a 
 small image in many 
 cases uh next on the list is uh lazy 
 loading um 
 so you know rather than loading images 
 uh 
 initially and when the page first loads 
 you know deferring that and doing it 
 later and it's even come natively to 
 uh some browsers at this point so like 
 will have you have you ever used this 
 the native laser loading 
 uh i have yeah i've used it a little bit 
 i 
 i think that the crazy thing to me is 
 now like browsers are supporting this 
 out of the box which is really amazing 
 but 
 uh one thing i think about with lazy 
 loading is there 
 it's not like a set it and forget it 
 kind of thing because when it comes to 
 optimizing your website you might think 
 oh i'll just load all of my images uh 
 lazy and then it'll be fine but 
 what that might degrade your user 
 experience because your user wants to 
 see you know if the image is part of the 
 interactivity of your website uh your 
 user wants to see that quickly it 
 doesn't want to you know the image get 
 deprioritized in the queue of uh 
 assets that are loading 
 so uh that especially comes into play 
 with largest contentful paint if you 
 have a huge image 
 that you want to uh 
 try to optimize by saying load this you 
 know lazy load this and then it gets 
 move pushed down to the bottom of the 
 queue it has to wait for all those 
 assets to load and then your image loads 
 and meanwhile um you know 
 search engines like google or your rank 
 on uh 
 lighthouse or your score on lighthouse 
 can get degraded because it'll take that 
 much longer for the largest contentful 
 paint to happen 
 yeah so good tip there so this might be 
 valuable you know if you had a 
 um slider of like you might also like 
 products or something that was like 
 further down down the page or something 
 something like that you know that's not 
 the largest part of the page that the 
 user is interested in seeing it's more 
 of a you know supplementary data right 
 that's further down the page and you 
 could likely you know lazy load those 
 images without um 
 without you know incurring any issues in 
 fact it would help performance because 
 you wouldn't have to load them 
 um when the page first loads 
 yeah so i think generally you would want 
 to avoid certainly any above the fold 
 content 
 you want to think twice 
 before i'm not saying you shouldn't lazy 
 load images on above the full content 
 but you might want to think twice before 
 you do that 
 and also any large images on your page 
 you 
 you might want to 
 see if you should lazy load them or not 
 and how it affects your largest 
 contentful paint score yeah 
 yeah so for years it's been possible to 
 lazy load images 
 manually with some javascript you know 
 so you'd have to use intersection 
 observer to figure out 
 you know where the user had navigated on 
 your on your site or or what part of the 
 viewport was in in view 
 and then when an image was about to come 
 into interview then you'd have some 
 javascript to fetch the image and then 
 insert it um but now 
 chrome you know they're the first ones 
 to implement a native lazy loading as we 
 said so it's possible now for 
 images and even other elements actually 
 like iframes you can do this with as 
 well you can specify a 
 loading equals lazy attribute and it'll 
 tell the browser to do that for you so 
 no more custom javascript it'll just 
 figure out you know what what um images 
 are currently in view and what images 
 are about to be in view if the user 
 scrolling and it will you know fire out 
 that request to fetch the image for you 
 now uh as of the day this recording 
 that's not in all browsers though like 
 safari doesn't still have support and i 
 believe it's like partially implemented 
 in firefox 
 right now 
 next up on the list we had um 
 uh having placeholder images uh for for 
 some elements on the page and then 
 replacing those with the 
 you know the image or maybe you have a 
 low res version of an image you swap out 
 for a hi-res version 
 yeah so something to be really cognizant 
 of with images and and even in videos 
 uh 
 stuff that can take a little bit of time 
 to load because maybe you have larger 
 files or or something like that that can 
 affect your cumulative layout shift 
 significantly as well so 
 uh so you want to 
 if you are loading a lot of images you 
 want to load not only you know you can 
 load placeholder images that might be 
 low res so they can load faster and then 
 you can back fill them with the images 
 but you also want to be sure that you 
 loading your images does not 
 cause a jerky loading 
 layout shift in your site so with that 
 you you want to know ahead of time 
 what the size of the images you know 
 aspect ratio and length and width or 
 width and height of your image on your 
 page and make sure you 
 have a placeholder for that amount of 
 space on your page so you don't get that 
 layout shift 
 yep yeah and this is another one where 
 it's been possible to do this for for 
 years i think it was is popularized i 
 think by facebook was one of the 
 the um 
 you know first 
 uh big sites out there i think to serve 
 the low-res placeholder images that 
 would then get swapped out for the 
 high-res ones and then a lot of other 
 folks on the web um followed suit and i 
 think gatsby is one of the frameworks 
 that really popularized this and made it 
 very easy you know they had they came 
 out with an image component and just 
 said you know if you use 
 uh their image component and point it to 
 where your image lived it would take 
 care of running it through its um sharp 
 library that it has to generate a low 
 res image of that 
 and save that 
 with your project 
 and it would it would in line that i 
 think it's like a base64 encoded image 
 that's just right in the body of your 
 html so it doesn't even take a network 
 request actually it's just like 
 you know an inline image uh right in 
 your content and then they would guess 
 who would take care of swapping that out 
 for the actual high-res image that also 
 lives in your project elsewhere but it's 
 just so you know 
 so darn easy to do that i think a lot of 
 gasby projects you know benefited from 
 from having that make the easy thing or 
 make the right thing the easy thing kind 
 of you know method that i guess you 
 brought with with their image component 
 and now nextgs has followed suit as as 
 well they have a 
 image component 
 themselves it does similar 
 things 
 um external services let's talk about 
 those so cloud and airy is the one that 
 comes to mind for me as probably the 
 most 
 popular one out there 
 but they're an option as well for 
 optimizing images on your site 
 cloudinary does some very cool things 
 like it can generate different image 
 sizes on the fly so even if even if 
 you've uploaded a certain size 
 to cloudnary if it sees a request has 
 come in and in the request it's asking 
 for a different size of that image 
 it will on the in milliseconds it'll you 
 know generate that new size your your 
 your um requesting and then serve that 
 up uh so in your web app it makes it 
 very easy to 
 have multiple sizes without manually 
 generating those yourself 
 yeah cloudflare can also do this and 
 there are there are a few other tools 
 that can help optimize images and 
 actually next 
 uh can plug into those so if you're 
 using next image components you don't 
 have to rely on next itself to do the 
 image optimization you can point it to 
 cloudnary or cloudflare or or these 
 other tools to say hey that's where my 
 image optimization is happening so that 
 helps a lot if you 
 are trying to serve files over a cdn and 
 you want to integrate with that um you 
 know like a cloudflare nice 
 yeah so in addition to the um 
 the automatic resizing and serving um 
 sizes uh cloudinary um from what i've 
 heard does an excellent job with 
 optimizing images 
 as as well so they'll strip out any any 
 meta data any extraneous things that 
 might you know bloat the size of images 
 now they'll strip those out to make them 
 very small which is helpful for 
 performance and not only that but 
 they'll serve 
 the images that are appropriate for the 
 user's browser 
 so what that means is if your original 
 image was a jpeg let's say they'll 
 generate a webp 
 version of that perhaps or a new format 
 um on the scene is avif it's you know 
 gaining support and is becoming more 
 more well supported on the web so 
 cloudinary when a request comes in they 
 can actually take a look at the user 
 agent to know oh this user is on this 
 type of browser it supports webp i'm 
 going to serve up that version rather 
 than my jpeg version because i know it's 
 you know 60 
 reduction 
 in the size or whatever else so 
 yeah i get several several gains if you 
 go for a service like that 
 yes so along those lines you mentioned 
 different formants formats like avif and 
 webp 
 uh 
 there are multiple different formats of 
 images the standard ones that people use 
 in browsers are like svgs pngs jpegs and 
 then webp is on top of a jpeg or a png 
 and then there's the new avif format 
 something i'll say is that 
 you might i mean i'm not an 
 image expert i'm not a graphic designer 
 like i don't i don't follow 
 um a lot of that stuff but i will say 
 that 
 don't just think that hey you can create 
 a webp on your own and it's going to be 
 it's always going to be smaller than 
 your underlying png or jpeg that's not 
 always the case it depends on how it's 
 configured same thing goes with jpegs 
 versus pngs 
 uh you know a jpeg is not always going 
 to be a smaller version of the same png 
 so you have to optimize for uh for the 
 image that you're showing and then also 
 with svgs 
 don't just go and turn everything into 
 an svg svgs are particularly good at 
 certain kinds of vector graphics and not 
 not necessarily pictures 
 right 
 yep absolutely 
 uh so that was a lot um on images and 
 there's it's a whole world you know of 
 um how to optimize images but i think we 
 hit some of the highlights there next we 
 want to talk about um 
 dynamic imports in javascript uh this 
 would be another option we talked about 
 um code splitting tree shaking things 
 like that to to limit you know the 
 amount of javascript that gets served 
 um on page load uh but another option 
 that you would have is just to strip 
 things out you know so that they don't 
 appear 
 in that bundle on 
 on the initial load but rather they're 
 imported dynamically um so that could be 
 you know if the user 
 um interacts with the page in some way 
 and hits a button that says like 
 you know 
 this it says 
 that they want um a map to pop up or 
 something like that you know what you 
 could do is when they click that button 
 you could just dynamically import the 
 javascript necessary to power that map 
 and now all of a sudden they have it but 
 you didn't have to pay that cost you 
 know on the initial page load because 
 maybe from your research you figured out 
 90 90 plus percent of users don't click 
 that button and don't need the 
 javascript for that map but for those 
 other you know 10 who may click the 
 button no problem we'll you know fetch 
 that uh javascript needed for that 
 particular um resource or particular 
 feature on the fly you know when it's 
 when it's needed 
 um so you can just 
 google that dynamic imports other 
 different ways of doing that depending 
 on your 
 build tools and frameworks and so on but 
 it can be really helpful 
 how about um pre-fetching have you done 
 much of this 
 well with lynx uh 
 yes so 
 a long time ago like five years ago or 
 so i i built my own 
 pre-fetching tool to for a framework 
 that i was using 
 and it was 
 a little bit cumbersome 
 say now some of these modern frameworks 
 like next.js 
 and gatsby they make prefetching a lot 
 nicer so 
 what we mean by prefetching is if you 
 load a page 
 and then your mouse kind of hovers near 
 a link 
 then you might want to go and pre-fetch 
 all the resources you need to get to 
 that link so you can keep 
 uh the user client side and immediately 
 just pop that 
 new page in there without having any 
 delay at all 
 and next and gatsby and someone you know 
 many of the front end frameworks are 
 really good at doing that for you now 
 and even allowing you to configure which 
 uh which urls should be pre-fetched yep 
 yeah and it's not free right this is 
 another one where you need you need you 
 need to be careful you could just say 
 like well if it's faster i would just 
 prefetch every single link that's 
 everywhere on my site right but if you 
 have 100 links then their browser is 
 going to be the main thread that the 
 browser is going to be very busy 
 grabbing all of those you know 
 prefetching all of those pages so i 
 would say you know just just be mindful 
 like when you use this it is a huge 
 performance 
 booster you know and maybe if when users 
 come to your site 
 if you know 80 90 of them all go to the 
 shop page since it's an e-commerce site 
 you're pre-fetching that you know if 
 someone's on your home page prefetching 
 the shop page so that when they 
 most likely do click that link they get 
 a nice immediate cut over to shop i 
 think something like that would be 
 appropriate um but not doing it like i 
 said every link under the sun 
 yeah you want to be careful because say 
 you have a sidebar 
 you know maybe you're doing a 
 documentation page or something you have 
 a sidebar that has a tree of all of the 
 pages that you can go visit on your site 
 you might not want to prefetch every 
 single one of those pages when a user 
 comes to one of them right so uh so yeah 
 you need it a good balance definitely 
 pre-fetching things that are within the 
 main content 
 uh that somebody might be viewing on 
 your site that's that's more where you 
 might want to do some pre-fetching yeah 
 yeah so you can prefetch 
 at different times so like what i was 
 referring to with the shop um link 
 example that would be like on page load 
 you could just say when the page is done 
 and things are idle at that point 
 prefetch the shop page because they'll 
 probably go there and when they do will 
 have a nice you know instantaneous cut 
 over there i will describe another 
 option though and that is like you can 
 do it on hover 
 i've seen some some statistics that that 
 say 
 users who are are using a mouse or a 
 track pad that they will actually hover 
 over a link 
 something like 300 or 400 milliseconds 
 before they 
 you know before the on click event 
 happens so what you could do is as well 
 described you could just listen for you 
 know when that hover happens start 
 prefetching the page then so that when 
 they actually do click maybe you're 
 halfway through you know uh the the 
 request so it just feels like it feels 
 like a quicker one that would be an 
 example of um 
 of perceived performance right it may be 
 that your server isn't responding 
 quicker than it was 
 yesterday right but because you have 
 this on hover effect that just starts 
 fetching the pages a little bit quicker 
 it just feels a bit more snappy to the 
 user 
 yeah the uh 
 when it comes to core web vitals some of 
 the the pre-fetching stuff doesn't 
 really 
 apply to some of these core vital scores 
 in fact sometimes it can cause them to 
 go down not not particularly the core 
 web vitals but things like server 
 response time can go down because uh if 
 your prefetch requests end up 
 in um you know in the queue above other 
 assets on your page you want to avoid 
 those kinds of things 
 so the hover 
 effect works or saying hey you know load 
 this on some delay so after my content 
 has actually loaded that's when i want 
 to prefetch all those things are 
 important to take into account but yeah 
 you weren't 
 you you know just simply pre-fetching 
 assets and 
 uh and 
 html and maybe some scripts that's not 
 necessarily going to bump up your core 
 web vital score or your lighthouse score 
 it's it's something that you want to do 
 for user experience and for general you 
 know usability of your site and 
 perceived performance but 
 it doesn't necessarily at 
 this time at the time of this recording 
 does not necessarily affect your 
 lighthouse score 
 and for folks listening who you know 
 maybe you maintain or work on some 
 traditional monolithic wordpress sites 
 um there's a great plug-in called flying 
 pages 
 you can turn on and it allows you to 
 have control over what gets pre-fetched 
 and 
 adds a nice 
 nice prefetching effects for nice uh 
 transitions between 
 um 
 traditional monolithic wordpress sites 
 or otherwise many of the frameworks 
 we've talked about in the headless 
 environment would you know as will said 
 allow you to easily add this as well 
 so pre-fetching that's where you grab 
 the html document of that next page that 
 you're interested in loading ahead of 
 time and there's such a thing as 
 pre-loading as well so you do a similar 
 thing but just for different types of 
 assets 
 so if there's like a font or an audio 
 file or video file you know that you're 
 going to need very soon um for based on 
 something users about to do if you know 
 ahead of time you know you're going to 
 do that there's an option there as well 
 you can preload those so that they're 
 available 
 another one i want to plug real quick 
 just because the library i like a lot i 
 think it's cool is 
 this library by paul irish it's called 
 light youtube embed 
 this one i think is really cool because 
 it's nearly indistinguishable from an 
 from a you know traditional um embedded 
 youtube video 
 uh but it just 
 lazy it just um loads the 
 uh youtube iframe on demand 
 is what it does so so the uh traditional 
 youtube embed what it does is it has an 
 iframe where it loads you know the 
 actual video into your page and you pay 
 a performance cost for that 
 and all the user sees is 
 the image of the video with a play icon 
 in the middle 
 so this library i i use on 
 some projects as a replacement for that 
 because the user on the page sees the 
 same thing they see the video thumbnail 
 with a play icon in the middle 
 it looks exactly the same 
 but the actual iframe the video hasn't 
 been loaded yet it's only when they 
 click somewhere on it 
 it um on the fly you know well at that 
 point fetch the ifry iframe and then 
 swap out the image with this iframe to 
 play the actual video so 
 so libraries like that are cool just for 
 getting some you know quick wins when 
 you have 
 embedded assets and um 
 i want to speed things up 
 another service um 
 i've heard of folks getting some 
 gains from getting some mileage out of 
 is polyfill.io 
 um i think this is less relevant these 
 days where we have these evergreen 
 browsers that are releasing updates 
 constantly and the amount of polyfills 
 that you have to include in your 
 projects i think is getting less and 
 less and less compared to a few years 
 ago 
 something i will say is that 
 yes safari uh 
 is kind of the one nowadays a little bit 
 behind the time so 
 uh so polyfills are still needed but 
 yeah it feels like with the 
 uh 
 you know 
 end of support for ie 11 yeah and now 
 we're all on evergreen browsers 
 it's becoming less and less 
 necessary to focus on 
 polyfills and that's for javascript 
 uh and css css polyfills are a little 
 bit less necessary now yeah 
 yeah so this service polyfill.io is a 
 cool one you might want to look at um i 
 believe it's an open source uh service 
 that you can use and what it does is um 
 it detects uh what browser the user is 
 running based on their user agent and it 
 would serve to that person only the 
 polyfills that they need 
 so if the person is running like the you 
 know latest and greatest google chrome 
 for example 
 they'll get next to no polyfills since 
 that browser would be very up to date 
 otherwise if they're you know running a 
 version of 
 samsung browser that they haven't 
 updated in 
 two years or whatever else it may you 
 know the service may ship down but the 
 polyfills that that user would need so 
 the cool thing there is you don't have 
 to include them um in your code in your 
 bundle you have to serve these to all 
 users some of them actually don't need 
 them so 
 so search allows you to um to only serve 
 polyfills to users who are going to need 
 them which is cool 
 all right um next time i talk about 
 content visibility this is one that only 
 came across my radar 
 within the last year i think i think 
 it's a relatively new 
 addition to browsers um and also we 
 should mention for browser support i 
 don't think it's supported in all 
 browsers yet either 
 but what this is is a it's a content 
 visibility attribute that you can apply 
 to some kind of a container you know 
 like a div on your page 
 it's a way of telling the browser 
 not to calculate the layout 
 of anything inside of this container 
 ahead of time 
 and 
 it can result in better performance 
 when you do that so again like we've 
 said several times this one you want to 
 be careful with in css it's possible to 
 do 
 lots of things on the web right if i 
 have a div and something is inside of 
 that 
 it may not look like it's inside of that 
 right i may be using position 
 absolute or position fixed and putting 
 it somewhere else on the page so 
 browsers have to do a lot of 
 fancy footwork to figure out where 
 things are actually positioned 
 you know because uh it may not be how 
 they're represented in in the html 
 and also with the advent of css grid 
 that's another one right you can make it 
 so that the item that's fifth down on 
 the list actually looks like it's the 
 first right because you've in css you've 
 positioned at the top so because of 
 those things what the browser typically 
 does is it will figure out 
 all of the layout for the entire page 
 and then it's actually able to start 
 painting 
 the page and that's what the user 
 actually sees so with this content 
 visibility um 
 utility here it's possible to tell the 
 browser 
 i know that the content inside of this 
 particular div you know none of it is is 
 going to be going to be displayed fixed 
 or absolute or it somewhere outside of 
 this i know all of it is you know going 
 to be encapsulated within this and i'm 
 just going to save you the work of doing 
 of calculating the layout you know ahead 
 of time so don't worry about doing it 
 now you can do this when the user's 
 about to scroll it into view you know 
 you can defer that work until later 
 and that depending on your your site and 
 what content is there you can get um 
 some some significant performance gains 
 out of that 
 yeah i mean this is it there's a concept 
 for this on uh 
 ios and i believe on android 2 that apps 
 take advantage of it and actually it's 
 inherently built into the language that 
 uh ios uses to build your applications 
 so that's 
 uh it's nice that that's kind of being 
 brought to the web and it actually makes 
 me think a lot about how people have for 
 a few years done like virtualization so 
 like infinite scrolling on lists and 
 things like that where 
 uh content visibility is a little bit 
 different but it basically takes that 
 concept of virtualization 
 and applies it to 
 you know it something you inform the 
 browser of right so 
 where in virtualization you don't even 
 put the html on the screen until the 
 right moment 
 content visibility allows you to put the 
 html there but inform the browser hey 
 don't worry about this until uh you know 
 it's 
 necessary 
 yep 
 yeah and i believe i missed book i said 
 it was an attribute it's actually a 
 css properties that you you would apply 
 to these elements 
 yeah um so check that out we'll include 
 the link in the show notes if you want 
 to see what that looks like and why you 
 might want to use it um the video is 
 kind of funny jake archibald from google 
 who does the video he uh he actually 
 takes like the official html 
 specification which is this like large 
 document on the web and he says you know 
 what could we do 
 how could we effect 
 affect the performance if we 
 applied you know content visibility 
 none to that 
 or kind of visibly hidden i believe it 
 is to that container what would it do to 
 performance and then runs an audit and 
 figures out like oh it's 
 500 times faster or whatever you know 
 because the browser no longer has to 
 calculate the layout 
 for all of these um all of these 
 elements on the page so 
 that's cool when you have your disposal 
 as well 
 um 
 next let's talk about uh tooling um so 
 uh 
 will mentioned um 
 a good point that we want to bring up on 
 this podcast and that is like next.js 
 which is of course a very popular 
 react-based meta framework um introduce 
 some linting rules right and they're 
 specific to performance on your site 
 yeah so i i'd say next.js 
 i think it was 11 but either 10 or 11 
 came out with this concept of lint rules 
 that they publish that are specifically 
 targeted at core web vitals 
 uh as well as just general you know next 
 usage and following best practices for 
 next usage this is 
 really awesome uh you know and if you're 
 building on the next project you should 
 totally be 
 taking advantage of this i'd say right 
 now they they're last i checked there 
 were only a handful of rules and 
 they basically do what you what a lot of 
 people are already doing when they're 
 building these sites uh however that 
 does 
 show a commitment to core web vitals and 
 and it's something that will only get 
 better over time so it's something that 
 would be good to start using now 
 yeah so um another one another 
 optimization that i i don't see people 
 in practice using but i just think it's 
 cool so i'm gonna throw it out there 
 anyways 
 uh and it could be helpful if you have 
 some some really computationally heavy 
 stuff going on your site that is 
 offloading work from the main thread to 
 web workers 
 so in the browser we have the main 
 thread and that's what's responsible for 
 all things related to 
 to layout in the browser and rendering 
 things to the screen that's what the 
 main thread handles 
 beyond that though it also responds to 
 two events that happen and you don't 
 want to tie up the main thread with too 
 much work because then you get kind of a 
 janky experience and lag you know the 
 first input delay and so on 
 would be affected if you 
 tie up the main main thread with with 
 too much work 
 so it's possible to offload that work to 
 uh something else you can have 
 another thread handle that so that would 
 be called a web worker 
 so a 
 uh i believe the dev advocate is his 
 title at google surma he created this 
 really neat library called com link and 
 it just puts like a really nice wrapper 
 around the web workers api in the 
 browser it makes it promise based so 
 what you can do in your javascript code 
 is if you have some computationally 
 heavy thing to do you can call comma 
 link and say here's my task let me know 
 when it's done and it'll return a 
 promise and then you can you know 
 respond to whenever the promise is 
 resolved then you'll know that work is 
 done and you'll you know get the data um 
 that it's sent back and so on so that 
 could be cool if you have any 
 computationally heavy things uh going on 
 i would say anything that has to do with 
 rendering content to the page don't do 
 this like leave that in the main thread 
 that's where it's four 
 but other things like uh number 
 crunching 
 um kind of work you could offload that 
 to another thread 
 yeah you can't do any ui the main thread 
 in javascript is the ui thread so you 
 can't do anything with the ui in your 
 worker threads uh 
 and i mean anyone who has done any 
 thread-based programming it operates 
 pretty similarly so you have a 
 a message that you can send back from 
 your web worker to get it get it back to 
 your main thread but yeah if you have 
 any the the worker thread is for io not 
 necessarily um 
 uh dom manipulation things 
 right yeah 
 yeah and i guess um 
 another thing you could do even these 
 days is wasm you could do web assembly 
 stuff if your app has some 
 some um 
 computationally heavy stuff to do you 
 could offload that to something more 
 performant like c plus plus or rust or 
 something and then get the response 
 that'd be another yet another option 
 beyond web workers even 
 yeah i'd say if you're for most of the 
 sites that are concerned about corway 
 vitals and things you might not go down 
 that path uh yeah that would be like the 
 last form of optimization 
 yep if uh if you've tried every other 
 thing because 
 there are so many other tools available 
 to you now to make some of this stuff 
 very easy 
 and um you know wasm is 
 still not very easy same with web 
 workers absolutely yeah 
 yeah so probably not advantageous to to 
 uh the average web developer but still 
 cool to know about i think 
 like one impressive case study is figma 
 my understanding is like they so it's an 
 in browser you know editing image 
 editing software that a lot of folks 
 know and love it's um 
 supposed to have a very good user 
 experience i don't have a ton of 
 experience using the web app but 
 supposed to have very good experience 
 and my understanding is all of the 
 image modification you know work that's 
 done that's all offloaded to 
 webassembly so that code is run it run 
 in something like like rust you know to 
 do all the 
 data intensive 
 modifications to images and then when 
 it's done 
 you know that um the webassembly will 
 respond and then javascript they render 
 the result to the screen so 
 for projects like that then it might 
 actually be worth it to you know 
 consider uh offloading this work so your 
 main thread isn't attempting to 
 you know render gigantic images and and 
 do uh computationally heavy things 
 um so with that uh we've gone through 
 what we wanted to in terms of 
 things to look at kind of tactics you 
 can take to 
 increase your core web vitals and get 
 really performant sites really good 
 scores 
 and you have a few closing things here 
 one is a case study so like will do you 
 want to talk for a second about android 
 authority 
 yeah so uh wp engine 
 recently released the atlas platform 
 and part of that is a you know it's 
 partly a node hosting platform and 
 android authority is one of the 
 uh early adopters of this platform and 
 android authority had a traditional 
 wordpress site and they have gone to 
 headless and they're on the atlas 
 platform and uh they noticed 
 you know obviously once they went 
 headless they did some optimus 
 optimizing and things but they noticed 
 that when they 
 moved just simply moving from 
 traditional wordpress to headless 
 wordpress gave them a huge jump in light 
 speed 
 uh in their light speed score in their 
 in their core web vitals in general 
 because they were able to take advantage 
 of some of these modern frameworks that 
 uh that have a lot of this baked in and 
 to me that speaks to how 
 there are 
 things you can optimizations you can 
 make in wordpress and wordpress has been 
 developed over years ever you know 
 there's always a plug-in that you can 
 install that can help you optimize your 
 performance in some way shape or form 
 and wordpress is focused on that and 
 even uh take it the other way i mean 
 google is focused on working with 
 wordpress to make sure that 
 um you know wordpress understands what 
 the future of core web vitals is 
 however 
 some of these modern frameworks are 
 very easy like quick to adapt to some of 
 these upcoming things in lighthouse 
 scores and and they're really moving the 
 needle in terms of user experience and 
 performance on websites 
 so taking advantage of 
 these modern tools 
 is is something that just without any 
 additional optimization on your own 
 today you can very easily increase your 
 lighthouse score 
 nice um and lastly we want to talk about 
 an upcoming event that wp engine has and 
 we're doing in conjunction with google 
 so what's that event all about 
 yeah so the the event is just going to 
 be a deep dive into core web vitals uh 
 wp engine is in partnership with google 
 so we're going to be 
 uh talking about that a lot and that 
 event will happen 
 after the recording of this podcast but 
 uh 
 once it's released it'll be happening 
 soon 
 very nice so stay tuned for that if 
 you're listening to this podcast episode 
 before that event happens 
 um otherwise just want to thank you for 
 listening thanks for tuning in to the 
 podcast and hearing us drone on about 
 all things performance and core web 
 vitals for this episode 
 uh well thanks for being on with me and 
 listeners we will catch you in the next 
 episode 
 [Music] 
 you