When I ran my portfolio site, aryancreates.com, through Google PageSpeed Insights on mobile, it scored 94. That sounds great, and it is. But two numbers were still orange: Largest Contentful Paint (LCP) at 2.6 seconds and Speed Index at 4.4 seconds.

A score of 94 can hide real problems. So instead of celebrating, I dug into the report to find out what was still slowing the page down. Here is what I found, and what it taught me about LCP.

What LCP actually measures

LCP is the time it takes for the biggest visible thing on the screen to appear. On most sites that is a hero image. On mine, it was something I didn’t expect: the hero paragraph text (“We build custom WordPress websites and hand-coded web solutions for businesses…”).

Google wants LCP under 2.5 seconds. At 2.6 seconds, I was just over the line.

The server was not the problem

My first guess was slow hosting. The report proved me wrong. PageSpeed Insights breaks LCP into parts, and my Time to First Byte (TTFB) was only 330 ms. The server was answering quickly.

The real problem was a different line in the breakdown:

• Time to First Byte: 330 ms
• Element render delay: 2,340 ms

In other words, the browser had my hero text almost immediately, but waited more than two seconds before actually showing it. That is where almost all of my LCP time was going.

Why text can be slow to appear

Render delay means the content is downloaded but something is stopping the browser from painting it. For a text element, the usual suspects are:

1. Render-blocking CSS. The browser will not draw anything until it has loaded the CSS files in the page head. My report flagged one render-blocking CSS file (about 10.7 KiB) costing around 350 ms.
2. Web fonts. If a custom font is still loading, the browser may hide the text until the font arrives.
3. Entrance animations. Page builders like Elementor make it easy to add a “fade in” or “slide up” animation. The text starts invisible and only appears when JavaScript runs, which can add a lot of delay to LCP.
4. Heavy JavaScript. Scripts that run before the page is painted can hold everything back.

What I am doing about it

Based on the report, these are the fixes that target render delay directly:

• Remove the entrance animation from the hero text. The most important content on the page should be visible straight away, not faded in.
• Load fonts with font-display: swap. The text shows immediately in a fallback font, then switches when the custom font is ready.
• Inline the critical CSS and defer the rest. The styles needed for the top of the page go directly in the HTML, so the render-blocking file no longer holds up the first paint.
• Delay non-essential JavaScript until after the page has loaded.

Three lessons from this

1. Don’t stop at the score. A 94 looked finished, but the metrics underneath showed exactly what was left to fix.

2. Find out what your LCP element really is. I assumed it would be an image. It was a paragraph. Every fix depends on knowing this.

3. Read the LCP breakdown. Fast hosting is useless if the browser is waiting to paint. The breakdown tells you whether to fix the server, the file size, or the rendering.

Check your own site

Open PageSpeed Insights, test your homepage on mobile, and scroll to the LCP section. Look at which element is your LCP and which part of the breakdown is the largest. That one number will tell you where to start.

If you need help speeding up a WordPress site, get in touch.