PageSpeed explained

Google

• CrUX

  CrUX is short for Chrome User Experience Report and is able to provide you with real user data.

  You might have seen the data of your own website or webshop already, for example via:

  • PageSpeed Insights;
  • Datastudio Dashboard.

  You can even directly query the data using queries within Google BigQuery, where data is actually being stored.

  Google's explanation on Chrome User Experience Report.

• BigQuery

  Google BigQuery is a Google database containing Chrome User Experience data. You can query the data yourself, for example searching data of your own or your competitors website or webshop, maybe split across multiple dimensions. For example specific metrics, devices or months.

  Each first terabyte of used data per month will be free. Do note though that the following query could already use 65GB of data:

  SELECT
  *
  FROM
  `chrome-ux-report.materialized.metrics_summary`
  WHERE
  origin = 'https://www.google.com' AND
  yyyymm = 202001

• Google Data Studio Dashboard

  Google Data Studio is a free to use reporting and visualization tooling. Even for non-Google data, you can use existing templates to create your own dashboards.

  The same applies for Chrome User Experience data of your very own website as well. Google created a ready to go template. Use my free tooling if you don't clicking configuring it yourself.

  Your free CrUX datastudio dashboard

• Google Search Console

  Google Search Console used to be called Google Webmaster Tools. Google Search Console will aid website owners in viewing and monitoring search traffic (impressions, ranking, clicks) and performance (web vitals, crawlability).

  Any crawl- or Web Vitals issues are, for example, reported as well within Google Search Console to enable website owners to act rather sooner than later.

• Chromium

  Chromium isn't completely the same as Google Chrome. When introduced in 2008, its source code became open source and is still maintained by the Chromium Project. While Google Chrome is just adding their own features, the underlying Chromium can also be used by other browser vendors.

  For example, While Microsoft Edge was running on EdgeHTML, they are now running on Chromium too.

• Google Chrome

  Chrome is Google's browser running on Chromium. Chrome is the one browser that is sending data to Chrome User Experience report in order to supply website owners with real user experience data of their websites and webshops.

  Data is only submitted by Google Chrome when users did not opt out to this feature.

• Visual indicator

  Google announced a visual indicator within their search engine results pages for webpages or origins that would be having sufficient data to show a reliable indicator. When passing Core Web Vitals, you might get a positive visual indicator. Or when just nog passing Core Web Vitals, you might not get any visual indicator at all.

• AMP

  AMP stands for Accelerated Mobile Pages. This basically is an HTML framework enabling you to provide better page experience via improved pagespeed and performance. This would mean you had to install a plugin for your CMS or create AMP pages yourself. AMP pages would then be served by default when clicking on Google results, or for example when clicking on AMP pages within social media apps, such as Twitter or LinkedIn.

  AMP was introduced in October 2015, way before Core Web Vitals. AMP could be seen as a signal as to where Google is heading, which eventually led to Core Web Vitals: improved user experience for users using Google Search.

• Lighthouse

  Google Lighthouse is an analysis tooling to analyse performance, accessibility, best practices, SEO and PWA. Lighthouse is embedded within Google Chrome, but can also be used in other ways. In can be used in a headless setup to do automated testing and PageSpeed Insights is actually running a Lighthouse performance analysis when submitting your url.

PageSpeed Insights

• PageSpeed Insights

• Field data

• Lab data

• Origin summary

• 28 days collection period

• Eliminate render-blocking resources

  Resources are blocking the first paint of your page. Consider delivering critical JS/CSS inline and deferring all non-critical JS/styles.

  .

• Parse blocking

• Preload key requests

  Consider using `<link rel=preload>` to prioritize fetching resources that are currently requested later in page load.

  .

• Remove unused JavaScript

  Remove unused JavaScript to reduce bytes consumed by network activity.

  .

• Serve images in next-gen formats

  Image formats like JPEG 2000, JPEG XR, and WebP often provide better compression than PNG or JPEG, which means faster downloads and less data consumption.

  .

• Ensure text remains visible during webfont load

  Leverage the font-display CSS feature to ensure text is user-visible while webfonts are loading.

  .

• Reduce the impact of third-party code

  Third-party code can significantly impact load performance. Limit the number of redundant third-party providers and try to load third-party code after your page has primarily finished loading.

  .

• Minimize main-thread work

  Consider reducing the time spent parsing, compiling and executing JS. You may find delivering smaller JS payloads helps with this.

  .

• Reduce JavaScript execution time

  Consider reducing the time spent parsing, compiling, and executing JS. You may find delivering smaller JS payloads helps with this.

  .

• Avoid an excessive DOM size

  A large DOM will increase memory usage, cause longer style calculations, and produce costly layout reflows

  .

• Avoid long main-thread tasks

  Lists the longest tasks on the main thread, useful for identifying worst contributors to input delay.

  .

• Preconnect to required origins

  Consider adding `preconnect` or `dns-prefetch` resource hints to establish early connections to important third-party origins.

  .

• Defer offscreen images

  Consider lazy-loading offscreen and hidden images after all critical resources have finished loading to lower time to interactive.

  .

• Properly size images

  Serve images that are appropriately-sized to save cellular data and improve load time.

  .

Core Web Vitals

• Core Web Vitals

  Google introduced Core Web Vitals to help you gain real life insight in how your users experience your website or webshop. At the same time, the Core Web Vitals thresholds are also giving you a clear picture as to what to achieve in order to:

  • improve page experience, reducing bounce-rate;
  • benefit from Google's announced ranking update, taking Core Web Vitals into account.

  Currently, the Core Web Vitals contains a set of three metrics:

  • First Input Delay;
  • Largest Contentful Paint;
  • Cumulative Layout Shift.

• Pageview

  A pageview is a user action where a user is navigation to another page. Within Core Web Vitals, this is important as Core Web Vitals is about all pageviews and not only -for example- first uncached pageviews within new sessions.

  An important nuance is that soft page navigations aren't initiating a new Core Web Vitals pageview, having its own consequences.

• Soft navigations

  Soft navigations are often produced by client side rendered websites or webapps, such as Single Page Applications. Instead of going to a new page, the contents of the clicked link is being fetched and inserted into the current page in case of soft navigations. On top of that, the url will change dynamically and a developer is responsible to also take care of technical SEO/crawlability as well as analytics tracking.

  However, as soft navigations aren't default browser pagehits, the performance APIs aren't treating them as new page views. As a result:

  • any CLS happening on such pages might add up to the CLS of the previous page;
  • LCP of new pageviews aren't tracked and won't average out overall LCP.

• Page loading

  Page loading as part of Core Web Vitals is the non-technical description of the Largest Contentful Paint metric.

• Interactivity

  Interactivity as part of Core Web Vitals is the non-technical description of the First Input Delay metric.

• Visual stability

  Visual stability as part of Core Web Vitals is the non-technical description of the Cumulative Layout Shift metric.

• Thresholds

  Each metric is setup with thresholds. Specific regions for specific units to communicate a good, moderate and poor user experience for a specific metric. For thresholds per metric, see:

  • Time to First Byte;
  • First Contentful Paint;
  • Largest Contentful Paint;
  • First Input Delay;
  • Cumulative Layout Shift.

• 75th percentile

  When it comes to the Core Web Vitals metrics, it's the 75th percentile that counts. Meaning, at least 75% of all pageviews should have an experience that falls within the "good" threshold.