The Busy Team’s SSR Optimization Checklist: 8 Quick Wins

Introduction: Why SSR Performance Matters More Than Ever

Server-side rendering (SSR) has become a cornerstone of modern web development, enabling faster initial page loads, better SEO, and improved user experiences on slow networks. However, with great power comes great responsibility—and often, great performance debt. Many teams adopt SSR frameworks like Next.js, Nuxt, or SvelteKit without fully understanding the performance implications. A poorly optimized SSR application can suffer from high time-to-first-byte (TTFB), excessive server load, and a sluggish first contentful paint (FCP). For busy teams juggling feature development and tight deadlines, performance optimization often takes a back seat. But the good news is that you don't need a complete overhaul to see significant gains. This checklist focuses on eight quick wins—changes that can be implemented in hours, not weeks—that address the most common SSR performance bottlenecks. Each win includes a clear explanation of why it works, step-by-step implementation guidance, and common pitfalls to avoid. We'll cover caching strategies, data fetching patterns, bundle optimization, streaming, and more. Whether you're running a Next.js app on Vercel or a custom Node.js server on AWS, these optimizations are framework-agnostic and designed for maximum impact with minimum effort. By the end of this guide, you'll have a prioritized, actionable roadmap to improve your SSR performance without derailing your development roadmap. This overview reflects widely shared professional practices as of May 2026; verify critical details against current official guidance where applicable.

Quick Win 1: Implement Incremental Static Regeneration (ISR)

One of the simplest yet most impactful SSR optimizations is moving from fully dynamic server-side rendering to a hybrid model using Incremental Static Regeneration (ISR). ISR allows you to pre-render pages at build time, then update them incrementally as data changes, without requiring a full rebuild. This dramatically reduces server load and improves response times because pages are served from a CDN cache rather than being generated on each request. For busy teams, ISR is a game-changer because it requires minimal code changes—often just a configuration option in your framework. In Next.js, for example, you can add a revalidate property to getStaticProps to specify how often (in seconds) the page should be regenerated. This means your most frequently accessed pages are served instantly, while less critical pages can be regenerated periodically. The key trade-off is data freshness: pages are only as up-to-date as the revalidation interval. For pages that need real-time data, ISR may not be suitable, but for many use cases—like blog posts, product listings, or marketing pages—it's a perfect fit. One team I read about reduced their server costs by 40% simply by applying ISR to their top 20 traffic-heavy pages. To get started, identify pages that don't require real-time updates, set a reasonable revalidation interval (e.g., 60 seconds for a news site, 1 hour for a documentation site), and monitor cache hit ratios to fine-tune. Remember that ISR works best with a CDN that supports stale-while-revalidate, which serves the cached version while fetching the updated one in the background. This ensures users never experience a delay, even during regeneration. In summary, ISR is a low-effort, high-impact optimization that busy teams should implement first.

Step-by-Step ISR Implementation

To implement ISR in a Next.js application, start by identifying the pages that benefit most from static generation but still need periodic updates. For each such page, modify your data fetching function to export getStaticProps with a revalidate property. For example, set revalidate: 60 to regenerate the page every 60 seconds. Ensure your page components are static-friendly—avoid using server-only APIs like req or res in the component itself. After deployment, test by visiting the page and checking the response headers for x-nextjs-cache; a value of HIT indicates the page is served from cache. Monitor your server logs to see how often regeneration is triggered. If you notice high regeneration frequency, consider increasing the revalidation interval or using on-demand revalidation via webhooks when data changes. For complex scenarios, combine ISR with a CDN that supports stale-while-revalidate to serve stale content immediately while fetching fresh content in the background. This ensures zero downtime for users. Common pitfalls include forgetting to revalidate dynamic routes (use getStaticPaths with fallback: 'blocking') and setting too-short revalidation intervals that defeat the purpose of caching. Start with conservative intervals and tighten them based on real-world traffic patterns.

Quick Win 2: Optimize Data Fetching with Request Deduplication and Batching

