Skip to content

Instantly share code, notes, and snippets.

@WebCloud

WebCloud/lcp_network_analysis_better_attribution.md

Created May 12, 2025 17:40
Show Gist options
  • Save WebCloud/28464f0a0d15ed226b15850581cb57d5 to your computer and use it in GitHub Desktop.
Save WebCloud/28464f0a0d15ed226b15850581cb57d5 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
lcp_network_analysis_better_attribution.md

LCP Performance Analysis Report

Trace URL: https://www.volvocars.com/se/build/xc90-hybrid LCP Candidate Timing: 5619.998ms (5.6 seconds) LCP Candidate Type: image

Summary: The Largest Contentful Paint (LCP) for this page occurs at approximately 5.6 seconds, which is significantly outside the recommended threshold of 2.5 seconds. The primary bottleneck identified in the LCP phase timings is the Load Delay phase, accounting for over 5.5 seconds of the total LCP time. This indicates that the browser knew what the LCP image was relatively early (low TTFB), but was heavily delayed in starting to fetch it.

LCP Candidate Phase Timings Breakdown:

  • TTFB (Time to First Byte): 1ms - Excellent. The initial HTML document arrived almost instantly.
  • Load Delay: 5553ms - Critical Issue. This is the time between the browser discovering the LCP resource and starting its download. A very high load delay points to resources blocking the discovery or initiation of the LCP image download.
  • Load Time: 26ms - Excellent. Once the download started, the image itself transferred very quickly.
  • Render Delay: 42ms - Reasonable. The time from the image finishing download to being painted is acceptable.

Network Activity Analysis (Up to LCP):

The trace shows a large number of resources being loaded from multiple origins before the LCP occurs.

  • First-Party (https://www.volvocars.com):

    • Dominates the total time spent (140+ seconds cumulative).
    • Loads a significant number of assets: 1 HTML, 18 CSS, 63 JavaScript (application/javascript + text/javascript), 20 Images, 3 Fonts, 34 JSON.
    • Key Finding: 6 CSS files are marked as Render Blocking. These resources must be downloaded and parsed before the browser can render the page content, including potentially discovering the LCP image.
    • A large number of JavaScript (63 files) and JSON (34 files) requests are made. While not marked as render-blocking in this data, they consume significant network bandwidth and CPU time, potentially delaying other critical tasks.

  • Third-Party Origins (25 distinct origins):

    • A large number of third-party requests are initiated before LCP.
    • Origins contributing significant total time include: app.launchdarkly.com (1.7s, JSON), www.googletagmanager.com (1s, JS), px.ads.linkedin.com (0.76s, JSON/JS/text), service.force.com (0.64s, JS/CSS/HTML), connect.facebook.net (0.28s, JS), ib.adnxs.com (0.24s, XML/image), cdn.decibelinsight.net (0.2s, JS), se-gmtdmp.mookie1.com (0.19s, image), cdn.cookielaw.org (0.35s, JS/JSON/CSS/image).
    • Key Finding: 1 JavaScript file from cdn.cookielaw.org is marked as Render Blocking. This adds another resource that must be processed before rendering can proceed.
    • Many third-party scripts and tracking pixels are loaded, adding overhead and potential contention for network and CPU resources.

Insights and Patterns:

  1. High Load Delay is the Root Cause: The 5.5-second Load Delay for the LCP image is the primary reason for the poor LCP score.
  2. Render-Blocking Resources are Likely Culprits: The presence of 6 first-party render-blocking CSS files and 1 third-party render-blocking JavaScript file strongly suggests that the browser is waiting for these resources to download and parse before it can discover or start loading the LCP image. The critical rendering path is being blocked.
  3. LCP Image Discovery Issue: As highlighted by the pre-existing recommendations, the LCP image is likely not discovered early in the HTML source or is being lazy-loaded, preventing the browser from initiating its download until later in the page load process, after blocking resources are handled.
  4. Resource Contention: The sheer volume of requests (especially JS and JSON) from both first and third parties, even if not strictly render-blocking, can consume network resources and CPU time needed for critical tasks, potentially exacerbating the delay.
  5. Third-Party Impact: While first-party resources account for the majority of render-blocking issues, the render-blocking third-party script adds to the problem. The numerous other third-party requests contribute to overall page weight and complexity.

Recommendations based on Insights:

The analysis confirms the pre-existing recommendations and provides context from the network data:

  1. Prioritize LCP Image Discovery and Loading:

    • Ensure LCP Image is in Initial HTML: Verify that the <img> tag for the LCP candidate is present directly in the initial HTML document and not added later by JavaScript.
    • Avoid Lazy Loading: Remove loading=\"lazy\" or similar lazy-loading attributes from the LCP image element.
    • Preload the LCP Image: Add a <link rel=\"preload\" as=\"image\" href=\"[URL_OF_LCP_IMAGE]\"> tag high up in the <head> of the HTML document. This instructs the browser to fetch the image with high priority as soon as possible, bypassing the need to wait for CSS/JS parsing to discover it in the DOM.

  2. Reduce Render-Blocking Resources:

    • Optimize First-Party CSS:
      • Combine multiple CSS files into fewer requests.
      • Identify critical CSS needed for above-the-fold content and inline it directly into the HTML.
      • Load non-critical CSS asynchronously using <link rel=\"stylesheet\" media=\"print\" onload=\"this.media='all'\"> or similar techniques.
    • Optimize Third-Party Render-Blocking JS:
      • Investigate the cdn.cookielaw.org script. Can it be loaded asynchronously using the async or defer attributes? If it's a cookie consent banner, it often doesn't need to block initial rendering. Load it later in the page lifecycle if possible.

  3. Optimize Overall Resource Loading:

    • Defer Non-Critical JavaScript: Use async or defer attributes on <script> tags for JavaScript files that are not essential for initial rendering. Review the large number of first-party JS files (63 total) and third-party JS files to identify candidates for deferral.
    • Optimize API Calls: Review the 34 first-party JSON requests. Ensure they are efficient and only fetch data necessary for the initial view. Can some be combined or deferred until user interaction?
    • Evaluate Third-Party Scripts: Audit the necessity and loading strategy of all third-party scripts. Can any be removed, loaded later, or loaded asynchronously?

By addressing the significant Load Delay through early LCP image discovery/preloading and reducing the impact of render-blocking CSS and JS, the LCP time can be drastically improved. The focus should be on ensuring the browser can start downloading the LCP image much earlier in the page load process.

Next steps

  • Identify the specific LCP image element in the page's HTML and verify its loading strategy (e.g., is it lazy-loaded, is it in the initial HTML?).
  • Analyze the critical rendering path in DevTools to see exactly which resources are blocking rendering and when the LCP image request is initiated.
  • Profile the main thread activity to understand if script execution (first-party or third-party) is delaying parsing or rendering, even if resources aren't marked as render-blocking.
  • Investigate the content and necessity of the render-blocking CSS and the render-blocking third-party JavaScript.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment