How We Build Websites That Score 95+ on Lighthouse

Why Performance Is a Business Decision, Not a Technical One

A one-second delay in page load time reduces conversions by 7% (Akamai). Google uses Core Web Vitals as a ranking signal. And 53% of mobile visitors abandon a site that takes more than three seconds to load (Google).

Performance isn’t about impressing developers. It’s about whether your website actually works as a business tool. A beautiful site that loads in six seconds is a brochure nobody reads. A fast site that loads in under two seconds is a revenue engine.

We treat performance as a first-class requirement on every project, not something we optimize after the fact. Here’s exactly how we do it.

The Tech Stack That Makes It Possible

Astro: Ship Less JavaScript

Most web frameworks send a mountain of JavaScript to the browser, even for pages that are mostly static content. A typical React-based marketing site might ship 200-400KB of JavaScript just to render text and images that don’t change.

Astro flips this model. It renders everything to static HTML at build time and sends zero JavaScript to the browser by default. Interactive components only load their JavaScript when they’re needed — a pattern called partial hydration or “islands architecture.”

The result: a typical page on a site we build sends under 50KB of JavaScript. Often much less. That’s not a marginal improvement. It’s an order-of-magnitude reduction that users feel immediately.

SvelteKit: When You Need Full Interactivity

For applications that need rich interactivity — dashboards, client portals, tools — we use SvelteKit. Svelte compiles components to vanilla JavaScript at build time, eliminating the runtime overhead that frameworks like React and Vue carry. A Svelte component is typically 40-60% smaller than its React equivalent doing the same thing.

We pick the right tool for the job. Marketing sites and content-heavy pages get Astro. Interactive applications get SvelteKit. Sometimes a single project uses both.

The Techniques That Actually Matter

Font Loading Done Right

Web fonts are one of the most common performance killers. A single Google Font can add 200-500ms to your page load and cause visible layout shift as the font swaps in.

Here’s what we do:

• Subset fonts to include only the characters actually used on the site. A full font file might be 250KB. A subset for English with common punctuation is often under 30KB.
• Self-host everything. No external requests to Google Fonts or Adobe Fonts. The font files live on the same server as the site, eliminating DNS lookups and connection overhead.
• Use font-display: swap with size-adjusted fallbacks. The page renders immediately with a system font that’s been tuned to match the web font’s metrics, so when the web font loads there’s zero layout shift.
• Preload the primary font. A single <link rel="preload"> tag tells the browser to start downloading the font before it even parses the CSS that references it.

Image Optimization That Goes Beyond Compression

Images are typically the heaviest assets on any page. We don’t just compress them — we rethink how they’re delivered.

• Modern formats first. Every image is served in WebP or AVIF with a JPEG fallback. AVIF is typically 50% smaller than JPEG at the same visual quality.
• Responsive srcset attributes. The browser downloads an image sized for the device, not a 2400px desktop image on a 375px phone screen.
• Lazy loading below the fold. Images that aren’t visible on initial load don’t download until the user scrolls near them. The hero image loads eagerly; everything else waits.
• Explicit dimensions on every image. This prevents Cumulative Layout Shift (CLS) — that annoying jump you see on pages where content shifts as images load.

Minimal JavaScript, Maximum Impact

Every kilobyte of JavaScript has to be parsed, compiled, and executed by the browser. On a mid-range Android phone (which is what most of the world uses), parsing JavaScript is 3-4x slower than on a MacBook Pro.

Our approach:

• No JavaScript by default. Every component starts as server-rendered HTML and CSS. We only add JavaScript when there’s an interaction that genuinely requires it.
• No heavy frameworks for simple interactions. A mobile menu toggle doesn’t need React. A few lines of vanilla JavaScript or a CSS-only solution handles it.
• Tree-shaking and code splitting. When we do use JavaScript libraries, bundlers strip out unused code and split the remainder into chunks that load only on the pages that need them.
• Third-party script audit. Analytics, chat widgets, and tracking pixels are some of the worst performance offenders. We audit every third-party script, defer what we can, and eliminate what doesn’t justify its weight.

Core Web Vitals, Explained Simply

Google measures three specific things, and they matter for both SEO and user experience.

Largest Contentful Paint (LCP)

What it measures: How long it takes for the largest visible element (usually a hero image or heading) to render.

Our target: Under 2.5 seconds. We typically hit under 1.5 seconds.

How we achieve it: Server-side rendering, preloaded critical assets, optimized images, and fast hosting. The largest element should be in the initial HTML response, not loaded by JavaScript after the fact.

Interaction to Next Paint (INP)

What it measures: How quickly the page responds when a user clicks, taps, or types.

Our target: Under 200ms. On most of our sites, it’s under 100ms.

How we achieve it: Minimal JavaScript means the browser’s main thread isn’t blocked by script execution. When we do have interactive elements, event handlers are lean and don’t trigger expensive re-renders.

Cumulative Layout Shift (CLS)

What it measures: How much the page layout moves around as content loads.

Our target: Under 0.1. We aim for zero.

How we achieve it: Explicit dimensions on all images and embeds, size-adjusted font fallbacks, and no content injection above the fold after initial render.

Real Results

The site you’re reading right now is built with Astro. Run a Lighthouse audit on it — we’ll wait.

This isn’t theoretical. Every site we ship goes through a performance audit before launch. We test on real devices, on throttled connections, on the cheapest Android phones we can find. Because that’s how a significant portion of your audience experiences your site.

Here’s what this translates to in practice:

• Pages load in under 2 seconds on a standard broadband connection and under 3 seconds on 4G mobile.
• Google rewards the speed with better crawl efficiency and ranking signals. One client saw a 15% increase in organic traffic within three months of launching their rebuilt, performance-optimized site — with no other SEO changes.
• Bounce rates drop. When pages load fast, people stay. We’ve seen bounce rates decrease by 20-35% on site rebuilds where performance was the primary focus.

What About Design? Does Performance Mean Boring?

No. Performance constraints actually force better design decisions. When you can’t rely on heavy animation libraries and auto-playing video backgrounds, you focus on typography, whitespace, color, and layout — the fundamentals that make a site genuinely beautiful rather than just busy.

Some of the most visually striking sites on the web are also the fastest. Performance and aesthetics aren’t in tension. They’re complementary.

Bottom Line

A fast website isn’t a luxury or a technical flex. It’s a direct contributor to your bottom line through better search rankings, lower bounce rates, and higher conversions. The tools and techniques to achieve it are well-established — Astro for static content, modern image formats, disciplined JavaScript budgets, and attention to Core Web Vitals.

If your current site is sluggish, bloated with JavaScript, or failing its Lighthouse audits, it’s costing you visitors and revenue every day. Let’s talk about rebuilding it the right way.