Data fetching is often the primary bottleneck in SSR applications. Each page request can trigger multiple API calls—to databases, external services, or internal microservices—each adding latency and server load. Two powerful techniques to reduce this overhead are request deduplication and batching. Deduplication ensures that if multiple components on the same page request the same data, only one API call is made. Batching combines multiple requests into a single call, reducing the number of round trips. These optimizations are especially effective in frameworks like Next.js, where getServerSideProps often makes multiple fetch calls. Implementing deduplication is straightforward: use a caching layer (like a memoized fetch function) that stores promises rather than resolved values, so concurrent requests for the same key share the same promise. Libraries like swr or react-query can help, but a simple in-memory cache with a short TTL works too. Batching requires more architectural consideration: you might need to design a GraphQL endpoint or a specialized batch API that accepts multiple resource IDs. For busy teams, a pragmatic approach is to start with deduplication, as it requires no backend changes. Simply wrap your fetch calls in a helper that caches in-flight requests. One common scenario: a product page that fetches user reviews, product details, and recommendations—all of which might share a user ID. With deduplication, that single ID is fetched once. Batching becomes valuable when you notice multiple independent requests to the same service; for example, fetching user profiles for a list of authors. In that case, a batch endpoint that accepts an array of IDs can reduce N requests to one. The trade-off is increased complexity on the backend and potential latency if the batch request waits for all sub-resources. Start with deduplication, measure the number of redundant requests, and then consider batching for the top offenders. This approach minimizes engineering effort while delivering tangible performance gains.

Implementing a Simple Request Deduplication Cache

Create a utility function that wraps your standard fetch and caches ongoing requests. In Node.js, you can use a Map that stores promises keyed by a unique string (e.g., URL + serialized params). When a new request comes in, check if a promise for that key already exists; if so, return it; otherwise, initiate a new fetch and store the promise. After the promise resolves, delete it from the cache to allow fresh requests on subsequent calls. This pattern works for both client and server, but on the server, be careful about memory leaks—set a TTL (e.g., 5 seconds) using setTimeout to clear stale entries. Example code snippet: const cache = new Map(); async function dedupedFetch(url) { if (cache.has(url)) return cache.get(url); const promise = fetch(url).then(res => res.json()); cache.set(url, promise); promise.finally(() => setTimeout(() => cache.delete(url), 5000)); return promise; }. Test by making multiple concurrent requests to the same URL—you should see only one network call. Monitor your server logs to verify that deduplication is reducing the number of outbound requests. For batching, you'll need backend support: create an endpoint like /batch?ids=1,2,3 that returns an array of responses. Then modify your frontend to collect all needed IDs for a given resource type and make one call. This works best for data that is frequently accessed together, such as user profiles or product prices. The key is to measure before and after: use APM tools to track request counts and latencies. If you see a significant reduction in outgoing requests, you've likely improved TTFB and reduced server load.

Quick Win 3: Implement Caching for API Responses and Rendered HTML

Caching is the bread and butter of SSR optimization, yet many teams underutilize it. There are two primary caching layers you should consider: API response caching (server-side, for data fetches) and rendered HTML caching (CDN or reverse proxy). For API response caching, you can use a fast in-memory store like Redis or even a simple in-memory object for smaller applications. The idea is to cache the results of expensive database queries or external API calls, with a configurable TTL. This reduces the load on your data sources and speeds up page generation. For HTML caching, tools like Varnish, Nginx FastCGI Cache, or CDN edge caching can store the final rendered HTML and serve it directly, bypassing the Node.js server entirely. This is especially effective for pages that are identical for all users, like blog posts or documentation. The key is to choose the right cache invalidation strategy: time-based (TTL), event-based (purge on data change), or key-based (include version in URL). For busy teams, a pragmatic approach is to start with time-based caching for both layers, using conservative TTLs (e.g., 60 seconds for HTML, 300 seconds for API responses). Monitor cache hit ratios and adjust TTLs based on data freshness requirements. A common pitfall is caching personalized content (like user dashboards) without proper keying—include user IDs or session tokens in the cache key to avoid serving wrong content. Another mistake is not purging caches when data changes, leading to stale content. Use webhooks or database triggers to invalidate related caches when data is updated. For example, when a blog post is edited, send a request to purge the HTML cache for that post's URL. This combination of caching layers can cut response times from hundreds of milliseconds to single digits. One team I read about reduced their server CPU usage by 70% after implementing a two-layer caching strategy. The effort is moderate—setting up Redis and configuring a CDN—but the payoff is substantial. If you're using a platform like Vercel, edge caching is built-in; you just need to set proper Cache-Control headers. For custom setups, consider using a service like Redis Labs or a self-hosted Redis instance. Remember that caching is not a silver bullet; it requires careful planning and monitoring. But for busy teams, it's one of the highest-ROI activities you can undertake.

