TL;DR: with Optimize, you can now offload 100% of Sitecore Content Delivery to a CDN and keep personalization and tracking.
The Optimize capability is in Private Beta at the moment and will be released shortly. In meantime, if you are interested in evaluating how Optimize can help you accelerate your existing Sitecore solution now, please reach out to us at firstname.lastname@example.org.
The Optimize is a plug-and-play capability for Sitecore that decouples the configuration of personalization in Sitecore from the execution of personalization, giving you the best of both worlds: marketers to continue using their existing tools to configure personalization, developers and IT can get fast performance, no impact on scaling their infrastructure to support personalization, and less complexity by having more flexibility in terms of how personalization is executed.
If you are familiar with the "XP" part of Sitecore Experience Platform, think about it as decoupled personalization and tracking without xDB. There is no origin-based session that is required to execute personalization. The "act" part of personalization happens on the CDN-level (the "edge"). The "context" part of personalization - tracking, happens in user's browser. The whole process is backend-less and origin-less, which allows you to maintain fast performance characteristics without compromising on performance and scale. The collection of data is taking place via dispatchers, and can be configured to go to Google Analytics or xDB (if you still like to collect data there).
In order to help illustrate the business value of Optimize, consider the standard origin-based Sitecore personalization (simplified for the illustration purposes).
This approach appears to be simple: the visitor connects to the Sitecore instance; Sitecore needs to instantiate the visitor context (the session and server-side tracker, which results in many expensive IO), then render the page; Sitecore returns the page to the visitor. The server-side session can often be the bottleneck in scaling and the dynamic Content Delivery process that is highly reliant on in-memory caching being primed to deliver the page in a reasonable amount of time.
This also means that you cannot take full advantage of a CDN. Since personalization has to run on the Sitecore instance, the CDN's use is limited to delivering images and other static assets.
Uniform moves the execution of personalization rules from the CD server to the CDN. Since the CDN can deliver content to visitors much faster than even the most highly tuned and scaled Sitecore Content Delivery architecture and can do it with virtually no configuration, you end up with the fastest possible personalized Sitecore site.
To understand how this works, consider the two things that happen when the CDN receives a request: the request is for a page that is not currently cached (called a cache miss), or the request is for a page that is currently cached (called a cache hit).
What happens during a cache miss?
When a cache miss happens, CDN must make a call to the Sitecore instance. This does slow things down, but since the personalization does not run on the Sitecore instance, Sitecore is able to handle the response faster than it would if it had to build a personalized response.
What happens during a cache hit?
This is where things get interesting because this time CDN has everything it needs to handle the request. It does not need to make a call to the Sitecore CD instance:
Every personalization needs visitor context. Visitor context tracking is handled completely client-side, and the data can be configured to be dispatched using an asynchronous call to the Sitecore CD instance. This way, Sitecore can continue to track visitor behavior without affecting site performance. If you don't really need to collect visitor behavior in Sitecore xDB, you can use the Uniform Tracker to write visitor behavior data to any repository you like, including Google Analytics, a CDP, your own data warehouse, etc.
The ability to cache Sitecore pages has been a limitation since server-side origin-based tracking and personalization were introduced to the platform in the early days. This effectively prevented caching the pages at the CDN level without lost functionality, which is why many existing Sitecore solutions only leverage CDN for static resource caching, but not pages. Typically, CDNs are able to deliver the page in 50ms TTFB or less, while with origin-based delivery, TTFB may vary significantly and reach the territory of multiple seconds, especially if the system is not optimized or experiencing unusual load. With performance being the SEO concern these days as well, the pursuit of sub-second page load time is pretty much impossible without CDN-based Content Delivery.
Once the Content Delivery is offloaded to the CDN, the only time when the Sitecore CD server needs to render the page is during cache misses (after the page has been published or when the PoP node on the CDN infrastructure needs to pull from the origin).
Having less work for Sitecore Content Delivery servers to do means that you are usually able to downscale both vertically and horizontally, which saves cost.
That feeling when the business is about to launch a massive campaign and you cross your fingers that your auto-scaling setup is just right and you have enough juice to support the traffic spikes. By offloading 100% of page delivery to the CDN, your offload the scaling problem to that layer as well, which is far more elastic than any web server and database.
No, in fact, we built this capability in a way that you don't have to make any code changes to your existing solution, as Optimize can interpret Sitecore personalization rules, as well as custom ones, and have them execute on the edge.
No, you don't have to, but Optimize is built to be compatible with Jamstack architecture as well, but also Optimize is compatible with Sitecore MVC and JSS solutions as is, whether you use the Deploy part of Uniform for Sitecore or not.
Both Sitecore MVC and Sitecore JSS are supported. The support for Sitecore JSS is quite special, as Optimize allows to maintain the Single Page Application architecture and personalize not only HTML of rendered pages, but also Layout Service requests (JSON).
No. While it's true that the Sitecore origin server returns all the variances of a given component, the CDN layer ("the edge") rewrites the response before it is sent to the client (the browser), so the client only sees the only variance they are supposed to see based on their user context.
Currently, Optimize supports Akamai CDN as the edge-personalization execution engine with more CDN support coming soon. If you'd like to use Optimize but using a different CDN, hit us up at email@example.com.