A site that feels quick at 20 pages often stops feeling quick at 2,000. The database grows, third-party tags accumulate, the marketing team adds a hero video, and one day Search Console starts flagging URLs as Needs improvement. The fix is rarely a single clever trick. It is a small set of decisions about measurement, caching layers, CDN configuration and deployment discipline. Here is the sequence we use at Workaholic Developers when a growing site needs to get faster without a rebuild.
Measure field data first, not lab scores
The most common mistake is optimising against a Lighthouse score. Lighthouse runs a simulated load on a throttled connection from wherever you happen to be sitting. Google's page experience signals are based on the Chrome User Experience Report (CrUX), which aggregates real Chrome users at the 75th percentile over a rolling 28-day window. Those are different questions, and they often give different answers.
Practical setup before you change anything:
- Open the Core Web Vitals report in Search Console and note which URL groups are failing, and on which device class. Mobile and desktop are graded separately.
- Add real user monitoring. The official web-vitals JavaScript library is a few kilobytes and will report LCP, INP and CLS from actual visitors, with attribution data telling you which element or script caused the problem.
- Because CrUX moves on a 28-day window, expect roughly a month of lag before a fix shows up as a passing status. Your own RUM data will confirm the win within days.
The three metrics that decide the verdict
LCP: largest contentful paint, target under 2.5 seconds
LCP is usually a hero image or a headline block. Break it into server response time, resource load delay, and render delay, then attack whichever dominates. The highest-yield moves are almost always the boring ones: serve the LCP image in AVIF or WebP at the size it actually renders, mark it as high priority rather than lazy-loading it, and remove render-blocking CSS and fonts sitting in front of it. If your LCP element is discovered late because it is injected by JavaScript, no amount of compression will save you — move it into the server-rendered HTML.
INP: interaction to next paint, target under 200 milliseconds
INP replaced First Input Delay as a Core Web Vital in March 2024, and it is where most modern sites now fail. INP measures the full latency from a tap or click to the next visual update, so heavy hydration, oversized event handlers and long tasks all show up here. The fixes are structural: reduce the amount of JavaScript that must execute before the page is interactive, break long tasks into smaller chunks, and yield to the main thread inside expensive handlers using scheduler.yield where available with a setTimeout fallback. Also check what your tag manager is loading — analytics, chat widgets and A/B testing scripts are frequent INP offenders, and deferring them costs nothing.
CLS: cumulative layout shift, target under 0.1
CLS is the cheapest metric to fix and the easiest to regress. Set explicit width and height (or aspect-ratio) on every image, embed and ad slot. Reserve space for cookie banners and promotional bars instead of injecting them above existing content. For web fonts, use font-display swap together with a size-adjusted fallback so the swap does not reflow the page.
Caching is three layers, not one setting
Teams often treat caching as a plugin toggle. It is really three independent layers, and each needs its own policy.
- Browser cache. Fingerprinted static assets should be immutable with a one-year max-age. HTML should never carry a long browser max-age, or visitors will see stale pages after every deploy.
- CDN or shared cache. This is where the leverage is. Give HTML a short shared max-age (s-maxage) plus a generous stale-while-revalidate window. The CDN then serves the cached copy instantly while refreshing in the background, so a slow origin never becomes a slow page. A typical pattern for a content page is a max-age of 0 for browsers, an s-maxage of a few minutes, and stale-while-revalidate measured in hours.
- Application and object cache. Redis or Memcached for query results, rendered fragments and session data. This is what keeps your origin healthy when the CDN does miss.
The piece most teams skip is targeted invalidation. Purging the entire cache on every publish throws away your hit ratio and hammers the origin. Tag responses by entity — product ID, category, author — and purge only the affected tags. Fastly calls this Surrogate-Key; Cloudflare offers Cache-Tags on Enterprise plans; most modern frameworks expose an equivalent, such as Next.js revalidation tags or Laravel cache tags backed by Redis.
CDN decisions that matter when traffic spans India and Canada
For our clients in Pathankot and Punjab who also sell into Canada, the single origin server is usually the bottleneck. A visitor in Toronto hitting a Mumbai origin pays the round-trip cost on every uncached request, and that cost lands directly in LCP.
- Enable tiered caching or origin shield so edge nodes fill from a regional parent rather than all reaching back to your origin independently. This lifts hit ratio and cuts origin load sharply on multi-region traffic.
- Turn on HTTP/3 and Brotli at the edge. Both are one-click on every major CDN and both help most on long-distance, lossy mobile connections.
- Push redirects, country routing and bot rules to the edge instead of resolving them in PHP or Node. A redirect chain served from the origin costs a full round trip per hop.
- Normalise your cache key. Marketing URLs carrying utm parameters will fragment your cache into thousands of near-identical entries unless you strip them from the key.
DevOps guardrails that stop regressions
Performance is not a project; it is a property you defend. Three guardrails do most of the work:
- Budgets in CI. Run Lighthouse CI or a bundle-size check on every pull request and fail the build when the JavaScript budget is exceeded. It is far easier to reject 300KB before merge than to hunt it down a quarter later.
- Server-Timing headers. Emit database, cache and render timings so slow responses are diagnosable from production rather than reproducible only on a laptop.
- Cache-aware deploys. Deploys should purge by tag, warm critical routes, and never ship a blanket no-store header. Note that Cache-Control: no-store disqualifies a page from the back/forward cache, which turns instant back-navigation into a full reload.
Where performance work turns into SEO wins
Speed is one signal among many, so treat Core Web Vitals as a tie-breaker rather than a ranking lever. The compounding wins come from the same infrastructure work: server-rendered HTML so crawlers do not depend on JavaScript execution, fast and consistent responses so crawl budget goes to real pages, single-hop redirects instead of chains, clean canonicals, and correct 404s rather than soft ones. On Chromium browsers you can add the Speculation Rules API to prerender likely next pages, which makes navigation feel instant for users even though it does not change your measured metrics.
A realistic 30-day sequence
Week one: instrument with RUM and confirm which metric is actually failing. Week two: fix LCP — image formats, priority hints, render-blocking resources, origin response time. Week three: set the three-layer cache policy and tag-based purging, then verify hit ratio at the edge. Week four: attack INP by cutting or deferring JavaScript, and add CI budgets so the gains hold.
Most growing sites do not need a rewrite. They need honest measurement, a caching policy someone actually designed, and a CDN configured for where their visitors really are. If you want a second pair of eyes on yours, the team at Workaholic Developers works on exactly this kind of audit and remediation for businesses across India and Canada.