Setting Up a Simple In-Memory API Cache

For smaller applications or as a starting point, you can implement an in-memory cache in your Node.js server. Create a class or module that stores key-value pairs with expiration times. Use a Map to hold the cache data, and when setting a value, also store a timestamp. On retrieval, check if the entry has expired; if so, delete it and return null. To avoid memory bloat, set a maximum number of entries (e.g., 1000) and implement a simple LRU eviction policy or just clear old entries periodically. Example: class MemoryCache { constructor(ttl = 300000) { this.cache = new Map(); this.ttl = ttl; } get(key) { const entry = this.cache.get(key); if (!entry) return null; if (Date.now() > entry.expiry) { this.cache.delete(key); return null; } return entry.value; } set(key, value) { this.cache.set(key, { value, expiry: Date.now() + this.ttl }); } }. Use this cache to wrap your database queries or external API calls. For example, instead of directly calling fetchPosts(), call cache.get('posts') first; if null, fetch and store. This simple pattern can dramatically reduce repeated calls. However, be aware that in-memory caching doesn't scale across multiple server instances—each server has its own cache. For distributed environments, use Redis or Memcached. Also, ensure your cache is invalidated when data changes; you can implement a del(key) method and call it from your data mutation endpoints. The key is to measure the cache hit ratio: if it's low, your TTL may be too short or your cache keys too specific. Aim for a hit ratio above 80% for API calls. This quick win requires minimal code changes and can be done in an afternoon. It's especially effective for pages that fetch the same data repeatedly, such as a homepage with a list of recent articles.

Quick Win 4: Reduce JavaScript Bundle Size with Code Splitting and Tree Shaking

Large JavaScript bundles are a common source of slow SSR performance, especially on the initial load. When the server renders a page, it needs to execute all the JavaScript required for that page—including components, utilities, and third-party libraries. If your bundle is bloated with unused code, you're wasting CPU cycles and increasing TTFB. Two key techniques to reduce bundle size are code splitting and tree shaking. Code splitting allows you to break your application into smaller chunks that are loaded on demand, rather than loading the entire application on every page. In SSR, this means the server only renders the components needed for the current route, reducing the amount of code that must be executed. Tree shaking is a build-time optimization that removes dead code—functions, imports, or components that are never used. Modern bundlers like Webpack, Rollup, and Vite support tree shaking automatically if you use ES module syntax. For busy teams, the quickest win is to audit your bundle using tools like webpack-bundle-analyzer or source-map-explorer. Look for large dependencies that you might only use partly. For example, if you import the entire lodash library but only use debounce, switch to importing only that function: import debounce from 'lodash/debounce'. Similarly, use dynamic imports (import()) for components that are not immediately needed, such as modals or heavy chart libraries. In Next.js, you can use next/dynamic to load components on the client side only, reducing server-side bundle size. However, be cautious: if a dynamically imported component is needed for the initial render, it may cause a flash of missing content. Use it for non-critical UI elements. Another approach is to lazy-load third-party scripts—like analytics or chat widgets—that are not essential for the initial page load. The impact of these changes can be significant: reducing the server-side bundle from 500 KB to 200 KB can cut TTFB by 30% or more. One team I read about reduced their bundle size by 40% simply by replacing a heavy charting library with a lighter alternative and removing unused polyfills. The effort is moderate—you'll need to analyze your dependencies and refactor imports—but the performance gains are lasting. Start by identifying the largest modules in your bundle and look for opportunities to split or replace them. Remember that tree shaking only works with ES modules; if you're using CommonJS, consider migrating to ESM.

Using Bundle Analyzer to Find Bloat

