Website Speed Optimization: How a Regional Home Services Brand Achieved 95+ PageSpeed Scores Across 1,122 Programmatic Pages

The Challenge: A 15-Page Legacy Site With No Path to Scale

When this regional home services brand approached BFM, their web presence was a liability, not an asset. The site consisted of just 15 manually-coded HTML pages with no templating system, no component reuse, and no modern build pipeline. Every new page required a developer to write raw HTML from scratch — a process that made scaling to cover their full service territory practically impossible. Duplicate code was scattered across files, branding was inconsistent, and page load performance was poor enough to measurably affect conversion rates. There was no programmatic content strategy, no structured approach to local SEO, and no infrastructure capable of supporting the kind of location-based page coverage that drives organic visibility for home services businesses competing across a multi-city market.

The core business problem was equally clear: slow website performance was costing real revenue. With phone calls valued at $150 per conversion, every visitor who bounced due to a slow-loading page represented a direct and measurable loss. The brand operated across 66 service locations but had almost no dedicated landing pages for those areas — leaving enormous amounts of local search traffic uncaptured. The gap between where the site was and where it needed to be was not a gap of incremental improvement. It required a complete architectural rebuild designed for speed, scalability, and programmatic content generation from the ground up.

Key Performance Metrics

Our Approach: Static-First Architecture Built for Page Speed Optimization

BFM's strategy centered on one non-negotiable principle: every page delivered to a visitor must be pre-rendered static HTML. For a home services brand where every organic visit has a direct conversion value attached to it, there is no acceptable trade-off between content freshness and page speed. The solution was a Next.js application configured for full static export, generating all pages at build time using data-driven route parameters. This approach allowed the team to define products and locations as structured data, then use Next.js's generateStaticParams pattern to enumerate every valid combination — producing 1,122 product-location pages in a single automated build process. No manual page creation. No CMS bottlenecks. No server-side rendering overhead on the critical path.

The architecture was also designed to support multiple layout contexts without polluting the URL structure. Route groups — a Next.js App Router pattern — allowed the team to create distinct header and footer configurations for the main site, the programmatic SEO pages, and internal tools, each with its own optimized layout. This meant the 1,122 high-volume landing pages could use a streamlined, performance-optimized layout while the main product and service pages retained full navigation and conversion-focused components. Infrastructure was provisioned alongside the application, with Nginx serving static assets from disk with one-year cache headers, gzip compression enabled for all text-based content, and automated CI/CD pipelines keeping deployment time to a minimum.

Implementation Deep Dive: From 15 Pages to 1,175+ in Four Phases

The project was structured across four sequential phases, each with defined deliverables and acceptance criteria. Phase one focused exclusively on architecture design — establishing the route group structure, layout hierarchy, and static export configuration before a single component was written. This upfront investment paid dividends throughout the build: because the file structure and data patterns were agreed upon before implementation, the development team never had to refactor routing decisions mid-project. Phase two executed the full Next.js application build, including TypeScript configuration with strict mode enabled, all 129 React components, and the dynamic route files with generateStaticParams for every content type. Phase three addressed infrastructure — provisioning cloud hosting, configuring Nginx as a reverse proxy with aggressive caching rules, and establishing the automated CI/CD pipeline via GitHub Actions.

Phase four covered performance validation and deployment hardening. Each of the 1,122 programmatic pages was verified against Lighthouse benchmarks, with the 95+ threshold treated as a hard requirement rather than a target. Server response times were measured under the production Nginx configuration to confirm sub-200ms TTFB across all route types. Deployment pipelines were tested end-to-end on the staging environment before production promotion, and backup archives were confirmed to enable rollback within minutes if needed. The entire project — from architecture design through production launch — was completed inside a tight delivery window, demonstrating that disciplined phased execution is as important to website performance outcomes as any individual technical decision.

Technical Architecture: The Systems Powering 95+ Core Web Vitals Optimization

