Core/Dash Dimension: Urls
Isolate and fix Core Web Vita;ls performance bottlenecks by specific Urls
Trusted by market leaders
Dimension: Page & Navigation: URLs (u)
The Element Type (LCP) dimension (lcpet) categorizes the Largest Contentful Paint node into one of four architectural classes: text, image, background-image, or video.
While the Attribution Element dimension pinpoints the exact DOM node, the Element Type dimension dictates your high-level engineering strategy. LCP is the sum of four timing intervals: TTFB, Load Delay, Load Time, and Render Delay. The Element Type tells you which of these intervals is damaging your score, allowing you to select the correct optimization protocol without guessing..
Optimizing the Core web Vitals by LCP element type
After improving the TTFB, which is independent of the LCP element type, you should take a different approach to optimizing the LCP by looking at your LCP different element.
1. Text
When CoreDash reports text as the Element Type, static network resource bandwidth is rarely the bottleneck. Text resides directly in the HTML document, meaning the content is available immediately after the initial server response (TTFB). If your LCP is slow here, the issue is almost exclusively Render Delay.
To fix this, focus entirely on the Critical Rendering Path. The browser is likely blocked from painting the text by heavy CSS calculations or synchronous JavaScript in the <head>. Additionally, check your font loading strategy; if you are not using font-display: swap or optional, the browser is artificially hiding the text (FOIT) while waiting for the font file to download.
2. Image (<img>)
This type triggers the full resource pipeline: discovery, download, and decode. Unlike text, an image LCP is heavily dependent on Load Delay and Load Time. You are fighting physics and network latency here, so your goal is to make the asset lighter and discoverable sooner.
Optimization here requires strict asset management. Ensure the <img> tag exists in the initial HTML source (Server-Side Rendering) to minimize Load Delay. Add fetchpriority="high" and strictly remove any loading="lazy" attributes, as these delay the browser's request. Finally, tackle Load Time by serving next-gen formats (AVIF/WebP) and using srcset to prevent mobile devices from downloading desktop-sized files.
3. Background Image
This classification signals an architectural inefficiency. Because the image is defined in CSS (e.g., background-image: url(...)), the browser cannot discover the URL until it has fully downloaded and parsed your stylesheets. This creates a massive Load Delay because the Preload Scanner is effectively blind to the asset.
The only robust engineering fix is refactoring. Move the visual asset from CSS to a standard HTML <img> tag to expose the URL to the browser immediately. If you cannot refactor the markup, you must use <link rel="preload"> in the document head to force early discovery, though this is often a maintenance burden compared to using a native image element.
4. Video
When the LCP element is a video, the browser measures the paint time of the poster image or the first frame (if autoplaying). This behaves similarly to the Image type but is often heavier due to the file size of video assets.
Treat this strictly as an image optimization task. Ensure a lightweight poster attribute is present in the HTML so the browser doesn't have to download video segments to render the first pixel. Compress the poster image as aggressively as you would a standard LCP image.
Workflow: finding LCP issues based on LCP element type
The LCP Element Type is not static nor the same for every visitor. It frequently changes based on the user's device, revealing fundamental flaws in responsive design.
Use the CoreDash Device Form Factor filter to compare Element Types between Mobile and Desktop. You will often find that Desktop users get an image LCP (e.g., a Hero Banner), while Mobile users get a text LCP. This confirms that your mobile CSS layout pushes the Hero Banner below the fold or scales it down so significantly that a paragraph of text becomes the "Largest" element.
If you are optimizing the hero image to improve mobile LCP in this scenario, you are wasting effort. The browser isn't even counting the image. You must either adjust the layout to bring the image back into primary view or shift your focus to optimizing the text rendering (fonts/CSS) for mobile users.