Integrate a bundle analyzer into your build process. For Next.js, you can use @next/bundle-analyzer by adding it to your next.config.js. After running a build, open the generated analyze.html file in your browser. You'll see a treemap of all your modules, sized by their byte contribution. Focus on the largest blocks—these are your optimization targets. Look for duplicate modules (same library included multiple times due to version mismatches) and large utility libraries used sparingly. For each large module, ask: can I replace it with a smaller alternative? Can I use a specific import instead of the whole library? Can I lazy-load it? For example, if you see moment.js (over 200 KB), consider replacing it with date-fns or dayjs. If you see chart.js used on only one page, make it a dynamic import. After making changes, rerun the analyzer to confirm size reductions. Also, check your server-side bundle separately—some tools show client-side bundles only. For SSR, the server-side bundle matters too, because it's executed on every request. Use webpack-bundle-analyzer with a server-specific config if needed. Common pitfalls include forgetting to exclude server-only code from the client bundle (e.g., database drivers) and not accounting for CSS-in-JS libraries that add runtime overhead. Tree shaking can be finicky with side effects; ensure your package.json has "sideEffects": false if your library supports it. This quick win is foundational: smaller bundles mean faster SSR and faster client hydration. It's a one-time effort that pays dividends every time you deploy.

Quick Win 5: Enable Streaming and Server-Side Suspense

Streaming is a powerful technique that allows the server to send HTML to the browser in chunks, rather than waiting for the entire page to be rendered. This means the user sees content sooner—the browser can start rendering parts of the page while the server is still processing other parts. In React 18 and Next.js 13+, streaming is supported via Suspense boundaries. The core idea is to wrap components that depend on slow data fetching (e.g., API calls, database queries) in a Suspense component with a fallback UI (like a spinner). The server will first send the rest of the page (e.g., header, navigation) and then stream the wrapped component once its data is ready. This improves perceived performance and reduces TTFB because the initial HTML is sent immediately. For busy teams, implementing streaming is relatively straightforward if you're already using a modern framework. In Next.js, you can use loading.js files to automatically wrap page segments in Suspense. For custom Node.js servers, you can use the ReadableStream API to pipe rendered chunks. The key is to identify which parts of your page are blocking the initial render. Typically, these are data-dependent sections like user profiles, comment sections, or recommendation widgets. By streaming them, you ensure the critical content (headline, main text) appears quickly. However, streaming is not suitable for all scenarios. If your entire page depends on a single slow API call, streaming won't help until that call resolves. In that case, consider parallelizing data fetching or using caching first. Also, streaming can complicate SEO if search engine crawlers don't wait for the full page to load. Google's crawler supports streaming, but older crawlers may not. For SEO-critical pages, ensure your main content is not inside a streaming boundary. Another consideration is server resource usage: streaming keeps the server connection open longer, which can increase memory usage under high concurrency. Use streaming judiciously, starting with one or two slow sections. Measure the impact on TTFB and FCP using real user monitoring (RUM) data. One team I read about reduced their FCP by 25% by streaming their comment section, which previously blocked the entire page load. The implementation took only a few hours. In summary, streaming is a quick win for improving perceived performance, especially on pages with mixed content priorities. It's a low-risk optimization that modern frameworks support natively. Just be mindful of SEO and server resource implications, and test thoroughly.

Implementing Streaming in Next.js 13+

To enable streaming in a Next.js app, first ensure you're using the App Router (not Pages Router) and Node.js 18+. In your layout.js or page.js, import Suspense from React, then wrap any component that performs asynchronous data fetching. Provide a fallback UI, such as a loading spinner or skeleton. For example: . The Comments component should be an async component that fetches data directly (using async/await inside the component). Next.js will automatically stream the fallback first, then replace it with the actual content when ready. You can also use loading.js files at the segment level to define a loading UI for a group of routes. This automatically wraps the segment's page in Suspense. For optimal performance, avoid wrapping your entire page in a single Suspense boundary; instead, use multiple boundaries for independent sections. This allows each section to stream independently. Test by observing the network tab: you should see the initial HTML arrive quickly, followed by chunks containing the streamed content. Monitor the Transfer-Encoding: chunked header. If you encounter issues with server-side rendering of streaming content (e.g., errors in async components), ensure your fetch requests are properly handled with error boundaries. Also, be aware that streaming can increase server memory usage because the response is kept open. Under high load, consider limiting the number of concurrent streaming requests or using a CDN that supports streaming aggregation. The trade-off for improved user experience is slightly higher server resource consumption. For most busy teams, the benefits outweigh the costs. Start with one non-critical section, measure the impact, and expand gradually.

Quick Win 6: Optimize Images and Static Assets

