Skip to content

Instantly share code, notes, and snippets.

@WebCloud

WebCloud/improved_lcp_report.md

Created May 14, 2025 21:56
Show Gist options
  • Save WebCloud/7feefd4079e085714e59991b619288cc to your computer and use it in GitHub Desktop.
Save WebCloud/7feefd4079e085714e59991b619288cc to your computer and use it in GitHub Desktop.
Download ZIP
Raw
improved_lcp_report.md

LCP report based on trace analysis

Your LCP value is 5619.998 and your score is bad

Your Largest Contentful Paint (LCP) is a Core Web Vital that measures the loading performance of your page's main content. A score of 5619.998 ms is considered "bad", indicating that users are waiting too long to see the primary content on your page. The goal is to achieve an LCP of 2.5 seconds or less for a good user experience.

Analyzing the trace data helps pinpoint the specific reasons behind this slow LCP. The breakdown of the LCP time reveals that the delay is primarily caused by the time it takes for the browser to start loading the LCP image, rather than the server response or the image download itself.

Actionable Optimizations

The primary bottleneck identified in the trace data is the significant delay before the Largest Contentful Paint image begins loading. To improve your LCP score, focus on ensuring the LCP image is discovered and prioritized for loading as early as possible during the page load process.

Data from trace analysis

  • TTFB: 1ms - This indicates an excellent server response time. The server is delivering the initial HTML quickly, which is a strong foundation for good loading performance.
  • Load Delay: 5553ms - This is the most significant factor contributing to your poor LCP. It represents the time from the start of the page load until the LCP image begins to load. A delay of over 5.5 seconds suggests the image is not being discovered or prioritized early in the critical rendering path. This could be due to the image not being in the initial HTML, being lazy-loaded incorrectly, or its discovery being blocked by other resources like render-blocking JavaScript or CSS.
  • Load Time: 26ms - Once the LCP image started loading, it only took 26ms to download. This is very fast and confirms that the image file size or network conditions during the download phase are not the primary issue.
  • Render Delay: 42ms - This is the time from when the LCP image finished loading until it was painted on the screen. This value is low and does not contribute significantly to the overall LCP delay.

To address the high Load Delay, investigate why the LCP image is not discovered immediately. Ensure the image is included directly in the initial HTML markup if possible. Avoid using JavaScript-based lazy loading for images that are likely candidates for LCP (i.e., images in the initial viewport). Consider using <link rel="preload"> for the LCP image to give the browser a hint to fetch it earlier. Researching and optimizing your critical rendering path will be crucial to ensure essential resources, including your LCP image, are loaded without unnecessary delays.

Largest Contentful Paint (LCP) network analysis

LCP Candidate Timing: 5619.998ms LCP Candidate Type: image

Analysis

The Largest Contentful Paint (LCP) for this page occurs at 5619.998ms, which falls into the "Poor" category according to Core Web Vitals thresholds (> 4.0s). The LCP candidate is an image.

Analyzing the LCP candidate phase timings reveals the primary bottleneck:

  • TTFB (1ms): Excellent server response time.
  • Load Delay (5553ms): This is the most significant factor, indicating a very long delay between the browser discovering the LCP image resource and starting its download.
  • Load Time (26ms): The image itself downloaded very quickly once the download started.
  • Render Delay (42ms): The time from download completion to rendering was also relatively fast.

The LCP request headers show the image is served via Akamai Image Manager (a CDN), uses the modern AVIF format, and has a reasonable cache policy (max-age=43200). This suggests the issue is not with the image delivery itself (server speed, format, caching) but rather with when the browser decided to fetch it.

The large Load Delay points to the LCP image being discovered late in the parsing process or its download being blocked by other critical resources that needed to be fetched and processed first.

Network Activity Insights

image

First party vs Third party activity map

