PageSpeed 100: How We Build Websites That Score at the Top for Performance, Accessibility, Best Practices and SEO

Why speed matters more than the score

The PageSpeed Insights score is a lab estimate; what matters is how fast real visitors on real phones see and use the page. Google measures that through Core Web Vitals: Largest Contentful Paint (how quickly the main content appears), Interaction to Next Paint (how quickly the page responds to taps) and Cumulative Layout Shift (whether things jump around). Pages that are fast on these measures convert better, especially on mobile and especially for paid traffic, where every lost visitor is money already spent. Speed is a modest ranking signal; it is a large conversion signal. See web.dev on Core Web Vitals.

Decision 1: render on the server

This site is server-rendered HTML from Node.js and EJS templates, with one small plain JavaScript file for navigation, forms and analytics. There is no client-side framework, no bundler and no hydration step. The browser receives a complete page it can paint immediately. For most marketing and service websites, a heavy single-page application framework adds weight with no benefit to the visitor. Our case study sites, including Prime Comfort Group and Black Label Detailing, follow the same principle.

Decision 2: CSS inlined, fonts non-blocking

Our single stylesheet is read once when the server starts and inlined into the head of every page. That removes a render-blocking request which, on a slow mobile connection, cost close to a second. The font loads with a media trick that applies it after load, with a system font shown first, so text is never invisible. If your CSS is large, inline only the critical portion and load the rest after first paint.

Decision 3: images with rules

Every image has explicit width and height so the layout never shifts. Hero images use srcset so phones download smaller files. Photos are compressed JPEG or WebP at sensible sizes; logos are small PNGs or SVGs. Images below the fold load lazily; the main hero image does not. When we started on this site, it carried around 46 MB of images, including favicons near a megabyte each; it now sits around 2.6 MB in total. Most slow websites are slow because of images nobody resized.

Decision 4: defer analytics and third parties

Analytics, ad pixels, chat widgets and embedded videos are usually what costs the last points. We keep tiny stubs for Google Analytics and the Meta pixel that queue events immediately, so nothing is lost, and load the actual vendor scripts on first interaction or when the browser is idle. Embedded videos load a lightweight preview until clicked. Each third-party script should justify its weight; remove the ones nobody uses. There is an honest trade-off here: the Meta pixel's third-party cookies cost points in Best Practices on our own site, and we accept that because the tracking matters to the business.

Decision 5: caching and delivery

Static assets carry long cache lifetimes with versioned URLs, so returning visitors download nothing twice and new deployments still update immediately. HTML is compressed. A CDN in front of the server shortens distance to visitors in the USA, UK and elsewhere. Scroll and resize handlers are throttled to animation frames, and read-depth tracking uses IntersectionObserver rather than measuring the page on every scroll, which avoids forced layout work that hurts responsiveness.

Accessibility is part of the job

Accessibility and speed come from the same discipline. Text contrast must meet WCAG AA; we keep separate grey tokens for light and dark backgrounds because using the wrong one twice dropped our score. Links inside paragraphs are underlined, because colour alone is not enough. Buttons and form fields have labels, headings run in order, there is a skip link and a visible focus state, and motion respects reduced-motion settings. These help screen reader and keyboard users, and they also make pages easier for crawlers and AI assistants to parse.

How to check your own site

Run PageSpeed Insights on your home page, a service page and a blog post, on mobile. Look at the field data first if Google has it, then the lab diagnostics. The usual culprits, in order: oversized images, render-blocking CSS and fonts, third-party scripts, and heavy themes or page builders. Fix those and most sites move dramatically. Then check accessibility in the same report and fix contrast and labels. See also our Core Web Vitals and leads guide.

Server and hosting choices

The fastest page still waits for the server. Time to first byte should be low and consistent, which means a server close enough to your visitors or a CDN in front of it, application code that does not query a database ten times per page, and caching for anything that does not change per visitor. Shared hosting with noisy neighbours, slow PHP stacks without caching and overloaded plugins are common causes of slow first bytes. Our own site runs on Node.js behind Cloudflare, with pages rendered from in-memory data, so the server responds quickly and the CDN serves static files from locations near visitors in the USA, UK and India.

Measure before and after any hosting change. A faster server does nothing for a page carrying four megabytes of images, and lighter pages on modest hosting often beat heavy pages on expensive hosting.

Keeping the score

Speed decays. Each new plugin, tracking pixel, chat widget, font weight or unoptimised photo costs a little, and a site that scored in the high 90s at launch can drift into the 60s within a year. Check PageSpeed Insights on key templates after every significant change, keep an image size rule for everyone who uploads content, and review third-party scripts every quarter. Our own project notes record each decision that made the site fast and why, so later changes do not undo them by accident.

When to rebuild instead of optimise

If a site is built on a heavy page builder with dozens of plugins, optimisation often hits a ceiling. A rebuild on a lean stack can cost less than months of tuning and produces a faster, easier-to-maintain site. We build those through our website development and UI/UX services for businesses in the USA and every other market we serve.

Frequently asked questions