Why the Start Is the Best Time

Retrofitting performance onto an existing site is expensive, slow, and partial. Decisions made in the first sprint — framework choice, image pipeline, font strategy, caching architecture — set the ceiling for everything that follows.

Starting a new project is a rare opportunity. Don't miss it.

Infrastructure

• Choose a CDN-native hosting platform (Vercel, Netlify, Cloudflare Pages). Global edge delivery should be free and automatic, not a paid upgrade.

• Enable HTTP/2 or HTTP/3. Both are supported by default on modern platforms. HTTP/2 multiplexing alone reduces connection overhead significantly.

• Set aggressive cache headers for static assets. Content-hashed filenames + max-age=31536000 + immutable is the correct default.

• Configure TTFB monitoring from day one. Baseline it before traffic hits so regressions are visible immediately.

Images

• Choose WebP as your default format. AVIF where supported. Never default to PNG for photographs.

• Set up an automated image optimization pipeline — either via your build tool or a CDN-based image transformation service.

• Always set explicit width and height on img elements to eliminate CLS before it starts.

• Use lazy loading on all images below the fold. Add loading="eager" and fetchpriority="high" on your hero image.

Fonts

• Use variable fonts wherever possible — one file, full range.

• Preload your primary font weight in the document head.

• Set font-display: swap or fallback on all @font-face declarations.

• Limit to 2–3 font families maximum. Audit every weight you load — unused weights are pure waste.

JavaScript

• Enable route-based code splitting before writing any feature code. Most frameworks do this automatically — verify it's working.

• Audit your initial dependencies before the project grows. Every npm package added later is harder to remove.

• Set a JS bundle size budget in your build config. Fail the build if you exceed it.

• Defer non-critical scripts by default. Make synchronous loading the exception, not the rule.

Monitoring

• Instrument Core Web Vitals from day one using the web-vitals library.

• Set up Lighthouse CI in your deployment pipeline. A performance regression should block a deploy.

• Define your performance budget before launch — LCP under 2.5s, CLS under 0.1, INP under 200ms.

None of these decisions are hard to implement at the start. All of them are expensive to add later. Build them in now.