Website Performance Optimization: How We Hit PageSpeed 99-100

Most websites score below 60 on Google PageSpeed Insights.

That’s not just a vanity metric problem. Slow websites lose customers. Google’s own research shows that 53% of mobile visitors leave a page that takes longer than 3 seconds to load. Every 100ms of delay reduces conversion by 7%.

We recently built a platform — Sesudu.com — that scores 99-100 on PageSpeed Insights across all 89 pages. Not on a simple landing page. On a full-stack platform with interactive calculators, location-based search, AI-generated images, and real-time API integrations.

Here’s exactly how we did it — and how you can apply the same principles to your website.

---

Why PageSpeed Actually Matters (Beyond the Score)

Let’s be clear about what’s at stake:

“PageSpeed isn’t about impressing developers. It’s about not losing customers before they see your product.”

The real impact:

• SEO Rankings — Google uses Core Web Vitals as a ranking signal. Slow sites get pushed down.
• User Experience — Fast sites feel professional. Slow sites feel broken.
• Conversion Rate — Every second of load time costs you 7% in conversions.
• Bounce Rate — 40% of users abandon a site that takes more than 3 seconds to load.
• Mobile Users — 60%+ of traffic is mobile, where performance gaps are amplified.

This isn’t theoretical. We’ve seen these numbers in real projects.

---

The Architecture Decision That Changes Everything

Before writing a single line of optimization code, the architecture decision determines 80% of your performance outcome.

Most websites start with heavy JavaScript frameworks that ship megabytes of client-side code. Then developers spend months trying to optimize what should have been fast from the start.

We took the opposite approach.

Static-First, Interactive Where Needed

For Sesudu.com, we chose Astro — a framework designed for content-heavy sites that ships zero JavaScript by default. Interactive components (calculators, search, product browsers) are loaded as isolated “islands” only when users need them.

The result:

Metric	Typical Website	Sesudu.com
JavaScript shipped	500KB - 2MB	< 50KB (95% of pages: 0KB)
Time to Interactive	3-8 seconds	< 1 second
Largest Contentful Paint	2.5 - 6 seconds	< 1.2 seconds
Cumulative Layout Shift	0.1 - 0.5	0.00
PageSpeed Score	40 - 75	99 - 100

This isn’t magic. It’s architecture.

---

The 8 Optimization Techniques We Used

Here’s the exact playbook we followed — every technique contributed to hitting that 99-100 score consistently.

1. Triple-Format Image Pipeline

Images are the #1 performance killer on most websites. We solved this with an automated pipeline:

• AVIF (primary) — 50-80% smaller than JPEG at same quality
• WebP (fallback) — 25-35% smaller than JPEG
• PNG (legacy fallback) — for older browsers

Every image gets responsive srcset attributes so mobile devices download smaller files. No user ever downloads a 2000px image on a 390px phone screen.

Impact: 60-70% reduction in image bandwidth.

2. Zero Cumulative Layout Shift (CLS)

CLS happens when elements move around as the page loads — images loading without dimensions, fonts swapping, ads injecting. Users hate it. Google penalizes it.

Our approach:

• Every <img> tag has explicit width and height attributes
• Fonts are self-hosted with font-display: swap and size-adjust fallbacks
• No third-party ads or dynamically injected content
• CSS loaded inline — no layout recalculation from external stylesheets

Result: CLS = 0.00 across all 89 pages.

3. Inline CSS Strategy

Most websites load CSS from external files. The browser has to:

1. Parse the HTML
2. Discover the CSS file reference
3. Request the CSS file
4. Wait for it to download
5. Parse the CSS
6. Then render the page

We eliminated steps 2-5 by inlining all CSS directly into the HTML. The browser gets everything it needs in a single request.

Impact: First Contentful Paint reduced by 200-400ms.

4. Self-Hosted Variable Font

Web fonts from Google Fonts or Adobe require additional DNS lookups, connections, and downloads. Each external font request adds 100-300ms.

