Caching and CDNs: Speeding Up Business Websites and Apps Without Adding Servers

When a business website or app feels slow, many people's first instinct is to add server capacity. Sometimes that is right, but often there is a much cheaper and more effective way: stop doing the same work over and over. The same page is rebuilt for every visitor, the same image is downloaded from a distant server, and the same database query result is recomputed every second. Caching is the practice of storing the result of that work so it can be reused, while a CDN (Content Delivery Network) places copies of content in many locations close to visitors.

This article explains layered caching from the browser to the database, how a CDN works, when content is safe to cache and when it is not, how to clear caches precisely when content changes, and how to measure the impact. The goal is to help business owners and technical teams make sensible decisions without promising specific figures, because real results depend heavily on each architecture and traffic pattern.

Summary

• Layered caching (browser, CDN, application, database) reduces server work and speeds up responses without adding machines
• Static assets such as images, fonts, and script files are almost always safe to cache for a long time with versioned file names
• Dynamic pages and personal data must be treated carefully so users never see someone else's data
• Invalidation strategy matters as much as storage strategy; stale cache is a source of confusing bugs
• HTTP headers such as Cache-Control determine cache behavior and are worth understanding for non-technical staff too
• Measure before and after using real user metrics and server metrics, not feelings

What a cache is and why it works

A cache is fast temporary storage for the results of expensive work. The principle is simple: if a result is needed repeatedly and rarely changes, store it instead of recomputing it. The benefits are layered:

• **Faster responses** because data comes from a closer or cheaper place
• **Lighter server load**, so traffic spikes are easier to absorb
• **More controlled infrastructure cost**, especially for traffic that mostly reads the same content
• **Better resilience**: part of the cache can keep serving visitors while the origin server has trouble

The price is the risk of stale data and added complexity. There is an old saying in programming that the two hardest things are naming and cache invalidation. It is not a joke: many production incidents come from a cache that stored something too long or too broadly.

The layers of cache

A visitor's request can pass through several layers before reaching the database. Each layer is a chance to stop earlier.

1. Browser cache

The visitor's browser keeps files it has downloaded. When the visitor opens a second page, the logo, stylesheet, and scripts are not downloaded again. This is the fastest layer because it involves no network at all. Its behavior is controlled by response headers from your server.

2. CDN and edge cache

A CDN is a network of servers spread across many cities and countries. Content is copied to the server nearest the visitor, so data travels a shorter distance. Visitors in Medan and Makassar can be served from locations near them rather than from a single central server. A CDN also absorbs traffic spikes and often provides basic protection against attacks, automatic compression, and image optimization. For businesses targeting international visitors, a CDN helps reduce the distance between server and reader, which is relevant to the strategy in international SEO: hreflang, URL structure, and content localization.

3. Page or response cache

Pages built from templates and data, such as blog articles or product pages, can be stored as ready-made HTML. Instead of assembling the page each time, the server or CDN immediately sends the existing result. Modern web frameworks offer various modes: pages built at build time, pages refreshed periodically in the background, and pages generated on request and then stored.

4. Application and data cache

Inside the application, calculation results or calls to other services can be kept in memory or in fast storage such as Redis. Examples are a list of product categories, configuration, computed prices, or responses from third-party APIs. This layer is especially useful for business APIs, as discussed in business API design: versioning, documentation, and rate limits.

5. Database cache

Databases have their own internal caches for data pages and query plans. In addition, summary tables or materialized views can store heavy aggregate results such as sales reports, so a dashboard does not compute millions of rows each time it opens. Tuning indexes and queries remains the foundation before adding a cache, because a cache does not fix a bad query, it only hides it.

HTTP headers worth understanding

Browser and CDN cache behavior is largely determined by response headers. Here are the most commonly used, explained without too much jargon:

