Speed Suite
(Speed Suite)
30-day money back guarantee
Gitlab access is only given to Agencies and Freelancers after
approval process.
Please note: we do not provide installation or implementation services for our extensions.
Installation should be handled by the developer or agency managing your store. This approach ensures:
- Compatibility with your current setup
- Proper configuration based on your specific version
- Implementation by someone familiar with your codebase
Although we don’t offer installation, we maintain a curated list of recommended development agencies experienced with our solutions.
If you'd like to receive this list, please contact us at [email protected].
Partnership Inquiries
- For partnership opportunities, reach out to: [email protected]
Description
Structural speed optimization for large Magento installations.
Speed Suite is a set of Magento 2 optimization modules designed to remove bottlenecks inside the Magento runtime - not only at the cache/CDN layer. It reduces the amount of work Magento performs per request and during catalog operations, which stabilizes response times under real traffic and large-catalog conditions.
The suite combines three complementary layers: query batching (Preloaders), runtime precompilation (STOP Protocol), and accelerated indexing (Optimized Indexers). Together they reduce SQL amplification, shrink indexing windows, and improve overall throughput without rewriting your application.
Full technical overview
If you want the extended narrative, architecture deep-dive and more context, see the full landing page: https://qoliber.com/qoliber-speed-suite-for-magento-2
Engineering Summary
A Magento optimization layer that removes structural bottlenecks inside the application runtime.
What you get (technical scope)
- Preloaders that batch Magento database queries across product collections and heavy blocks.
- STOP Protocol runtime configuration precompilation loaded from OPcache (compile once, reuse across workers).
- Optimized Indexers replacing inefficient row-by-row catalog processing with batch SQL patterns.
- Reduced DB amplification and improved stability of response times under traffic and catalog scale.
If your store runs a large catalog, complex pricing logic (tier prices, rules, groups), frequent imports, or campaign bursts that expose uncached paths - Speed Suite targets the root causes that caching alone can’t fully eliminate.
What Speed Suite solves (at scale)
Magento performance problems usually don’t start on day one - they appear when the catalog grows, merchandising complexity increases, and the store becomes operationally “busy” (imports, rules, indexers, search, multi-store). Speed Suite addresses the structural causes.
SQL amplification (N+1)
Listing/search pages and “product blocks” can trigger repetitive per-product queries for pricing, salability, attribute options, rule pricing and other computed data. With 40–60 products per page this becomes hundreds of queries.
Framework runtime overhead
Magento repeatedly resolves configuration, DI graphs, routes, layouts, translations and other “foundation” data. Even if you cache the output, these costs still exist across uncached surfaces and many operational flows.
Indexing bottlenecks
Default indexers can be lock-heavy and memory-hungry, turning pricing updates, imports or rule changes into long maintenance windows. Slow indexing is not just “ops pain” - it impacts how quickly you can run campaigns and refresh catalog state.
Modules included in Speed Suite
Each module targets a different layer of Magento performance. Together they cover storefront request cost, framework bootstrap overhead and catalog operational throughput.
Preloaders
Query batching layer designed to eliminate the N+1 amplification pattern in real Magento storefront flows.
Preloaders targets the scenarios where Magento loads expensive product-related data “one product at a time”. Instead of triggering repeated SQL queries per product, it preloads required datasets in a small number of batch queries and reuses them across the whole product collection.
- Category and search result pages
- Related / upsell / cross-sell product blocks
- Cart surfaces that require pricing + salability checks
- REST API responses that carry product collections
N+1 query amplification is one of the fastest ways to “burn” DB resources: it increases query counts, intensifies lock contention and causes response time volatility under concurrency. Batching is a structural fix, not a cosmetic patch.
Default Magento (simplified):
for each product in collection:
query price
query stock/salability
query configurable options
query rule price
Preloadersin one batch:
load prices for ALL product_ids
load stock/salability for ALL product_ids
load rules/options for ALL product_ids
STOP Protocol
STatic Object Precompilation: compile runtime structures once, load them from OPcache memory on every request.
Magento is designed as a dynamic framework: it reads configuration trees, resolves DI graphs, parses XML and evaluates large parts of its runtime model repeatedly. STOP Protocol moves this repeated work out of request time by compiling selected runtime structures into optimized PHP arrays and loading them into OPcache.
- Core configuration trees and DI bootstrap structures
- Routing / module configuration maps used across requests
- Frequently resolved “foundation” objects and lookups
- Data that would otherwise trigger repeated disk I/O and SQL reads
Even with strong caching, many critical flows are partially uncached: logged-in customer pricing, cart operations, personalization, API calls, warm-up phases, admin operations. STOP Protocol improves performance where caching doesn’t fully eliminate the cost - by removing repeated framework overhead.
Compile phase:
XML/config/runtime structures
-> optimized PHP arrays
arrays -> OPcache preload
Runtime phase:
no repeated parsing
fewer disk reads
fewer config-related DB lookups
more stable request cost
Optimized Indexers
Drop-in indexer replacements that reduce lock contention and accelerate catalog operations at scale.
Magento indexing becomes a business constraint when catalogs reach tens of thousands of SKUs, rules get complex, imports become frequent and the store needs fast operational iteration. Optimized Indexers focuses on batch-based SQL execution and shorter lock windows instead of row-by-row processing.
- Price indexing (tier prices, group pricing, specials)
- Stock / inventory indexing (including multi-source contexts)
- EAV attribute indexing on large attribute sets
- Catalog rule indexing for frequent promotion updates
- Search indexing where rebuild windows are painful
Faster indexing is not only “ops comfort”. It enables higher merchandising agility: promotions can be updated more frequently, stock and pricing changes reach customers faster, and maintenance windows shrink. This directly improves store responsiveness to business operations.
Default (common pattern):
row-by-row updates
long lock windows
high memory pressure
Optimized:
batch operations
reduced lock duration
more predictable execution time
Architecture Diagram
Speed Suite is designed as a layered optimization stack. Each module reduces a different part of request and operational cost, producing a compounding impact: fewer queries, less runtime overhead, faster catalog rebuilds.
┌────────────────────────────────────────────────────────────┐
│ Magento Request / Ops │
├────────────────────────────────────────────────────────────┤
│ STOP Protocol → Precompiled runtime structures in OPcache │
│ (less bootstrap/config resolution per req) │
├────────────────────────────────────────────────────────────┤
│ Preloaders → Batch loading of product collection data │
│ (pricing/stock/rules/options in few queries)│
├────────────────────────────────────────────────────────────┤
│ Optimized → Faster indexing + shorter lock windows │
│ Indexers (more agile catalog operations) │
└────────────────────────────────────────────────────────────┘
This architecture is intentionally complementary: STOP reduces framework overhead, Preloaders reduces per-collection DB work, and Indexers reduce operational downtime. None of these replaces caching - they improve the performance of both cached and uncached paths.
Most “performance” efforts focus on the output layer: CDN, full-page cache, JS/CSS. Those help but they don’t fix: logged-in pricing, cart behavior, warm-up phases, API calls, admin operations and heavy catalog processing.
Speed Suite reduces the work Magento performs before a page can even be cached. This is why it remains valuable on stores that already use Varnish/Redis/CDN and modern frontend stacks.
Lower per-request variance is critical for P95/P99, especially under bursts and partial cache misses.
Faster indexing means promotions, pricing and stock changes propagate faster with smaller maintenance windows.
Magento vs Speed Suite request lifecycle
A simplified lifecycle comparison that explains why “just add caching” is not always enough. Speed Suite reduces the internal work Magento performs before it can return a response.
Default Magento (typical expensive path)
- Magento resolves configuration structures and runtime dependencies repeatedly.
- Product lists trigger per-product DB reads (pricing, stock, options, rules).
- On higher concurrency, DB amplification becomes the bottleneck.
- Catalog operations (imports/rules) cause long indexing cycles and lock contention.
REQUEST →
bootstrap / config resolution
load product collection
per-product lookups (N+1)
render blocks
response
Magento + Speed Suite (optimized path)
- STOP Protocol loads precompiled runtime structures from OPcache (less bootstrap overhead).
- Preloaders batch-loads collection data (pricing/stock/rules/options) in a few queries.
- Optimized Indexers shorten rebuild windows and reduce lock pressure during catalog operations.
- Result: lower DB amplification, faster responses, more stable P95/P99 under concurrency.
REQUEST →
precompiled config in memory
load product collection
batch preloads (few queries)
render blocks
response (lower variance)
Performance Benchmarks (how to read them)
Benchmarks should be interpreted as directional improvements under controlled conditions. Your absolute numbers depend on hosting, theme, extensions, catalog shape, rules, and traffic patterns. The key outcome is reduced per-request work and improved stability under load.
Preloaders reduces query volume by batching collection-level data retrieval. This typically improves both response time and DB headroom.
STOP Protocol reduces repeated bootstrap/config overhead by serving compiled runtime structures from OPcache memory. This often shows up as lower variance in uncached or personalized flows.
Optimized Indexers shorten rebuild windows and reduce lock pressure during imports, rule updates and catalog operations. That translates into higher operational agility.
What enterprise teams care about most
Lower variance is as important as “faster averages”. Structural improvements reduce tail latency under concurrency, which is where user experience and conversion tend to fail first.
Faster indexing and lower DB pressure mean you can update catalog state more frequently without turning each update into a risk event.
Want the full deep-dive before purchase?
See the full landing page with extended positioning and narrative: qoliber Speed Suite for Magento 2