We self-host a single variable font file (Outfit) that covers all weights. One file, no external requests, no font-loading flash.

Impact: Zero external font requests. Zero FOUT (Flash of Unstyled Text).

5. Lazy Loading with IntersectionObserver

Content below the fold doesn’t need to load immediately. We use the IntersectionObserver API to:

• Load images only when they enter the viewport
• Initialize interactive components only when scrolled into view
• Defer non-critical JavaScript until after the page is interactive

This means the initial page load only includes what the user can actually see.

6. Content-Visibility Optimization

CSS content-visibility: auto tells the browser to skip rendering sections that aren’t visible yet. For pages with heavy components (maps, image galleries, calculators), this dramatically reduces initial render time.

The browser still downloads the content — it just doesn’t waste time rendering it until the user scrolls there.

7. Edge-First Infrastructure

We deploy on a global CDN with edge caching. Every page is pre-rendered at build time and served from the nearest edge location to the user.

• Build time: Pages rendered once, served millions of times
• Edge caching: Content served from 300+ global locations
• API responses: Cached in KV storage with configurable TTL

A user in Tokyo gets the same sub-second load time as a user in Kuala Lumpur.

8. Schema Markup at Body End

Most websites put JSON-LD structured data in the <head>. This forces the browser to parse potentially large JSON blocks before rendering anything.

We moved all schema markup to the end of <body>. The browser renders the visible page first, then processes the structured data. Same SEO benefit, faster perceived load time.

---

The Results: Real Numbers From a Real Project

After implementing all 8 techniques on Sesudu.com, here are the actual Lighthouse scores:

• Performance: 98-100
• Accessibility: 100
• Best Practices: 100
• SEO: 100

Across 89 pages. Not a single-page marketing site. A full platform with:

• 21 interactive recipe infographics with AI-generated images
• Location-based restaurant search with dual API providers
• Global halal finder with Google Street View integration
• Interactive air fryer calculator (10 brands × 37 foods × 3 modes)
• 45+ components and 106 TypeScript data files

“Performance optimization isn’t about choosing between features and speed. It’s about engineering both.”

Read the full Sesudu.com case study →

---

The Performance Checklist

If you’re building or optimizing a website, here’s the checklist we use on every project:

• Architecture: Does your framework ship minimal JavaScript by default?
• Images: Are you using AVIF/WebP with responsive srcset?
• CLS: Does every image have explicit width and height?
• CSS: Can you inline critical CSS to eliminate render-blocking?
• Fonts: Are you self-hosting fonts instead of using external services?
• Lazy loading: Are below-fold elements deferred?
• Caching: Are you using edge caching with a global CDN?
• Schema: Is structured data at the end of body, not head?

If you answered “no” to more than two of these — your site is leaving performance on the table.

---

When to Hire a Performance Engineering Team

DIY optimization works for simple sites. But if you’re building:

• A content platform with hundreds of pages
• A SaaS product with interactive features
• A business application that needs to handle real traffic
• A mobile-first experience where every millisecond counts

You need a team that thinks about performance from architecture, not as an afterthought.

That’s what we do at ITULIS. We don’t bolt performance onto existing projects — we engineer it into the foundation.

“The cheapest performance optimization is choosing the right architecture before writing code. The most expensive is trying to fix a slow site after launch.”

---

The Bottom Line

Website performance optimization isn’t about tricks or plugins. It’s about architectural decisions made before the first line of code and engineering discipline maintained throughout development.

The difference between a 40-score website and a 99-score website isn’t talent — it’s approach.

We proved this with Sesudu.com: 89 pages, PageSpeed 99-100, zero CLS, sub-second load times — while delivering a feature-rich platform that users actually want to use.

If your website is slow, it’s not a content problem. It’s an engineering problem.

---

Building a platform that needs to be fast? Talk to ITULIS — we engineer high-performance web applications that score 99-100 on PageSpeed without compromising on features. See how we did it for Sesudu.com →