• **Cache-Control**: the main header. Values such as "public" mean shared caches (CDNs) may store it, "private" means only the user's browser, "no-store" forbids storage entirely, and "max-age" sets how many seconds the result is considered fresh
• **s-maxage**: like max-age but specifically for shared caches such as a CDN. Useful so the CDN stores for longer than browsers
• **stale-while-revalidate**: allows the cache to serve the old version while fetching a new one in the background. Visitors get a fast response and the content is refreshed shortly after
• **ETag and Last-Modified**: version markers that let the browser ask, "Has this file changed?" and receive a short answer if not
• **Vary**: tells caches that the response differs depending on certain headers, for example language or compression type. Misconfiguring Vary can give visitors the wrong language version
• **Set-Cookie**: responses that set cookies are often not cached by CDNs by default; watch out so public pages are not affected

You do not need to memorize them all. What matters is that the team has a written policy: which content categories use which settings, and why.

What is safe to cache and what is not

The practical split below helps decide a strategy per content type.

Safe to cache for a long time

Static assets such as images, icons, fonts, stylesheets, and scripts. The trick: give files names that contain a version or content hash (for example app.3f9a1c.js). When a file changes, its name changes, so the old cache is automatically no longer used and does not need manual clearing. Files like these can be stored for a year without staleness risk. Images should also be optimized in size and format, as discussed in Core Web Vitals: LCP, INP, CLS.

Safe to cache briefly

Public content pages such as articles, service pages, and catalogs that change a few times a day or week. Use a short freshness period with background refresh, or invalidate when content is edited.

Be careful

• **Pages containing user data**: dashboards, shopping carts, profiles, and order history. Never store them in a shared cache without a cache key that separates each user. Storing personal pages on a CDN is a classic cause of data leaks between users
• **Prices, stock, and promotions**: if they change quickly, an old cache can display the wrong price. Separate the display (may be cached) from critical numbers (fetched fresh at checkout)
• **Search results and filters**: the variety is huge so the cache hit rate is low. See also [semantic search and vector search](/blog/pencarian-semantik-dan-vector-search-untuk-website-dan-aplikasi-bisnis)
• **Responses with security tokens**: forms with CSRF tokens or nonces must not be cached in a shared cache

Do not cache

Write transactions (payments, order creation), authentication responses, and data that must always be current for legal or financial reasons. In these cases use "no-store" and make sure the CDN respects it.

Invalidation: clearing the cache precisely

Storing is easy; deleting at exactly the right moment is hard. There are several strategies, often used together:

• **Time-based expiry (TTL)**: the cache is automatically considered stale after some minutes or hours. Simple, but data can be stale for the length of the TTL
• **Versioned names for assets**: as mentioned above, no invalidation is needed because the name changes
• **Event-based invalidation**: when an editor saves an article, the system clears the cache for that page and related pages such as the article list and sitemap
• **Tags or surrogate keys**: some CDNs let you label responses (for example "product-123") and then purge them all at once by label
• **Background refresh**: show the old version while preparing the new one, like stale-while-revalidate

Also design what happens when invalidation fails. Will a stale page persist for an hour? A day? Set a limit the business can accept and provide an emergency button to purge the cache manually. Make sure important changes, such as a price correction or removing legally problematic content, can propagate quickly.

Impact on SEO and user experience

Speed affects visitor satisfaction and is also part of the page experience that search engines assess. Some things to remember:

• A slow server hurts time to first byte (TTFB), which underlies other metrics. Page caching and a CDN are the most direct way to improve it
• Make sure the version served to search engines matches what users see, and do not serve stale pages whose content has been deleted
• Make sure correct status codes are served from cache: moved or deleted pages must give a redirect or suitable code, not keep showing 200 from an old cache. This matters during a [website redesign and migration](/blog/redesign-dan-migrasi-website-tanpa-kehilangan-peringkat-seo)
• Sitemaps, robots.txt, and other important files should have short cache periods so changes are seen quickly
• For multilingual sites, make sure language variants have separate cache keys and that automatic redirects based on browser language do not store the wrong result

Security and reliability

