Caching, Compression and Delivery
Caching and compression are among the most effective individual measures in performance optimization. Properly configured, they can reduce transferred data volume by 60 to 80 percent and make repeat page views nearly instantaneous. The following questions explain the different caching layers and compression methods we use in our performance projects. Learn more about our team and working methods on the About page.
- What is the difference between browser cache and server cache? Browser cache stores resources like images, CSS and JavaScript locally on the visitor's device. On repeat page visits, these resources load directly from local storage without contacting the server. Server cache, on the other hand, stores pre-rendered HTML pages or database queries on the server, so they are delivered faster on every request, including from new visitors. Both caching layers complement each other: server cache accelerates the first page load, browser cache accelerates all subsequent loads from the same visitor.
- What is Brotli compression and why is it better than Gzip? Brotli is a compression algorithm developed by Google, specifically optimized for web content. Compared to Gzip, Brotli achieves 15 to 25 percent better compression for text-based resources like HTML, CSS and JavaScript (Google, 2023). This means smaller transfer sizes and faster load times. Modern browsers fully support Brotli. We configure servers to use Brotli as the preferred algorithm and provide Gzip as a fallback for older clients.
- How does a reverse proxy like Varnish work? A reverse proxy sits between the web server and visitors and stores complete HTML pages in memory. When a visitor requests a cached page, the reverse proxy delivers it directly from memory without the web server or database being contacted at all. This reduces TTFB to a few milliseconds, even for complex dynamic pages. Varnish is particularly effective for shop systems with many category and product pages that change infrequently.
- What does Critical CSS mean and how is it implemented? Critical CSS refers to the minimum CSS code needed to correctly render the visible area of a page (above the fold) during the first load. This CSS code is embedded inline in the HTML document so the browser can immediately render the page without waiting for external CSS files. The remaining CSS is loaded asynchronously. Implementation involves automated extraction of critical CSS using specialized tools that analyze the visible area for different screen sizes. The result is a significantly faster First Contentful Paint.
- How do I handle third-party scripts that slow down performance? Third-party scripts such as analytics, chat widgets, marketing pixels and social media embeds are among the most common performance bottlenecks. We proceed in three steps: First, we inventory all included third-party scripts and assess their business value. Second, we eliminate scripts that are no longer needed. Third, we optimize the remaining ones through delayed loading (lazy loading after user interaction), self-hosting script files on your own server, facades for chat widgets and embeds, and service workers for targeted caching.
- How do I ensure performance remains stable after optimization? Performance regressions frequently arise from new content, plugin updates or changes to third-party scripts. To maintain stability, we recommend three measures: automated monitoring that continuously measures Core Web Vitals and alerts on degradations, a performance budget definition that sets maximum page sizes and script volumes, and regular performance reviews on a quarterly basis. This way, regressions are detected within hours and can be addressed before they negatively affect field data.