Images often account for the majority of bytes downloaded on a web page, and they can significantly slow down SSR if not handled properly. During server-side rendering, images that are not optimized can increase the size of the HTML (via inline base64 or large src attributes) and delay the render. The quickest wins include using next-gen formats (WebP, AVIF), lazy loading, and serving correctly sized images via a CDN or image optimization service. For SSR, the most important optimization is to ensure images are not blocking the initial render. Use the loading='lazy' attribute for images below the fold, and consider using fetchpriority='high' for critical images (like hero banners). Also, avoid inlining large images as base64 in CSS or HTML, as this bloats the HTML and prevents caching. Instead, reference the image URL and let the browser fetch it asynchronously. Many frameworks offer built-in image optimization components: Next.js provides next/image which automatically serves responsive images in modern formats. If you're not using such a framework, implement a server-side image resizing service (e.g., using Sharp) that generates multiple sizes and formats on the fly. For busy teams, the easiest path is to integrate a CDN-based image optimization service like Cloudinary or Imgix, which handles resizing, format conversion, and caching automatically. The cost is often negligible for small to medium traffic. The key is to audit your current image usage: look for large images that are not responsive, unnecessary PNGs (use WebP instead), and images that are loaded but not visible on the initial viewport. Also, ensure your server sets proper Cache-Control headers for static assets to leverage browser caching. One common mistake is using images with dimensions much larger than displayed; for example, a 2000px-wide photo in a 300px-wide container. This wastes bandwidth and slows rendering. Use responsive images with srcset to serve the appropriate size. The impact of image optimization can be dramatic: reducing image payload by 50% is common, leading to faster FCP and LCP. One team I read about cut their LCP by 30% simply by switching to WebP and lazy loading below-the-fold images. The effort is moderate—you'll need to update your image tags and possibly integrate a service—but the ROI is high. Start with your most-trafficked pages and optimize images one by one. Remember that SSR itself doesn't serve images; it's the browser that fetches them. But optimizing the HTML and markup that references images ensures the browser can start fetching them quickly and efficiently.

Implementing Responsive Images with srcset

To implement responsive images, modify your tags to include srcset and sizes attributes. The srcset attribute lists multiple image URLs with their widths (e.g., image-400w.jpg 400w, image-800w.jpg 800w), and the sizes attribute tells the browser how much space the image will occupy at different viewport widths (e.g., (max-width: 600px) 100vw, 50vw). The browser then picks the most appropriate image based on device pixel ratio and viewport size. To generate the different sizes, use an image processing library like Sharp in your build pipeline or a CDN service. For dynamic images (user uploads), consider using an on-the-fly resizing service that accepts URL parameters (e.g., /image.jpg?w=400&fm=webp). For static images, pre-generate multiple sizes during build. In your code, you can write a helper function that returns the srcset string. For example: function getSrcset(url, sizes) { return sizes.map(s => `${url}?w=${s} ${s}w`).join(', '); }. Then use it in your component: . Also, add loading='lazy' for images that are not above the fold. For the hero image, consider using fetchpriority='high' to hint the browser to load it early. Test by using Chrome DevTools to simulate slow networks—check that the correct image sizes are loaded and that lazy images load on scroll. The key is to avoid serving overly large images. This quick win is straightforward and can be implemented incrementally. Start with your homepage and product pages, then expand. The performance gains are immediate and measurable.

Quick Win 7: Profile and Optimize Server-Side Rendering Logic

Sometimes the bottleneck isn't infrastructure but the rendering logic itself. Complex computations, inefficient data transformations, or blocking operations in your server-side code can significantly slow down SSR. Profiling your server-side rendering can reveal hotspots that are easy to fix. Use tools like the Node.js built-in profiler (--prof), Chrome DevTools for Node, or APM solutions like Datadog or New Relic to identify slow functions. Common culprits include heavy string manipulation, unoptimized loops, and synchronous file reads. For busy teams, the quickest win is to look for any synchronous operations that could be made asynchronous (e.g., using fs.promises instead of fs.readFileSync). Another common issue is serializing large objects to JSON within the render path—consider streaming JSON or using a faster serializer like fast-json-stringify. Also, be mindful of memory allocations: creating large objects repeatedly can trigger garbage collection pauses. Use object pooling or reuse objects where possible. A specific example: one team found that their server was spending 30% of its time generating a complex navigation tree from a database query. By caching the tree in memory and only rebuilding it when the menu data changed, they cut that time to near zero. Another example is using lodash functions like _.groupBy inefficiently inside a render loop; consider precomputing groups outside the render path. To profile, record a few typical SSR requests and analyze the flame graph. Look for functions with high self-time or that are called excessively. Pay attention to the time spent in your framework's render functions—these are often out of your control, but you can reduce the amount of work inside them. Also, check for unnecessary re-renders or repeated computations caused by missing memoization. Use useMemo and React.memo in your server-side components if your framework supports hooks on the server. For class components, override shouldComponentUpdate. The effort for this quick win varies depending on your codebase, but often a few targeted optimizations yield disproportionate gains. Start by profiling a single, representative page request. Identify the top three slowest functions and optimize them. Measure before and after to ensure improvement. This is not a one-time activity; make profiling part of your regular development cycle. For busy teams, even a 10% improvement in SSR time can translate to significant cost savings in server resources and better user experience.

