web.dev LIVE 2020: Day One

Key Takeaways

[Music] [Applause] [Music] hey there welcome to web dev live I'm deal now mayor and I work on the web developer ecosystem at Google and I'm delighted to kick off our online event first though I want to acknowledge the times we're in we're dealing with a global pandemic that has taken a huge toll on us all and most recently we witnessed two events which have once again surfaced the systemic racism in our society that we must do everything we can to eradicate you know these events have been really humbling they're showing us how much work we have ahead of us but they also show us the power of community so we join you today and over the next three days in the spirit of being together and helping each other because we were upset when we had to cancel Google i/o and I kept thinking about an empty Shoreline Amphitheatre on the days that some of us would have congregated a web developers reached out showing these same feelings wishing we could be discussing ideas and enjoying the hallway track whether you're joining us from your couch kitchen or hammock we hope you're safe and ready to kick web dev live into gear now we'll be coming to you in different time zones each day reaching you no matter where you are on the globe will be bringing you content from across our teams as well as members from their web community at large now each day you'll have Googlers on standby to answer your questions in real time so as you're watching the session simply head over to the live chat on web dev slash live or on YouTube and just ask away now when coronavirus became global we really felt the need to stabilize this resulted in a spawning chrome releases and temporarily rolling back the same site cookie changes now we wanted to track chrome usage and see what changed to make sure that we could be on top of any ecosystem changes too you probably won't be surprised that we saw surges in usage of meteor api's as video chat and streaming really soared now also some types of content so large traffic surges such as food commerce entertainment how of science etc and many developers will focus in on making sure these sites were as resilient as possible that's when we gathered our best practices and made them available on web dev slash Cove at 19 we saw a lot of developers scramble to make changes to their web sites and many created new ones governments had to jump on this to make sure the people had all of the critical information that was changing rapidly I remember seeing Alex Russell tweet about one of these government sites from the state of California we were really inspired with their work and wanted to ask them about their experience and they kindly agreed to join us so let's welcome Aaron Hines the engineering tech lead on the project thank you great to be here so Aaron I'm really curious about how this site even all came together the Alpha Todd ca.gov team was formed in December of 2019 by analytical work day to bring human centered design processes to the state of California and improve their online services we built a lot of prototypes for things like how to help people review the safety of their tap water and see if they're eligible for subsidized phone services and to prepare for wildfires and then when the pandemic at the state were asked to stand up the public response site tonight so when a government team has to build something like this like how do you go about it what do you all call principals the number one goal is to make something that works well for everybody and the technical considerations they're passing accessibility audits making sure it works with keyboard navigation with screen readers and that it has a smooth experience on low-end hardware we use the cheapest phone which we get from the local Cricket Wireless as our test device and the non-technical considerations are the readability what's the grade level of all the content and are we really building something that users need and iterating based on their feedback got it now I've been trying to picture the time pressure that you had here to get this site out he tell us a little bit about how you actually built the site and how you manage the trade-offs between quality and that time line sure it's definitely an accelerated timeline put the site up in four days and the announced a statewide lockdown and we had millions of visitors really happy that we chose a static site generator for that because it helped us whether the traffic smoothly we chose the Lebanese for the step static site generator and we augment that with web components and surveillance API is built on nodejs got it we're actually fans of eleventy - we use it on web dev and really like it was this kind of a new setup for the team to build a website like this or have you been doing this for a while I remember reading the article about how web dev was built and being really happy that we were using some of the same tools we started using 11d at the end of last year just to use it for a blog on Alfred on CA gov and when we used it for the Cova 19 site it's built on content authored in the WordPress environment and then we consume it with the WordPress API and use github actions from the 11 T production build got it so you know now you've got the site out there now I'm curious what's next fate for you and the team next things for the team are continuing to respond to the pandemic we're going to be getting back to helping improve other online services and we're hiring check us out at news that alpha dot ca.gov if you want to help out we're talking about eleven E and the other tools that we're using I wanted to mention that lighthouse is an incredibly important tool for us because performance is such a paramount concern and I love the way that it came affianced by development you can get the rest of your teammates challenged each other and say who can put up some more points today we really need to get that score up and I some I'm curious who who's winning on the points race and I've really impressed and how you know you think of like performance being a key part of the accessibility story in general wire and it's been really inspiring to see the work that the U and the team did here again at an incredibly stressful time thank you so much for coming on and sharing the story with us thank you now it's been great to see developers like Aaron focus on accessibility resilience and performance and we've made some announcements over the last month about a program that brings us all together under the umbrella of Web vitals to hit more let's welcome Elizabeth a p.m. on the chrome team to explain thanks Dan yeah there have been a lot of product updates and releases and I'm really excited to go over them with you yeah it's been particularly busy here over the past couple of months so be great to have you get us up to speed on webb vitals and what developers should be really considering here yep what's great let's Ivan first off what are our core web idols they are a set of user centric metrics and thresholds that apply to all web pages across all industry verticals and all types of experiences on the web they are signals to developers and business stakeholders about the basic health of your site and as such they should be measured by everybody but okay I jumped straight into definitions let's take a step back why did we introduce core what vitals as a thing there are already tons of metrics lots of guidance about how to measure your site's performance how do core web vitals help us well let's go back to our foundational goal we want to create outlandishly phenomenal experience for all of our users and it's not just out of the goodness of our hearts either we know that every time we have a rage clicker on our site we lose out on a reader a customer or a client also we want a money bug so there is this mythical absolutely fabulous experience that we've set our sights on creating it seems easy until you realize that the unicorn horn requires both loading and interactivity performance measurement and the rainbow well the rainbow requires an entire rum setup for each color so there you are watching your flying unison unicorn dachshund and you realize that you have this it's gorged on a bit too much JavaScript it doesn't respond when you're issuing it commands and that's upsetting but it's going to take quite a bit to get this to this so the question is where do you start well in order to know if you've improved we need to know what to measure to know what to measure we need to define our goals so put another way what makes a web experience shine this is where the core dimensions of quality come in there are foundational elements of a user experience that make a unison shine above the competition content needs to load quickly we've all been there the longer we have to wait the more likely we are to bail so your pages have to load fast interactivity is just as important you're clicking and nothing is happening no fun you don't just need content to be visible you need it to be available for use lastly we want a page to be stable and predictable just a few pixels moving around can make a huge difference these core dimensions of quality reflect user centric signals that have long been mission-critical for you and your site's success so we are closer to defining quality but how do we measure these quality dimensions and that's where representative metrics come in to represent fast-loading we have largest contentful paint or LCP it provides insight into how quickly a user is able to see the meat of what they are expecting and wanting out of a page for responsive interactivity we have first input delay or FID this metric has been a critical signal for developers for some time to understand how long a page takes to respond to a user's initial input and finally to represent visual stability we have cumulative layout shift CLS CLS measures the amount that the elements within the viewport move around during load time ok so we know how to measure our core quality dimensions and let's say my LCP is three seconds do I celebrate wait I don't actually have any idea whether or not that's good so I need to evaluate my performance on a spectrum for each metric which is where the final element of core web vitals comes in our thresholds for each representative metric we have clear goal posts around what constitutes a good experience one that needs improvement and one that's poor so for instance for LCP anything that is 2.5 seconds or less is on its way to being a unison anything between 2.5 and four seconds needs some work and anything above four seconds is needing quite a bit of love so to finish up our definition of what our core web vitals the initiative is a combination of three things first is user centric quality dimensions then we have representative metrics of those dimensions and finally thresholds to help you evaluate whether or not performance is good or not against any given metric but there is one more piece of really important information we need to know how many page loads need to hit the thresholds for the core web vitals metrics to constitute a good experience so say we have a hundred users if only one of them has an LCP below 2.5 seconds do I pass Korowai vitals the answer is no core web vitals uses the 75th percentile value of all page views in the field to evaluate against the thresholds in other words if at least 75% of page views to a site meet the good threshold the site is classified as having a good performance for that metric and this applies to all three metrics LCP vid and CLS the 75th percentile is used to evaluate all three poor way vitals is a holistic package of everything you need to create the foundation of a healthy site they are valuable because they show you exactly where to start to set yourself up for success if 75% of your users are getting fast interactive stable content its cause for celebration but as we know there are other dimensions of quality that are extremely important accessibility security mobile friendliness there are a lot of dimensions that make a basic unison even more fabulous and are important to your site's success so don't stop measuring these if you already are and if you aren't already once you've optimized your core web idols you can begin to venturing into measuring and benchmarking against other important vitals that are relevant to your business and your users core Web vitals are just as the name indicates they are core and provide you with a solid foundation upon which to further optimize given how important it is to quantify a user's experience accurately in order to be successful on the web we are constantly working to find ways to better measure all quality dimensions what this evolution has often meant in the past is a stream of new metrics tweaks to existing metrics and new guidance many times at an unpredictable cadence we know how difficult this can be when trying to set goals aligned roadmaps and good organizational buy-in because of this we want to set a predictable cadence of updates to Cora vitals they will be refreshed once a year around the time of Google i/o to ensure that they reflect the latest in our learnings and this includes adjustments to the set of metrics as well as the thresholds looking ahead towards 2021 we will be providing regular updates on future metric candidates motivations and implementation status okay so this is all fine and good but how do I get started to know whats optimized you have to measure first and Korowai vitals are now in all of your favorite developer tools and there are more than what is listed here including a new web vitals library and a bunch of ecosystem tools that have already adopted them as you can see core web vitals are available across the board you're able to measure them for a specific page for your origin locally in the lab and from real users in the field remember that first input delay is only measurable in the field so you have to have a real user clicking on your page in order to measure it but that doesn't mean you can't use lab tools to help you improve it total blocking time TBT is a proxy lab metric for fit that allows you to debug and improve your interactivity in the lab before you users ever have to experience a bad fit the next obvious question is again this is great but where do I start what tool should I use I'm so glad you asked each tool has its own strengths for example psi is one of the only places you can see your lab and field data in one place and search console is critical for identifying page types that need improvement as I mentioned earlier we're seeing so many great ecosystem players and production monitoring solutions already implementing support for core what vitals and we're really delighted but again you asked you've shown me the magical unison and now you've given me a pallet of tools to choose from that's amazing but tell me what to do first okay two things first go to PageSpeed insights that will give you a pulse of your core with vitals performance in both the field and the lab from crux you'll be able to see whether or not 75% of your loads are hitting the core with vitals thresholds for both your page and your origin in the field then you can take a look at your lab data from lighthouse to see whether or not you are hitting the core web vitals thresholds for each metric in a synthetic testing environment this helps to guide you towards actionable opportunities to improve your pages performance second check out some more in depth talks later today that go into detail about measuring and optimizing against your core what vitals and with that I'm gonna pass it back to Deon thank you so much great yeah thanks for showing us the context and all of the information across the whole slew of tools there Elizabeth my pleasure one of the critical steps in modern web development with a lot of influence over your vitals is your build step that's where your CSS modules are turned into real CSS your bundler analyzes your module graph and optimizations can really kick in we wanted to go deeper here to understand the popular bundlers how they work what they can and cannot do and how to set them up for success let's welcome Surma to tell us more hey Surma hey Deon so there are many best practices to follow in web development knowing them is one thing but getting your build system to follow them as well is kind of another beast so do you have anything - maybe rapport on that front so there's two bits on this side of things on the one hand there are many developers who want to know what build tool they should learn in to use for the next project and on the other hand there are many project that already have a build tool setup but are looking to improve their output to tackle both of these problems we build tooling report tooling report is a website that you can actually go to right now tooling report we create an extensive list of best practices in web development took what we think are the four most popular build tools and checked for each build tool if it allows you to follow that best practice and each tool gets a point for each test and it passes we chose to start this project with browserify parcel roll-up and web pack now browser if I might be surprising to some but the data indicates that there are still many sites out there that use browserify and we want to help those projects improve their sites as well of course we have been working with the core teams of all these tools to make sure that we're not only used a tool correctly but also represent them fairly the tests are subdivided into categories and in the overview you can get a quick sense of which tool is excelling at what category you can get more information on the test in the overview and learn more about it and now this is where I think tooling report gets really interesting each test has a dedicated page where you can compare how the tool score on this specific tests there is an in-depth explanation on why this test is important and how it relates to best practices and web development we also explain how we codify the best practice and what the expected outcome is and finally at the bottom you can find an explanation for each tool and writers past or why it might have failed this test if a tool is not passing a test we will also link to back reports on the tools issue tracker many of them we have actually filed ourselves while building tooling report we also link to a minimal NPM project that we use to determine the tools behavior this way Turing report not only tells you what a tool can and cannot do but you can also look at the configuration files and plugins to see how you can follow a best practice with this tool this way the site double functions as a source of documentation the entire site is open source on github and we'd love the community to help us come up with more tests and help us add modules over time so you can check this out now on tooling dot report thanks for joining me soma Cheers now we're all becoming more aware of the importance of security and privacy chrome believes in an open web that's respectful of users privacy and maintains key use cases that keeps the web working for everyone I'd love to welcome Rowan to have a chat and kind of share some of what's new here hey there thanks Deon my name is Ryan and I look after web dev rel for security privacy payments and identity or spy for now wow that's a cute internal name we are part of the wider trust and safety team within Chrome great so why don't we start with same site cookies and the temporary rollback that that kind of kicked into gear for us when kovat kind of really started to hit globally can you kind of share whether what the latest news is there sure yeah so hopefully as a lot of you are aware there's an update to the cookie standard that's being adopted across Chrome Firefox edge and others to restrict cookies to first party by default along with requiring explicitly marking cookies for third party contexts now that's all configured via the same site attribute hence same site cookies we were rolling this out to stable Chrome but decided reverse this at the start of April because the covert situation saw a huge jump in demand for online services but also a huge shift in developers being at home without their equipment or looking after their families we made the call that it was important to prioritize stability at that moment now these changes are intended to make the web a safer place protecting against cross-site request forgery and trying to minimize the surface for covert tracking sadly during a crisis when people are most vulnerable you see these kind of scams in the tax jump - so with the chrome 84 stable release which is mid-july or about two weeks from now if you're watching the stream we are gonna start rolling this out again across all chrome versions ok so what I'm hearing here is that if you haven't tested your site yet if you haven't made changes to kind of make sure that everything works well now is actually the time to get going absolutely so we have documentation and examples and samples out there right now forcing site on web dev as well as on chromium.org and we'll be covering implementation and debugging in our segment on day three okey doke so we all love cookies but I'm assuming there's going to be a few more things that we're going to be talking about in the kind of general view of trust and safety I'll be honest with you I am gonna talk about cookies a lot but the rest of the team does have a healthier range of interests okay sounds good so we're gonna cover things like you know back in 2018 Spector kind of raised its head and we as a web community started to really look at what can we do to help make sure that our users are secure are there gonna be kind of those type of aspects that will be covering - for sure yeah so age is gonna be taking us through some of the new cross-origin opener and embedder policies or a coop and co-op for short so like you were saying Specter was a vulnerability that in a super short summary meant that malicious code running in one browser process might be able to read any data associated with that process even if it's from a different origin and that is super bad now one of the mitigations that is site isolation or putting each site into a separate process AG's going to be running through how the headers allow sites to opt into that along with a bunch of other benefits that it brings as well got it got it got it okay so we've got restricting cross-site cookies and then we've got isolating sites to individual processes we've got this interest in evolution so I'm sensing there's kind of a bit of a theme here yeah there is definitely a theme so we've also got salmon mod on the team and they're gonna kick off our little segment to explain the link between these and really comes down to the web today is seeing this evolution of expectations regarding privacy that includes users expecting more transparency and control over their online data and new regulations impacting how data can be used and collected now at Google we believe in an open web that's respectful of the users privacy whilst also maintaining a healthy ecosystem so under the banner of the privacy sandbox we're introducing a number of standards proposals that aim to support the use cases that let people make their living off creating web content but do that in a way that better respects user privacy we're also actively seeking feedback on these proposals we're participating in all the open forums of the w3c to discuss our proposals as well as those submitted by other parties too okay so the web's evolving and we're getting new privacy-preserving api's coming in and we're getting rid of the old cross-site data leaking API so they're kind of moving out exactly and one of the ways I like to think about it with our team as well is that we're kind of all about the Prost places where you create relationships on the web so people should feel in control of their data when they browse around the web with a clear choice about what and where they share things and when they do want to create a relationship like signing into a site or making a purchase that should be simple secure and only share what's needed awesome thanks so much for the brain dump on what we're thinking about here in the realm of trust and safety ro and I'm really excited to see the content that's coming later on the stream from the team where we can kind of go into more of a deep dive cool and I'll see you around now the web has a great history as a content platform with its roots in hyperlinked documents but digital content has gotten richer and richer we think the web has a great role to play here too I'd like to invite Paul back out to talk about a new content type that we're really excited about called web stories hey Dion hey Paul so what are these web stories and why are we working on them my team and I have been hard at work working on web stories and I'm very excited to share some updates with you and yes I'm talking about these kind of stories you know fullscreen portray tapped advanced swipe to move on and if you like wait a second and you link to the show then you'd be right but these are not your stand-up walled garden stories current implementations focus on ephemerality and ultra low barrier to creation but our bet is that destroys format works beyond the ephemeral use case and can become its own pillar in the open web media landscape and that's because they're really cheaper to make them video and more engaging in a text article and really important web stories are different to all our stories many important ways just like a regular web page you own them you host them and very important you get the money from the ads not the platform serving stories because stories are really a visual format my friends at Google search and discover showcasing them in really cool ways telling me that many more integrations are coming later this year we think these can be a great net new traffic source for web creators these stories look visually really compelling but how hard is it actually to create them if you want the web to be able to compete with the closed platforms out there story creation needs to be as intuitive and fast for all content creators now lots of people are working on making web stores a thing but one of the things my own team is doing is bringing story creation to WordPress the most used CMS in the world in the form of a visual editor coming to you very soon kind of more about the beta at goog LD slash story editor you'll hopefully see all the basic editing features you would expect like smooth image and video handling text controls shake masking and so on but we're also working on some you might not expect like this one we call text magic running in real time against images from the unsplash API here target on this feature makes it so that the editor always ensures text is readable making dynamic decisions about groan line-height and so on I hope you like it as much as I do yeah it looks really cool you know I can't wait to read some of these stories on the web thanks so much for Fisher in there Paul and thanks again to Paul and everyone who took the time to join me as we kick off the event today yeah I'm really excited about the upcoming sessions starting with the focus on how to make your website hit its vitals and discovery through such now please enjoy the show remember the whole team is here to chat with you on web dev slash live and via YouTube I will see you there today and I'll be back tomorrow morning for the day to kick off [Music] [Applause] [Music] hello again everybody for those of you who don't know me yet my name is Elizabeth Sweeney and I'm a product manager on the web platform team in Chrome I'm excited to talk with you all today about the latest and greatest in our speed tooling I'll be sharing some updates as far as how we think about measuring user experience including metrics updates and our new core web idols initiative as well as making sure that we're privy to you know all of the newest features products and updates to our developer tooling as far as speed measurement is concerned so let's dive in well I know we've heard it before it is worth reiterating why metrics change well ultimately it's because our understanding of how to best measure user experience evolves over time as we learn more and work through technical hurdles we need to make sure that our metrics and tooling are updated to reflect the latest in our learnings fundamentally we view it as mission-critical to give you the most accurate and effective mechanisms by which to optimize your site's experience and help you achieve your goals and that doesn't just mean for one of your users or a few we want to make sure that as many users as possible regardless of what network they are on or what hardware they're using are in the bucket of users that want to come back to your site again and again and that brings us to the impetus behind court what vitals we have long been espousing performance and user experience quality because we believe that good site performance leads to better outcomes for users businesses developers and for the web in general the core vitals initiative aims to bring together a more cohesive picture of web performance so that there is a better shared understanding of what should be prioritized first let's take a moment to review the metrics themselves largest contentful paint LCP is a measurement of perceived loading experience it marks the point during page load when the primary or largest content element has loaded and is visible to the user within the viewport it's an important complement to first contentful paint FCP which only captures the very beginning of the loading experience LCP provides a signal about how quickly a user is actually able to see the content of the page to provide a good user experience sites should strive to have largest contentful paint occur within the first 2.5 seconds of the page starting to load to ensure you're hitting this target for most of your users a good threshold to measure is the 75th percentile of page floats segmented across mobile and desktop devices first input delay fi D measures the time from when a user first interact with the page so they're clicking on something tapping a button that kind of thing - the time when the browser is actually able to respond to that interaction to provide a good user experience for fid sites should strive to have a first input delay of less than 100 milliseconds to ensure you're hitting this target for most of your users a good threshold to measure again is the 75th percentile of page loads given that FID can only be measured in the field with real users we want to make sure that you have a way to locally debug and optimize fit in the lab that's where total blocking time TBT comes in TBT quantifies load responsiveness measuring the total amount of time when the main thread is blocked long enough to prevent input response abyss so TBT measures the total amount of time between first contentful paint and time to interactive so in short you should definitely make sure that you're leveraging the signals that you're getting from TBT in the lab to optimize for F ID in the field cumulative layout shift CLS is a measurement of visual stability it quantifies how much of pages content visually shifts around a low CLS score is a signal to developers that their users aren't experiencing undue content shifts a CLS score below point 1 is considered good CLS in a lab environment is measured through the the page load whereas in the field you can measure CLS up to the first user interaction or including all user input so that was a quick overview but it's important to remember that our goal is to have the vast majority of our users served with fast interactive stable experiences to that end core web vitalist uses the 75th percentile value of all pageviews in the field to evaluate against these thresholds so in other words if at least 75% of page views into a site meet the good threshold then the site is classified as having a good performance for that metric and this applies to all three of the Korowai vitals LCP fit and CLS the 75th percentile is used to evaluate all of them as I mentioned before our ability to measure user experience quality is always improving we expect to update core web idols on an annual basis and provide regular updates on the future candidates motivation and implementation status looking ahead toward 2021 the core Web vitals will be refreshed to ensure that it reflects the latest in our learnings and this includes adjustments to the set of metrics as well as the thresholds let's do a quick refresher on the value of combining both lab and field signals together to diagnose optimize and monitor your site's performance lab data which is synthetically collected in a testing environment is critical for tracking down bugs and diagnosing issues because it is reproducible and has an immediate feedback loop field data allows you to understand what real-world users are experiencing conditions that are impossible to simulate in the lab the real world's messy you mean there's permutations of devices there's Network configurations cache conditions the list is long either set of metrics taken in isolation aren't nearly as powerful as when they're combined and that's why we try to provide you with ample coverage for both lab and field tools we have the tools that focus on providing you with what you know information about what real users are experiencing field tools such as the chrome user experience report search console and the new Web vitals extension and then we have our lab tools as well coming in to provide you with mechanisms to see what needs improvement before a user ever even sees your page and it gives you a reproducible environment to debug and optimize those are tools like chrome dev tools and lighthouse PageSpeed insights is a great place to start to give you a pulse on your core web idols performance in both the field and in the lab because it leverages crux and lighthouse under the hood given that the Korowai vitals initiative aims to help folks know what should be prioritized first we wanted to make sure you had full support and tooling coverage for LCP FID and CLS core what vitals are now in all of your favorite developer tools and there are more than the what is even listed here and that includes a new web vitals library and a bunch of ecosystem tools that have already adopted them you're able to measure your Korra vitals for a specific page for your origin locally in the lab and from real users in the field and as I mentioned before total blocking time TBT it's a proxy metric for FID that allows you to debug and improve your interactivity in the lab which is why it's listed here in the fit column before we go over all of the latest updates in each tool I wanted to make sure that you had all of our tools mapped in a workflow for core Web vitals which tools do what where do I go first as I said before a good place to start to get a general pulse is PageSpeed insights but all of our tools have a really critical role to play using search console allows you to see across your entire site and identify which types of pages need improvement then you can diagnose and optimize locally with lighthouse and chrome dev tools we have some really new capabilities by the way I'm excited to share with you in a moment and then you can prevent regressions with lighthouse CI and create a custom dashboard to monitor your site with crux along the entire journey you can turn to web dev for guidance all right let's get into the tool updates themselves lighthouse just announced v6 last month which has new metrics including Cora vitals new audits and a new performance score let's start with the updates to the perf score on a high level we want to make sure that you can get a sense of your loading performance interactivity and layout predictability the metrics and the weights of those metrics that formulate the top level score are intended to give you a balanced view of your user experience against critical dimensions of quality while three new metrics have been added the core web idols metrics three old ones have been removed first meaningful paint for CPU idle and max potential fit these removals are due to considerations like metric variability as well as simply having newer metrics that offer better reflections of the part of the user experience that we're trying to measure with that metric there are also improvements to the weights based on user feedback for instance reduction of time to interactive suite in the final scoring calculation is in direct response to user feedback about variability and inconsistencies in metric optimizations correlating with improvements to the user experience however it is still a valuable signal to understand when a page is fully interactive that's why we still keep it TBT serves as a nice complement to TTI so that together you're able to more effectively optimize for user interactivity there's also a super nifty scoring calculator to help explore the performance score the calculator gives you a comparison between v5 and v6 scores as well it's not shown here but it's in the tool and when you run an audit with lighthouse 600 the report comes with a link to the calculator with your results pre-populated so I highly recommend you check it out lighthouse v6 also offers quite a few new audits these are with a focus on JavaScript analysis and accessibility you can now easily trace how much unused code is being shipped with your application as well as making sure that you're providing audits to check that screen readers and other assistive technologies have all of the information they need about the behavior and purpose of controls on your web page to serve users well all of the products that lighthouse powers are updated to reflect the latest version including lighthouse CI which now enables you to easily measure your core Y vitals on pull requests before they're merged and deployed PageSpeed insights psi reports on the lab and field performance of a page on both mobile and desktop devices the tool provides an overview of how real-world users are experiencing the page that's powered by crooks and a set of actionable recommendations on how a site owner can improve page experience and that's provided by lighthouse PageSpeed insights and the psi API have also been upgraded to use lighthouse Excel under the hood and now support measuring core web vitals in both the lab and field sections of the report so core web vitals are annotated with the blue ribbon that you see here from the crux data set you'll be able to see whether or not 75% of your loads are hitting the core web idles thresholds for each metric in the field for both your page and for your origin then you can take a look at your lab data from lighthouse to see whether or not you are hitting the core web vinyls thresholds for each metric in a synthetic testing environment this helps to guide you towards actionable opportunities to improve your pages performance now the new core web idles report in search console helps you to identify groups of pages across your site that require attention and this is also based on real-world field data from crux URL performance is grouped by status metric type and URL group which is basically groups of similar webpages the report is based on the three core web vinyls metrics and it's a great way to identify pages that need attention on your site there are many many cool new things in dev tools but I'm going to focus on just two of them right now that are related to core web Idol support first is the capacity to now debug interaction readiness with total blocking time in the footer the total blocking time TBT metric again the proxy for first input delay is now shown in the footer of the chrome dev tools performance panel when you measure page performance the performance panel has a new experience section that can help you detect unexpected layout shifts this is helpful for finding and fixing visuals instability issues on your page that contribute to cumulative layout shift so you select a layout shift to view it's details in the summary tab and to visualize where the shifted self occurred hover over the moved from and move to fields and for more information on everything that's new in dev tools um see that what's new in dev tools chrome 84 link that's here the chrome UX report crux is a public data set of real user experience data on millions of websites we just hit over 7 million so that's awesome it measures field versions of all of the core web idols even if you don't have room on your site crux can provide a quick and easy way to assess your core web idols the newly redesigned crux dashboard allows you to easily track an origins performance over time and now you can use it to monitor the distributions of all of your core web idols metrics to get started with the dashboard you can check out the tutorial on web dev we've also introduced this new core web violence landing page to make it even easier to see how your site is performing at a glance there is also a new crux API for you to use built from the ground up to provide developers with simple fast and comprehensive access to field based experience data developers can query for an origin or a URL and segment results based on different form factors the API updates daily and summarizes the previous 28 days worth of data including your core web idols performance we're excited to integrate more features over time to enable new ways to explore the data and discover insights about the state of user experiences webdev is your go-to place for guidance on web development it also now sports the canonical page for information about load vitals the weapon of measure tool also allows you to measure the performance of your page over time and it provides a prioritized list of guides and code labs on how to improve its measurement is powered by PageSpeed insights which has lighthouse 6.0 under the hood and fully supports the core with vitals metrics as you can see here there are also a slew of other amazing tools to help you with measuring optimizing and monitoring your core while vitals the web vinyls extension measures the three core web idles metrics in real time for desktop in Google Chrome this is helpful for caching issues early on during your development workflow and as a diagnostic tool to assess performance of core web vinyls as you browse the web the extension is now available to install from the Chrome Web Store the web vinyls library is a tiny modular library for measuring web vitals metrics on real users in a way that accurately matches how they're measured from chrome and reported to other Google tools the library supports all of the core Web vitals as well as other field vitals site kit Google's official WordPress plugin allows you to get insights about how people find and use your site how to improve monetize your content directly in your WordPress dashboard they've also just updated to ensure that you know how you're performing against core web idols as I mentioned earlier - we're so excited to have so many amazing ecosystem players and production monitoring solutions already implementing support for car well vitals honestly we're delighted and thank you so much for your amazing work it's really cool and this is a long list of links but I'll make sure to tweet them as well so that you can click through them more easily there are a bunch of goodies in here and with that I'm just gonna give you a huge thank you really appreciate your time [Music] [Applause] [Music] hey folks my name is addy osmani and welcome to optimizing for core web vitals so today we're going to talk about optimizing user experiences on the web with a case study on French luxury fashion house Chloe Chloe we've recently been taking a fresh look at web performance and I'm really excited to share their learnings with you now you may have seen Google search announced an upcoming search ranking change recently that incorporates page experience metrics now these metrics include the core web vitals which together with a few other signals paint a pretty holistic picture about the quality of user experiences on a page but what are the core Web vitals and how do you go about optimizing for them well core web vitals are a set of metrics related to speed responsiveness and visual stability now these three aspects of user experience are measured using three metrics so first of all we have largest content full paint which measures loading performance next up we have first input delay which measures interactivity and last we've got cumulative layout shift which measures layout stability let's kick things off by talking about cumulative layout shift or CLS now CLS is a pretty important metric for measuring visual stability because it helps quantify all those times when we see really surprising shifts in the content on page it helps make sure that the page is as delightful as possible have you ever been reading like an article online when all of a sudden something suddenly changes on the page and without warning the text moves and you've lost your place that's literally what happens a giant chicken kicks your content away and he has no regrets look at him he's basically CLS so what causes poor CLS well first of all we've got images without dimensions ads and beds or iframes without dimensions dynamically injected content and web fonts that might cause a flash of unstyled content now as I mentioned Chloe is a French luxury fashion house and it's become a bit of a go-to brand not just for like luxury apparel but also handbags and fragrances and things like that and they have recently been focused on improving cumulative layout shift on all their like main pages so their home page their product listings page and their product details page through a bunch of work they've been able to reduce their CLS all the way down to zero which is about as perfect as you can get so how did they get here this is the before view of the Cloe homepage where we can observe a number of surprising layout shifts due to elements on the page not following CLS best practices so let's dive into a few tips that worked well here first off always include width and height size attributes on your images and video elements alternatively you can always do things like reserve the required space with CSS aspect ratio boxes but in general this approach just make sure that the browser can allocate the correct amount of space in the document while the image is loading so here's a demo of this in action these are some images that don't have width and height specified and what you see happening is that they're pushing content in the page all the way down this is something that's reflected in our tools like lighthouse and I've got a little bit of a clip out here you can see the lighthouse report where CLS is in the red and not quite where we want it to be so how do we address this well in the early days of the web developers would add width and height attributes all over the place that add them to their image tags they make sure that they kept enough space allocated on the page before browsers would start fetching images that was great because it would minimize reflow and relay out now when responsive web design was introduced developers began to omit these width and height attributes and they started to use CSS to resize their images instead one of the downsides to this approach is that space could only be allocated for an image once it began to download and you know at that point the browser could determine its dimensions as images load in in that old world you know the page would reflow was each image appears on the screen and a lot of us got used to you know our text suddenly popping down the screen which wasn't a very great user experience and this is where your aspect ratio comes in so the aspect ratio of an image is the ratio of its width to its height it's pretty common to see this expressed as two numbers separated by a colon so for example 16 colon 9 or 4 colon 3 for an x colon y aspect ratio the image is X units Y and y units hide what that means is that if we know one of the dimensions the other one can be determined so for a 16 to 9 aspect ratio if dress jpg has got a 360 PX height the width is 360 x 16 over 9 which gives us 640 PX I'm not very good at math so hopefully that was helpful now modern browsers now set the default aspect ratio of images based on an images width and height attributes so it's really valuable to set them if you want to avoid those layout shifts this is a change in modern browsers and it's all thanks to the CSS working group they've done some work that basically allows us to just set width and height as normal and this calculates an aspect ratio based on the width and height the attributes before the image is loaded so what we're seeing on screen here this is something that's added to the default style sheet of all browsers and it calculates aspect ratio based on the elements width and height attributes so as long as you're providing width and height the aspect ratio can be calculated and everything will will hopefully avoid layout shifts so this is a great best practice to be following this is also something that works well with responsive images so with source set you're generally defining images that you want to allow the browser to select between you need to find sizes for those images to make sure that you image width and height attributes can be set just make sure that each image is using the same aspect ratio and here's that demo once again with width and height attributes added notice that in a modern browser you won't see any layout shifts there and the user will get a much more pleasant experience so another reminder set those width and height attributes as much as you can here's the impact that this change has on lighthouse as we can see before we went from a CLS of 0.36 so we're in the red all the way back to something that's a little bit better there one or two other things in this page that could have been improved but on the whole we've had a relatively significant impact on reducing layout shift you might be wondering how can I figure out what elements on my page are contributing to CLS we've got you covered so in lighthouse we have an avoid large layout shifts audit that highlights the top Dom elements contributing most of the CLS to the page so check out that audit in dev tools we also have a good story here so if you're using the dev tools performance panel it has an experience section that can help you detect unexpected layout shifts super helpful for finding and fixing visual instability issues they highlighted in this experience section with some kind of reddish pinkish layout shift records and if you click on one of those records we'll be able to get more details about you know what was the score where did this element move to and from really great Diagnostics to help you nail down how to fix your CLS so khloe's approach to image loading is that they use a skeleton pattern with a SAS CSS mixin called bruschetta loading bruschetta is one of those things that are a little bit of a luxury through major in quarantine they're they're right up there with toilet paper and antibacterial soap but let's stick with bruschetta loading so this is Chloe's approach to image loading they have a parent container with a color similar to the final image that's being loaded now lo the lazy loading strategies like this where you have a little bit of a preview of what's finally going to be shown are sometimes referred to as a low-quality image placeholder you can use you know a predominant color from the final image you can use a low resolution image sometimes people will use like a 1 pixel by 1 pixel image or something like 10 pixel by 10 pixel something very low resolution that just gives you a preview of what's finally going to be displayed now lazy loading strategies like this which either use a color or that kind of placeholder they don't strictly improve largest content full paint but they do improve perceived performance so they can still be pretty good for the user experience now what Chloe did here in addition to using this skeleton loading approach was that they do use responsive images and they do make sure that they're setting dimensions on their images as well to avoid CLS let's shift up and things up chef things up let's go on to the next tip so reserve enough space for any of your dynamic content things like ads or promos ideally you want to make sure that you were giving any of that content a container that it's not going to just you know bounce out of and suddenly cause shifts in the page a related tip to this one is avoid inserting new content above existing content unless it's in reaction to a user interaction you want to make sure that any layout shifts in your page are ones that you are making a conscious decision around and like occur as as expected so let's try to visualize this here's an example of a promo where we're dynamically injected into the page we haven't reserved space and it's just pushed everything all the way down we can see this reflected in our lighthouse call-out at the bottom of the screen now this is something that very typically happens with ads i fro iframes promos and these types of assets can sometimes be the largest contributors to layout shifts on the web now many ad networks and publishers will often support dynamic ad sizes and ad sizes that are you know dynamic or something that can sometimes increase revenue because you're giving people a lot of flexibility around you know what can go inside their your ad slots but it can also be something that can potentially negative the impact the user experience by pushing things down so that's something that you want to avoid so how do we approach this well one solution to the problem is statically reserving space for the slot so you can make sure that you're defining a container for these ads or embed frames so that regardless of what goes inside you're not shifting the content of the page around so here I've got a container where I've set my width and my height I've set a background color but I've also set it to overflow:hidden just in case anything dynamic is a little bit you know a little bit taller than the container I don't I still don't want it to be able to break out of it ideally the content fits inside of our container like our iframes or whatever else we might inject in there and what you can do if you're in the you know if you're somebody that has lots of dynamic content that gets injected into your page you can take a look at your your data look at what are the medians or the 95th percentile widths and Heights for this dynamic content and size your container accordingly that'll just mean that you have the best chance at still being able to present that content to users without negatively impacting the rest of the user experience so here's what it looks with with my pattern in place I've reserved enough space and that content pops in but there are no layout shifts in the page so I'm really happy about that slightly better is my baseline for everything in life at the moment so yeah this is the lighthouse 6 dotto impact we can see that we reduced our layout shifts from zero point two four all the way down to about zero I'm gonna give myself about zero it's in the green so that's great so let's talk about a production example of something like this on Chloe so Chloe had a promotion banner for shipping at the top of their product listings page and you'll see this like free standard shipping promotion list in the very top but this wasn't always there there was a time when this product listings page had a CLS of 0.4 which is like really not great because of two things the first was the way they approached dynamic promo banner and the way that they approached filters let's talk about the banner first now this banner used to be positioned in line underneath the main page header and as you can see here it looks it looks kind of harmless but what's the impact of having a dynamically sized banner on the user experience well we have a video here let's take a look as we can see here once the content is fetched and rendered for this banner it pushes the content for the rest of the page all the way down and that's not very ideal so how did Chloe go about fixing this well they reserved space for this banner the content for this banner was also coming from a client-side request there four messages were causing a pretty visual layout shift occurring a few seconds into page load now they moved this API call street to the server and they made sure to reserve enough space for the banner with a simple height setting as a part of this work they moved the position of the banner up a little bit but altogether like moving more work the server always a good idea and just making sure that they're reserving space these things made a bit of a difference so here's here's the after view here we can see the impacts to their product listings pages after these pages after these changes have been made it's uh it's a lot less shifty so I'm happy about that so we talked about their promo banner the other big CLS issue for product listing pages was that Chloe had a filters widget for filtering products now this would rehydrate to become dynamic once it booted up and so on the client it was pending xha our calls for data was waiting on session state based on filter choices in order to be able to like finally render this thing on the screen so this is what this basically looked like we wait for kind of contest to be sent down for the filter widget we wait for hydration and it would still push content on the screen all the way down now what they ended up doing here was that they adapted this widget to contain more of the information needed to render the filter widget server-side they'd rendered it with better defaults this helped avoid those layout shifts and I just wanted to give a call out here to the right of the screen we can see the Web vitals Chrome extension this gives you a real-time view of all of your vitals metrics and it can just be helpful as you are building your site's locally or you're just browsing the web and want to get a sense for the performance of different sites that you you check out on the regular and here's what things look like after their rehydration fix for filters as you can see CLS reduced by a decent amount looking at the before and after and it was just another case of like pay attention to the little things in your pages that might be in aggregate causing lots of things to be pushed down every little CLS fix helps and here's the overall impact of these changes on desktop we can see that the above the full content is relatively stable and offers a much better user experience on the whole and this is also reflected in lighthouse work on lighthouse got to give got a give lighthouse shut up as we can see here cumulative layout shift is in the green we've hit zero so it's in a really solid place so to improve CLS Chloe acted on a number of different elements it wasn't just one thing they reserved space for the promo content in terms of its ratio they made sure to set width and height dimensions on their images and they adopted a skeleton pattern they improved perceived performance they reserved space for their promo banners requests before receiving messages and they also reserved space for the filters dynamic component as well as making a few other optimizations to just help with rendering so on the whole it was it was definitely worth it alright so I have a big surprise for you we've got more metrics to talk about put a lot of work into this light historically it's been a bit of a challenge for web developers to measure just how quickly the main content of the web page loads and is visible to users thankfully we now have metrics like artists contain full paint that are able to report the render time of the largest content element that's visible within the viewport now you might be wondering what causes a poor LCP well there are there are lots of things slow server response times or a big one this could be your back-end infrastructure it could be unoptimized database queries API responses that are just taking a while to resolve it could be render blocking JavaScript and CSS slow resource times are another big one you could have an optimized images slowing down your LCP and then there's client-side rendering there's a whole class of problems where those of us who love working in JavaScript and using modern libraries and frameworks and bumblers can sometimes get into a place where we have our requests for assets like images in particular hero images behind JavaScript fetches so the browser first of all has to fetch your JavaScript then it has to parse and process that JavaScript to fetch your image and that whole process can take so long that you delay showing meaningful content to your user so it's just things like that you should keep an eye on there are plenty of tools that can help diagnose these issues so let's take a look at a at some real-world production challenges around LCAP and how to work around them Chloe started off with an L CP of about 10 or 11 seconds in this view here we can see that their primary hero image content wasn't wasn't getting fetched and rendered until about 11 seconds in to our trace their home page suffers from in this case it suffered from a few different things it had heavy full-screen image downloads poorly optimized images some images that were requested late in the network chain and these are very common issues there's nothing here that's just like that they're doing crazy wrong it's just very common issues and it's useful to be aware of some of the things that impacts LCP so things that impact LCP our image elements image elements that might be inside of an SVG element video elements block level elements containing text nodes and so let's talk about images first because they're there they're pretty often a cause for poor LCP so for many sites images are the largest element in view when the page is finished loading especially as UX patterns have shifted towards us using more hero images in our pages so it's very very important to optimize our images especially anything that's visible within the initial viewport now there are a few techniques that you can use here you can consider not having you know an image in the first place if it's if it's not that relevant maybe you remove it compress those images use you know love law there are plenty of image optimization tools out there compress your images maybe consider converting them it's more efficient modern formats use responsive images and you can also consider using an image CDN I'm seeing an increasing number of sites leveraging image CDNs just to help them get control over a ability to just tweak parameters in a URL for an image and change what format gets served down or what quality you have and it's just using an image CDN can be a really good way of staying on top of modern best practices because even even us like that are you know web pursues iasts sometimes have a hard time staying on top of all everything happening in the image optimization world now you might be wondering how can I identify the elements that is my like LCP thankfully we've got some solutions here in dev tools in the performance panel if you record a trace and you go to timings you should find a record for LCP click on that record and you'll get the summary pane showing up that includes things like the size of the image and more importantly they're related note so if you hover over that related note it'll highlight what in your page was considered LCP I personally find this really valuable as kind of a stepping stone to where should I be spending my time optimizing so check that out if you use the performance panel this is also something that we try to capture in lighthouse so lighthouse has got a law is content full paint element audit and we try to highlight what element was responsible here too so if you use lighthouse check that out so back to Chloe so Chloe discovered that they were delivering very high-resolution images even to even very high resolution for retina screens because there is a bit of a cutoff point where if you're serving kind of two by three by images the human eye is is not going to be able to perceive large amounts of difference there and there are kind of you know you have diminishing values that you get out of just serving very very very high resolution images now in this case we're in Ren dev tools were in the elements panel we're looking at a specific image and what we see is that the maximum width of image is being served down is 1920 pixels it's pretty it's pretty large so one of the things that Co we actually decided to do was change things up here they resized their images to not be more than 2 times the image viewport size so they removed source of sizes over 828 width to keep an image maximum size that they were comfortable with and that actually ended up being pretty fine on retina devices as well so is this nice trade-off of how do we deliver rich imagery without negatively impacting the user experience now by doing this work on an iPhone X or a pixel to excel that was previously seeing any were up to 245 kilobytes worth an image bytes being downloaded they were able to reduce it down to 125 that's that's huge that's like a 51 percent decrease in image bytes being served down with no noticeable difference so optimize your images people the next thing we're going to talk about is some of the other image optimizations that they performed so on the product listings page Chloe use image lazy loading which is you know it's a relatively popular pattern what they discovered was that there were four primary images being loaded above the fold however there was one off-screen image that seemed to be tripping up their lazy loading heuristics and was still being fetched now this particular image happens to be 248 kilobytes in size about 200 plus kilobytes in size and this was this was negatively impacting the user experience they wanted to try improving this now on the whole there are a number of things Chloe did they were able to bring down their above-the-fold image download size all the way to 14 and a half kilobytes they were able able to tune their lazy loading heuristics so that off-screen images like the one I was just talking about were no longer a problem they adopted an image CDN they adopted wet pee by defaults improved their image resizing strategy and the results of this outside of just having a nice like lighthouse report with lots of greens is that each product page now weighs 57% less than it did before which is a really nice outcome to have as a result of like optimizing your images taking a step back here's what the homepage LCP look like after these changes we can see that again previously those hero images were not rendering in a total about 11 seconds in now LCP happens at about 4 seconds into the process and it's complete just a few seconds later the request time for our LCP related note for kind of our hero images is about 1.3 seconds in so on the whole this is this is really great there's still work they could do here but on the whole this is like fantastic to see so let's switch things up to our next tip defer any non-critical JavaScript and CSS to speed up loading the main content of your page now this is guidance that is it's not new it's been around for a few years but for anyone that's not familiar with this guidance I'll give you a very quick recap of it now before a browser can render any content it needs to parse HTML markup into a Dom tree the parser needs to pause if it encounters any external stylesheets your synchronous script and scripts and stylesheets can both you know render bbbb render blocking resources which can delay your first content full paint consequently your largest content will paint as well and so what we tell people to do is defer any of your non-critical scripts and stylesheets the speed upload so let's take a look once again at the product listings page for Chloe as we can see this is a trace independent of their image optimizations and as we can see here light house highlights that there are a few render blocking style sheets that are delaying early paints on the product listings page now this is this is kind of manifested in terms of like just how much white we're seeing in our film strip so one approach to addressing this problem is by inlining your critical CSS and deferring the load of non-critical styles we often call this technique critical CSS so critical CSS is all about extracting CSS for above-the-fold content ideally across a number of different breakpoints and making sure that you can render the above-the-fold content as quickly as possible in the first few our TTS and deferring the load of the rest of your style sheets for the page you know for things below the fold as soon as possible otherwise so how did Chloe do this well they built some tooling they implemented critical CSS in their sass build process and they constructed a syntax allowing their developers to specify for each widget what part of the CSS code goes into their critical CSS this is highlighted using the critical keywords you see on the screen right now now at Build time they're able to build both the critical CSS and the non-critical CSS so that every single build is consistent with both there are many ways that you can approach critical CSS I've contributed to some tooling on this topic in the past and you can you can automate it you can go very custom I see some teams that will just have a critical dot CSS file that they manually curate and regardless of the the approach that you take what's key is just making sure that you're delivering important content to the user as quickly as possible so we talked about the need for you know loading in the other style sheets for the page will quit what Chloe do is their non critical CSS style sheets are stored in an array so they point to references to them on their servers and that's injected with a deferred script so that it's hopefully not render blocking but it's still loaded with a relatively high priority that isn't going to interfere with the HTML parser so what was the impact of optimizing their critical CSS well en the answer is pretty large they were able to bring down their first content full paint from 2.1 seconds to about 1.1 and their LCP from 2.9 seconds to about 1.5 now this is this is really great work optimizing your critical CSS can be a bit of a time investment but is something that can just make sure that your page is getting styled as soon as possible so let's talk about another tip I mentioned slow server response times when we were discussing like what what impacts LCP now the longer that it takes a browser to receive content from the server the longer that it takes to render anything on the screen the faster server it can respond that that's going to improve every single page load metric including LCP so you might be wondering how can I tell if I have a slow server response time lighthouse has you covered in lighthouse we have an audit called reduce initial server response time and if you if you see this it's a good hint to spend more time diagnosing the problem and causes of the problem as I mentioned earlier it can be plenty of things on your back-end and we're trying to optimize our server response times there's plenty that we can do in terms of optimizing you know our DNS our pre connects all of those types of things but there are also things that we can do to optimize loading priority this is where techniques like link rel preload and server push can come into play now if you're new to server push I'll give you a quick summary of it to improve latency hb2 introduced this idea server push which basically allows the server to push resources to the browser before they're explicitly requested now you and I as developers we can as well as anyone else watching you're all awesome too we often know what the most important resources are on a page and so we can start pushing those as soon as you know things respond with the initial request this allows the server to fully utilize what's otherwise an idle network to improve page load times now server push is is not without its it's nuanced this is one of those optimizations where you need to be careful it's possible to over push so server pushes not HTTP cache aware so I could push something for a particular page the user could come back to another related page and the server would push those exact same resources again the way to avoid that is by either using cookies or a serviceworker to avoid those those refetch is for those types of resources and track what's in the cache but it does involve a little bit more work in general server pushes an optimization that can have a big impact but just just be aware of some of that nuance it's not quite as simple as just like turning it on sometimes now Chloe use automatic server push which is an implementation provided by Akamai it uses data to decide you know when to push critical CSS fonts and script and if you're manually using server push yourself you might end up looking at syntax that looks a little bit like this what we see here is the link h-2b header this is actually the preload resource hint in action and it's a separate but distinct optimization from server push but in reality most hb2 implementations will push an asset that's specified in a link header containing a preload resource hint so you can use the syntax in order to na server pushes for for a page so what was the impact of this optimization without server push Chloe you're finding in their lab tests that LCP was closer to four seconds but with it it was closer to 2.5 seconds which is like a huge amount of impact on screen at the moment we've been verifying that using lighthouse but you can also tell if individual requests in you know we're server pushed using things like dev tools and using things like webpage tests Network waterfall view both are very very handy now we're on to our very last metric right Chloe didn't optimize for forced input delay but I did want to very quickly cover it now first input delay measures the time from when a user first interacts with a page so that moment when they start to click on a button or tap some UI some JavaScript powered control to the time that the browser is actually able to respond to that interaction now there are many things that cause a poor first input delay there can be long tasks on the main thread heavy JavaScript execution large JavaScript bundles can delay how soon script can be processed by the browser and it can have an impact here and then you have things like render blocking script now in general I would strongly recommend using lighthouse and using dev tools because they do try to point out areas where you might have long tasks or heavy script execution very often the solution is to just break up this work serve what the user needs when they need it and try to look at opportunities for you know minimizing main thread work as much as possible sometimes people will contextualize this in terms of you know maybe shift some of that work some of the logic work to a web worker but regardless of the path you want to take there the the end goal is essentially just making sure that the main thread isn't busy and that user interactions are not delayed so we're almost at the end of our journey with khloé' here we can take a look at khloe's overall web vitals in the lab thanks to their investments in performance and user experience they were able to reduce their cumulative layout shifts down to zero and their LCP by almost half this is like this is mind-blowing ly awesome this is like really really cool as you've seen all of this work is kind of the culmination of a number of smaller optimizations that when added up actually make a pretty significant impact to your end user experience and we don't have to just look at data in the lab we can look at the field as well here is chrome user experience report data for Chloe and as we can see our core web vitals metrics for LCP and CLS are trending in the right direction CLS went from 0.85 down to zero in the latest data set and this is all like on the whole it's tremendous work it's really great to see and I know that Chloe are happy to continue building on this work in the future as well now if you're interested in building dashboards like this for your own team measuring the core Web vitals you might be interested in checking out the chrome user experience report dashboard this is a great solution that just allows you to drop in a URL and very quickly get access to field data and distributions for the different core Web vitals it also summarizes the metrics so if you're trying to share around this report with other people on your team they'll hopefully be able to also get some familiarity with the core web vitals too we also recently shipped a new chrome user experience report API crux API this is great for programmatically being able to build out your own dashboards very similar to what we were just taking a look out so check that out too and that's it I hope that you found this talk useful go and optimize your web vitals there are plenty of Doc's over on web dev that cover the methodology the tools as well as the best practices that you can use to get fast and stay fast my name is addy Osmani I hope this has been useful thank you [Music] [Applause] [Music] hi everyone thanks for joining me my name is Rick Viscomi I'm an engineer and developer advocate on web transparency projects at Google including the chrome user experience support or crux for short as you may know crux is a powerful data set containing insights about how real users experience the web and this data set goes all the way back to late 2017 and includes data from over 18 million websites this will be a somewhat advanced presentation so if you want to brush up on the basics you can visit the crux docks at bitly slash chrome UX report to learn about things like metrics dimensions best practices and more what I'll be sharing with you today are a few pro tips for mining the low-level data set on bigquery for insights about how users are experiencing the web so by now I'm sure you've heard of core web vitals there are the most important UX metrics we think you should be looking at in 2020 the list includes LCP FID and CLS in fact Kruk supports all three of these metrics and has months of data across millions of websites so let's head over to bigquery to see what we can find here I'm querying the metrics summary table which is a really quick and easy way to get high-level stats about a website's core web titles you can see here that we're extracting the percent of user experiences that meet the good thresholds for LCP FID and CLS as well as metrics 75th percentiles all of these stats are pre computed for you so you can spend more time finding insights and less time writing queries this summary table is also much smaller and more efficient you can see it processes only about a hundred megabytes so you shouldn't have any concerns about exceeding your one terabyte of free monthly quota the raw data still exists if you need access to specific histogram bins but almost everything you need is here in the materialized data set if you've ever queried the raw day you'll know that there are several useful dimensions that you can drill down on like month device type and country so let's look at a few examples of doing that efficiently with the summary tables the first thing we'll do is modify this query to see how the core web vitals have changed in recent months to do that we need to change our where clause to include all releases in 2020 by setting the condition to date greater than 20 2001 oh 1 or January 2020 next we include the year and month of the release and the select clause so we can see it in the output the difference between year month and date is that the tables are partitioned by date while the yeren month corresponds to the table names in the raw data set and finally we can sort the results chronologically and run the query you can see from the results that web dev has had relatively stable and good user experience this year but what if we want to break this down by desktop and phone experiences for that all we need to do is change over to the device summary table will restrict the results to only desktop and phone results now tablet is available but it's less interesting next we'll add the device name to the select clause and secondary sort by it to keep the ordering of the results consistent I'm going to run this query but there's one thing I wanted to show you in the results these percentages are out of all user experiences on the origin not just the percent of desktop experiences or the percent of phone experiences for boring technical reasons so one last thing we need to do is normalize these distributions so it doesn't matter that desktop is more popular than phone to do that we just divide the metric by the total now we have comparable results between devices and we can see that desktop actually trends slightly better than phone and finally what if we want to break this down even further by users countries for that we can change over to the country summary table for demonstration purposes let's restrict the results to two countries with very different experiences Korea and Nigeria and focus only on desktop now we could write the country code to the results but I wanted to show you one other cool trick the crux data set includes an experimental function to map country codes to full names and the last thing we'll do before running the query is to sort by country rather than device the results tell a really interesting story about the disparity and user experience by country and Vickery was able to analyze this in only a couple of seconds and using only about a gigabyte of data so that's it these are just a few quick examples of the power of the bigquery data set and it doesn't have to be mysterious or expensive I hope you start exploring the data set and finding insights about the state of the web you can find links to all the resources and queries we discussed in the description and comments of this YouTube video if you have any questions at all we have a whole support network set up for you you can find me on twitter at rick Viscomi and i also tweet from a chrome UX report we have announcement and discussion groups for important product updates and support we have the crux cookbook on github where you can find example queries for common problems and finally we have crux office hours where we can meet virtually and get your questions answered I hope you found this useful please hit the thumbs up if you did thanks for watching everyone [Music] [Applause] [Music] hi everyone hope you're all staying safe my name is Racine journey and I'm a developer advocate on the web team at Google for this segment of web dev life we're going to talk about different ways to explore and analyze JavaScript undos on a wet beach analyzing bundles is a good first step to optimizing the amount of JavaScript shipped to the browser which can improve page load times and directly result and better large example paint and first input delay jobs the bundling is a term commonly used to describe the approach many websites take to group multiple jobs group files or modules into a single file or bundle many tools that bundle Java code for the browser usually include a number of different optimization steps such as minification and sculpt wasting this is a good thing because code written across multiple files and modules can be combined into a single optimized bundle although this might be useful from a developer and user experience standpoint this process usually obvi skates javascript code to the extent that it can't easily be read and analyzed without the help of additional tooling let's take a look at some examples to get a better idea if you're using chrome the network panel on the dev tools is the easiest way to look at all the JavaScript downloaded on a page open dev tools by pressing ctrl shift J or command option J on the Mac and click the network tab to open the network panel to take a look at all the network activity during page load reload the page while dev tools is still open click the jobs good button to filter requests by JavaScript and click any URL to view the response by the format button can make a minify file more readable notice how with this simple static site there's only a single jobs file and although minified it's easily human readable if we do the same for a site that bundles the JavaScript code it gets harder trying to understand exactly what lives in the bundle this is an example of a site that bundles many third-party libraries and hundreds first party modules into chests a few discreet bundles so let's take a look at some ways to analyze this code the coverage tab can show you how much JavaScript code is unused and any of your files or bundles directly in dev tools open the command menu with ctrl shift P or command SP for Mac type coverage and select the show coverage command click the reload button to reload the page while capturing coverage and in a drop-down menu select JavaScript in the table the unused bytes field shows exactly how much JavaScript Sun used for each fun click any URL to see a line by line breakdown so although the coverage tab gives us a lens of how much code is being used on a page it still isn't easy to identify which modules make up the bundle now there are other tools out there to make this possible if you're already bundling code for your site chances are you're using a module bundler like web pack roll-up and many of these modular blunders provide either first class or the third-party tooling like you can use to visualize and map your bundles let's go over an example if you use webpack you can generate a staff JSON file that contains statistics about all bundled modules a single CLI command emits the fire although reading this file yourself can give some information about what modules live in the bundle there are community build libraries that can consume this file and display a more useful visualization one such library is called web pack Dawn's landline and it works by parsing the bundles generated by web pack and then mapping them to the module names and the stats JSON file by doing this it creates an interactive tree map visualization of an entire bundle showing the sizes of each module as well as the relation to each other gzip and parse sizes are also displayed to give you a better idea of how large each of the modules are bummer specific visualization tools are great they make it easier to see what makes up each of your bundles but they are blunder Fredi site regardless of whether a specific model Bunder is used or not source maps are a way to map original written code to transform the output this is useful because of an allow us to continue to obfuscate and transform our code during the build process but still have a means to map it back to its original form javascript files that have been transformed due to minification or other bundling optimizations need to point to the location of a source map file with a source mapping URL comment or a source map HTTP header all newer browsers support source Maps and with chrome you can enable it in the dev tools by opening up settings and checking the enable JavaScript source Maps option when chrome can detect that a source map is available it'll show a message and we're able to open and debug these separate associated files as regular JavaScript files source map Explorer is the library that you can use to see a tree map visualization of the bundle this visualization is an example of using source map Explorer with a production built just by looking at this we can identify a few issues already a few common des models here mam and Jas and lodash are already larger than they need to be if they were switched to use es modules they could be smaller and more optimized there are duplicate copies of react and code needed for multiple different routes all live in this bundle and they could easily be lazy loaded into their own separate bundles these are all common issues than many sites run into and we can spot them by using a visualization tool like source map Explorer other tooling that you may already be familiar with are also starting to consume source maps in different ways that can be useful light house an open source web site auditing tool is currently experimenting with source map support for some of these audits with source maps the unused JavaScript audits can show how much onions code and potential savings live in bundled modules there's also a new legacy jobs with audit being developed that takes advantage of source Maps to show legacy code within the bundle contains polyfills and newer browsers don't need and there we have it we just went over a number of different techniques to analyze bundle JavaScript code to recap the network panel and dev tools is the easiest way to start seeing how much JavaScript code is being downloaded the coverage tab could show you how much JavaScript is actually used many module bundlers have supported tooling and make it easier to visualize bundles if you use webpack for example you can administer a JSON file and use webpack bundle analyzer consider enabling source maps on your site and use source map Explorer to visualize your bundles if you'd prefer not to omit source maps from production you can set it up as part of your build process so that it's only generated during development and lighthouse is also working in collecting source maps to display more useful audit recommendations these changes will land in a future version so keep an eye out so analyzing your bundles and limiting the amount of JavaScript in a web page reduces the amount of time the browser needs to spend parsing compiling and executing JavaScript code this speeds up how fast the browser can begin to respond to any user interactions improving first simple delay and results in a fast render improving largest content paint thanks for watching I hope you found this screencast super useful [Music] [Applause] [Music] hi everybody I'm Paul Lewis and I'm Philip Walton okay so we thought today what we do is we would talk about the core web vitals inside a dev tools now I know about the dev tools side in fact I implemented some of the core web vitals in side of dev tools but Phil you're more of the person that knows about the actual metrics where they came from and that kind of stuff right that's right I know a lot about the metrics I work on the chrome team working with some of the people that were helping to define the metrics and standardize them in browsers but I don't really know much about how they work in dev tools so Paul you're a great person for me to talk to here let's let's dive in and see what we can what we can find out okay so I guess our plan is to have a bit of a conversation to go back and forth we'll be diving in and our dev tools having a bit of a discussion about these metrics and just trying to kind of explore understand and share what's kind of going on there so I guess the first one that I was kind of thinking about when we were discussing this was LCP and FCP so there guess the first thing to do to kind of talk about is what are what are they like where do they come from you know these are both paint metrics so FCP is first content for paint its tan it represents the first point in time that the browser is able to paint any content on the screen and LCP is largest contentful paint and that represents the largest single text node or image element on the page and the idea between these two is that FCP represents like the first time the user sees something and and LCP represents when you know the main content of the page has painted I mean in general whatever the largest thing on the largest image or text node on the screen is generally the thing that the user is going to notice and so that kind of represents once the page is really loaded so I guess for a lot of people then the first thing they're going to think of certainly for the largest content for paint will be something like a hero element or something like that right yeah they can a big image at the top of their page for example absolutely okay right but it's not always that I'm guessing because you could be deep linking into some content like further down the page and everything else yeah that's up so I okay I tell you what we'll do then let's take it I've got a page here actually I've got this page on web dev performance tab open inside of dev tools and I guess the the goal here is going to be to show FCP and LCP in context and I have web dev open here on a page in the performance section around using image CD ins to optimize images so if you've not seen this content definitely worth a look it's a great art okay and we have yeah we have I'm going to DC I can deep link into this section right from with the right and so this I guess would become our hero imagery and an interesting point to make here is that the hero image is not necessarily going to be above the fold like in this case you're loading a page halfway down how if we scroll down the page and so LCP is always you know it's only going to consider elements that are actually visible to the user on the screen right great points so this is what's going to make this brilliant bit interesting so what I'm going to do is I'm actually gonna going to go to fast three G so in the performance tab you can open the capture settings here I'm going to change just online oh it's a fast 3d so we're just going to switch to a slow down on the performer you see this little exclamation mark shows up saying Network throttling throttling is enabled and I'm gonna actually gonna slow down the CPU just a little bit and you doing this so that we can see things you're doing this to simulate maybe a lower power device or something like that correct yeah yeah I am but right now as well what I wanted to do is if I take a recording with things just slow down a little bit it might be easier to just to see what's going on because I happen to be it's somewhere in my house is actually a really good internet connection so I don't particularly see Network latency quite as much as you would in other cases say you know if you're on a mobile device out and that so I just thought let's just try this and see what happened so I'm gonna hit record I'm gonna hit command shift art to do a reload okay and I'm gonna stop and we can discuss what we see okay let me just wrap this up here now the first thing to notice I suppose would be the timings row here to have to remind ourselves what these are don't content loaded this has been around forever hasn't it yeah but there is first paint first concept for paint first meaningful paint which we could talk about a little bit I suppose largest content for painting you can see that's actually highlighted our screenshot here and then the load event now I can use the keys on the keyboard to come into a little bit closer zoom in a little bit on this particular area of interest and you see here I suppose the first content for paint is presumably happening and then the largest content for paint is happening slightly later that's right now I think we can get a little bit more info about this because first content for paint is happening and then the largest content for paint which implies to me that the image is coming in after the initial page concept so we're drawing something we're painting something and then we're painting the image after the fact so let's see we do that with screenshots on and we will record again and see what we get okay I'll stop there and hopefully they just lose this a little bit and we might see okay so roundabout fact they wonder if I can just bring this in a little bit further let me just see if I can track that down break this a little bit okay that might be as clear as this is gonna get I wonder yeah it is okay I think what we're going to do we're going to make this a little bit clearer because what's happening is we're actually seeing the page content before I did the refresh and then slightly after so I can do I can if I take this and I go to about blank this is actually a really interesting way to do this testing if you're ever curious about it record it from about blank so that you start without a thing on the page can that can make it easier to find your screenshot so I'm gonna go paste in the URL here but not hit enter not go to that yet okay hit record and now go there okay hopefully that will make it a little easier to see what's going on okay so you see we've gone from here into the screenshots we see this we see the original page content the top of the page and then we're going down to our deep link just below that so my assumption is if we if we bring our zoom in here that around about here in fact we can just is this here yeah but you see we're just right on this line here where we go from nothing to something right nothing to something is exactly the point where we actually start to see this this the first register concept for paint coming in yes the first thing that the user sees but it's not the main thing that they wanted to see when they were when they were loading the page yeah in fact it's saying largest content for paint at this point is actually this piece of text now let's try it one more time from her just a really really dilated I wasn't going to go for slow 3G I'm gonna go to about blank again and I'm gonna hit record and I'm gonna see what happens I feel like we're going to see something reasonable here let's process that profile okay there we go this I think is starting to make more sense to me over here there we go okay Wow there we are first content for paint is here there okay and then much later OOP there comes our image okay which is slightly over to the right here and there so I can select that area and as from the based on the screenshots roughly there and I say that's the first content for paint and then if I select later on in the screenshots there I consider that's the largest concept for pick which is high imaging okay that's nice that dip tool shows you exactly what element on the page is the largest couldn't have full paint absolutely I can't resist I know we're going to talk about layout shifts next but why I'll just jump the gun a little bit we actually have a layout shift showing up between first at content for paint and largest content for paint and I think based on this I think the reason is because we're going from no image to image it's pushing the content down there train so I think we're seeing the page content move so my guess is if we were to go and find this image here in the elements panel we're going to see that it doesn't actually have yeah it doesn't have width and height attribute set yeah and I think that's basically causing this to happen so if you will come we're talking about layout shifts more in a second but the reason this page is shifting is because we have an image here that that loads when it loads it loads asynchronously essentially and it when it's loaded it pushes the rest of the page content down if we added width and height attributes to this image we wouldn't see we wouldn't see that layout shift as I said we'll come back to that more anymore yeah that's a good general I guess best practice though just let everybody know always put width and height attributes on your images that way the browser can render the space that it needs it can it can allocate a space that it needs to render them before it actually finished loading loading the image so then you don't get that layout shipped exactly the other thing I think we should talk about felt before we move on is how to optimize for this particular situation so what would you suggest if somebody said I need to get first content for paint and largest content for paint nearer the start that is taking too long to get to these numbers these numbers are too high do you have do you have a kind of go to list of things you would say to them yeah well definitely one thing that you you don't want to you know ever block I mean ideally you don't want ever block painting on more than kind of one Network request that initial Network request that you make ticket the page content you want to be able to paint at that point if you have additional requests like requests for fonts or style sheets or other things that are preventing you know the browser from painting that will just delay the time when that paint can happen and so you know I mean sometimes you know it depending upon the design you're working with you don't have a choice but in in an ideal world you would want to be able to paint right away and so looks like in this case on the web dev we are able to paint pretty quickly and then and that's why first paint is happening you know at the beginning and then the browser is loading this image and then largest can difficult paint happens as soon as that image gets loaded in exactly yeah I think what we're actually also seeing here is the app CSS which is the main stylesheet and the fonts as well okay my guess is that they are going to be blocking based on that you can see that when I roll over them the network panel here saying highest which is the priority that's been assigned to the CSS and the reason I guess is because the CSS is going to be blocking the render which is what you were saying so that's why I think some people would inline that but I guess if we go ahead and take a quick look in our head and if we can find we could search for it but I'm gonna link what link rel there's the stylesheet yeah you see there's a stylesheet for the fonts and right below it up dot CSS and so this would be a classic case of here's a stylesheet it's gonna block render because the browser crow is gonna take a look at that and go well I need to wait and see what styles are before I render anything right absolutely so there can be something that we can sometimes take a look at say with blocky JavaScript right yeah we see that one sometimes I guess gets in the way do something like differently so you sometimes hurt here this referred to as critical CSS where you identify just the CSS that is needed to layout the page not necessarily style all the components on your entire site and so you can inline just that CSS content in the head of your document and so then you're not blocking on an additional network request in order to paint something on the page exactly yeah so that that was FCP and they'll seep in as I say you'll you'll find those on the timing's track here in dev tools ok so next up layout shifts now we talked about this very briefly just now yeah but with these two down here but where does he come from what what's the history of the layout shift and cumulative layout shifting I think I've also heard it called yes so the metric name cumulative layout shift or CLS for short is a metric that tries to capture the experience of visual stability on a page now you've probably everyone's probably had this you know experience where you go to a website and you go to tap on you know a button or something and right before you tap on it it shifts out from underneath you it's a very frustrating experience even if you're not interacting with the page you're just reading it if you know some images late loading images pop in some ads pop in the content changes like a number of things gonna happen and you lose your place as you're reading and it's it's just not the greatest experience as a user from the user users point of view so cumulative layout shift is a metric that attempts to quantify that experience and so there's a couple pieces there but a layout shift is anytime an element on the page between one frame and the next frame it's start position changes and so this will happen like in this case that we just saw an image loads in and it pushes the text below it down and so the image that the layout shift was not on the image the layout shift was on the text below the image that on the previous frame it had you know an x and y position of something and then on the next frame it was pushed lower and so it's position change so it's a bit you know tough to explain but the CLS is a measure of both how much of the page content moved and also how far it moved and so if the entire page content shifts from being fully visible on the page to not visible at all that would be a CLS of 1 if that happened 20 times throughout the page life cycle that would be a CLS of 20 you know and then if it moves kind of half of the screen distance and the the image itself it's only filling up half the screen and that would be roughly you know 0.25 CLS you can go read more about how to calculate CLS and whether the debits a little bit too complicated to explain now but that gives you a sense it's a measure of kind of how much visible instability there is on the page okay so as we talked about before then we have this one layout shift here and so on right so this is probably the better one of the two to actually demonstrate this and when you click on this and it's in this experience track if you don't get this experience track in dev tools it means that we didn't detect any layout shifts in that particular recording if you do find that it's there then you'll see that it's populated with these kind of records now you can click on this and it will take you off to the detailed information about CLS but what we try and do is we try and give you a sense of the score and the cumulative score of buzzwords about what's going on but we also try and highlight for you see you go going from an image here that's 11 by 11 and we show it as this very small overlay on the on the left hand side there to a much bigger 801 by 4 1 4 so one of the items that I actually have to do in this area and you can see actually have a few going on here which are profit probably other images that are being shifted you know as we as we make our way through and let me let me just one of the things I wanted to step back for a second and just talk about why somebody would do this I mean typically you'll you know you'll run lighthouse on a page or you'll go to search consoles new corbels report or the chrome user experience report and you'll see that you know you have layout shifting happening on your page and you might be wondering to yourself okay but I don't see it when I visit my page so where is this layout shifting happening and so then dev tools is a great place to debug that into low you know figure out which page on your site has layout shifting and then load it up in dev tools under the throttling conditions that you know Paul showed earlier and then you know look and see what dev tools is telling you is shifting because that's how you can figure out what's causing the layout shift and then you know you know what you need to do to fix it yeah and there's more I have to do here to be clear I think one of the things that there's missing for which is actually available in the data I just need to pull up a plummet through is which elements are we talking about where I can show you that we've got these areas but we it just feel like we're missing a bit of information about exactly which elements it is like we do with the LCP we highlight the image that we're actually you know referring to here we should be able to do the same here so by the time this goes out and you're watching this give it a try in Chrome Canary because I might have been able to land the feature by there yeah I'm not making any promises but that would be good with it and just um yeah just as a kind of a quick point there there's often two pieces to a layout chef there's the there's the element that shifted and then there's the element that caused it to shift and so sometimes you know figuring out one or the other can be helpful in fixing because it looks like here that it's showing the image that came in but adding images so adding elements of the Dom doesn't in itself cause a layout shift but if adding an element of the Dom moves the elements below it then that would cause a layout shift right because the the default size in this image looks to be 11 by 11 pixels to begin with and then when it when it gets populated with the actual pixel data it pushes down the rest of the page content which I guess justifies be the layout shift there yeah yeah okay so that's that's that you know if you've got like we said earlier if you put width and height on these things that will help but you can also have I mean let me show you this other one even on the Google home page this privacy reminder down here if I take a recording here and I just refresh this page we're gonna see a layout shift here and similarly we've got this here which is going from down here and I presume there's some JavaScript or something like that that's looking to see whether the privacy reminder has been seen and if not it pushes that content on and so again this is probably JavaScript based and you're gonna know in your own apps you know what's going on what is it third-party content is it your own JavaScript is learning styles right and it's a case of digging into the specifics of your application to try and figure out exactly you know what's triggering that like what could be happening there in order to figure it out so that's just you know a couple of examples of the layout shifting that you can see yeah and just you know right what one thing to keep in mind is that in an ideal world you would have no layout shifts on your page but sometimes it's unavoidable and so the you know the threshold that we recommend you know folks stay below is is 0.1 and so it looks here that you know this layout shift is is quite a bit below that and so even though you know you still want to be at at at zero if you can as long as you're below 0.14 you know 75% of your users you're usually in good shape so you say 0.1 I guess that's like for page load because that's where a lot of these all of these metrics are aimed at page load right now right yeah so that's actually a really good point I'm glad you have it up CLS measures layout ships that happen during the entire lifecycle of the page from when you load the page until when you unload the page even if you leave the page open for you know days or weeks it does measure that entire time whereas here in dev tools you ran a trace and you got you saw the layout shift that happened during that trace and so in this particular case CLS was only measuring shifts for a small period of time it's important that developers keep that in mind because you know the layout the the actual metric definition is for the entire lifespan of the page so if you run lighthouse trace or webpagetest race or even in dev tools and you see a certain value and it's below 0.1 the threshold it just mentioned just keep in mind that you have to actually be measuring it the entire time you know that that's that's the the the metric the measure that counts is the entire lifecycle of the page also I think in this area we should talk about perhaps the the metrics themselves as a bit of an evolving art I mean we have for example first meaningful paint up here but this isn't one of the metrics that we would mention say something like core where vitals and is also no metric as far as I'm aware for something like animation performance so that's true I guess my question to you is what's going on there why have we got a metric here that we wouldn't refer to and why do we not yet have a metric for something that we might be interested in tracking what's the kind of history and story there yeah that's a good question so F and P are first meaningful paint if you remember from a previous you know Trace that that you did Paul FOP was right next to FP FCP and then LCP was Lena later in the page load so what actually ended up happening was that oh yeah and it looks like that's that's the case here so yeah after a bunch of testing I mean F and P is essentially it's a different metric it has a different meaning than LCP and after a bunch of research we found out that FMP actually wasn't as accurate at predicting when the main you know what most people consider to be the most important content of the page you know the most meaningful part of the page the metric itself has the word meaningful in the name but it turns out that LCP is actually a better predictor and so as we come up with metrics that are better at capturing the user experience will you know kind of deprecated older metrics and replace them with with newer metrics but you know we do recognize that that's happened a bunch over the years and I'm sure developers are getting tired of hearing new metrics announced all the time and so one of the things that we did with core web vitals with the web files initiative and specifically with Corbett vitals is we're committing to you know only introducing metrics at most once a year for the the core set of web vitals and so developers are following along they can bring that you know gives them a little bit of stability if they're building a business on these metrics or you know predictability if they just kind of don't want to have to you know always be following along with with the latest and so you know recently we announced LCP was one of the core Web vitals and an FM view is not one of the core Mon vitals and like over time that will probably be deprecated so you also bet also asked about animation performance this is definitely a metric that we're looking at for the future maybe you know in 2021 or 2022 so we know that these set of core 12 idols doesn't capture the entire you know the entire story of user experience and we're hoping that over time we can improve it and animation performance is definitely a metric that are a definite ly am an area of performance that we're exploring I think the last one that we talked about talking about if I gather right yeah I think I did it was first input first input delay which is not directly shown in dev tools so what is it's not sometimes called fi D right what is that and and why yes so first input delay or fit or F ID for short represents the time from when the user you know interacts with the page of taps on the screen or you know clicks a key a keyboard key to the point when the browser is able to respond to that input event so this can you might think that it's always going to be instantaneous like you you know you click on the screen and then something will happen but as users we kind of know that that's not the case oftentimes you know we've all had the experience of clicking on something or tapping on something and not having an instant response and so this can happen if you know there's a bunch of JavaScript running on the page maybe you have a large javascript file that the browser is currently parsing and executing and then so if at that exact time a user taps on the screen then the browser has to wait a little bit of time before it can respond to that input event and so f ID quantifies like that duration of time and you mentioned they it's not exposed directly in dev tools and the reason is because I'm assuming you know here you're the one who else implement this but first input delay requires an input it requires a user and so you know in many lab scenarios there is no user and so you can't always measure first input delay that way but we have another metric called total blocking time that quantifies just how we do half yeah that's great and that quantifies how often the main thread how much of the main like how much time the main thread is blocked and mock me and threat as I just mentioned contributes to you know the likelihood that a user will interact with a page but the browser won't be able to respond right away so you said that total blocking time is in dev tools can you show me where that is yes oh I see their screen I have I have long tests over here and I yeah it is down there and it currently says it's unavailable and I'll talk about that more a little bit I've been working on that feature in fact today so I can tell you a little bit more about what's going on there too so what others I've come to web dev and I've cleared it and I'm just going to record and I'm gonna hit refresh and I don't expect here that I'm going to see any particular blocking time because I've got a first machine I'm on a good connection and yeah you can see right down to the bottom here we have total blocking time and it's currently set to 0 millisecond so what that roughly translates to over here is when we zoom in on these top-level tasks which are on the main thread we have no task that goes over 50 milliseconds so 50 milliseconds is our threshold for hey this task is long and it's it's gonna contribute to the the blocking time right because what we want to do is we want to keep a track on on tasks that that go over 50 milliseconds because they're the ones that are most likely were the user to interact they're the ones that are most likely to prevent the browser from being able to respond in in an adequate amount of time right so we currently have no tasks blocked that's a blocking time is defined as any time greater than 50 milliseconds in a task so if the task is right 49 milliseconds there 0 blocking time and if a task is 51 milliseconds there's 1 millisecond of blocking time and just out of curiosity some people asked why you know why 15 milliseconds what's the thinking behind that yeah so the answer is that the idea you might have heard of rail the rail performance model and you've heard often times people say you should always respond within 100 milliseconds of user input and so the question is why is 50 milliseconds to the blocking time and the idea there is that if you ever have if you keep all of your tasks below 50 milliseconds then there's never situation where to I can't both run within 100 millisecond threshold and so that's kind of if people are wondering why that 50 millisecond time exists and why we chose that for the magic number with total blocking time exactly and of course if you were doing an animation then your task time really should be under like 10 or - that's regular seconds so so we'd sort of it you got to be context aware the 50 milliseconds number is a it's a great number to have in mind especially for load performance but it does change depending on the context and whether you'll say animating or not now what as I said we have no tasks here that are running long and now if I got a trace like this from somebody I would be very happy perfect I'd say listen oh yeah I wouldn't complain at this at all but what I can do is I can least simulate a slower device like only before over my capture settings I'm going to go to like a 6-time slowdown and I'm expecting that this 25 milliseconds here is gonna run long so this is some JavaScript that's being evaluated so I'm going six times slow down I'm gonna hit record and I'm gonna refresh again okay I want to do two things I'm gonna stop the recording a little bit earlier than I did last time but the first thing to notice here is our tests are now longer because of the slowdown and if i zoom in on this task it's a hundred and seventy-six mm 0.5 five milliseconds and you can see it's qualified for being a long task goodbye once a hundred and twenty six point five five milliseconds okay so what we do is after the 50 millisecond point on this task we do this candy striping here and we also pop a red triangle up into the top right hand corner so that when you're looking at a glance like zoomed out you get a sense of just how many of your tasks are getting a bit long I think almost universally here the ones that are running long are JavaScript based yeah so if you if you again you know are looking at the chrome user experience report or search consoles chrome web miles report and you see that you have a first input delay that's higher than you would have expected for a certain page I think this is a great example of how you would go about debugging that so like you might you know be on your fast MacBook Pro lap or something and not see any long task but if you go into dev tools and you throttle the CPU and then you start seeing a bunch of long tests like shown here and that would help explain why because if a user tried to interact with the page during one of these long tasks the browser would not be able to respond it would have to wait until the task completed before it could run those event handlers yes so parting and sing unavailable there in the bottom in dev tools what does what does that mean yeah so sometimes we do say unavailable the reason is we wait for bleep to tell us when it's happy for us to declare the page interactive and at that point it tells us how much blocking time it measured and so sometimes if the trace isn't long enough we don't actually get that information so what I've been working on actually recently is adding in an estimate which is essentially counting up the amount of candy striping that we're getting right in those top-level records so that we can at least give you an estimate even if blink hasn't given us the kind of official answer so hopefully you should see that in Chrome Canary them soon yeah that makes sense because yeah total blocking time is technically the definition is the amount of blocking time between first content for paint and time to interactive and so it makes sense that dev tools would wait until the browser is interactive but yeah that does seem like a good feature to just give like in an unofficial total when it's not interactive yeah exactly so now we've talked about FCP LCP layout shifting and long tasks and F ID all fit uh yeah if I was a developer who wanted to know more about these things as well as playing within dev tools where would I go and get more information that's a great question you can go to web dev slash vitals and that will have you know all the information about the definitions of the metrics links to guides and how to optimize for them you know links to more information about all the tools that support them and everything like that so definitely the best place is to go to web dev slash vitals [Music] you [Music] [Applause] [Music] hello Aaron thank you for joining us today my name is Sebastian Benz I'm part of the amp developer relations team and my name is Nana Riesling honey and I'm a product manager on the amp project we want to talk about the work we are doing on amp to make better women less painful and developers more productive yeah I'm incredibly excited so let's dive right into it so now we would be remiss if we talked about em and didn't talk about the impact of Google's recent announcement around the page experience ranking signal absolutely so even before we can actually start talking about amp and page experience first let's just talk about what the announcement is in May the Google search team announced that they're going to measure how the page is experienced by the user in addition to price signals such as a pages usefulness and this whole suite of X measurements is called page experience it uses core web vitals which the chrome team announced earlier that month and adds other pre-existing signals such as mobile friendliness safe browsing and HTTPS on top of it and the great thing is that these metrics line up really well with apps design goals of making sure that users are getting a content forward experience on a rig and are able to consume content without having to download unnecessary resources or wait for unnecessary processing okay so how does empty against Page experience good catch actually we did some analysis and we saw that a majority of amp pages actually already do pretty well against this criteria this means the amp is really living up to the intention of being a well-lit path to creating a great page experience so you said that a majority of amp pages meet the criteria but not all yep so in the cases where the amp page doesn't perform well against the page experience criteria we saw that they failed for reasons that were outside of amps control such as overly large images being served on mobile devices or the server response time being too slow that's a really interesting key aspect of Kay experience that the Cobra bottles a mash-up from real user data this means to improve your covert battles for example it's a good idea to use a CDN to ensure that users around the world get your content delivered quickly yeah and just like other libraries and frameworks the amp project will be monitoring these metrics closely and continue investing in amps performance by our performance working group but more generally it's really important to note that amp will intends to reduce the ongoing effort needed to create pages that offer a great user experience and we intend to do so by helping offload tasks and burries such as browser compatibility accessibility javascript budgets etc at its core and as a UI component library before using amp often struggled with too much choice when it came to adding a new feature to a site having to decide whether should bit my own carousel which is a bad idea or finding a suitable existing implementation could take a lot of time and energy with amp you get a flexible high quality or I components out-of-the-box and you can be sure that these perform well are accessible and play along well with each other recently I talked to a developer from an agency which uses am forbidding most of their clients websites they told me that one of their design interns had been able to build a fully interactive website from one of their clients without any JavaScript knowledge I think that's fantastic and a great example for the value of a good UI component library it makes it easy to get started for beginners and then also experienced developers to focus on creating new user experiences instead of bike sharing technical details and that's exactly what we're focusing on in 2020 we want amp to be a cost-effective and simple solution that allows developers to focus on their product and not worry about other things like performance infrastructure etc and this is an effort that we're calling amp as a service the idea here is to use an as a turnkey solution to easily create and then maintain a great page experience and make developers more productive simultaneously so what exactly do you intend to do so the first thing that we really want to do is address the feedback that amp dibala purrs have and some of the top complaints that we've seen with amp is first the need for custom JavaScript and second the fact that the inline CSS limit is too small at 50 kilobytes now we address the need for custom JavaScript by adding amp script a component that allows you to add custom JavaScript to amp to help fulfill any business specific need that amp doesn't solve and if you want to hear more here you should stay tuned because our colleagues Ben Morris and crystal Lambert will be talking you through this in their talk titled for Christ GS now with our CSS limit the intention was to promote CSS hygiene but we got feedback that the limit was too tight at 50 kilobytes so we worked with the amp community to understand what a reasonable CSS limit could be and after working with plugin developers news publishers and e-commerce site creators we realized that most interactive experiences could actually fit in within 75 kilobytes of CSS and so that's what we made our new limit 75 kilobytes and this really seems to have hit the sweet spot with a verb to kill a by limit I have from many developers that they've been struggling with keeping this yes below the limit but I still have to hear from someone I'm starting with the 75 kilobyte Clement yeah fingers crossed that this limit works now aside from addressing feedback we wanted it we want to make developers more productive we want to help them create and maintain performance sites as well the problem usually wasn't with Ambit self but they they had to maintain two versions of the pages the canonical one and an additional one and one yep that's far that's by far the largest problem that amp developers have the problem is even more acute if you have separate teams that are working on the amp and mobile web experience especially if they're in separate parts of the organization to be honest the amp team itself advocated for paired amp experiences when we got started we saw it as an easy way to create amp pages with the least amount of effort but talking to developers over time has made us realise the amount of pain that can be associated with maintaining this dual code base and that this outweighs the initial gains of actually creating the amp page quickly and Google's page experience announcement is a great move for amp developers in this regard it allows development teams to really think about how they want to continue invest going forward okay so Sam I'm publishing paired em pages because we wanted to be in the Google top stories council should I continue doing this so in that case I would ask for you to consider the maintenance cost that you're incurring by having to maintain an amp version of your code and a non amp version of your code now that you have the option to be flexible with your tech stack you should be looking to pick a setup that allows all your web developers to be productive from day one so you're telling those we're going the pad and route to completed drop and support know what we're telling them is to pick something that makes them the most productive and this could be a number of things developers could pick experiences on their site that could actually benefit from amp and only invest in amp for those experiences or they could go fully and first across all their site if they actually believe that amp is able to meet their needs and we've gotten pretty positive feedback from developers who use amp as their main library because they think that amp makes them more productive and this is what we see amps future as a component library that helps developers be more productive and this is why we're investing in allowing everyone to use amp components even outside of amp pages it's an effort that we're calling bento app and we look forward to releasing it later this year I'm really excited about this focusing on amp as your I component library is a much healthier direction in my opinion and I'm very happy that we're making this move another era we were taking or learnings from and are making them available to provide your audience our server side optimizations from pages at the beginning AM pages we're mostly served from AM caches and these perform additional optimizations enabling Armstrong user experience however many developers started using and forbidding their whole website in these cases and pages are not stopped from cache and there's been room for improving and slowly performance to address this we created app optimizer a tool to bring am cache optimizations to publishers for example we use an optimized for the official app website and our dev and by using I'm optimizing achieves the same performance as when the page is served from an app cache and what I really like an optimized fits really well into our idea of amethyst service it enables us to automate back development best practices for example the latest of optimizer bodies added support for image sausage generation to make it easier to serve optimized images another example is JavaScript modules the amp project is soon going to start serving them runtime of components as JavaScript modules and if you're using amp optimizer you will automatically get the benefit of smaller runtime modules once this becomes available i'm that sounds so great and I'm really excited about all the improvements that are coming to optimizer but what's the best way for developers to actually include an optimizer I mean of course you could include it normally in your build pipeline or your rendering pipeline but ideally you shouldn't have to think about how to do get M optimizer our goal is to make the integration seamless by integrating an optimizer into existing frameworks and human senses the next is integration is a great example for what a good and urban experience can look like next is has a special amp mode that you enable your flag and this will result in the generated page being valid app the cool thing is that you can start using amp component straight out of the box and you don't need to worry about the EM boilerplate or importing M components all this is automatically added in the background by the optimizer which is integrated directly into next rhiness and the resulting editing experience is really nice it feels like web development from 30 years ago and a great example for this is as Axios they recently launched the new site and it's completely built on am using the XS and they've been really happy with the experience another example for a CMS that has these features integrated is WordPress recently the official and breakfast plug-in start the publishing optimized amp by default so this means if you build an amp age using WordPress you get the best serving performance for wow it's it's really exciting to see so many new experiences that are being bought using amp and in fact I'm optimizer and I'm really hoping to see more but that's it that's our time and that's our vision for 2020 the Google page experience announcement allows em to focus on what it does best be a UI component library that helps developers be more productive by helping them deploy web development best practices at scale and if you want to read more about Em's plans for 2020 please read our blog post and gilded amp a definite service and with that thank you for joining us if you want to learn more about amp in general you can visit amp death today thanks everyone and we will being an ordinal chat I'll answer your questions for a bit [Music] [Applause] [Music] hey there I'm Ben Morse I'm a developer advocate working on the web and on amps and I'm crystal Lambert technically a writer working for the web on the ant project we're here to talk about something we think it's pretty cool a new way to run javascript in web workers with amp awesome let's get started but then what is this slide JavaScript foe I love JavaScript it lets me do whatever I want sure javascript is amazing is Nathan modern web possible but we both know that many websites are too slow and that's partially caused by lots of JavaScript that's one of the reasons like people like this are staring at their phones waiting for our sites to load yeah that's no good you think the more JavaScript the better I could write more code to make things quicker well it's like too much ice cream or time spent at home you don't want to overdo it well what about these web workers I hear you can use them to get JavaScript off the main thread but I'm not sure how to get started yeah it can be pretty intimidating because the and another thing amp doesn't let me write my own JavaScript period huh can I make a video about that - well conveniently crystal this video can be about both those things because amp now provides an easy way to use workers so we're gonna show JavaScript developers how amping Z's new try web workers after people are already using apt I'll show you how you can write your own JavaScript without breaking a performance guarantees for everyone is a nice way to run JavaScript anyway it's unlikely - hungry web vital scores oh yeah I'm hearing lots about this Web vitals that's uh our pages first input delay largest contentful paid and cumulative layout shift right those are the three so let's get going another slide what is this a guy knitting yeah it's a transition slide well it does remind me why is the web single threaded I mean every modern OS has multiple threads why hasn't the web caught it honestly it's just how browsers and JavaScript have always been I mean of course modern browsers can multitask they can be more than one thing at a time but each browser to have as a single thread for the UI only one process can make changes to the screen at a time that means JavaScript can block the browser from doing things and vice versa but wait javascript is asynchronous right so whenever an event gets fired doesn't the event handlers code start running right away well sure but all the code in a web page still runs in a single thread this diagram illustrates JavaScript event loop so the browser fires an event you have an event handler that code runs until it's done as other events fire they get added to a queue mmm I see so if my code is handling one event and another event fires the browser just can't spin up another thread instead it has to wait for that event in the queue right it has to wait until the current code is done let's say the user taps a button while your code is running a long task well a JavaScript can't handle it any other event until your task completes so the next bit of code will be delayed we're still the browser may be unable to change the UI because it's waiting for your code I guess if it weren't that way everything would just be fighting for control over the Dom and you'd have race conditions and general oh yeah and unfortunately to make JavaScript thread safe we'd have to completely rewrite it all right this is making some sense not only can excessive JavaScript make your page slow to load it can also make the page slow to respond to users interactions I'm guessing this is where web workers coming yes javascript in a web worker runs in a different thread and this is not a new idea web workers have been around for about ten years okay ten years that's longer than I've been working on the web why am I just learning about them I think because their limits have made them harder to use workers can't cause race conditions with other workers or the main thread because they lack access to the Dom or the global scope instead a worker communicates with the main thread by passing messages back and forth each message contains an object there are libraries that make this simpler notably comlink by Surma and Recker eyes by Jason Miller but workers can't access the Dom so workers are great for doing long tasks off the main thread but what if you want access to the Dom that's a big obstacle and that's where I am script comes to the rescue I knew at some point we were gonna bring amp into this we did so in 2018 the amp project released an open source library called worker Dom worker Dom makes a copy of the Dom for the workers use worker Dom also recreates a subset of the standard Dom API this lets the worker manipulate the DOM and make changes on the page using standard techniques worker Dom keeps the copy of the DOM and the real Dom in sync so something changes in the real Dom worker Dom sends a message to the worker to make that change and the copy and if your record changes its copy worker Dom sends a message over to the real DOM and the same change gets made there so I heard you say amp is all of this only true for amp or can I use worker Dom with a different stack you can't import wicked Amon to your own project but worker Dom is super useful for amp since it provides the way to run JavaScript in a sandbox where it can't run rampant and break amps performance guarantees an amp encapsulates working Dom in a component called amp script this is a little abstract can you show me some code code I understand ok fine let's make a basic hello world example with Apps Script in the body we insert an amp script components the dama contains gets passed to the worker so here to the worker that entire DOM is that h1 tag next we put our code in a script tag whoa that's weird you set the type to plain text instead of text JavaScript yeah we did that's what the browser won't see it as JavaScript and just execute it immediately instead an script finds the code it puts into a worker so the code in this script here grabs the first h1 tag in the Dom and appends a comma and the word world right on page load and does that work look magic that was pretty quick let's watch it again I'm overwhelmed well okay it's not Gmail but that world was really and truly added by a web worker can you prove it if we open dev tools and go to the sources tab and click over here we can see our script right under the code added by M script okay that's kind of cool here's how that looks in a full web page I have looked some things out for simplicity's sake but you can see that as with all amp pages were loading amps runtime scripts we're also including the JavaScript that makes the Emma scripts work so do you always have to include your JavaScript in line like that it's not really a best practice yeah that's a good point we can also store the JavaScript in his own file by using am scripts source attribute like this so that example works but it's not really that useful could we say add that world when the user presses a button okay fine let's add to our HTML a button that says hello who will write JavaScript that grabs that button and adds a handler for the click event when you click the button it works its magic let's try it out so there's hello there's our button and look hello world okay let's go a little crazy super neato what else can we do does am script let us do a fetch does it ever hears that hello world example modified to retrieve the word world from an endpoint workers natively support fetch XML HTTP requests and even WebSockets okay this is getting pretty cool but this is amp right how does aunt just let me write any JavaScript I want well that's a good point amp tries hard to guarantee you low cumulative layout shift to keep page elements from moving around if your code makes mutations to the page that would really disturb the page layout and preserves the right to disallow those changes or even shut the worker down if you're on script container can't change size it can't disturb the page as much and that gives you more freedom that's why I specified the height and width here in the HTML and why I didn't choose amps container layout there's a lot to this check the documentation on mo for details hold on can I just use amp script to inject more scripts into the Dom nope you're working with virtual Dom not gonna work fair enough but I see something about not allowing more than a hundred and fifty kilobytes of JavaScript is that on a page level that's where that 150 k is per page but I could still fit jQuery into that and I can just copy in my favorite image slider and charter libraries well remember the word Kadam is recreated um API that supports in its own JavaScript if we're Kodama supported the whole Dom API it would be cumbersome and huge it would slow down pages enormous ly it's a pretty few third-party libraries are going to work right out of the box okay and what's the best way to use Apps Script well one way is to use vanilla JavaScript while keeping an eye on this table of supported api's there is quite a bit there wait react can I use react yes that's the other way react uses a very specific subset of the Dom API so the worker Dom teammate stirred that subset is well supported okay but I've used react before my react bundle might need to break that 150 kilobyte limit yeah that's why it's probably better to use pre act instead pre act as highly compatible with react but it's only 3k minified in gzipped for projects with more code pre actives probably the way to go here I've made the button example using pre act I find it easier to write the debug the JSX in a simpler environment and then build it into my amp page so let's build this let's start up our server and there's our page with our button it works alright that was a lot if only there was an ant script tutorial out there wait a minute didn't you and I already make one of those yeah you want to take the next slide of course that tutorial is a great introduction to amp script head on over to go amp dev slash learn - script to get started and then keep on going remember that worker Dom is still quite new if you have feature requests or if I things that are missing please get involved on github help improve it in conclusion web workers can help you keep JavaScript from slowing down your web pages amp script is a nice way to try this technique out you can find all the code from this talk here on glitch thanks for listening and let's get to work on putting workers to work for you [Music] [Applause] [Music] hi everyone thanks for watching this session on debugging JavaScript SEO issues in the next 15 minutes I will take you on a short journey in which we will talk a bit about the various that a few SEO still have about JavaScript and Google search then look at the tools available to SEO and developers and then get our hands dirty on a few case studies from the real world now let's get started with looking at the basics can SEO and JavaScript be friends there's a bunch of history behind this that contributed to various opinions and answers to this question today the answer is generally yes sure as with every technology there are things that can go wrong but there's nothing inherently or categorically wrong with JavaScript sites in Google search let's look at a few things people tend to get wrong about javascript and search the number one concern brought up is that Googlebot does not support modern JavaScript or has otherwise very limited capabilities in terms of JavaScript features at Google IO 2019 we announced the Evergreen Googlebot this means that Googlebot uses a current stable Chrome to render websites and execute JavaScript and that Googlebot follows the release of new chrome versions quite closely another worry is concerned with the two waves of indexing and the delay between crawling and rendering Googlebot renders all pages and the two waves were a simplification of the process that isn't accurate anymore the time page is spent in the queue between crawling and rendering is very very short five seconds at the median a few minutes for the 90th percentile rendering itself well takes as long as it takes your website to load in the browser last but not least be wary of blanket statements that paint JavaScript as the general SEO issue well some search engines might still have limited capabilities for processing javascript they ultimately want to understand modern websites and that includes javascript if javascript is used responsibly tested properly and implemented correctly then there are no issues for google search in particular and solutions exist for SEO in general for example you may consider server-side rendering or use dynamic rendering as a workaround further crawlers when saying test your site properly the follow-up question is usually well how do I test my site properly and luckily we have a whole toolkit for you to test your site for Google search let's take a look at what's available the first tool in your tool belt is Google search console it's a super powerful tool for your Google search performance besides a ton of reports it contains the gyro inspection tool that lets you check if the URL is in Google search if there are any issues and how Googlebot sees the page the second tool that is really helpful is the rich results tests it takes any URL or lets you copy and paste code to check its main purpose is to show a structured data is correctly implemented but it has much more to offer than just that last but not least the mobile-friendly test is similar to the rich results test on top of the rendered HTML the status of all embedded resources and network requests it also shows an above the full screen shot of the page as well as possible mobile user experience issues now let's take these tools for spin I have built three websites based on real cases that I debug in the webmaster forums the first case is a single page application that does not show up and will at all as I'm not the owner of the domain I don't have access to Google search console for this side but I can still take a look I will start with a mobile-friendly test to get a first look at the page in question as we can see the page loads but shows an error message when I load the page in the browser it displays the data correctly hmm we can take a look at the resources Googlebot tried to load for this page here we see that one wasn't loaded the API dot example.org slash products URL wasn't loaded because it's blocked by robots.txt when Googlebot renders it respects the robots.txt for each network request it needs to make be HTML CSS JavaScript images or API calls in this case someone prevented Googlebot from making the API call by disallowing it in robots.txt in this case the web app handles a failed API request as a not found error and shows a corresponding message to the user we caught this as a software for and as it is an error page we didn't index it take note that there are safer ways to show a 404 page in a single page app such as redirecting to a URL with a 4/4 status or setting the page to new index right we solved that one that's pretty good all right on to the next one this one is described as a progressive web app or PWA that didn't show up in search except for their home page let's go find out why looking at the home page it looks alright the other views in this progressive web app also load just fine hmm let's test one of these pages we will use the mobile-friendly test again to get a first look at what's going on oh the test says it can't access the page but it worked in the browser so let's check with our dev tools in the network tab I see that I get 200 status from the serviceworker though what happens when I open the page in an incognito window oops so the server isn't actually properly set up to display the page instead the serviceworker does all the work to handle the navigation that isn't good Googlebot has to behave like a first-time visitor so loads page without the serviceworker cookies and so on this needs to be fixed on the server great two websites fixed but I have one more to go this one is a news website that is worried because not all content can be found by a Google search to mix things up a little bit I'll use the rich results test for this one the website doesn't seem to have any obvious issues let's look at the rendered HTML hmm even that looks fine to me so let's take a look at the website in the browser so it loads 10 news stories and links to each new story and then loads more stories as I scroll down do we find that in the render HTML 2 interesting this story isn't in the rendered HTML it looks like the initial 10 stories are there but none of the content that is being loaded on scroll wait does it work when I resize the window oops it only works when the user Scrolls well Google but doesn't scroll that's why these stories are loaded that's not exactly a problem this can be solved by using an intersection observer for instance generally I recommend checking out the documentation at developers.google.com slash search for much more information on this topic and other topics I hope this was interesting and helped you with testing your websites for Google search keep building cool stuff on the web and take care [Music] [Applause] [Music] hi everyone I'm excited to show you in the next 15 minutes how you can use structured data to make your website stand out more in Google search and how that can be done with JavaScript when a static implementation isn't feasible we will start by looking at what structured data is and why it is a good idea for your website then we will look at ways to implement it using JavaScript and last but not least we'll take a look at how to test and debug your implementation all right now what a structured data and why is it useful structured data is a standardized set of additional markup that you can put on your pages to tell machines like Googlebot more about the content on your page on the right side here you can see the information for a specific product being highlighted in both the image search as well as the search results including additional information like ratings and price we call such results rich results to implement structured data you can use json-ld microdata or rdf a but we recommend using json-ld here is an example of what a json-ld block on your page might look like besides products there are many verticals that can benefit from structured data and become manageable for which results here are some examples but you should check the link for the full gallery of supported verticals note that implementing structured data makes the page eligible for rich results but does not mean that we will always show them for every page that implements it so now we talked about what structured data is and how it benefits your website let's walk through a few possible implementations we've seen that the easiest way is to include a script tag with the json-ld data in the page this can of course be done in the backend or straightening the HTML of a page but what are the options if you are using client-side when there Charles first of all it is fine to implement it dynamically with client-side JavaScript we recommend to use server-side rendering to make your website as robust as possible but there is no issue with implementing it with JavaScript per se in this session we will look at three possible implementation approaches of course you can use JavaScript without libraries or frameworks to inject structured data into your pages here is an example of a vanilla JavaScript implementation for a client-side rendering single page application it fetches the json-ld data from an API and injects it into the head of the page as Googlebot renders this page it will execute the JavaScript and the structured data will be rendered just make sure that the API is available to Googlebot and not blocked by robots.txt when you are using frameworks such as react angular or view J's you very likely have helpers or built-in functionality available to insert structured data into your pages here is an example of a react component using the schema helper utility to create typed json-ld for a person's profile page should you not have access to the code of your pages but have Google tag manager on these pages you may use a custom tag in custom variables to create structured data from the information that is on the page to do that create a custom HTML tag in your container and insert the relevant json-ld as well as the variables for the values of each field in the json-ld block then create the necessary custom JavaScript variables to extract information from the page so it can be inserted into the custom HTML tag automatically we advise not to copy and paste information from the page directly into Google tag manager as that will likely cause a mismatch between page content and structure data generated by a Google tag manager to rise in the future right so we've seen three of generating structured data with JavaScript let's find out if our implementation works as expected there are two main tools for testing the implementations the first one is the rich results test you can paste a URL into the tool and see what structured data is recognized as well as if there are any issues with the structured data on the page when using javascript to generate structured data we recommend testing a URL instead of pasting code directly into the tool the other great tool for testing this is the Google search console in the URL inspection tool you can see the structured data that is detected and if it is valid but you can also see which pages of your site were eligible for which results and which ones have arrows or warnings to look into if you want to learn more about Google search in structured data check out our documentation at developers.google.com slash search or use this short link to read more on how to use javascript to generate structured data for your pages thanks a lot for joining and have a great day bye [Music] [Applause] [Music] you