Introduction to Accelerate Guru

#The honest truth about Magento performance

A default Magento 2 installation scores 12–25 on Google Lighthouse on mobile. The average checkout-to-purchase conversion rate drops 4.42% for every additional second of load time (Portent, 2019). Amazon famously measured a 1% revenue drop per 100 ms of added latency. If your Magento store takes 4 seconds to load on mobile, you are leaving a substantial fraction of your revenue on the table — not as a theory, but as a measured, documented, reproducible fact.

Fixing this the traditional way means rewriting themes, removing extensions, hand-tuning Varnish VCL, hiring a performance consultant, buying a CDN subscription, and crossing your fingers that the next deployment doesn't undo it. It takes months and it never fully works because the underlying architecture — a PHP monolith with synchronous MySQL queries — is not designed for sub-second delivery.

Accelerate Guru takes a different approach. It does not touch your Magento code. It does not require a module, a patch, or a theme change. It runs in front of Magento as a drop-in reverse proxy written in Rust, and it solves the performance problem at the infrastructure layer — permanently, automatically, and without maintenance.

#What Accelerate Guru is

Accelerate Guru is a Rust-based reverse proxy that sits between your users and your Magento store. Every HTTP request passes through it. On the way in, the edge applies security rules, bot detection, and rate limiting. On the way out, it caches the response, encodes images as AVIF, compresses everything with zstd, and injects dozens of browser-side performance optimisations — all in under 1 ms of added latency.

The result is that 90–95% of page requests never reach Magento at all. The edge answers directly from DragonflyDB — an in-memory store that responds in microseconds, not seconds. Your Magento server continues running normally; it just receives a fraction of the traffic it used to.

Without Accelerate Guru:
  User → [Internet] → Magento (PHP, 800ms avg) → User

With Accelerate Guru:
  User → [Internet] → Accelerate Guru edge → DragonflyDB (2ms, 90% of requests)
                                            ↘ Magento (remaining 10%)

#Zero-patch architecture

This is not a compromise. It is the point. Extensions and patches create upgrade debt, cause conflicts, and require maintenance forever. A proxy that operates at the network layer has none of those problems. You install it once, point your DNS at it, and it works for every version of Magento, every theme, and every third-party extension — including ones released after you installed it.

#What it actually does

Here is the complete list of what happens to every request that passes through the edge:

#On every request (inbound)

• WAF scoring — the request is scored against SQL injection patterns, bot fingerprints, path traversal variants, and rate limits. Known-bad traffic is blocked before it touches PHP.
• Cache lookup — the edge checks DragonflyDB for a cached response. If found (hit), the response is returned immediately. Magento is never invoked.
• TLS termination — SSL is handled at the edge. Magento can run plain HTTP on a loopback interface.
• Header normalisation — Host, X-Forwarded-Proto, and X-Forwarded-For are set correctly before the request reaches Magento.

#On every response (outbound, cache miss only)

• HTML rewriting — the response body is parsed and modified in a single streaming pass: DOM flattening, preconnect injection, accessibility fixes, script deferral, speculation rules, service worker registration, structured data injection, and more.
• Image rewriting — <img src> attributes are rewritten to point at the edge's image pipeline. AVIF and WebP variants are generated in the background.
• Compression — the response is compressed with zstd (if the browser supports it), brotli, or gzip. The correct variant is served with zero CPU at request time on subsequent hits.
• Cache storage — the response is stored in DragonflyDB with the computed TTL. Future requests are answered from cache.

#In the background (async, non-blocking)

• Image encoding — AVIF conversion runs in a background thread pool. The first request gets the original image; every subsequent request gets the optimised AVIF.
• Cache invalidation — when Magento writes to MySQL (product saves, price updates, CMS changes), the edge receives an invalidation signal via DragonflyDB Pub/Sub and evicts the affected cache entries. No manual purge needed.
• Service worker push — when a product price or availability changes, an SSE event is pushed to every connected browser. The service worker receives it and invalidates the relevant cached pages — without a page reload.

#By the numbers

The following figures are from real Magento stores measured before and after a standard Accelerate Guru installation.

#How it compares to the alternatives

#What you need

• A server (Linux or macOS) that can reach your Magento origin — same host, different host, or different region entirely.
• Magento 2.x running anywhere — any version, any theme (Luma, Hyvä, PWA Studio, custom).
• DragonflyDB installed on the same server as Accelerate Guru (or accessible via TCP). This is the caching layer. See the installation guide.
• A license key from accelerate.guru — or use dev for local testing and staging on .test / .local domains.

#Next step

→ Quick Start: get to near-100 Lighthouse in 60 seconds