First Party (Origin: https://www.volvocars.com)

  • Total Requests: 139 requests across various types. This is a high number of requests for the critical rendering path interval.
  • Render Blocking Resources: 6 CSS files are marked as render-blocking. These files must be downloaded and parsed before the browser can render the page content, including the LCP image. This is a strong candidate for causing the LCP Load Delay.
  • JavaScript: A large number of JavaScript files (34 application/javascript, 29 text/javascript) totaling over 3MB encoded size. While all are marked as Low Priority, their sheer volume can consume network bandwidth and potentially delay other resources, or their execution might delay the discovery or rendering of the LCP image if they manipulate the DOM or load content.
  • JSON: A very high count of 34 application/json requests, all marked as High Priority. These are likely API calls. While not typically render-blocking for initial paint, they consume significant network resources (1MB encoded size) and could compete for bandwidth with critical assets like the LCP image, especially if connection limits are hit.
  • CSS: 18 CSS files (13 High Priority). While only 6 are render-blocking, 18 separate CSS requests add network overhead.
  • Images: 20 image requests (5 High Priority, 15 Low Priority). The LCP image is one of the High Priority ones. The total image size is small (61kB), but the number of requests adds overhead.
  • Fonts: 3 High Priority font files. These are necessary for rendering text and can impact FCP and LCP if not loaded efficiently, though they are not marked as render-blocking here.

Third Party (Multiple Origins)

  • Total Origins: 20+ distinct third-party origins.
  • Total Requests: A large number of requests, primarily for JavaScript, JSON, and small tracking images/pixels.
  • Render Blocking: At least one third-party JavaScript file (from cdn.cookielaw.org) is marked as render-blocking. Cookie consent scripts are common culprits for delaying the critical rendering path.
  • Volume: The sheer volume of third-party requests adds significant network overhead and contention, competing with first-party resources for bandwidth and connections. Many of these appear to be related to tracking, advertising, and analytics.
  • Notable Third Parties:
    • cdn.cookielaw.org: Includes a render-blocking JS file.
    • app.launchdarkly.com: 12 high-priority JSON requests.
    • googletagmanager.com: Large JS file.
    • Numerous tracking/advertising domains loading small assets.

image

Network activity visualized by asset type

Bottlenecks

  1. LCP Image Load Delay: The primary bottleneck is the 5.5s delay before the LCP image starts downloading. This is likely caused by other resources blocking the critical rendering path or the image being discovered late.
  2. Render-Blocking Resources: The 6 first-party CSS files and 1 third-party JS file are blocking rendering, directly contributing to the LCP Load Delay.
  3. Excessive Request Count: The high number of first-party (especially JSON) and third-party requests creates network congestion, potentially delaying critical resources.
  4. Third-Party Overhead: The large number of third-party origins and requests adds significant overhead and risk, including a render-blocking script.

Recommendations

  • Prioritize LCP Image Discovery:
    • Ensure the LCP image is included directly in the initial HTML markup (<img> tag) and is not added or modified by JavaScript that executes late.
    • Use <link rel="preload" as="image" href="..."> in the <head> of the HTML document for the LCP image to instruct the browser to fetch it with high priority as soon as possible.
    • Verify the LCP image is not being lazy-loaded if it is within the initial viewport.
  • Optimize Render-Blocking CSS:
    • Identify the critical CSS needed for the above-the-fold content and inline it directly into the HTML document.
    • Load the remaining CSS asynchronously or defer it using techniques like media attributes or JavaScript loading.
    • Combine and minify CSS files to reduce the number of requests.
  • Optimize Render-Blocking Third-Party Scripts:
    • Identify the render-blocking third-party script (likely cookie consent). Explore options to load this script asynchronously or defer its execution until after the critical rendering path is complete. Many cookie consent solutions offer asynchronous loading options.
  • Reduce Request Count and Network Contention:
    • Audit the 34 first-party JSON requests. Can these be consolidated into fewer requests? Can their priority be lowered if the data is not immediately needed for the initial render?
    • Audit all third-party scripts and tracking pixels. Remove any unnecessary ones. Load non-critical third-party scripts using async or defer attributes, or load them after the load event.
  • Optimize First-Party JavaScript: While not render-blocking, the large volume and size of JS can impact overall load time and interactivity. Ensure efficient bundling, code splitting, and deferral of non-critical scripts.

Next steps

  • Identify the specific LCP image resource URL.
  • Verify how the LCP image is included in the HTML and if it's being lazy-loaded.
  • Identify the 6 render-blocking first-party CSS files and the render-blocking third-party JS file.
  • Investigate the purpose and necessity of the 34 high-priority first-party JSON requests.
  • Perform a detailed audit of all third-party scripts to assess their impact and necessity.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment