OPTIMIZELY PERFORMANCE ENGINEERING
Your Optimizely site is slow. We find out why — and prove it.
We have worked with some of the largest customers running on the Optimizely platform — the kind of enterprise CMS and Commerce implementations where a single slow page template is measured in lost revenue, not milliseconds. Those engagements are covered by confidentiality agreements, so we will not name the brands on a marketing page. What we will do is tell you exactly how we find the problem in your implementation.
Optimizely is a .NET application, and it slows down like one
Optimizely CMS and Optimizely Commerce (which most of the industry still knows as Episerver) are ASP.NET applications sitting on SQL Server, a content cache, a search index, and — on DXP — shared cloud infrastructure you do not fully control. That is our home ground. We do not treat your site as a black box and guess from the outside; we profile the running .NET process, read the traces, and point at the specific call that is costing you the time.
Most Optimizely performance work we see has stalled for one of two reasons. Either the team has front-end metrics but no server-side evidence, so every theory is plausible and none is provable. Or the team has been told "it is the platform" and has quietly accepted a ceiling that is not actually the platform's.
Where the time usually goes
Every implementation is different, but the shapes repeat. These are the areas we go after first in an Optimizely engagement:
Content loading in a loop
A block or partial that loads content per item, called once per row, called once per page, multiplied by the catalogue. Individually each load is fast and every one of them looks innocent in the code. In aggregate it is the page.
Caching that is not actually caching
Output and object caching configured but bypassed — by a personalisation rule, a visitor group, a query string, or an authenticated cookie. The cache hit rate looks fine in aggregate and is near zero on the pages that matter.
Publish-time invalidation storms
An editor publishes, the cache invalidates broadly, and every node in the cluster rebuilds the same expensive content at once. The site is fast all morning and falls over at the moment marketing ships a campaign.
Search and navigation queries
Unbounded result sets, facets computed for results nobody will page to, and filtering done in application code after the index has already returned far too much. Search is frequently the single largest contributor to a slow listing page.
Commerce pricing and inventory
Price, inventory, and promotion evaluation resolved per line item, per request, against the database, instead of once and in bulk. Carts and listing pages degrade non-linearly as the catalogue and the promotion set grow.
The database underneath
Missing or unusable indexes, plan regressions under parameter sniffing, and blocking that only appears at production concurrency. We came out of SQL Server internals; this is not a layer we hand off to somebody else.
Add-ons and custom initialisation
Third-party add-ons, scheduled jobs, and initialisation modules doing synchronous work on the request path. Cheap in a developer's sandbox, expensive at production traffic on shared infrastructure.
DXP capacity and scaling behaviour
On DXP you are sharing infrastructure and scaling on someone else's rules. Knowing which of your problems are genuinely capacity and which are your own code is the difference between paying for a bigger instance and actually fixing the site.
Everything after the server responds
Render-blocking assets, oversized images, and marketing tags that land after go-live and nobody re-measures. A fast server response that still produces a slow page is still a slow page to your customer.
How we engage
We are measurement-first. We will not send you a list of best practices and call it an engagement, and we will not ask your team to make changes we cannot demonstrate the value of afterwards.
Measure
We establish what "slow" means in your business terms and capture real evidence from the running system — traces from production or a faithful load, not synthetic guesses.
Find the root cause
We analyse the traces down to the call that is actually costing the time, and we tell you which problems are worth fixing and which ones are noise.
Fix
We either hand your team a specific, scoped change or we write it with them. Your developers keep ownership of the codebase; we are not trying to become a dependency.
Verify
We re-measure and quantify what changed, so the work is defensible to whoever signed off the budget — and so we can tell you honestly when you have hit diminishing returns.
That loop is the same one we describe in detail on our .NET performance process page. Optimizely does not change the method — it changes where we look first.
Why us for an Optimizely engagement
- We have done this at the top end of the platform. Our Optimizely experience is with enterprise customers operating at serious scale, under real commercial pressure. Those engagements are under NDA and we intend to keep them that way — which is the same discretion your own engagement will get.
- We profile, we do not speculate. Our practice is built on production-grade .NET profiling and trace analysis. When we tell you where the time is going, we can show you.
- We go all the way down. Razor and MVC through the Optimizely APIs into Entity Framework and into SQL Server internals. Performance problems do not respect layer boundaries and neither do we.
- We tie it back to money. Site speed is a revenue argument, not an engineering vanity metric. See the industry studies we work from, or put your own numbers into the loss calculator.
Start with a conversation, not a contract
Tell us what your Optimizely site is doing and what it is costing you. If we do not think we can help, we will say so on the call. If we can, you will leave the conversation knowing what we would look at first and why.
Reignite Software Performance is an independent performance engineering consultancy. We are not affiliated with, sponsored by, or endorsed by Optimizely. "Optimizely" and "Episerver" are used here solely to identify the platform our clients run on, and remain the trademarks of their respective owners.
