I Ran Lighthouse on My Personal Site - Here's What I Learned

I finally decided to test my personal website with Lighthouse. It's a simple, static, one-page site, so I always thought, “It’s fine as it is.”
Well… I was wrong.

When I ran the audit, I didn’t get a shiny report. Instead, I got an error.

First Contentful Paint Error (aka NO_FCP)

The page did not paint any content. Please ensure you keep the browser window in the foreground during the load and try again. (NO_FCP)

Let’s break that down.

FCP stands for First Contentful Paint and it's the moment something (text, image, etc.) first appears on the screen. It's one of the key metrics Lighthouse uses to measure performance.

At first, I thought this error was just a fluke, but then I found this helpful explanation on StackOverflow. The issue came from how I was handling page load animations.

Setting opacity: 0 on the entire body is a bad idea if you care about performance and accessibility.

Here’s what I had before:

// Bad idea to set opacity to 0
body {
  opacity: 0;
  animation: fadeIn 1s forwards;
}

@keyframes fadeIn {
  to {
    opacity: 1;
  }
}

This makes Lighthouse think nothing is ever painted, which triggers the NO_FCP warning.

Fixing It the Right Way

Here’s how I fixed it while keeping the animation and improving accessibility:

@keyframes fadeIn {
  0% {
    /* Start slightly visible to trigger FCP */
    opacity: 0.01;
  }
  100% {
    opacity: 1;
  }
}

/* Only animate if the user hasn't asked for reduced motion */
@media (prefers-reduced-motion: no-preference) {
  body {
    opacity: 1;
    animation-name: fadeIn;
    animation-duration: 0.6s;
    animation-timing-function: ease-in;
    animation-iteration-count: 1;
  }
}

Now the page paints something almost immediately, and animations still work as expected! Here’s the Lighthouse report after the fix. We’re back in business.

Eliminate Render-Blocking Resources

Next up, Lighthouse complained about render-blocking resources.

My FCP and LCP (Largest Contentful Paint) were both around 0.6s and it's not bad, but I knew I could do better.

So, I followed this awesome tip from Scott Jehl and changed how I load fonts:

In my case, that's not a big deal, but my perfectionism asks me to fix it. So, I found a really elegant solution in the article.

<link href="https://fonts.googleapis.com/css2family=Manrope:wght@200..800&family=Sora:wght@100..800&display=swap"
      rel="stylesheet" 
      media="print" 
      onload="this.media='all'">

Fonts now load without blocking rendering, and look at these numbers, much better:

And just one more tip:
If you're using custom fonts, consider adding a fallback font in your CSS. Google Fonts no longer blocks rendering, so users might briefly see a different font while the main one loads, especially on slow connections.

Final Thoughts

Running Lighthouse wasn’t just about fixing issues - it helped me spot things I never considered. I learned how to make my site faster, more accessible, and more user-friendly.

Even if your site is 'just a static page,' don’t skip the analysis. There’s always room for improvement and sometimes, it’s surprisingly fun.