Using Node.js Profiling to Find Bottlenecks

To profile a Node.js SSR application, start the server with the --prof flag: node --prof server.js. Then, make a few requests that represent typical user traffic. Stop the server and use node --prof-process isolate-*.log > processed.txt to generate a text report. Look for functions with high "ticks" (samples) in the JavaScript section. You can also use Chrome DevTools by starting node with --inspect and then opening chrome://inspect in Chrome. Under the "Memory" and "Performance" tabs, you can record a profile while making requests. The flame graph will show you which functions consume the most time. Focus on functions that are part of your application code (not third-party modules) and that are called frequently. Common patterns to look for: a database query that is executed multiple times for the same data (hint: deduplicate), a function that does heavy computation (e.g., sorting large arrays) inside a render loop (move it outside), or a synchronous file read that blocks the event loop (use async). Once you identify a hotspot, create a targeted fix. For example, if you see that formatDate is called thousands of times, consider caching its results or using a faster date library. If you see that JSON.parse is called on the same data repeatedly, parse once and store. After making changes, re-profile to verify improvement. The key is to be systematic: don't guess—measure. This quick win is about making informed decisions based on data. It may take a few hours to set up profiling and interpret results, but the insights can lead to substantial performance gains. For busy teams, this is a one-time investment that pays off every time you deploy.

Quick Win 8: Use a CDN and Edge Caching Effectively

A Content Delivery Network (CDN) is essential for delivering cached HTML, static assets, and API responses close to the user. But many teams don't fully exploit CDN capabilities for SSR. The key is to cache as much as possible at the edge, reducing the number of requests that reach your origin server. For static pages (like marketing pages, blog posts, or documentation), set a long cache TTL (e.g., 1 hour to 1 day) and use cache invalidation via webhooks when content changes. For dynamic pages, use shorter TTLs (e.g., 60 seconds) or serve stale content while revalidating (stale-while-revalidate). Most CDNs support this via the Cache-Control header. For example, Cache-Control: public, s-maxage=60, stale-while-revalidate=3600 tells the CDN to cache for 60 seconds and serve stale content for up to an hour while fetching a fresh version in the background. This gives you the freshness of SSR with the speed of static caching. Another powerful feature is edge computing: with platforms like Cloudflare Workers or Vercel Edge Functions, you can run lightweight logic at the edge, such as personalization or A/B testing, without hitting your origin server. This can further reduce latency. For busy teams, the quickest win is to review your current CDN configuration and ensure you're setting proper cache headers for all routes. Use tools like curl -I to check the headers. Look for missing Cache-Control or CDN-Cache headers. Also, ensure that pages that should be cached (e.g., public pages) are not being set to no-cache by default. One common mistake is accidentally caching personalized content (like user profiles) for all users because the URL doesn't include a unique identifier. Use the Vary header to differentiate by cookie or user ID. Another mistake is not purging the CDN cache when content changes, leading to stale pages. Implement a webhook that triggers a purge request to your CDN's API whenever a page is updated. For example, in Next.js, you can use the res.revalidate function with On-Demand ISR. The effort for this quick win is moderate: you'll need to configure your CDN and possibly write a few lines of code for cache invalidation. But the performance gains can be dramatic—reducing TTFB from 200ms to 20ms for cached pages. One team I read about reduced their origin server load by 80% by moving to a CDN with aggressive caching. The key is to balance freshness and speed: determine the maximum staleness acceptable for each page type and set TTLs accordingly. For busy teams, this is a foundational optimization that should be done early. It's not glamorous, but it's highly effective.