A CDN also plays a role in security and resilience. As the front layer, it can absorb excess traffic, filter malicious requests, and hide the origin server's address. Related practices are in protecting against bots, scraping, and automated attacks. However, there are things to watch:

• Wrong cache configuration can leak private pages, so test with different accounts and anonymous sessions
• Make sure HTTPS certificates and security settings continue through to the origin server rather than stopping at the CDN
• Restrict direct access to the origin server so traffic must pass through the CDN
• Prepare a plan for when the CDN has an outage, including how to reroute traffic, as in [disaster recovery and business continuity plans](/blog/rencana-pemulihan-bencana-dan-kesinambungan-bisnis)
• Consider dependence on a single provider and how to exit if needed, as discussed in [vendor lock-in and exit strategies](/blog/vendor-lock-in-di-cloud-dan-software-bisnis-strategi-keluar)

Measuring the impact

Do not judge caching success from one test on your own laptop. Use a combination of measurements:

• **Cache hit ratio** at the CDN and in the application. A low ratio signals rules that are too strict or cache keys that are too varied
• **Server response time and TTFB** before and after, from several locations
• **Real user experience metrics**, such as Core Web Vitals from actual visitors, not only lab tests
• **Origin load**: CPU usage, number of database queries, and number of requests reaching the origin
• **Error rate** and complaints about stale content
• **Cost**: compare CDN and storage cost with server savings

Before a big promotion, combine this with load testing to see whether the cache really holds back a spike, as discussed in load testing before big promotions and peak seasons. Also test the cold cache scenario, when the cache is empty after a release or purge, because that is when the origin server is most vulnerable.

Practical steps to start

This order rarely fails:

• **Initial audit**: list the content types on your site and decide whether each is public, semi-public, or private
• **Static assets first**: apply versioned names and long cache periods, plus compression and modern image formats
• **Put a CDN** in front of the site and verify that the headers sent match the plan
• **Cache public pages** with a short freshness period or staged refresh, and connect invalidation to the content editing flow
• **Add data caching** where performance profiling shows slowness, not where you guess
• **Document the cache policy** and who is authorized to change it
• **Monitor and adjust** periodically; needs change as content and traffic grow

Use staged releases for large changes to cache rules so they are easy to roll back, following the pattern of feature flags and staged releases. If your app should also stay useful on a poor network, see how on-device caching is used in Progressive Web Apps for business.

Common mistakes

• Storing pages containing user data in a shared cache
• Setting a long cache period for files without versioned names, so users do not see updates
• Having no quick way to purge the cache when a content error occurs
• Adding a cache to cover for an unindexed database query
• Measuring only on a fast office network and at locations near the server
• Ignoring the Vary header on multilingual sites
• Forgetting to test cold cache conditions after a release

Frequently asked questions

Is a CDN necessary for a small business website?

Not always, but often beneficial. Many modern hosting providers already include a CDN. The benefit is most noticeable when your visitors are widely spread or pages load many images.

Why don't changes on my website appear immediately?

Most likely the old content is still stored in the browser or CDN cache. Check the configured cache period, purge the cache, and make sure the invalidation flow is connected to the content editing process.

Does caching reduce security?

Not when configured correctly. The risk comes from misconfiguration, especially storing private content in a shared cache. Test with several accounts and use "private" or "no-store" for user pages.

How long should the cache period be?

It depends on the content type. Versioned assets can be very long, public content pages need minutes to hours with background refresh, and critical data is not cached. Set it based on how long the business can accept stale content.

Does caching replace code and database optimization?

No. Caching complements optimization, it does not replace it. Fix slow queries and heavy assets first, then use caching to maintain speed as traffic rises.

Conclusion

Caching and CDNs are the most economical way to make business websites and apps feel fast, because they reduce unnecessary work instead of adding machines. The key is to understand the layers, sort content by its nature, design invalidation from the start, and measure results with real data. Start with static assets and public pages, then carefully extend to dynamic data.