Studies consistently show that users expect pages to load within a few seconds, and each additional second of delay increases bounce rates significantly. Google has made page speed a ranking factor, meaning faster websites gain visibility while slower ones get buried in search results.<\/p>\n\n\n\n
This article covers practical techniques to achieve blazing-fast websites:<\/p>\n\n\n\n
- \n
- from caching strategies that handle the majority of requests,<\/li>\n\n\n\n
- through asset optimization that reduces file sizes,<\/li>\n\n\n\n
- to networking improvements and Core Web Vitals optimization.<\/li>\n<\/ul>\n\n\n\n
Where applicable, Adobe Experience Manager (AEM) features that support these optimizations are highlighted.<\/p>\n\n\n\n
In times of excessively long articles generated by AI, which, ironically, often need to be summarized by AI just to read, I’ll try to avoid unnecessary complexity and decoration by keeping the content concise.<\/p>\n\n\n\n
Cache<\/strong><\/h2>\n\n\n\n
Typically, developers of backend applications focus on code performance and page generation time, but in reality, the most important aspect for improving web performance is caching. If a request can be served from cache, the backend code path often does not matter. Make sure that generated responses are properly cached and don’t have to be recreated or always served from the “bottom” source. When set up correctly, it should handle 80% to 95% of all public traffic, although personalized and authenticated content naturally reduces the cacheable surface area.<\/p>\n\n\n\n
Think in layers:<\/p>\n\n\n\n
- \n
- browser cache,<\/li>\n\n\n\n
- CDN or reverse proxy cache,<\/li>\n\n\n\n
- web-server cache layer,<\/li>\n\n\n\n
- application output cache, where applicable.<\/li>\n<\/ul>\n\n\n\n
For AEM as a Cloud Service, traffic commonly passes through a CDN and Dispatcher before reaching publish instances.<\/p>\n\n\n\n
Cache Store<\/strong><\/h3>\n\n\n\n
Static content can be stored in a cache store. Most web servers, like Nginx or Apache, and load balancers, like HAProxy, which are typically placed in front of your backend, have their own mechanisms to cache files locally, but must be carefully configured to match your backend exactly.<\/p>\n\n\n\n
AEM provides its own Apache module for connectivity handling to AEM instances and a set of rules for managing the cache of static content properly (HTMLs, ClientLibs, assets, etc.). Another potential caching layer could be a Content Delivery Network, which is described in the Networking section.<\/p>\n\n\n\n
The important part is not only having a cache, but matching cache behavior to content behavior:<\/p>\n\n\n\n
- \n
- cache public assets aggressively,<\/li>\n\n\n\n
- cache public HTML when business rules allow it,<\/li>\n\n\n\n
- never cache personalized responses in shared layers,<\/li>\n\n\n\n
- avoid unnecessary cache fragmentation caused by query parameters or over-broad Vary headers.<\/li>\n<\/ul>\n\n\n\n
If your cache key changes for reasons that do not change the response, your hit ratio drops, and your origin does extra work for no user-facing benefit.<\/p>\n\n\n\n
Cache-Control header<\/strong><\/h3>\n\n\n\n
One of the most important ways to describe caching properties is the Cache-Control header in HTTP responses for a specific URL. There are important but often overlooked and misunderstood options that indicate the nature of the response, worth considering for every response type:<\/p>\n\n\n\n
- \n
public<\/code><\/strong> \u2013 may be cached in every layer of the shared cache, such as public static HTMLs and assets (images, videos, documents),<\/li>\n\n\n\nprivate<\/code><\/strong> \u2013 user-personalized content and MUST NOT be cached between the backend and the user’s browser, but CAN be cached in the browser,<\/li>\n\n\n\nimmutable<\/code><\/strong> \u2013 content will not be changed, perfect for files or documents that are versioned in the filename or JavaScript modules with a content hash in the filename,<\/li>\n\n\n\nno-cache<\/code><\/strong> vsno-store<\/code><\/strong> \u2013 often misleading: no-cache means the response CAN be cached (stored) in the browser but requires revalidation, while no-store forbids caching entirely, so it’s much better for sensitive content (personal data),<\/li>\n\n\n\nmax-age<\/code><\/strong> \u2013 browser freshness lifetime,<\/li>\n\n\n\ns-maxage<\/code> <\/strong>\u2013 shared-cache freshness lifetime; useful when CDN and browser TTLs should differ,<\/li>\n\n\n\n- s
tale-while-revalidate<\/code><\/strong> \u2013 allows caches to serve a stale response while refreshing it in the background,<\/li>\n\n\n\nstale-if-error<\/code><\/strong> \u2013 allows stale content to be used when the origin fails.<\/li>\n<\/ul>\n\n\n\nTypical patterns are:<\/p>\n\n\n\n
- \n
public, max-age=31536000, immutable <\/code>for hashed assets,<\/li>\n\n\n\npublic, max-age=300, stale-while-revalidate=3600<\/code> for frequently updated HTML,<\/li>\n\n\n\nprivate, no-cache<\/code> for personalized pages,<\/li>\n\n\n\nno-store<\/code> for highly sensitive responses.<\/li>\n<\/ul>\n\n\n\nBy properly configuring Cache-Control, you can fully control what can. You cannot be cached, ensuring not only that website files are served quickly but also that an improperly configured cache does not cause accidental data leaks. In AEM environments, it is often useful to control browser and edge caching independently. If your CDN supports surrogate cache headers, use them deliberately instead of forcing the same TTL everywhere.<\/p>\n\n\n\n
Optimizing assets<\/strong><\/h2>\n\n\n\n
Modern websites are full of images, photos, and videos. Such files are heavy, often several megabytes each. Nowadays, web browsers are evolving rapidly and, with automatic updates, most users are up to date. Thanks to new protocols and file formats now supported by modern browsers, it is possible to deliver smaller assets faster. It is not just about reducing file sizes, but also about reducing critical-path bytes.<\/p>\n\n\n\n
Images\/photos<\/h3>\n\n\n\n
Instead of serving a single source image or photo, prepare or generate an image or photo on request in multiple resolutions, better suited to different devices and viewports.<\/p>\n\n\n\n
AEM Assets automatically resizes the source on upload to prepare multiple resolutions (called “renditions”). The
srcset<\/code> attribute of the <img<\/code>> and <source<\/code>> tags allows you to specify multiple resolution variants (renditions). In contrast, the sizes attribute defines the ratio of the visible image on the page to the viewport size, and the browser itself will optimize which rendition to use.<\/p>\n\n\n\nUse the <
picture<\/code>> tag with multiple <source<\/code>> tags to define different images for various viewports – especially useful to provide different images for portrait and landscape orientations or different formats.<\/p>\n\n\n\nYou don’t have to stick with the JPEG format to serve images anymore. Use SVG for icons, logos, and diagrams. For raster images, WebP is a strong default, and AVIF is increasingly viable, while JPEG and PNG still serve as practical fallbacks. WebP can reduce a photo’s size by about 30% compared to JPEG, and switching to AVIF can often provide an additional reduction.<\/p>\n\n\n\n
AVIF now has roughly 95% global browser support, but fallback markup is still the safer default than assuming a single format will work everywhere. AEM as a Cloud Service supports web-optimized WebP renditions.<\/p>\n\n\n\n
Changing the image file format might not be possible for existing applications. Still, it should be possible to optimize existing PNG files and re-encode existing JPEG files with stronger compression while preserving high visual quality.<\/p>\n\n\n\n
Consider which images are crucial. Always provide explicit width and height so the browser can reserve space and reduce layout shift. Use
loading=\"lazy\"<\/code> for non-critical images, but do not lazy-load the likely LCP image. For the most important image, considerfetchpriority=\"high<\/code>” and preload it if the browser would otherwise discover it late.<\/p>\n\n\n\nAEM Image Core Component supports renditions, lazy loading, alternate text (for screen readers), linking, and more. Verify that it emits stable dimensions and responsive markup, and that page templates do not lazy-load the hero image.<\/p>\n\n\n\n
![\"Comparison](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2026\/05\/image1-1024x1024.png\")