Core Web Vitals performance metrics are complex and imperfect, and fixing page experience snags can be perplexing. Even now, Google made last-minute changes for upgrading all its tools to include sharpened formulas in response to cases brought by developers in the field.<\/p>\n
You can generally look forward to improved scores if you have been affected by the metrics which have undergone some reengineering. Particularly helpful are modifications to the way\u00a0Largest Contentful Paint (LCP)\u00a0and\u00a0Cumulative Layout Shift (CLS)\u00a0are measured.<\/p>\n
Changes to First Contentful Paint<\/h2>\n
The threshold for achieving \u201cgood\u201d scores for\u00a0First Contentful Paint (FCP), components of which contribute to Core Web Vitals without FCP actually being one, increased from 1.0 to 1.8 seconds. FCP accounts for\u00a0Time to First Byte, more a reflection of your server response time than anything you manipulate directly with code, plus the time it takes to process\u00a0render-blocking resources\u00a0such as CSS, which you can.<\/p>\n
Changes to Largest Contentful Paint<\/h2>\n
LCP, a significant milestone in the lifecycle of a page, originally didn\u2019t include some offscreen elements. Now LCP pinpoints the largest element even if after it is later removed from the page DOM once discovered, or when several images of the same size all qualify.<\/p>\n
Such situations occur when carousels load and cache content for offscreen slides. Another helpful modification is\u00a0background images get ignored by LCP, as well.<\/p>\n
Changes to Cumulative Layout Shift<\/h2>\n
To prevent situations like extremely long browsing sessions undermining CLS scores, smaller \u201cwindow\u201d sessions are capped at 5-seconds, marked as ended by a 1-second gap as a boundary to find the page\u2019s\u00a0worst 5 seconds of layout shifting.<\/p>\n
That\u2019s a much better representation of shifting than tallying wholly uncapped sessions which can last 20-minutes or more for scores that are blown way out of proportion.<\/p>\n
What\u2019s Old is New<\/h2>\n
Google won\u2019t be using the old calculation as part of the page experience ranking factor. For outlier use cases, however, whole session scores can still be useful. The way these data are retrievable by API means the old score calculation can live a second life for those who want it. You\u2019ll be able to retrieve it independently or by accessing Google\u2019s open repository via\u00a0CrUX Report (SQL):\u00a0 The trick is learning about more than one official way to retrieve your scores, which gets further complicated by how to think about the data you\u2019re viewing.\u00a0Page Speed Insights (PSI), often highlighted by SEO practitioners, doesn\u2019t provide enough information on its own to tell the whole story.<\/p>\n PSI is designed to give a comprehensive snapshot to developers for troubleshooting performance problems. When available from CrUX, field data aggregated over a previous 4-week period is useful for making comparisons. An appearance of both lab and field data will undoubtedly display a difference between the two.<\/p>\n Variance is a natural occurrence between testing sessions and when comparing tests from different devices and or networks. Field data, therefore, varies as wildly as a given website\u2019s audience. PSI field data, therefore, represents a range of data, aggregated over the previous 28-days, up to the most recently completed full day’s worth of data.<\/p>\n Google\u2019s page experience ranking factor conceivably could rely on the same previous 28-day aggregated scores. It\u2019s unlikely to, however, as it would be far more performant if Google\u2019s page experience ranking factor relied instead on the preceding month\u2019s aggregated 28-day prepared BigQuery dataset. In that case, we can expect any ranking changes to take effect on the second Tuesday of each new month.<\/p>\n That is, BigQuery data for CrUX reports undergo a performance optimization process that prepares the preceding month\u2019s data for public consumption. Such indexing, and possibly caching certain query responses, allow CrUX users to query historically all the way back to late 2017 when data was first being collected. Announcements arrive the second Tuesday of each new month for when the previous month is ready for queries.<\/p>\n Lighthouse lab scores in PSI are \u201ccalibrated to be representative of your upper percentiles\u201d for worst-case scenarios, like that of underpowered browsers on sluggish networks. Google purposefully calibrates it so developers have richer feedback to more easily troubleshoot problem areas that can occur but are less common in the real world.<\/p>\n If lab scores were indicative of more average conditions, it wouldn\u2019t reveal the performance bottlenecks developers need to see for making changes to improve page experience under stress conditions. Lighthouse outside of PSI, in Dev Tools or packaged by NPM as an open Node project, can be calibrated to simulate various scenarios.<\/p>\n It\u2019s incredibly important to read scores understanding what data gathering method was used for powering the scores you have at hand. In the case of PSI, you may see both lab and field data and they shouldn\u2019t be confused as the same thing. Field data is collected for CrUX reports and you can collect it on your own, as well. Field data is indicative of the audience as recorded by browsers with real-world usage of your website.<\/p>\n Field data is important because it is what Google uses for its page experience ranking factor. Field data scores will almost invariably be better than lab data scores for the same page. Field data stable through time once prepared for long-term storage performance, (which you can refine by several criteria), with recent data newly prepared on a monthly basis, while\u00a0lab data can differ with each new test.<\/p>\n When browsers have the requisite permissions to transmit scores, field data gets sent and collected for use by PSI, any\u00a0Core Web Vitals tool\u00a0that uses the\u00a0CrUX open API, or for those who write\u00a0Core Web Vitals JavaScript\u00a0into web pages. The only way to examine field data in real-time is to opt for writing the JavaScript and collecting it for your own use in a browser console or repository, or having it sent to Google Analytics.<\/p>\n The open-source Lighthouse project is what powers lab data and it has been implemented in Dev Tools and can also be installed in a package that comes with its own Command Line Interpreter (CLI). Lighthouse in Dev Tools can be configured to match decreased or boosted power and speed from the \u201cupper percentile\u201d default.<\/p>\n You might want to simulate varying power and speed, for example, if you have the wherewithal to deliver more elaborate experiences at certain simulated thresholds implementing a progressive enhancement strategy.<\/p>\n Lab data as available working from a local machine perhaps integrated into a workflow as part of pre-production testing and a continuous integration process. This type of setup requires you to have the Chrome web browser and Node installed.<\/p>\n The CLI will spawn a Chrome browser process for access to the rendering engine and Lighthouse library. It will tabulate data returned by, and then afterward kill that Chrome process. Options for opening the resulting report and calibrating to device and network settings are available as part of the command options<\/p>\n The most common options will be\u00a0 We really only care about these specific concerns if we\u2019re developers learning to troubleshoot and improve performance factors that affect page experience. Even when we\u2019re unconcerned about SEO, these factors are incredibly important for how our pages and applications which render pages, including native applications with WebViews, are experienced by actual users in the field.<\/p>\n All too often, an application that gets heavy usage results in countless hours of frustration and can negatively impact the bottom line. The NYTimes native apps on mobile phone-sized screens, for example, load content and script slowly under even the best networks conditions. It results in delays scrolling and clicking even after a top story is rendered in the viewport. It can further be truly awful to navigate constant layout shifting when adverts load at inconveniently delayed times.<\/p>\n Google has plenty of case studies that show the positive effect on revenue when implementing performance fixes brings more positive experiences. If not for the value of NYTimes content, their app might be further derided and suffer even far less useful than it currently enjoys. The app should definitely be improved which would be a welcomed change for so many readers.<\/p>\n If you are inclined to want to dive deep into Core Web Vitals, then be sure to attend our upcoming SMX Advanced conference sessions\u00a0next week. For those of you who are developers, the SEO for Developers Workshops on the 17th and 18th explore these topics with greater depth and detail.<\/p>\n","protected":false},"excerpt":{"rendered":" Google\u2019s mobile page experience ranking factor, originally thought to be part of May\u2019s\u00a0Core Ranking Update, will be rolling out in a matter of days. Are you ready? If not take heart. There are several weeks reserved for observation and adjustment: \u201cPage experience\u00a0won\u2019t play its full role as part of those systems until the end of […]<\/p>\n","protected":false},"author":1,"featured_media":892,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[3],"tags":[15],"yoast_head":"\nuncapped_cumulative_layout_shift<\/code>.<\/p>\nSELECT\r\n uncapped_cls\r\nFROM\r\n `chrome-ux-report.all.202105`,\r\n UNNEST(\r\n experimental.uncapped_cumulative_layout_shift.histogram.bin\r\n )\r\nAS uncapped_cls\r\nWHERE\r\n origin = 'https:\/\/searchengineland.com'<\/code><\/pre>\nWhen Page Speed Insights (PSI) Data is Useful<\/h2>\n
The CrUX of It<\/h2>\n
Lab Data Provide Richer Feedback<\/h2>\n
Field Data Provides Real-world Usage Examples<\/h2>\n
Use Lab Data for Optimization<\/h2>\n
CLI Usage<\/h2>\n
$ lighthouse <url> [OPTIONS]<\/code><\/pre>\n--view<\/code>, which automatically opens the report in your system default web browser,\u00a0--throttle<\/code>\u00a0directives for simulating different device environments, and\u00a0--only-categories<\/code>\u00a0for limiting tests to just those which affect performance and have subsequent determinant factors for Core Web Vitals. Although running SEO tests is useful, too many SEO improvements don\u2019t move the needle for Core Web Vitals.<\/p>\n![\"\"](\"https:\/\/searchengineland.com\/figz\/wp-content\/seloads\/2021\/06\/lighthouse-cli-1-800x131.png\")
Why We Care<\/h2>\n