Case studyTrauringspezialisten · AMG Dynamics · Jan 2026 to Oct 2026
A ring shop rebuilt around its 3D configurator
I finished and launched the new online shop of Trauringspezialisten, a German wedding ring chain, on 11 October 2026, with its 3D engagement ring configurator running inside the shop on AMG's own viewer and diamond search down from 24 s a visit to 0.3 s when cached.
- diamond search per visit, cached
- 0.3 s
- PageSpeed on mobile, largest product page
- 92
- old URLs redirected before launch
- 182
The live site

Fact sheet
Took a German wedding ring chain's unfinished Magento shop from a staging server to live. The configurator's catalogue moved out of Google Sheets into Magento, the media onto S3 and CloudFront in Frankfurt, and the branches kept selling over the counter through it.
- Client
- Trauringspezialisten, Germany
- Through
- AMG Dynamics
- Role
- Led the work as AMG Dynamics' technology partner, then led and wrote the shop rebuild as its CTO
- When
- Jan 2026 to Oct 2026
- Who else
- The shop's platform modules came from the vendor who built it before me. The configurator line started with freelancers I hired. The wedding ring pairs configurator is another vendor's product.
- Stack
- Magento 2
- Hyvä
- Alpine.js
- PHP
- React
- Vite
- three.js
- Amazon S3
- CloudFront
- Lambda
- Electron
- Stripe
- Link
- The configurator
The problem
Trauringspezialisten sells wedding and engagement rings online and in its branches across Germany. AMG had sold them a 3D engagement ring configurator, and in September 2026 the job grew into finishing their new Magento shop and getting it live. The shop existed only on a staging server, built on another vendor's modules.
A few things stood in the way. The configurator sat on a separate host inside an iframe: one configurator page made 142 requests to 18 hosts, its catalogue came from Google Sheets that took 2.6 to 3.6 s each to load, and the 3D view on the last step never actually drew the ring.
Diamond search ran the same search three times on every visit, after counting a feed of 1.4 million stones, so a visit took 24 s. And the new host's own disk couldn't hold the 3D, photo and video media that was on its way.
The old shop, before the rebuildThe same measures, after the rebuild
Diamond search, per visit
24 s0.3 scached6 scoldStone picker on a product page
3.0 s0.16 sConfigurator page requests
14258Configurator page hosts
186Booking page layout shift
0.3350Largest product page HTML
4.7 MB1.9 MBStore finder photos
4.8 MB435 KB
- PageSpeed, largest product page, mobile
- 92
- PageSpeed, largest product page, desktop
- 91
- Lighthouse accessibility
- 100
- Media from the CDN, new connection
- 20 ms
Constraints
- Branches sell over the counter through the same system, so counter orders had to keep working through the rebuild.
- Every option value is part of a product's SKU. Magento builds the SKU from the stored values, so the values could never be renamed, and only their labels were translated into German.
- SKUs weren't safe to parse: production had several segment orders, and an attribute added later left some SKUs a segment short.
- German throughout: the formal Sie, German ring sizes in half sizes, and German stone grading terms.
- The domain, DNS and mailboxes stayed with the existing provider. Only the shop moved.
- Wedding ring pairs stay on another vendor's configurator. Mine is the engagement ring configurator, and I wired the pairs' designs into the cart and orders.
Decisions
- Chose
- Run the configurator inside the shop page, with its files on the shop's own CDN
- Over
- Keeping it in an iframe on a separate host
- Because
- it was deployed by hand to a host of its own, so it never shipped with the shop's releases, and the iframe page made requests to many separate hosts
- Chose
- Move the configurator's sheets into Magento's admin, as a spreadsheet grid with validation and a saved revision on every change
- Over
- Reading Google Sheets
- Because
- the shop wanted to keep editing it like a sheet, but linked to its own database, cached and fast, and the import was byte for byte, so shoppers saw the same catalogue on the day it switched
- Chose
- Show every ring with AMG's own viewer: in the configurator, on its last step and on the configured ring's product page
- Over
- The old renderer
- Because
- the old renderer accepted a model and never drew it, and now all three places show the same viewer
- Chose
- Answer the diamond search once per request and keep the result for an hour under the tile prices cache tag, with a page warmer on top
- Over
- Each listing block running its own search
- Because
- the blocks asked the same question, and the feed import already clears that tag, so the cache never shows a stone that's gone
- Chose
- Keep all media in Amazon S3 in Frankfurt behind CloudFront
- Over
- The host's own disk
- Because
- the disk couldn't hold what was coming, and the rule was that the CDN had to answer as fast as a German server
- Chose
- 3D assets per ring family, matched on option ids, through a desktop tool, 3D Asset Bridge, that shows a dry run and writes nothing until you press Apply
- Over
- A model per variant, or matching by parsing SKU strings
- Because
- metal is applied as a material, so one model covers every alloy, and SKU strings weren't reliable
- Chose
- Pack the product page's per variant photo list and rebuild it in the browser, checked to rebuild identical data
- Over
- Printing every photo URL of every variant into the HTML
- Because
- the largest ring family's page carried every variant's photos in several sizes, and printing them all bloated its HTML
- Chose
- Start the 3D ring in the product gallery on the visitor's first touch, key or scroll
- Over
- Loading it with the page
- Because
- on desktop it loaded the whole 3D ring at page load and kept rendering, so PageSpeed's desktop run timed out
How it works
The design studio's Rhino files go through 3D Asset Bridge, which makes the web models and a photo per alloy and attaches them to the right products. All media lives in S3 in Frankfurt and reaches shoppers through CloudFront.
The configurator's tables live in Magento. A job publishes them as one catalogue file on the CDN every 15 minutes, or when someone presses the button, and the configurator in the page reads that file. Every 3D view on the site is the Jewelitt viewer, embedded in the page.
The diamond feed imports into the shop's own index, and search reads it through a cache the import clears. Online orders pay through Stripe, and the branches' counter orders run through the same shop.
Drawing
From the workshop's file to the product page
Studio Rhino files
from the design studio
- leads to 3D Asset Bridge
3D Asset Bridge
models and a photo per alloy
- leads to S3 and CloudFrontmodels, photos
- leads to Magento and Hyväattaches
Configurator tables
in Magento admin
- leads to S3 and CloudFrontcatalogue file
S3 and CloudFront
Frankfurt
- leads to Jewelitt viewer
Diamond feed
imports through the day
- leads to Search cacheclears tag
Search cache
cleared by the import
- leads to Magento and Hyvä
Magento and Hyvä
the shop
- leads to Jewelitt viewer
- leads to Shopper or branch
Jewelitt viewer
every 3D view
Shopper or branch
online and over the counter
Results
- Live on 11 October 2026. Every URL in the old site's sitemap was redirected before launch, so they all still resolve.
- The configurator now ships with the shop's own releases instead of being deployed by hand to a host of its own.
- One ring family's 1,188 variants run on 9 web models.
The numbers
| Metric | Before | After | How measured |
|---|---|---|---|
| Diamond search, per visit, cached | 24 s | 0.3 s | The cached path, from the same visit as before |
| Diamond search, per visit, cold | 24 s | 6 s | The first visit after the import clears the cache |
| Stone picker on a product page | 3.0 s | 0.16 s | Fixed after launch |
| Configurator page requests | 142 | 58 | Measured from the server, before and after the move into the shop |
| Configurator page hosts | 18 | 6 | Measured from the server, before and after the move into the shop |
| Booking page layout shift | 0.335 | 0 | CLS on the booking page |
| Largest product page HTML | 4.7 MB | 1.9 MB | The largest ring family, before and after the packed photo list |
| Store finder photos | 4.8 MB | 435 KB | WebP through the CDN |
| PageSpeed, largest product page, mobile | no earlier figure | 92 | After launch |
| PageSpeed, largest product page, desktop | no earlier figure | 91 | After launch |
| Lighthouse accessibility | no earlier figure | 100 | Every page audited before launch |
| Media from the CDN, new connection | no earlier figure | 20 ms | CloudFront from Frankfurt |
PermissionNamed with the client's approval. The screenshot is their public configurator as it looks today; no orders, customer data or revenue are shown.