The application is built on Next.js with App Router and TypeScript in strict mode, exported as fully static HTML at build time. The route structure uses three route groups: a main group for full-navigation pages, a minimal group containing all 1,122 programmatic product-location pages with a streamlined layout optimized for conversion and speed, and an admin group for internal tooling. Fonts are loaded via next/font with CSS variable injection and font-display swap, eliminating render-blocking font requests — a common source of poor Largest Contentful Paint scores. All 129 React components were built with static rendering compatibility as a baseline requirement; no component in the programmatic page tree introduces client-side data fetching on the critical rendering path.

On the infrastructure side, Nginx is configured as the primary traffic handler with separate upstream blocks for production and staging environments. Static assets — JavaScript bundles, CSS, images, and web fonts — are served directly from disk with one-year immutable cache headers, bypassing the Node.js process entirely for the majority of byte transfers. The Node.js process managed by PM2 handles only dynamic routes and API endpoints, keeping its memory footprint well within the allocated limit. Gzip compression is enabled for all text-based MIME types, SSL terminates at Nginx with TLS 1.2 and 1.3 only, and security headers including HSTS, X-Frame-Options, and X-Content-Type-Options are applied globally. The result is a hosting stack where the 95+ PageSpeed score is a product of architecture, not luck.

Results & Impact: Website Performance Metrics That Drive Revenue

The results of this website speed optimization engagement are measurable at every layer of the stack. At the page performance level, all 1,122 programmatic pages achieve 95+ on Lighthouse across Performance, Accessibility, and Best Practices — with the SEO audit returning a perfect 100. Server response time sits under 200ms, meaning visitors begin receiving HTML within a fifth of a second of their browser making a request. These numbers matter specifically in home services, where the primary conversion action is a phone call valued at $150. Faster pages reduce the friction between a local search and a dialed number. At the content scale level, the site grew from 15 pages to 1,175+ — a content expansion of 7,733% — covering all 66 service locations that were previously unrepresented in the site's page inventory.

Location coverage grew by 2,100%, from a handful of city references in page copy to 66 dedicated service area pages each with unique metadata, structured location data, and product-specific content combinations. The build infrastructure supporting these results is deliberately lean: the full 1,175+ page site builds in under 60 seconds, enabling deployment frequency that most agencies reserve for small brochure sites. The CI/CD pipeline auto-deploys to staging on every push to the main branch and promotes to production via a protected branch, with HTTP health checks confirming successful deployment before the workflow completes. This combination of front-end performance, content scale, and operational automation is what separates a website speed optimization engagement from a simple performance audit.

Key Takeaways: What Makes This Page Speed Optimization Approach Repeatable

Lessons Learned: What We'd Replicate on Every Home Services Website Optimization

The most important validation from this project is that architecture decisions made before a single line of application code is written determine the performance ceiling of the final product. The choice to use static export over server-side rendering was made in phase one, and every subsequent technical decision — component design, caching strategy, infrastructure configuration — was made in service of that constraint. Teams that attempt to optimize performance after architecture is set are fighting uphill. The route group structure, the TypeScript strict mode configuration, and the data separation between SEO products and GEO locations all traced back to deliberate upfront design. On any future engagement of similar scope, BFM would replicate this architecture-first sequence without modification.

One operational lesson that applies broadly: build time is a proxy metric for deployment health. When the full 1,175+-page build completes in under 60 seconds, the team has immediate feedback that nothing in the generateStaticParams pipeline is broken, that TypeScript compilation succeeded, and that the artifact is ready for deployment. Longer build times create uncertainty and discourage frequent deployment. Investing in incremental TypeScript compilation, pnpm caching in CI, and a lean dependency tree is not a developer experience optimization — it is a reliability investment. The second operational lesson: always deploy to a staging environment first. The branch-based workflow where the main branch auto-deploys to staging and a protected production branch gates production promotion caught configuration issues before they affected live traffic or the 95+ PageSpeed scores the site had earned.

Frequently Asked Questions About Website Speed Optimization at Scale

Home services brands and their marketing teams consistently ask the same questions when evaluating a website performance engagement of this scope. The answers below are drawn directly from the implementation documented in this case study — every metric referenced traces to the verified results of this project.