Critical render path rebuilt on your production stack

Most slow pages are not slow because the images are heavy. Break LCP into its four parts, time to first byte, resource load delay, resource load duration and element render delay, and on the sites I get called into the two delay segments are routinely larger than the download itself. A 180KB hero discovered in the first hundred bytes of HTML beats a 60KB one discovered fourth. Byte-shaving is the last thing I do here, not the first. Order of work: The origin comes first. Server-Timing headers exposed on every response, so cache hit and miss stop being guesswork, then the TTFB distribution rather than its median. Google's threshold is 800ms, and above it under real load nothing done in the browser rescues the page. The usual fixes at this layer are a stale-while-revalidate policy that lets the edge answer while the origin refreshes, cache keys that stop fragmenting on tracking parameters, and Early Hints where your edge supports them. The render-blocking chain comes second. Which stylesheets and scripts stand between the HTML arriving and the first paint, in the order the parser meets them. Preconnect capped at the two origins that earn it. Fonts self-hosted as woff2, with size-adjust and ascent-override tuned on the fallback so the swap costs no layout shift. JavaScript split by route rather than by vendor, and legacy polyfill payloads dropped once browserslist matches what your analytics actually reports. Images come third. fetchpriority high on the LCP element. Preload with an imagesrcset that matches the sizes attribute exactly, because a mismatch there quietly downloads the wrong candidate and costs a second. Lazy loading removed from anything above the fold, which is the most frequent self-inflicted LCP regression I meet. AVIF with a WebP fallback inside a picture element. Dimensions or aspect-ratio on every image, so CLS does not re-enter through the repair. The decision that usually costs something: The anti-flicker snippet. Client-side experimentation tools hide the document while the variant resolves, often with a timeout measured in seconds, and that hidden period sits inside LCP for every visitor whether or not they are in a test. Moving experiments to the server or the edge is the correct fix and it is not cheap, so that recommendation goes in writing to whoever owns the experimentation budget, with the measured cost in milliseconds attached to it. What you receive: Merged pull requests, not a slide deck. Each one isolated to a single change, with the before-and-after LCP subpart breakdown from the web-vitals attribution build recorded in the pull request description, so six months from now the person doing archaeology on a regression can see which change bought what. A synthetic baseline from WebPageTest on a throttled mobile profile for the reproducible half, and the CrUX record for the half that decides anything. Plus a written note on what I chose not to do and why, which clients tell me is the more useful document. Out of scope: No visual redesign, no rewrite of your component library, no accessibility remediation beyond what these changes themselves touch, no infrastructure migration, no CDN contract negotiation. Backend query work is not mine either. If TTFB is dominated by database time, I isolate it, hand your team the trace and stop there. Third-party tags come out only with their owner's agreement, never quietly. Do not hire me for this if: You want one number to rise and do not care where it comes from. You cannot merge to production within six weeks, since work parked on a branch cannot be measured and I will not invoice for it. Your platform does not let you edit the head of the document. Or the real problem is that the page tries to do too much at once, in which case the honest engagement is a scope conversation with your product lead rather than an engineering one, and you will hear that from me on the first call, not in the final report. Terms: I work inside your repository under your review rules, in Czech, German or English, and I bill against merged work rather than hours logged.