# Magento Varnish Cache: Why Your Store Is Still Slow *Published: 2026-09-29 | Author: Jason Ratzlaff* Every Magento performance conversation starts in the same place: put Varnish in front of it. That advice is right. It is also where most stores stop, and it is why so many Magento sites still feel slow to the shoppers who matter most — the ones filtering, logging in, adding to cart, and checking out. I built [FastMagento](https://github.com/parkktech/FastMagento) for the requests a full-page cache never sees. This post explains that gap, what the cache layer options actually do, and where FastMagento fits underneath them. **3.8×**faster uncached home page*2,911 ms → 775 ms* **−90%**SQL queries on search results*220 → 23* **~231 ms**cached page, with or without FastMagento*the cache already handles easy traffic* FastMagento README benchmarks, 513,000-product catalog. ![Server rack with blinking green lights](https://images.unsplash.com/photo-1762163516269-3c143e04175c?ixid=M3w4ODMzNjJ8MHwxfGFsbHx8fHx8fHx8fDE3OTA2NTg4Nzd8&ixlib=rb-4.1.0&w=1520&q=80&fm=jpg&fit=crop&ar=16:9)Photo by [Domaintechnik](https://unsplash.com/@fslfsl?utm_source=parkk_blog&utm_medium=referral) on [Unsplash](https://unsplash.com/?utm_source=parkk_blog&utm_medium=referral)What Magento Varnish Cache Actually Speeds Up --------------------------------------------- A full-page cache (FPC) stores the finished HTML of a page and hands it to the next visitor without running PHP or touching MySQL. For an anonymous shopper landing on a popular page, that is as fast as Magento gets. Your options in 2026: - **Built-in FPC (file or database)** — Adobe describes it as much slower than Varnish and suitable for development, not production ([Adobe caching overview](https://experienceleague.adobe.com/en/docs/commerce-operations/configuration-guide/cache/caching-overview)). - **Varnish** — Adobe’s recommended production cache and free open source. It is the right default for self-hosted stores. - **Fastly** — the cache and CDN bundled with Adobe Commerce Cloud, with image optimization that can serve WebP and AVIF ([Adobe docs](https://experienceleague.adobe.com/en/docs/commerce-on-cloud/user-guide/cdn/fastly-image-optimization)). - **LiteSpeed LiteMage** — LiteSpeed’s Magento cache. LiteSpeed publishes vendor benchmarks claiming up to 3x faster than nginx plus Varnish ([vendor claim](https://www.litespeedtech.com/benchmarks/vs-varnish)). - **Cloudflare edge HTML caching** — “Cache Everything” with bypass cookies, usually through a third-party extension. All of them share one rule: they only serve pages that are identical for everyone. The moment a request is personal or uncommon, it falls through to PHP and the database. ![Diagram of where each Magento speed fix acts: frontend, CDN, full-page cache, Magento application on cache miss, services and database](https://www.parkktech.com/wp-content/uploads/2026/09/magento-speed-layers.png)Every fix acts on one layer. Everything that misses the full-page cache lands on the red one.What Varnish Can’t Cache in Magento ----------------------------------- Here is what still reaches Magento’s application layer on a well-cached store: - **Cache misses.** Layered navigation creates thousands of filter and sort combinations. Most are requested rarely, so most are misses. - **Search results.** Every query string is its own page. - **Logged-in and B2B shoppers.** Customer-group pricing, tier prices, and shared catalogs make pages personal. - **Cart and checkout.** Never cached, and the most expensive requests Magento serves — and the ones closest to revenue. - **Cache warm-up after deploys and reindexes.** Every flush sends real traffic to cold pages. On those requests, stock Magento does what it always does: loads products through its EAV (entity-attribute-value) model, which spreads a single product across many tables, and runs hundreds or thousands of SQL queries to build one page. Served by the full-page cache identical for every visitor Popular category pagesCached Product pages, anonymousCached CMS and home pageCached SpeedAlready fast Falls through to Magento personal, rare or never cached Search resultsMiss Filter combinationsMostly miss Logged-in and B2B pricingMiss Cart and checkoutNever cached How FastMagento Speeds Up Uncached Magento Pages ------------------------------------------------ FastMagento keeps MySQL as the source of truth and serves the storefront’s product reads from OpenSearch — the search engine Magento already requires. It indexes products, categories, attribute options, and reviews into OpenSearch through Magento’s own indexer framework, then intercepts the places Magento loads product data: - Product loads and the product repository return a lightweight product object whose data comes from the OpenSearch document, skipping the multi-table EAV load. - Product and link collections, the category tree, URL routing, reviews, stock, and price models (tier, special, catalog-rule, customer-group) read from the index. - Stock changes sync to the index after the response has been sent, so shoppers do not wait on it. - If a product is missing from the index, it is loaded normally once and indexed. If OpenSearch is down, Magento falls back to its normal behavior. It sits *below* Varnish, not instead of it. On a cache hit, a store with FastMagento and one without serve the same cached HTML at the same speed. The difference is everything that misses. Varnish Alone vs Varnish + FastMagento: Benchmarks -------------------------------------------------- These are my published benchmarks from the [FastMagento README](https://github.com/parkktech/FastMagento), measured on a 513,000-product stress catalog (plus 4,187 configurables and a 50,000-option color attribute) with real-world extensions active. Each figure is a cold render — a full-page cache miss — taking the median of three runs, with the module disabled versus enabled. Server render time on a full-page-cache miss, 513,000 products Median of three runs, module disabled vs enabled, real third-party extensions active in both. Stock MagentoWith FastMagento Home page2,911 ms**775 ms** Search results631 ms**338 ms** Configurable product, 660 variants1,371 ms**827 ms** Cart totals, 10 items1,485 ms**1,009 ms** Checkout totals1,510 ms**1,110 ms** Simple product555 ms**480 ms** Category page543 ms**622 ms** The category page is the one surface that is not faster yet: its product grid still renders from MySQL. Source: FastMagento README. ![Bar chart: SQL queries per uncached Magento page at 513,000 products, stock versus FastMagento](https://www.parkktech.com/wp-content/uploads/2026/09/fastmagento-500k-sql-queries.png)SQL queries per uncached page: the home page drops from 10,090 to 80.A cached page served in about 231 ms with or without FastMagento. That is the point: the cache already handles the easy traffic. FastMagento shrinks the hard traffic. Where FastMagento Doesn’t Help Yet ---------------------------------- **Honest limits**Honest limits matter more than big numbers. On that same stress catalog, category pages went from 543 ms to 622 ms even though their SQL count dropped from 246 to 131 queries, because category product grids are still rendered from MySQL today. FastMagento also indexes only the default store view, and it does not yet apply Adobe Commerce category permissions or B2B shared catalogs. Those are on the roadmap, and the README lists them plainly. **Start with the cache, then fix what misses it**Varnish or Fastly first. Then measure search, filtered listings, logged-in traffic, cart and checkout — the requests from shoppers with intent to buy — and make those cheap. Varnish First, Then FastMagento: The Right Order ------------------------------------------------ If you are choosing where to start, start with Varnish (or Fastly on Adobe Commerce Cloud). Then measure what still misses the cache — search, filtered listings, logged-in traffic, cart, and checkout — and that is the traffic FastMagento was built for. The shoppers generating those requests are the ones with intent to buy, and speed is money: Deloitte’s [Milliseconds Make Millions](https://web.dev/case-studies/milliseconds-make-millions) study found a 0.1-second mobile speed improvement was associated with an 8.4% lift in retail conversions. Frequently Asked Questions -------------------------- Does FastMagento replace Varnish?No. FastMagento runs underneath Varnish or any full-page cache. The cache serves repeat anonymous pages; FastMagento speeds up the requests that miss it, such as search, filtered listings, logged-in pages, cart, and checkout. What does FastMagento require?Magento Open Source or Adobe Commerce 2.4.x (2.4.6+ recommended), PHP 8.1 or newer, and OpenSearch 1.x or 2.x, which Magento already requires for search. It installs with composer require parkktech/fastmagento. What happens if OpenSearch goes down?FastMagento falls back to Magento’s normal database loading, so the store keeps working at stock speed until OpenSearch is back. Is FastMagento open source?Yes. The code is public on GitHub at github.com/parkktech/FastMagento under the OSL-3.0 and AFL-3.0 licenses. Have a Magento store that is too slow? -------------------------------------- Bring me the store three agencies could not make fast. The first conversation is free, and it is a real one. I will tell you honestly where your time is going. [Start the conversation](https://www.parkktech.com/contact/) --- **Parkk Technology** — Custom Software Development, AI Integration, and Equity Partnerships - Custom Software Development: We build the software your business actually needs — scoped, shipped, supported. - AI Integration for Existing Businesses: Add AI capabilities to what you already have — without rebuilding everything. - Equity Partnership: Considered case by case for validated problems. No fixed package. Contact: https://www.parkktech.com/contact | Author: Jason Ratzlaff, founder of Parkk Technology