> For the complete documentation index, see [llms.txt](https://help.mimeeq.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.mimeeq.com/developer-guides/performance.md). # Performance Give customers fast, smooth 3D configurators anywhere in the world. Learn how Mimeeq uses HTTP/3, code splitting, compression and a global CDN. 3D product configurators represent one of the most demanding applications in modern web development. Unlike traditional websites that serve static content, 3D configurators must deliver complex rendering engines, mathematical libraries, asset management systems and real-time interaction capabilities — all while maintaining fast load times and smooth user experiences across global audiences. At Mimeeq, we've developed a comprehensive performance solution that combines multiple cutting-edge optimisation strategies. Our approach integrates HTTP/3 technology, advanced asset compression, global CDN architecture and sophisticated loading techniques that most platforms haven't yet adopted. *** ## 3D configurator performance challenges Unlike traditional websites, 3D configurators face unique performance demands that require specialised optimisation approaches: **Real-time rendering requirements:** * WebGL shader compilation and GPU resource management * Dynamic lighting calculations for material accuracy * Real-time shadow rendering and reflection mapping * Smooth animation systems for product interactions **Memory management:** * Efficient texture memory allocation across multiple product variations * Garbage collection optimisation to prevent frame rate drops * Strategic asset caching to balance memory usage with load times * Progressive texture resolution based on available system resources **Cross-device compatibility:** * Adaptive rendering quality based on device capabilities * Battery optimisation for mobile devices during 3D interactions * Automatic fallback systems for lower-powered hardware * Frame rate optimisation across different screen refresh rates **Interactive responsiveness:** * Sub-100ms response times for configuration changes * Predictive loading of likely user selections * Smooth transition animations between product states * Real-time price and availability updates without blocking interaction ### Mimeeq's 3D-specific optimisations * **Adaptive rendering pipeline:** Our configurators automatically adjust rendering quality and complexity based on device capabilities, ensuring smooth performance on both high-end desktops and mobile devices. * **Smart caching strategies:** We implement intelligent caching of 3D assets, textures and compiled shaders, with automatic cache management that balances performance with storage constraints. * **Progressive enhancement:** Basic product visualisation loads instantly, with enhanced features like realistic materials, lighting effects and animations loading progressively as system resources allow. *** ## The evolution from HTTP/1 to HTTP/3: why request count no longer matters ### The old paradigm (HTTP/1.1) Traditional web optimisation focused heavily on reducing HTTP requests because each request required a separate connection, creating significant overhead. This led to the common practice of bundling everything into large files — sometimes resulting in multi-megabyte JavaScript bundles that took forever to download and parse. ### The HTTP/2 improvement HTTP/2 introduced multiplexing, allowing multiple requests over a single connection. However, it still suffered from TCP's head-of-line blocking problem, where a single lost packet could delay all streams. ### The HTTP/3 revolution HTTP/3, built on the QUIC protocol, fundamentally changes the performance equation: * **True multiplexing without head-of-line blocking:** Each stream is independent * **Faster connection establishment:** Combining transport and TLS handshakes * **Better packet loss recovery:** Only affected streams are delayed * **Connection migration:** Seamless network switching for mobile users As the experts at the JavaScript Conference explain: *"Don't worry about bundling; request count doesn't really matter any more, and larger numbers of small requests are easier for the browser to cache and manage."* ([Source](https://javascript-conference.com/blog/quic-and-http-3-the-next-step-in-web-performance/)) *** ## Mimeeq's advanced code splitting architecture ### Our approach: intelligent code chunking While most web applications serve 5–20 JavaScript files, Mimeeq's 3D configurators deliver hundreds of precisely optimised code chunks, scaled to feature complexity and requirements. This isn't inefficiency — it's sophisticated engineering designed for HTTP/3's capabilities. Here's how our delivery compares with the traditional approach:
#ApproachBundlesLoadingCachingExecution
1Traditional1–5 large bundles (1–10MB each)Entire codebase downloads on initial loadPoor cache efficiency when updates occurBlocking JavaScript execution during parsing
2Mimeeq's HTTP/3-optimised approachHundreds of small, focused chunks (typically 5–50KB each), scaled to feature complexityOn-demand loading of only required functionalityGranular caching — only changed chunks re-downloadParallel parsing and execution without blocking
### Technical implementation details Our chunking strategy follows several key principles: 1. **Feature-based splitting:** Each configurator feature (materials, dimensions, colours, etc.) loads independently 2. **Library segmentation:** Third-party dependencies are split into logical, reusable chunks 3. **Progressive enhancement:** Core functionality loads first, advanced features load on demand 4. **Cache optimisation:** Vendor chunks rarely change, application chunks update frequently 5. **Dynamic distribution:** Configuration changes in the admin panel automatically generate and distribute updated JSON files globally *** ## Industry validation and best practices ### Webpack's official recommendation Webpack, the industry-standard bundling tool, officially supports this approach through its AggressiveSplittingPlugin, specifically designed for HTTP/2+ environments. Its documentation demonstrates splitting bundles into 30–50KB chunks, creating hundreds of files for optimal performance. ([Source](https://github.com/webpack/webpack/blob/main/examples/http2-aggressive-splitting/README.md)) ### Academic research support Recent academic research from ResearchGate on "Resource Multiplexing and Prioritization in HTTP/2 over TCP Versus HTTP/3 over QUIC" validates the performance benefits of this approach, particularly for complex web applications. ([Source](https://www.researchgate.net/publication/345980642_Resource_Multiplexing_and_Prioritization_in_HTTP2_over_TCP_Versus_HTTP3_over_QUIC)) ### Industry expert consensus Performance optimisation experts consistently recommend this approach for HTTP/2+ environments. As noted in comprehensive webpack chunking guides: *"Multiple requests are only a concern for HTTP/1.1, using HTTP/2 would mean that only 1 request would be required to retrieve the required async chunks... Optimising for HTTP/2 means creating many chunks."* ([Source](https://www.chrisclaxton.me.uk/chris-claxtons-blog/webpack-chunksplitting-deepdive)) *** ## Real-world performance benefits ### Faster initial load times * Core configurator functionality loads in \~1–2 seconds globally * Advanced features stream in as needed * Users can start interacting immediately ### Superior caching strategy * Individual feature updates don't invalidate entire bundles * Return visitors experience near-instantaneous loads through multi-tier caching * Bandwidth usage optimised for actual feature usage * Automatic global distribution of updated chunks via Fastly CDN ### Optimised asset delivery * Brotli compression reduces transfer sizes by 20–30% over gzip * Compressed 3D models minimise initial load times * Smart image optimisation adapts to device capabilities * Progressive loading prevents blocking of critical functionality ### Mobile network optimisation HTTP/3's connection migration means seamless performance as users switch between Wi-Fi and cellular networks — crucial for mobile shopping experiences. ### Global performance consistency Our multi-tier CDN architecture ensures optimal performance worldwide. With origin servers in Frankfurt, Sydney and North Virginia, regional Fastly shields and global POP locations, users experience consistent performance regardless of geographic location. HTTP/3's connection migration capabilities further enhance this by maintaining seamless performance as users move between networks. *** ## Beyond traditional performance metrics ### Why traditional performance metrics need context While performance testing tools like GTmetrix, PageSpeed Insights, Pingdom and WebPageTest provide valuable insights, it's important to understand what they measure and how to interpret results for HTTP/3 applications. **Modern tool capabilities:** * GTmetrix's "Make fewer HTTP requests" audit specifically won't trigger "if your page is detected to be using HTTP/2" * PageSpeed Insights has supported HTTP/2 since March 2021 and focuses primarily on Core Web Vitals * These tools increasingly prioritise user experience metrics over simple request counts **What these tools don't capture:** * HTTP/3's superior multiplexing and caching benefits * Real-world performance improvements from granular chunking * Progressive loading advantages for returning users * Edge caching efficiency gains ### Performance monitoring and continuous optimisation **Real-world metrics that matter:** * **Time to first interaction:** How quickly users can start configuring (typically 1–2 seconds) * **Feature load latency:** How fast new capabilities become available as users explore options * **Cache hit rates:** Percentage of returning users who avoid downloads entirely (often 85%+) * **Mobile performance:** Actual usage metrics across varying network conditions and device capabilities **Continuous performance engineering:** * Real-time monitoring across all global CDN locations * Automatic performance regression detection during deployments * A/B testing of different optimisation strategies * Regular analysis of user interaction patterns to optimise loading priorities {% hint style="success" %} **Global performance consistency:** Our monitoring shows consistent sub-2-second load times across major global markets, with return visitors often experiencing sub-500ms configuration changes due to intelligent caching strategies. {% endhint %} *** ## Implementation considerations ### CDN-first architecture Our approach only works effectively when combined with proper CDN implementation: * **Global edge distribution** ensures chunks load from nearby servers * **HTTP/3 support** throughout the delivery chain * **Intelligent caching policies** for different chunk types ### Mimeeq's global distribution architecture Our sophisticated chunking strategy is supported by a multi-tier global infrastructure designed for optimal performance worldwide: ![Mimeeq global CDN architecture with S3 origins, Fastly shields and edge POP locations](https://621103948-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FsqWfi8ifBhTdkvf1vOlY%2Fuploads%2FJK0RfTXBDQm6eu15DgJQ%2Fglobal-cdn_82gbuh.png?alt=media) **Data generation and distribution:** When configuration changes are made in Mimeeq's admin panel, we automatically generate optimised JSON files containing all necessary configurator data. These files are immediately distributed across our global CDN infrastructure via Fastly. **Multi-tier infrastructure:** * **Origin servers:** 3 AWS S3 locations (Frankfurt, Sydney, Ashburn North Virginia) * **Shield layer:** Fastly shields at each origin location for enhanced caching * **Edge layer:** Global Fastly POP (Point of Presence) locations worldwide **Performance optimisation hierarchy:** Our system is designed to serve content from the closest and most optimised location:
#ScenarioWhere the content comes from
1Best caseEdge POP server has all required files locally
2Next bestEdge has some files, retrieves remainder from regional shield
3GoodEdge has no files, shield has all required content
4AcceptableShield has partial content, retrieves remainder from S3 origin
5BaselineShield retrieves all content from S3 origin
{% hint style="info" %} **Zero backend dependency for public configurators:** For public configurators, no requests to our EU servers are required during the configuration experience — the only backend call is for pricing, which runs asynchronously and doesn't block user interaction. This means users worldwide get the same fast, responsive experience regardless of their distance from our origin servers. {% endhint %} ### Advanced asset optimisation Beyond our sophisticated delivery architecture, Mimeeq implements multiple layers of asset optimisation that dramatically reduce bandwidth usage and maximise loading speed. **3D model optimisation:** * Advanced geometry compression algorithms reduce model sizes by 60–80% while maintaining visual fidelity * Mesh optimisation and polygon reduction based on viewing distance requirements * Texture compression using industry-leading formats and quality-based encoding * Multiple Level of Detail (LOD) versions automatically selected based on device capabilities **Brotli compression advantage:** * All HTTP requests use Brotli compression, delivering 20–30% better compression than gzip * JSON configuration files achieve exceptional compression ratios due to repetitive data structures * JavaScript chunks benefit from Brotli's superior performance on code with repeated patterns * Real-time compression for dynamic content ensures optimal transfer sizes **Smart image delivery:** * Modern image format delivery optimised for each browser's capabilities * Responsive image sizing automatically adapts to device screens and network conditions * Progressive loading prioritises above-the-fold visual content * Texture streaming loads high-resolution materials only when users interact with specific product areas * Lazy loading of non-critical visual assets prevents blocking of core functionality **Intelligent resource prioritisation:** * Critical rendering path optimisation ensures configurator UI loads first * Non-blocking asset loading prevents user interaction delays * Preloading strategies based on user behaviour patterns and product complexity * Background loading of likely-needed assets while users interact with current options ### Fallback compatibility While HTTP/3 is supported by all modern browsers (Chrome, Firefox, Safari, Edge), our chunks are designed to work efficiently with HTTP/2 as well, ensuring universal compatibility. *** ## The future of web application architecture Mimeeq's approach represents the future of complex web application delivery. As HTTP/3 adoption continues to grow (with over 70% browser support as of April 2024 according to research studies), this architecture becomes increasingly advantageous. **Current HTTP/3 browser coverage:** Based on current browser market share and HTTP/3 support status, approximately **78–79% of users worldwide** have HTTP/3 fully enabled by default: * **Chrome (66% market share):** Full HTTP/3 support enabled since April 2020 * **Microsoft Edge (5% market share):** Full HTTP/3 support (Chromium-based) * **Firefox (3% market share):** Full HTTP/3 support enabled since April 2021 * **Opera (2.5% market share):** Full HTTP/3 support (Chromium-based) * **Samsung Internet (2–3% market share):** Full HTTP/3 support (Chromium-based) An additional **18% of users (Safari)** have HTTP/3 capability but it remains disabled by default, meaning the total browser capability reaches over **95% of major web browsers** as of September 2024. Traditional bundling strategies made sense for HTTP/1.1's limitations, but they're becoming counterproductive in the HTTP/3 era. Organisations still optimising for 2015's constraints are missing significant performance opportunities. *** ## Sources and further reading For technical teams interested in implementing similar optimisations, we recommend starting with the resources linked throughout this article, particularly Webpack's official HTTP/2 optimisation documentation and the latest performance research on HTTP/3 implementations. * [QUIC and HTTP/3: The Next Step in Web Performance - JavaScript Conference](https://javascript-conference.com/blog/quic-and-http-3-the-next-step-in-web-performance/) * [HTTP/3 Official Specification - Cloudflare Learning Center](https://www.cloudflare.com/learning/performance/what-is-http3/) * [Webpack HTTP/2 Aggressive Splitting Example - Official Documentation](https://github.com/webpack/webpack/blob/main/examples/http2-aggressive-splitting/README.md) * [HTTP/3 vs HTTP/2 Performance Analysis - Catchpoint](https://www.catchpoint.com/http3-vs-http2) * [Resource Multiplexing Research - ResearchGate](https://www.researchgate.net/publication/345980642_Resource_Multiplexing_and_Prioritization_in_HTTP2_over_TCP_Versus_HTTP3_over_QUIC) * [Webpack Chunk Splitting Deep Dive - Chris Claxton](https://www.chrisclaxton.me.uk/chris-claxtons-blog/webpack-chunksplitting-deepdive) *** ## Related articles
Custom UIBuild and deploy your own interface around the Mimeeq 3D configurator.Custom UI
Custom LoaderShow your own loading animation while the configurator initialises.Custom Loader
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://help.mimeeq.com/developer-guides/performance.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.