Skip to main content
    SEYMOURDIGITAL
    Performance
    10 December 2025
    9 min read

    Why Every Seymour Digital Website Scores 95+ on PageSpeed from Day One

    Our sites do not start at a poor PageSpeed score and get optimised later. They launch at 95+. Here is the architecture and methodology that makes that the baseline.

    James Seymour

    Founder, Seymour Digital

    Most website performance problems are not discovered at launch. They emerge slowly over months — a new plugin added here, a tracking script there, images uploaded without optimisation, a third-party integration that blocks rendering. By the time a business recognises that its site is slow, it has already compounded the SEO and conversion cost for a year or more. The Seymour Digital approach is different: performance is not a post-launch remediation activity. It is an architectural constraint from the first line of code.

    The Architecture Decisions That Determine Performance

    The most impactful performance decisions are made before any code is written. The choice of technology stack is the primary one. We build on React with a Vite build pipeline — a modern, optimised setup that outputs lean, code-split JavaScript bundles rather than a monolithic file. Every page loads only the JavaScript it needs. Assets unused by the current route are deferred entirely.

    We use no WordPress, no Wix, no Webflow, no template-based CMS. Each of these platforms carries inherited technical debt — render-blocking resources, bloated plugin ecosystems, or abstractions that trade performance for editorial convenience. Starting from custom architecture means starting without that debt.

    Images are handled through a disciplined pipeline: WebP format as standard, explicit dimensions on every element to prevent layout shift, responsive srcset attributes to serve the appropriate resolution for each viewport, and fetchpriority='high' on the Largest Contentful Paint element. This single set of decisions typically accounts for the majority of LCP improvement on any site we touch.

    What Our Sites Actually Score at Launch

    Mobile PageSpeed scores above 95 are standard across our builds. LCP consistently below 1.5 seconds. CLS below 0.05 — well within Google's 'good' threshold. INP below 100ms. These are not targets we aspire to after optimisation — they are the baseline our architecture delivers at launch.

    Desktop scores of 99–100 are typical. The delta between mobile and desktop performance on most of our sites is less than 5 points — which reflects a genuine mobile-first design process rather than a responsive afterthought added to a desktop-first build.

    These scores are achieved without performance theatre. We do not defer useful content, artificially reduce layout complexity, or strip features to hit metric targets. The performance comes from architectural decisions that are invisible to users but measurable in milliseconds.

    The Specific Technical Decisions Behind the Numbers

    Font loading is handled with font-display: swap and preconnect hints in the document head. Fonts are self-hosted where possible, eliminating cross-origin connection overhead. We use a maximum of two typefaces per site and load only the weights actually used in the design — not the full font family.

    Third-party scripts are deferred. Analytics, marketing pixels, and any external integrations are loaded after the page has rendered and become interactive. A user visiting the site should never have their experience degraded by a tracking script executing on the main thread before they can interact.

    Server infrastructure runs on isolated environments with global CDN caching, 48-hour cache lifetimes for static assets, and server-side gzip compression as standard. HTTP/2 is used across all delivery. These are not premium add-ons — they are baseline requirements for a site that performs in the real world.

    • React + Vite build pipeline with automatic code splitting
    • No CMS or plugin ecosystem overhead
    • WebP images with explicit dimensions and fetchpriority on LCP element
    • Self-hosted fonts with font-display: swap
    • Third-party scripts deferred to post-interaction
    • Global CDN with 48-hour static asset caching
    • HTTP security headers and HTTPS as standard

    What These Scores Mean Commercially

    A mobile PageSpeed score above 90 means Google's Core Web Vitals are in the green band — the threshold at which the Page Experience ranking signal works in your favour rather than against you. Competing sites on WordPress or template platforms typically score 30–55 on mobile. That gap in Page Experience signals translates to a ranking advantage that compounds over time.

    The conversion impact is equally measurable. Google's research shows a 27% improvement in conversion rate per second of load time improvement. For a professional services site moving from 3.5 seconds to 1.2 seconds — a realistic improvement when moving from WordPress to custom architecture — the conversion uplift is material and sustained.

    Critically, these gains are durable. Unlike paid advertising, which generates returns only while the budget is active, a performance advantage built into the architecture continues to pay returns for the life of the site.

    Our sites do not need performance optimisation after launch. They are architected to perform correctly from the first day they are live.

    Every organisation we build for receives a site that launches at 95+ on mobile PageSpeed, with Core Web Vitals in the green band from day one. This is not a premium upgrade — it is the standard. If you are comparing this against your current site's performance, PageSpeed Insights (pagespeed.web.dev) will show you the current gap in under 60 seconds. We are happy to discuss what closing that gap would mean for your specific business.

    Related Service

    Performance Tuning

    View Service