Why We Cut the Slowest Try-Ons, Not the Average One
- A working try-on stayed 8.7 to 12.4 seconds; we cut the failure-path waits instead.
- A render the AI service blocks now ends in about 11 seconds, not 35 to 47.
- A slow AI service now stops at about 30 seconds with a message, not a minute.
Conclusion: a working Ello try-on has run about 8.7 to 12.4 seconds since October 9, and that number barely moved this month. The wait that loses a shopper is not the working one; it is the failure, the spinner that runs 40 seconds and ends in an error. So we spent the month cutting the tail, not the median. A render the AI service blocks used to retry in the background and make the shopper wait through two attempts, 35 to 47 seconds, before an error; it now stops after about 11 seconds with a try again message. A slow service had no stop, so a bad minute could become two; it now stops at about 30 seconds with a clear message. A dropped phone connection used to mean starting over, after 5 of 84 try-ons failed that way in 30 days; it now reconnects and collects the render already running. The non-obvious point: optimize the slowest experience, not the average one (our data).
Which try-on does a shopper remember?
Not the fast one. The slow one: the spinner that runs 40 seconds and then shows an error. So this month we spent our time on the tail, the worst-case waits, not the median that was already fine.
What was the worst case, and what is it now?
| What the shopper waits for | Worst case before | Now |
|---|---|---|
| A try-on that works | 8.7 to 12.4s | 8.7 to 12.4s, unchanged |
| A render the AI service blocks | 35 to 47s, then an error | about 11s, then try again |
| The AI service running slow | a minute or more, sometimes twice | about 30s, with a clear message |
- Blocked render, before: 35 to 47s, then an error
- Blocked render, now: about 11s, then try again
- Slow service, before: 60s or more, sometimes twice
- Slow service, now: about 30s, with a clear message
The median did not move. Two failure paths did.
Why did a failure take longer than a success?
- A blocked render retried in the background, so the shopper sat through two attempts before the error.
- A slow service had no stop, so a bad minute could quietly become two.
- A dropped phone connection meant starting over, even when the render had already finished.
Each one hid the delay from the shopper and often doubled it. We put a stop and a plain message on every path, and a dropped connection now reconnects instead of restarting.
What can any store check this week?
- Time your worst case, not your average: trigger an error and count the seconds to a message.
- Kill silent background retries: one failed attempt a shopper can see beats two they cannot.
- Put a hard stop on every long wait, with a plain message, so a stall never looks infinite.
- Test any change with a holdout (see: how to measure virtual try-on lift).
FAQ
How long does an AI virtual try-on take?
An Ello try-on has run about 8.7 to 12.4 seconds since October 9, including a front and back print and a two-view bag at the shopper's height (our data). A render the service blocks now ends in about 11 seconds.
Why did a failed try-on take longer than one that worked?
A blocked render used to retry in the background, so the shopper waited through two attempts, 35 to 47 seconds, before the error. It now stops after about 11 seconds with a try again message.
What happens if the AI service is slow?
A slow try-on now stops at about 30 seconds and tells the shopper it is taking longer than usual. Before, a slow render could run a minute or more, and sometimes twice (our data).
What should a store check on its own site?
Time your worst case, not your average. Trigger an error and count the seconds to a visible message, and remove any silent background retry that doubles the wait a shopper feels.
Sources
- Ello public changelog, 2026-09-23 to 2026-10-22 (our data) [C]: a working try-on at 8.7 to 12.4s (10-09), a blocked render ending in about 11s instead of 35 to 47s (10-15), a slow service stopping at about 30s (10-22), and a dropped-connection reconnect after 5 of 84 try-ons failed that way (09-23).