Optimizely Performance and Stability

The first of the 14 Focus Points is Site Performance and Stability, that an eCommerce site must be fast, available, and error-free before adding enhancements or features to drive conversions.

Out of the box, Optimizely Configured Commerce is a solid B2B eCommerce platform. But like all enterprise solutions, there are many configurations, settings, or even custom work to not just maximize, but sometimes even achieve the base performance expected. Not attending to these can result in lost sales and customers. There are many pitfalls that can lead to poor site performance and stability, the most important are:

1. Number and architecture of background jobs
2. Fragile front-end UI implementations
3. Poorly architected API and 3^rd party integrations
4. Bottlenecks due to large database (product catalog, orders, etc.)
5. Improper hardware scaling

More detail is provided on each of these below.

1. Jobs. Optimizely has many jobs running in the background, often too many. We often hear clients ask us “Do I have too many Optimizely jobs running?” or “Which Optimizely jobs can I eliminate?” They have a lack of confidence in which jobs should be running and which shouldn’t. Running too many concurrent jobs can be detrimental to site performance (slow speeds or page loads) and is especially damaging when the jobs are unnecessary. We know which jobs are required and where to trim the fat. 
   In another instance, a new client was having issues with their large daily product data job, which took hours to run a single cycle, failing. This led to consecutive days with product data changes not making it to the site and outdated information provided to the customer. We broke this up into multiple smaller jobs that consistently ran. This allowed for successful jobs to update the site and quicker identification of the issues with the failed data.
2. Fragile UI. With the abundance of “off the shelf” JavaScript libraries on the market, developers can often try to assemble these libraries in a hodge-podge method to achieve the client’s goals. This can lead to a fragile UI that has intermittent issues due to the asynchronous nature of JavaScript within modern browsers.
   The remedy is often to simplify the number of libraries used along with the overall architecture. While creating a completely modular architecture is nice in theory it can create stability issues due to the complexity of debugging and the timing of calls.  Simplifying can simply mean fewer API/AJAX calls and the use of large more stable models per page.  (more on this topic here)
3. APIs/3^rd Party Integrations. Connectors that pull data into Optimizely from other systems (ERP, DAM, PIM, etc.) can often fall victim to the instability and performance constraints of the remote system.  This can then appear as if the eCommerce site itself is performing poorly. The use of a proper caching strategy and asynchronous calls from JavaScript can lead to lightning-fast site response.
4. Large Database Bottlenecks. In the current versions of Optimizely, the database cannot be horizontally scaled and requires significant server power to handle large databases (>1M SKUs).  This problem can often be solved in a few ways. 1) Ensure that the SQL server implementation is adequate for the number of customers, orders, and SKUS. 2) Use of database replication in a SQL cluster and 3) Use regular maintenance jobs to clean up unnecessary data within the database (abandoned carts, inactive customers, etc.).
5. Hardware Scaling. As stated in the above points, lack of attention to the size of the servers running your eCommerce platform can result in a poor overall user experience.  Ensuring that you are following Optimizely’s recommendations is a simple starting point.

Tending to these areas will greatly increase Optimizely’s performance and stability leading to the tangible results of increased revenue and site adoption.

Site Performance and Stability is the first of Layer One's

See the other 13 Focus Points here!

< Read other articles from our thought leadership blog