Web Performance & Page Speed Services
Page speed optimization is the work of making a site render and respond faster for real users on real devices and networks. We measure where the time goes — server response, JavaScript, images, fonts, layout — fix the parts that cost the most, and hold the gains with performance budgets. Core Web Vitals optimization is the part Google scores, and the part we target first.
What we do
- Core Web Vitals optimization. We tune the three metrics Chrome reports from field data and that feed Google’s page experience signals: Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift. The goal is the “good” threshold for the 75th percentile of your traffic, not a one-off lab score.
- Page speed audits. A single deep pass on a slow page or template: a waterfall trace, a JavaScript cost breakdown, render-blocking analysis, and a prioritized list of fixes ranked by milliseconds saved per hour of work.
- Ongoing performance budgets. Limits set in CI — bytes of JS, request count, LCP target — that fail the build when a change regresses speed. This is how you stop a fast site from getting slow again three deploys later.
The metrics and the thresholds we hit
Field data is what counts. These are the “good” targets we work toward at the 75th percentile:
- LCP (Largest Contentful Paint): under 2.5s. The moment your main content — usually a hero image or headline — finishes painting.
- INP (Interaction to Next Paint): under 200ms. How fast the page responds to taps and clicks across the whole session. This replaced FID in March 2024 and is harder to pass, because it measures every interaction, not just the first.
- CLS (Cumulative Layout Shift): under 0.1. How much the layout jumps while loading. Usually caused by images without dimensions, late-injected ads, or web fonts swapping.
- TTFB (Time to First Byte): under 800ms. Server and network time before the browser gets anything. Not a Core Web Vital itself, but a slow TTFB caps how good LCP can ever be.
How we fix it
The wins are almost always in the same places:
- JavaScript. Most slow INP is main-thread work. We code-split, defer non-critical scripts, cut third-party tags, and break up long tasks. Shipping 200KB of JS instead of 800KB often moves INP more than any server change.
- Images. Serve AVIF/WebP, size them to the layout, set explicit width and height to kill CLS, and lazy-load everything below the fold. The LCP image gets
fetchpriority="high"and is never lazy-loaded. - Fonts. Preload the one font in the LCP element, use
font-display: swapwith a matched fallback to avoid layout shift, and subset to the glyphs you actually use. - Hydration. On React/Vue/Astro sites we cut client JS by moving work to the server, using islands or partial hydration, and streaming HTML so the browser paints before all the data arrives.
- Edge and CDN. Cache HTML at the edge, push TTFB down with a CDN close to users, and use stale-while-revalidate so a cache miss never blocks a render.
How we measure
We never optimize against a single number. Lighthouse and WebPageTest give us the lab traces to find the cause — the waterfall, the long tasks, the unused bytes. But the metric that ranks is field data: the Chrome User Experience Report (CrUX) and your own Real User Monitoring, segmented by device and connection. A 95 Lighthouse score with a failing CrUX LCP means your lab device is faster than your users’ phones. We track both and ship against the field.
Why work with us
We’re engineers who build the apps we optimize, so a fix isn’t a config tweak handed off and forgotten — it’s a change to the render path that holds. We’ve taken LCP from 6s to under 2s by fixing image priority and server response, and dropped INP under 200ms by deleting third-party scripts nobody could justify. Every engagement ends with a budget in CI so the next person on your team can’t quietly undo the work.
Send us a URL and we’ll tell you what’s slow, why, and what it costs to fix.
