How to Improve Lighthouse Scores for Local SEO (Without Chasing a Perfect 100)

Lighthouse scores get treated like a report card, but Google doesn’t rank you on the number in that little circle. It ranks you on the things that score is a rough proxy for: how fast your page paints, how stable the layout is, and whether a phone on a bad connection can actually use it. If you’re doing local SEO, the goal isn’t 100. It’s making the page fast and stable enough that people in your town don’t bounce before they find your address and phone number.

I’ve rebuilt enough small business sites to know which fixes matter and which ones are just noise. Here’s the honest version.

First, stop optimizing the wrong number

Lighthouse runs four categories: Performance, Accessibility, Best Practices, and SEO. People obsess over Performance and ignore the rest, or they chase a perfect score by gaming the test. Two things to know before you touch anything:

• Run it against your real URL, not a local build. Your dev machine has no network latency and no third-party scripts. The score you get locally is fiction.
• Use the mobile tab. Google indexes the mobile version of your site first. A 98 on desktop and a 41 on mobile means your real score is the 41.
• Ignore the SEO category’s passing grade. It checks for a meta description and crawlable links. It does not check whether you rank for “plumber near me.” That part is actual Long Island SEO work, and it happens outside Lighthouse.

Fix the layout shift that’s killing your local trust signals

This is the one people skip, and it’s the one that hurts. If your address, hours, or phone number jump around while the page loads, that’s a bad experience for a customer trying to call you. It also tanks your Cumulative Layout Shift score.

The usual culprits are images without dimensions and ads or embeds that inject content after load. The fix for images is boring and effective. Always set width and height:

<img src="https://i0.wp.com/www.kennykey.com/storefront.webp" alt="Our Commack storefront on Jericho Turnpike"
 width="1200" height="800" loading="lazy" decoding="async">

Setting width and height lets the browser reserve the space before the image loads, so nothing jumps. Pair it with CSS that keeps the aspect ratio honest:

img {
 max-width: 100%;
 height: auto;
}

For anything that loads late (a map embed, a review widget, a chat bubble), reserve its space with a fixed-height container. A Google Maps iframe that pops in and shoves your phone number down the page is a real problem, not a theoretical one.

Serve images people can actually download

Most small business sites I look at are shipping 2MB JPEGs straight off a phone camera. That single habit is often the difference between a 50 and a 90. Two moves:

• Convert to WebP or AVIF. Both are supported everywhere that matters in 2026. AVIF compresses better; WebP is a safer default.
• Serve the right size. Don’t send a 2000px image into a 400px slot.

The modern way to handle both is the <picture> element with a srcset. The browser picks the smallest file that fits the screen:

<picture>
 <source srcset="/hero-800.avif 800w, /hero-1600.avif 1600w"
 sizes="(max-width: 800px) 100vw, 800px" type="image/avif">
 <source srcset="https://i0.wp.com/www.kennykey.com/hero-800.webp 800w, https://i0.wp.com/www.kennykey.com/hero-1600.webp 1600w"
 sizes="(max-width: 800px) 100vw, 800px" type="image/webp">
 <img src="https://i0.wp.com/www.kennykey.com/hero-800.jpg" alt="Team at our Commack office"
 width="800" height="500" loading="lazy">
</picture>

You don’t have to hand-write this. Any decent build tool or image CDN will generate the variants. The point is that a phone on LTE in a parking lot shouldn’t wait three seconds for your hero image.

Cut the third-party scripts you’re not using

Open DevTools, hit the Network tab, reload, and sort by size. Every chat widget, heatmap tool, and marketing pixel adds to your Total Blocking Time. I’ve seen sites with four analytics platforms firing on page load. Pick one. Defer the rest:

<script src="/js/chat-widget.js" defer></script>

defer tells the browser to download the script without blocking the HTML parse, then run it after the document is ready. For a chat widget that nobody clicks in the first two seconds, that’s a free win. If a script truly isn’t needed until the user interacts, load it on interaction instead of at page load.

For fonts, self-host them and preload the one file the page actually renders above the fold:

<link rel="preload" href="/fonts/inter.woff2" as="font"
 type="font/woff2" crossorigin>

Don’t preload five weights. Preload the one you use. The rest can load normally.

Make the local details crawlable and fast to find

Lighthouse won’t tell you this, but it matters more for local rankings than any score: your name, address, and phone number should be real text in the HTML, not baked into an image. Screen readers can’t read a JPEG of your address, and neither can Google as reliably.

Mark it up so search engines understand it:

<script type="application/ld+json">
{
 "@context": "https://schema.org",
 "@type": "LocalBusiness",
 "name": "Your Business Name",
 "telephone": "+1-631-555-0100",
 "address": {
 "@type": "PostalAddress",
 "streetAddress": "123 Main St",
 "addressLocality": "Commack",
 "addressRegion": "NY",
 "postalCode": "11725"
 },
 "url": "https://example.com"
}
</script>

Keep that markup consistent with your Google Business Profile. Mismatched hours or a different phone number between your site and your profile is one of the most common local SEO problems I run into, and it has nothing to do with your Lighthouse number.

What to actually target

Chasing a perfect 100 usually means breaking something real, like lazy-loading your hero image so the Largest Contentful Paint measurement gets weird, or inlining so much CSS the page becomes unmaintainable. Here’s a saner set of goals for a local business site in 2026:

• LCP under 2.5 seconds on mobile. This is the one that correlates most with people staying.
• CLS under 0.1. Keep things from jumping.
• INP under 200ms. The page should respond when tapped.
• Accessibility above 90. It’s cheap to fix and it’s the right thing to do.

Hit those and you’re in good shape. If you’d rather not spend a weekend in DevTools, this is exactly the kind of work that falls under Long Island web design projects, and it’s usually a few hours of cleanup, not a rebuild.

FAQ

Does a higher Lighthouse score directly improve my local rankings?
No. Lighthouse is a diagnostic tool, not a ranking factor. Google uses real-world performance data (Core Web Vitals) as a tiebreaker, but content, links, and your Google Business Profile matter far more for local results.

Is a 100 score worth chasing?
Rarely. The last few points usually come from hacks that don’t help real users. Aim for the Core Web Vitals thresholds and a solid accessibility score, then stop.

Should I test my homepage or my service pages?
Both, but prioritize the pages people land on from search. For a local business that’s usually a specific service page and your contact page, not the homepage. Those are the ones a customer actually uses to call you.