All Collections
FAQs & Troubleshooting
Mutiny Performance and Reliability
Mutiny Performance and Reliability

Performance and reliability is critical. Latency, availability, and data durability are at the heart of what we do.

Updated over a week ago


At Mutiny, performance and reliability are critical. In order to deliver personalization, Mutiny servers sit in the critical path of our customer's websites. Because of this, latency, availability, and data durability are at the heart of what we do.

Below we break down the infrastructure we have in place to ensure the Mutiny client is fast and reliable, and the built-in failsafes that protect your website in the event of an error.

Reducing Latency

Latency is the amount of time (generally in milliseconds) that it takes a server to build and send a response to the client.

Before our customer's site is rendered, the visitor has to download our client. This is typical of many JavaScript integrations with products. We help reduce the latency of our client in two main ways – by reducing its size, and by being efficient about how we distribute it.

Client Size

The fewer bytes we send over the wire, the faster the browser can parse the client and the faster a customer's page will load. We’ve always worked to keep our client as small as possible. Currently, the Mutiny client comes in under 30kb for 95% of customers which is ~40% smaller than others on the market, for example, Google Optimize.

Client Distribution

The second part of optimizing the client is ensuring we distribute it in an efficient manner. Mutiny customers each include a custom JavaScript client on their website. This JavaScript client is loaded whenever a visitor comes to your website and is the only synchronous component in the critical path of loading your website. Because of this, we have built our infrastructure to leverage industry standards that ensure that this JavaScript is delivered rapidly and reliably.

To maximize reliability, we prebuild the JavaScript client and upload it to Amazon S3. Amazon Simple Storage Service (Amazon S3) is an object storage service that offers industry-leading scalability, data availability, security, and performance. Every time you launch or edit an experience, the client is rebuilt and sent to S3 for distribution. This ensures that nothing dynamic sits between your website visitor’s browser and our server, utilizing extensive caching and maximizing reliability.

To minimize load times, we front our Amazon S3 client registry with Fastly’s global content delivery network (CDN). Fastly’s CDN caches content (in this case, your JavaScript tag) in proxy servers that are located geographically closer to your end-users, enabling the JavaScript tag to load faster and more reliably. Every time a change is made to the underlying file, Fastly’s CDN is flushed and the new client is picked up for distribution.

Once the client has been loaded by the browser, the page begins to render and we must fetch data about the visitor in order to personalize their experience. We expose a User Data API that our JavaScript uses to fetch the information we need about them (behavioral attributes, Salesforce records, IP enrichment, etc). This happens asynchronously while the browser renders the rest of the page, in order to take advantage of the browser’s parallel processing and maximize the efficiency with which the experience is applied. While the request is processed, the Mutiny JavaScript will hide only the elements being personalized, so the rest of the page can load in tandem and the user never sees a flash of the original content.

Our User Data API must be dynamic and up-to-date, so it is backed by a dedicated set of web servers that are tuned for performance. The first time we see a visitor, the service responds in less than 350ms in the 95th percentile. Subsequent page views from that same visitor will leverage a separate Fastly CDN to cache the data geographically closer to the visitor, and typically those responses load in less than 100ms. Whenever data about a user changes, the updated content is pushed to Fastly’s CDN so Mutiny can leverage that data in real-time.


In the extremely rare event of an AWS outage, we’ve implemented a hard timeout in the Fastly CDN of 200ms so that your website will be left untouched. When it comes to the user data, the Fastly CDN will implement a hard timeout of 500ms to ensure we don’t prevent the browser from rendering personalized elements if user data can’t be accessed. If there is a cached response available, that will be used, otherwise, it will fall back to your base website.


Mutiny delivers personalization on tens of millions of pages every month, and we have architected our system for scale and stability. S3 enables us to create an extremely reliable repository for delivering JavaScript and Fastly’s dynamic CDN capabilities allow us to make sure the JavaScript tag and the User Data API load quickly for visitors coming to a Mutiny enabled website. We optimize for maintaining the best performance for the end user, and in the rare event that personalization cannot be delivered, we always fall back to the underlying content on the website.

Don't be a stranger

If you have any questions about performance or the best way for you to implement Mutiny for your site, please contact

Did this answer your question?