{"id":507,"date":"2023-10-31T15:00:00","date_gmt":"2023-10-31T16:00:00","guid":{"rendered":"https:\/\/upprofits.net\/?p=507"},"modified":"2024-08-30T11:28:33","modified_gmt":"2024-08-30T11:28:33","slug":"answering-common-questions-about-interpreting-page-speed-reports","status":"publish","type":"post","link":"https:\/\/upprofits.net\/index.php\/2023\/10\/31\/answering-common-questions-about-interpreting-page-speed-reports\/","title":{"rendered":"Answering Common Questions About Interpreting Page Speed Reports"},"content":{"rendered":"<p>              <title>Answering Common Questions About Interpreting Page Speed Reports<\/title><\/p>\n<article>\n<header>\n<h1>Answering Common Questions About Interpreting Page Speed Reports<\/h1>\n<address>Geoff Graham<\/address>\n<p>                  2023-10-31T16:00:00+00:00<br \/>\n                  2024-08-30T10:05:08+00:00<br \/>\n                <\/header>\n<p>This article is sponsored by <b>DebugBear<\/b><\/p>\n<p>Running a performance check on your site isn\u2019t too terribly difficult. It may even be something you do regularly with Lighthouse in Chrome DevTools, where testing is freely available and produces a very attractive-looking report.<\/p>\n<figure class=\"\n  \n    break-out article__image\n  \n  \n  \"><\/p>\n<p>    <a href=\"https:\/\/files.smashing.media\/articles\/answering-questions-interpreting-page-speed-reports\/1-lighthouse-report-smashing-magazine.png\"><\/p>\n<p>    <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"561\" src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/answering-questions-interpreting-page-speed-reports\/1-lighthouse-report-smashing-magazine.png\" alt=\"Lighthouse report on Smashing Magazine performance\" \/><\/p>\n<p>    <\/a><figcaption class=\"op-vertical-bottom\">\n      Can\u2019t be perfect every time! (<a href=\"https:\/\/files.smashing.media\/articles\/answering-questions-interpreting-page-speed-reports\/1-lighthouse-report-smashing-magazine.png\">Large preview<\/a>)<br \/>\n    <\/figcaption><\/figure>\n<p>Lighthouse is only one performance auditing tool out of many. The convenience of having it tucked into Chrome DevTools is what makes it an easy go-to for many developers.<\/p>\n<p>But do you know <em>how<\/em> Lighthouse calculates performance metrics like First Contentful Paint (FCP), Total Blocking Time (TBT), and Cumulative Layout Shift (CLS)? There\u2019s a <a href=\"https:\/\/googlechrome.github.io\/lighthouse\/scorecalc\/#FCP=620&amp;SI=730&amp;FMP=635&amp;TTI=635&amp;FCI=6500&amp;LCP=980&amp;TBT=0&amp;CLS=0.01&amp;device=desktop&amp;version=10\">handy calculator<\/a> linked up in the report summary that lets you adjust performance values to see how they impact the overall score. Still, there\u2019s nothing in there to tell us about the data Lighthouse is using to evaluate metrics. The <a href=\"https:\/\/developer.chrome.com\/docs\/lighthouse\/performance\/performance-scoring\/\">linked-up explainer<\/a> provides more details, from how scores are weighted to why scores may fluctuate between test runs.<\/p>\n<p>Why do we need Lighthouse at all when Google also offers similar reports in <a href=\"https:\/\/pagespeed.web.dev\">PageSpeed Insights<\/a> (PSI)? The truth is that the two tools were fairly distinct until <a href=\"https:\/\/developers.google.com\/speed\/docs\/insights\/release_notes#november-2018\">PSI was updated in 2018<\/a> to use Lighthouse reporting.<\/p>\n<figure class=\"\n  \n    break-out article__image\n  \n  \n  \"><\/p>\n<p>    <a href=\"https:\/\/files.smashing.media\/articles\/answering-questions-interpreting-page-speed-reports\/2-psi-report-smashing-magazine-performance.png\"><\/p>\n<p>    <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"598\" src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/answering-questions-interpreting-page-speed-reports\/2-psi-report-smashing-magazine-performance.png\" alt=\"PSI report on Smashing Magazine performance\" \/><\/p>\n<p>    <\/a><figcaption class=\"op-vertical-bottom\">\n      (<a href=\"https:\/\/files.smashing.media\/articles\/answering-questions-interpreting-page-speed-reports\/2-psi-report-smashing-magazine-performance.png\">Large preview<\/a>)<br \/>\n    <\/figcaption><\/figure>\n<p>Did you notice that the Performance score in Lighthouse is different from that PSI screenshot? How can one report result in a near-perfect score while the other appears to find more reasons to lower the score? Shouldn\u2019t they be the same if both reports rely on the same underlying tooling to generate scores?<\/p>\n<p>That\u2019s what this article is about. <strong>Different tools make different assumptions using different data<\/strong>, whether we are talking about Lighthouse, PageSpeed Insights, or commercial services like <a href=\"https:\/\/www.debugbear.com\/?utm_campaign=sm-2\">DebugBear<\/a>. That\u2019s what accounts for different results. But there are more specific reasons for the divergence.<\/p>\n<p>Let\u2019s dig into those by answering a set of common questions that pop up during performance audits.<\/p>\n<h2 id=\"what-does-it-mean-when-pagespeed-insights-says-it-uses-real-user-experience-data\">What Does It Mean When PageSpeed Insights Says It Uses \u201cReal-User Experience Data\u201d?<\/h2>\n<p>This is a great question because it provides a lot of context for why it\u2019s possible to get varying results from different performance auditing tools. In fact, when we say \u201creal user data,\u201d we\u2019re really referring to two different types of data. And when discussing the two types of data, we\u2019re actually talking about what is called <strong>real-user monitoring<\/strong>, or RUM for short.<\/p>\n<h3 id=\"type-1-chrome-user-experience-report-crux\">Type 1: Chrome User Experience Report (CrUX)<\/h3>\n<p>What PSI means by \u201creal-user experience data\u201d is that it evaluates the performance data used to measure the core web vitals from your tests against the core web vitals data of actual real-life users. That real-life data is pulled from the <a href=\"https:\/\/developer.chrome.com\/docs\/crux\/\">Chrome User Experience (CrUX) report<\/a>, a set of anonymized data collected from Chrome users &mdash; at least <a href=\"https:\/\/developer.chrome.com\/docs\/crux\/methodology\/#user-eligibility\">those who have consented to share data<\/a>.<\/p>\n<p>CrUX data is important because it is how web core vitals are measured, which, in turn, <a href=\"https:\/\/www.debugbear.com\/docs\/core-web-vitals-ranking-factor?utm_campaign=sm-2\">are a ranking factor for Google\u2019s search results<\/a>. <strong>Google focuses on the 75th percentile of users<\/strong> in the CrUX data when reporting core web vitals metrics. This way, the data represents a vast majority of users while minimizing the possibility of outlier experiences.<\/p>\n<p>But it comes with caveats. For example, the data is pretty slow to update, refreshing every 28 days, meaning it is not the same as real-time monitoring. At the same time, if you plan on using the data yourself, you may find yourself limited to reporting within that floating 28-day range unless you make use of the <a href=\"https:\/\/developer.chrome.com\/docs\/crux\/history-api\/\">CrUX History API<\/a> or <a href=\"https:\/\/developer.chrome.com\/docs\/crux\/bigquery\/\">BigQuery<\/a> to produce historical results you can measure against. CrUX is what fuels PSI and Google Search Console, but it is also available in other tools you may already use.<\/p>\n<p>Barry Pollard, a web performance developer advocate for Chrome, <a href=\"https:\/\/www.smashingmagazine.com\/2021\/04\/complete-guide-measure-core-web-vitals\/\">wrote an excellent primer on the CrUX Report for Smashing Magazine<\/a>.<\/p>\n<h3 id=\"type-2-full-real-user-monitoring-rum\">Type 2: Full Real-User Monitoring (RUM)<\/h3>\n<p>If CrUX offers one flavor of real-user data, then we can consider \u201cfull real-user data\u201d to be another flavor that provides even more in the way individual experiences, such as specific network requests made by the page. This data is distinct from CrUX because it\u2019s collected directly by the website owner by installing an analytics snippet on their website.<\/p>\n<p>Unlike CrUX data, full RUM pulls data from other users using other browsers in addition to Chrome and does so on a continual basis. That means there\u2019s no waiting 28 days for a fresh set of data to see the impact of any changes made to a site.<\/p>\n<p>You can see how you might wind up with different results in performance tests simply by the type of real-user monitoring (RUM) that is in use. Both types are useful, but<\/p>\n<blockquote class=\"pull-quote\">\n<p>\n    <a class=\"pull-quote__link\" aria-label=\"Share on Twitter\" href=\"https:\/\/twitter.com\/share?text=%0aYou%20might%20find%20that%20CrUX-based%20results%20are%20excellent%20for%20more%20of%20a%20current%20high-level%20view%20of%20performance%20than%20they%20are%20an%20accurate%20reflection%20of%20the%20users%20on%20your%20site%20because%20of%20that%2028-day%20waiting%20period,%20which%20is%20where%20full%20RUM%20shines%20with%20more%20immediate%20results%20and%20a%20greater%20depth%20of%20information.%0a&amp;url=https:\/\/smashingmagazine.com%2f2023%2f10%2fanswering-questions-interpreting-page-speed-reports%2f\"><\/p>\n<p>You might find that CrUX-based results are excellent for more of a current high-level view of performance than they are an accurate reflection of the users on your site because of that 28-day waiting period, which is where full RUM shines with more immediate results and a greater depth of information.<\/p>\n<p>    <\/a>\n  <\/p>\n<div class=\"pull-quote__quotation\">\n<div class=\"pull-quote__bg\">\n      <span class=\"pull-quote__symbol\">\u201c<\/span><\/div>\n<\/p><\/div>\n<\/blockquote>\n<h2 id=\"does-lighthouse-use-rum-data-too\">Does Lighthouse Use RUM Data, Too?<\/h2>\n<p>It does not! It uses synthetic data, or what we commonly call <strong>lab data<\/strong>. And, just like RUM, we can explain the concept of lab data by breaking it up into two different types.<\/p>\n<h3 id=\"type-1-observed-data\">Type 1: Observed Data<\/h3>\n<p>Observed data is performance as the browser sees it. So, instead monitoring real information collected from real users, <strong>observed data<\/strong>\u00a0is more like defining the test conditions ourselves. For example, we could add throttling to the test environment to enforce an artificial condition where the test opens the page on a slower connection. You might think of it like racing a car in virtual reality, where the conditions are decided in advance, rather than racing on a live track where conditions may vary.<\/p>\n<figure class=\"\n  \n    break-out article__image\n  \n  \n  \"><\/p>\n<p>    <a href=\"https:\/\/files.smashing.media\/articles\/answering-questions-interpreting-page-speed-reports\/3-chrome-devtools-performance-testing-conditions.png\"><\/p>\n<p>    <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"334\" src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/answering-questions-interpreting-page-speed-reports\/3-chrome-devtools-performance-testing-conditions.png\" alt=\"A screenshot with a specific performance tab in Chrome DevTools where you can choose between fast 3G, slow 3G, and offline\" \/><\/p>\n<p>    <\/a><figcaption class=\"op-vertical-bottom\">\n      Chrome DevTools includes a separate \u201cPerformance\u201d tab where the testing environment\u2019s CPU and network connection can be artificially throttled to mirror a specific testing condition, such as slow internet speeds. (<a href=\"https:\/\/files.smashing.media\/articles\/answering-questions-interpreting-page-speed-reports\/3-chrome-devtools-performance-testing-conditions.png\">Large preview<\/a>)<br \/>\n    <\/figcaption><\/figure>\n<h3 id=\"type-2-simulated-data\">Type 2: Simulated Data<\/h3>\n<p>While we called that last type of data \u201cobserved data,\u201d that is not an official industry term or anything. It\u2019s more of a necessary label to help distinguish it from <strong>simulated data<\/strong>, which describes how Lighthouse (and many other tools that include Lighthouse in its feature set, such as PSI) <a href=\"https:\/\/www.debugbear.com\/blog\/simulated-throttling?utm_campaign=sm-2\">applies throttling to a test environment and the results it produces<\/a>.<\/p>\n<p>The reason for the distinction is that <a href=\"https:\/\/www.debugbear.com\/blog\/network-throttling-methods?utm_campaign=sm-2\">there are different ways to throttle a network<\/a> for testing. Simulated throttling <a href=\"https:\/\/www.debugbear.com\/blog\/simulated-throttling#what-is-simulated-throttling?utm_campaign=sm-2\">starts by collecting data on a fast internet connection<\/a>, then <strong>estimates how quickly the page would have loaded on a different connection<\/strong>. The result is a much <em>faster<\/em> test than it would be to apply throttling before collecting information. Lighthouse can often grab the results and calculate its estimates faster than the time it would take to gather the information and parse it on an artificially slower connection.<\/p>\n<h3 id=\"simulated-and-observed-data-in-lighthouse\">Simulated And Observed Data In Lighthouse<\/h3>\n<p>Simulated data is the data that Lighthouse uses by default for performance reporting. It\u2019s also what PageSpeed Insights uses since it is powered by Lighthouse under the hood, although PageSpeed Insights also relies on real-user experience data from the CrUX report.<\/p>\n<p>However, it is also possible to collect observed data with Lighthouse. This data is more reliable since it doesn\u2019t depend on an incomplete simulation of Chrome internals and the network stack. The accuracy of observed data depends on how the test environment is set up. If <a href=\"https:\/\/www.debugbear.com\/blog\/packet-level-throttling?utm_campaign=sm-2\">throttling is applied at the operating system level<\/a>, then the metrics match what a real user with those network conditions would experience. <a href=\"https:\/\/www.debugbear.com\/blog\/chrome-devtools-network-throttling#how-exactly-does-devtools-network-throttling-work?utm_campaign=sm-2\">DevTools throttling<\/a> is easier to set up, but doesn\u2019t accurately reflect how server connections work on the network.<\/p>\n<h3 id=\"limitations-of-lab-data\">Limitations Of Lab Data<\/h3>\n<p>Lab data is fundamentally limited by the fact that it only looks at a single experience in a pre-defined environment. This environment often doesn\u2019t even match the average real user on the website, who may have a faster network connection or a slower CPU. Continuous real-user monitoring can actually tell you how users are experiencing your website and whether it\u2019s fast enough.<\/p>\n<p>So why use lab data at all?<\/p>\n<blockquote class=\"pull-quote\">\n<p>\n    <a class=\"pull-quote__link\" aria-label=\"Share on Twitter\" href=\"https:\/\/twitter.com\/share?text=%0aThe%20biggest%20advantage%20of%20lab%20data%20is%20that%20it%20produces%20much%20more%20in-depth%20data%20than%20real%20user%20monitoring.%0a&amp;url=https:\/\/smashingmagazine.com%2f2023%2f10%2fanswering-questions-interpreting-page-speed-reports%2f\"><\/p>\n<p>The biggest advantage of lab data is that it produces much more in-depth data than real user monitoring.<\/p>\n<p>    <\/a>\n  <\/p>\n<div class=\"pull-quote__quotation\">\n<div class=\"pull-quote__bg\">\n      <span class=\"pull-quote__symbol\">\u201c<\/span><\/div>\n<\/p><\/div>\n<\/blockquote>\n<p>Google CrUX data only reports metric values with no debug data telling you how to improve your metrics. In contrast, lab reports contain a lot of analysis and recommendations on how to improve your page speed.<\/p>\n<h2 id=\"why-is-my-lighthouse-lcp-score-worse-than-the-real-user-data\">Why Is My Lighthouse LCP Score <em>Worse<\/em> Than The Real User Data?<\/h2>\n<p>It\u2019s a little easier to explain different scores now that we\u2019re familiar with the different types of data used by performance auditing tools. We now know that Google reports on the 75th percentile of real users when reporting web core vitals, which includes LCP.<\/p>\n<blockquote><p>\u201cBy using the 75th percentile, we know that most visits to the site (3 of 4) experienced the target level of performance or better. Additionally, the 75th percentile value is less likely to be affected by outliers. Returning to our example, for a site with 100 visits, 25 of those visits would need to report large outlier samples for the value at the 75th percentile to be affected by outliers. While 25 of 100 samples being outliers is possible, it is much less likely than for the 95th percentile case.\u201d<\/p>\n<p>&mdash; <a href=\"https:\/\/web.dev\/articles\/defining-core-web-vitals-thresholds\">Brian McQuade<\/a><\/p><\/blockquote>\n<p>On the flip side, simulated data from Lighthouse neither reports on real users nor accounts for outlier experiences in the same way that CrUX does. <strong>So, if we were to set heavy throttling on the CPU or network of a test environment in Lighthouse, we\u2019re actually embracing outlier experiences that CrUX might otherwise toss out.<\/strong> Because Lighthouse applies heavy throttling by default, the result is that we get a worse LCP score in Lighthouse than we do PSI simply because Lighthouse\u2019s data effectively looks at a slow outlier experience.<\/p>\n<h2 id=\"why-is-my-lighthouse-cls-score-better-than-the-real-user-data\">Why Is My Lighthouse CLS Score <em>Better<\/em> Than The Real User Data?<\/h2>\n<p>Just so we\u2019re on the same page, Cumulative Layout Shift (CLS) measures the <a href=\"https:\/\/web.dev\/user-centric-performance-metrics\/#types-of-metrics\">\u201cvisible stability\u201d of a page layout<\/a>. If you\u2019ve ever visited a page, scrolled down it a bit before the page has fully loaded, and then noticed that your place on the page shifts when the page load is complete, then you know exactly what CLS is and how it feels.<\/p>\n<p>The nuance here has to do with page interactions. We know that real users are capable of interacting with a page even before it has fully loaded. This is a big deal when measuring CLS because layout shifts often occur lower on the page after a user has scrolled down the page. CrUX data is ideal here because it\u2019s based on real users who would do such a thing and bear the worst effects of CLS.<\/p>\n<p>Lighthouse\u2019s simulated data, meanwhile, does no such thing. It waits patiently for the full page load and never interacts with parts of the page. It doesn\u2019t scroll, click, tap, hover, or interact in any way.<\/p>\n<p>This is why you\u2019re more likely to receive a lower CLS score in a PSI report than you\u2019d get in Lighthouse. It\u2019s not that PSI likes you less, but that the real users in its report are a better reflection of how users interact with a page and are more likely to experience CLS than simulated lab data.<\/p>\n<h2 id=\"why-is-interaction-to-next-paint-missing-in-my-lighthouse-report\">Why Is Interaction to Next Paint Missing In My Lighthouse Report?<\/h2>\n<p>This is another case where it\u2019s helpful to know the different types of data used in different tools and how that data interacts &mdash; or not &mdash; with the page. That\u2019s because the Interaction to Next Paint (INP) metric is <em>all about interactions<\/em>. It\u2019s right there in the name!<\/p>\n<p>The fact that Lighthouse\u2019s simulated lab data does not interact with the page is a dealbreaker for an INP report. INP is a measure of the latency for all interactions on a given page, where the highest latency &mdash; or close to it &mdash; informs the final score. For example, if a user clicks on an accordion panel and it takes longer for the content in the panel to render than any other interaction on the page, that is what gets used to evaluate INP.<\/p>\n<p>So, when INP <a href=\"https:\/\/web.dev\/inp\/\">becomes an official core web vitals metric in March 2024<\/a>, and you notice that it\u2019s not showing up in your Lighthouse report, you\u2019ll know exactly why it isn\u2019t there.<\/p>\n<p><strong>Note<\/strong>: <em>It is possible to script user flows with Lighthouse, including in DevTools. But that probably goes too deep for this article.<\/em><\/p>\n<h2 id=\"why-is-my-time-to-first-byte-score-worse-for-real-users\">Why Is My Time To First Byte Score <em>Worse<\/em> For Real Users?<\/h2>\n<p>The Time to First Byte (TTFB) is what immediately comes to mind for many of us when thinking about page speed performance. We\u2019re talking about the time between establishing a server connection and receiving the first byte of data to render a page.<\/p>\n<figure class=\"\n  \n    break-out article__image\n  \n  \n  \"><\/p>\n<p>    <a href=\"https:\/\/files.smashing.media\/articles\/answering-questions-interpreting-page-speed-reports\/4-ttfb-page-speed-performance.png\"><\/p>\n<p>    <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"216\" src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/answering-questions-interpreting-page-speed-reports\/4-ttfb-page-speed-performance.png\" alt=\"A graph illustrating the Time to First Byte, which consists of full TTFB and HTTP request TTFB\" \/><\/p>\n<p>    <\/a><figcaption class=\"op-vertical-bottom\">\n      Source: <a href=\"https:\/\/www.debugbear.com\/docs\/metrics\/time-to-first-byte#ttfb-in-lighthouse\">Source: DebugBear<\/a>. (<a href=\"https:\/\/files.smashing.media\/articles\/answering-questions-interpreting-page-speed-reports\/4-ttfb-page-speed-performance.png\">Large preview<\/a>)<br \/>\n    <\/figcaption><\/figure>\n<p>TTFB identifies how fast or slow a web server is to respond to requests. What makes it special in the context of core web vitals &mdash; even though it is not considered a core web vital itself &mdash; is that it <em>precedes<\/em> all other metrics. The web server needs to establish a connection in order to receive the first byte of data and render everything else that core web vitals metrics measure. TTFB is essentially an <strong>indication of how fast users can navigate<\/strong>, and core web vitals can\u2019t happen without it.<\/p>\n<p>You might already see where this is going. When we start talking about server connections, there are going to be differences between the way that RUM data observes the TTFB versus how lab data approaches it. As a result, we\u2019re bound to get different scores based on which performance tools we\u2019re using and in which environment they are. As such, TTFB is more of a \u201crough guide,\u201d as <a href=\"https:\/\/web.dev\/ttfb\/\">Jeremy Wagner and Barry Pollard explain<\/a>:<\/p>\n<blockquote><p>\u201cWebsites vary in how they deliver content. A low TTFB is crucial for getting markup out to the client as soon as possible. However, if a website delivers the initial markup quickly, but that markup then requires JavaScript to populate it with meaningful content [\u2026], then achieving the lowest possible TTFB is especially important so that the client-rendering of markup can occur sooner. [\u2026] This is why the TTFB thresholds are a \u201crough guide\u201d and will need to be weighed against how your site delivers its core content.\u201d<\/p>\n<p>&mdash; <a href=\"https:\/\/web.dev\/ttfb\/\">Jeremy Wagner and Barry Pollard<\/a><\/p><\/blockquote>\n<p>So, if your TTFB score comes in higher when using a tool that relies on RUM data than the score you receive from Lighthouse\u2019s lab data, it\u2019s probably because of caches being hit when testing a particular page. Or perhaps the real user is coming in from a shortened URL that redirects them before connecting to the server. It\u2019s even possible that a real user is connecting from a place that is really far from your web server, which takes a little extra time, particularly if you\u2019re not using a CDN or running edge functions. It really depends on both the user and how you serve data.<\/p>\n<h2 id=\"why-do-different-tools-report-different-core-web-vitals-what-values-are-correct\">Why Do Different Tools Report Different Core Web Vitals? What Values Are Correct?<\/h2>\n<p>This article has already introduced some of the nuances involved when collecting web vitals data. Different tools and data sources often report different metric values. So which ones can you trust?<\/p>\n<p>When working with lab data, I suggest preferring observed data over simulated data. But you\u2019ll see differences even between tools that all deliver high-quality data. That\u2019s because no two tests are the same, with different test locations, CPU speeds, or Chrome versions. There\u2019s no one right value. Instead, you can use the lab data to identify optimizations and see how your website changes over time when tested in a consistent environment.<\/p>\n<p>Ultimately, what you want to look at is how real users experience your website. From an SEO standpoint, the 28-day Google CrUX data is the gold standard. However, it won\u2019t be accurate if you\u2019ve rolled out performance improvements over the last few weeks. Google also doesn\u2019t report CrUX data for some high-traffic pages because the visitors may not be logged in to their Google profile.<\/p>\n<p>Installing a custom RUM solution on your website can solve that issue, but the numbers won\u2019t match CrUX exactly. That\u2019s because visitors using browsers other than Chrome are now included, as are users with Chrome analytics reporting disabled.<\/p>\n<p>Finally, while Google focuses on the fastest 75% of experiences, that doesn\u2019t mean the 75th percentile is the correct number to look at. Even with good core web vitals, 25% of visitors may still have a slow experience on your website.<\/p>\n<h2 id=\"wrapping-up\">Wrapping Up<\/h2>\n<p>This has been a close look at how different performance tools audit and report on performance metrics, such as core web vitals. Different tools rely on different types of data that are capable of producing different results when measuring different performance metrics.<\/p>\n<p>So, if you find yourself with a CLS score in Lighthouse that is far lower than what you get in PSI or DebugBear, go with the Lighthouse report because it makes you look better to the big boss. Just kidding! That difference is a big clue that the data between the two tools is uneven, and you can use that information to help diagnose and fix performance issues.<\/p>\n<figure class=\"\n  \n  \n  \"><\/p>\n<p>    <a href=\"https:\/\/files.smashing.media\/articles\/answering-questions-interpreting-page-speed-reports\/5-debugbear-lcp.png\"><\/p>\n<p>    <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"641\" src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/answering-questions-interpreting-page-speed-reports\/5-debugbear-lcp.png\" alt=\"A screenshot of the DebugBear LCP\" \/><\/p>\n<p>    <\/a><figcaption class=\"op-vertical-bottom\">\n      (<a href=\"https:\/\/files.smashing.media\/articles\/answering-questions-interpreting-page-speed-reports\/5-debugbear-lcp.png\">Large preview<\/a>)<br \/>\n    <\/figcaption><\/figure>\n<p>Are you looking for a tool to track lab data, Google CrUX data, and full real-user monitoring data? <a href=\"https:\/\/www.debugbear.com\/?utm_campaign=sm-2\">DebugBear<\/a> helps you keep track of all three types of data in one place and optimize your page speed where it counts.<\/p>\n<div class=\"signature\">\n  <img decoding=\"async\" src=\"https:\/\/www.smashingmagazine.com\/images\/logo\/logo--red.png\" alt=\"Smashing Editorial\" width=\"35\" height=\"46\" loading=\"lazy\" \/><br \/>\n  <span>(yk)<\/span>\n<\/div>\n<\/article>\n","protected":false},"excerpt":{"rendered":"<p>Answering Common Questions About Interpreting Page Speed Reports Answering Common Questions About Interpreting Page Speed Reports Geoff Graham 2023-10-31T16:00:00+00:00 2024-08-30T10:05:08+00:00 This article is sponsored by DebugBear Running a performance check on your site isn\u2019t too terribly difficult. It may even be something you do regularly with Lighthouse in Chrome DevTools, where testing is freely available [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[10],"tags":[],"class_list":["post-507","post","type-post","status-publish","format-standard","hentry","category-performance"],"_links":{"self":[{"href":"https:\/\/upprofits.net\/index.php\/wp-json\/wp\/v2\/posts\/507"}],"collection":[{"href":"https:\/\/upprofits.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/upprofits.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/upprofits.net\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/upprofits.net\/index.php\/wp-json\/wp\/v2\/comments?post=507"}],"version-history":[{"count":1,"href":"https:\/\/upprofits.net\/index.php\/wp-json\/wp\/v2\/posts\/507\/revisions"}],"predecessor-version":[{"id":508,"href":"https:\/\/upprofits.net\/index.php\/wp-json\/wp\/v2\/posts\/507\/revisions\/508"}],"wp:attachment":[{"href":"https:\/\/upprofits.net\/index.php\/wp-json\/wp\/v2\/media?parent=507"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/upprofits.net\/index.php\/wp-json\/wp\/v2\/categories?post=507"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/upprofits.net\/index.php\/wp-json\/wp\/v2\/tags?post=507"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}