Authoring-time VS Runtime

By Optimizely Education
Published: Feb 14, 2026
Rating 1 star 2 stars 3 stars 4 stars 5 stars

Average rating: 0 No reviews

Outline

At a glance

Runtime performance = public site speed (rendering, APIs, caching, CDN, DB access).
Authoring-time performance = CMS UI + workflows (tree browsing, edit mode, publish latency, indexing).
Shared infrastructure means changes can help one side while hurting the other (cache freshness vs speed).
Best outcome comes from selective caching + lightweight publishing pipelines + measurable editorial UX.

Introduction

Performance in Optimizely CMS 12 (PaaS) must be evaluated from two distinct but interconnected perspectives: authoring-time performance and runtime performance. Developers new to the platform often focus primarily on frontend load times and caching strategies. However, in enterprise CMS environments, performance must also account for editorial workflows, content indexing, search operations, and administrative responsiveness.

This article explores the conceptual and technical differences between authoring-time and runtime performance in CMS 12, how architectural decisions impact both, and how developers can design solutions that balance editorial productivity with end-user speed.

Understanding the two performance contexts

Runtime performance

Runtime performance refers to the performance characteristics of the public-facing application. This includes:

Page rendering speed
API response times
CDN delivery latency
Caching effectiveness
Database access patterns

Runtime performance directly affects visitors, customers, and search engine indexing.

Authoring-time performance

Authoring-time performance refers to the responsiveness and scalability of the editorial and administrative interfaces. This includes:

Page tree loading in the CMS UI
Block and media library browsing
Content save and publish operations
Search and indexing inside the CMS
Property rendering in edit mode

Poor authoring-time performance reduces editorial efficiency and increases operational friction.

Although these two contexts share infrastructure, they are not optimized in the same way.

Runtime performance considerations

Runtime performance in CMS 12 is influenced by rendering logic, caching configuration, and resource delivery strategies.

1. Caching and output strategy

Runtime optimization frequently relies on fragment caching and response caching. The ASP.NET Core response caching model is supported in CMS 12.

Example of response caching in a controller:

[ResponseCache(Duration = 60, Location = ResponseCacheLocation.Any)]
public IActionResult Index()
{
    return View();
}

This reduces repeated rendering cost but must only be used for content that is identical for all users.

Fragment caching in Razor views can be applied using the built-in cache tag helper:

<cache expires-after="00:10:00">
    @await Html.PartialAsync("_Menu")
</cache>

Fragment caching improves performance for shared components without affecting the entire page.

2. CDN integration

Runtime performance significantly improves when static resources are served via a CDN.

Client resource configuration example in appsettings.json:

{
  "EPiServer": {
    "Cms": {
      "ClientResources": {
        "BasePath": "https://yourcdn.example.com"
      }
    }
  }
}

CDNs reduce origin load and latency for globally distributed audiences.

3. Database and content retrieval

Optimizely CMS uses an internal object cache to reduce database calls for content retrieval. However, inefficient querying patterns or unnecessary repository calls can still degrade runtime performance.

Developers should:

Avoid excessive recursive content loading
Limit dynamic queries during rendering
Prefer strongly typed content models over dynamic lookups

4. Search and indexing impact

Large sites relying heavily on search or filtering must consider indexing overhead and query performance. Improper indexing strategies can impact both runtime response times and editorial indexing delays.

Authoring-time performance considerations

Authoring-time performance is frequently overlooked but becomes critical in enterprise deployments.

1. Content tree and structure

Large hierarchical content structures increase load time in the editorial interface.

Best practices include:

Avoiding excessive child nodes under a single parent
Structuring content into logical segments
Archiving unused content

Deep trees impact UI rendering and navigation speed.

2. Property complexity in edit mode

Complex property types and heavy initialization logic inside content types can slow down the editing interface.

Developers should avoid:

Executing heavy service calls during property rendering
Performing runtime queries inside custom editor descriptors
Adding unnecessary metadata calculations in edit mode

Authoring performance is sensitive to what happens inside content type constructors and property getters.

3. Publishing and event handling

Publishing triggers indexing, cache invalidation, and event pipelines.

If event handlers perform expensive operations (external API calls, heavy recalculations), publishing latency increases.

Developers should:

Keep publish event handlers lightweight
Offload heavy processing to background jobs
Avoid synchronous remote calls during content save

4. Large media libraries

Unoptimized media storage can slow media browsing in the CMS UI.

Performance recommendations for large media repositories include:

Logical folder segmentation
Avoiding extremely large flat media directories
Using structured naming conventions

Shared infrastructure considerations

Both authoring and runtime performance share infrastructure components:

Application instances
Database
Search indexing
Distributed cache

Optimizations applied for runtime can negatively impact authoring if not carefully designed. For example:

Aggressive response caching may prevent editors from seeing updated content.
Heavy CDN caching without proper invalidation can delay visibility of published updates.

Therefore, performance strategies must be environment-aware.

Release and platform improvements (PaaS context)

Recent CMS 12 PaaS releases emphasize performance, stability, and infrastructure improvements. Platform updates frequently include enhancements in:

Indexing performance
Background processing stability
CMS UI responsiveness
Resource handling efficiency

Developers should monitor release notes and platform updates, as improvements at the infrastructure level can significantly affect both authoring and runtime experiences without code changes.

Balancing authoring and runtime optimization

A mature CMS solution does not optimize for one context at the expense of the other.

Developers should:

Separate editorial and public traffic patterns
Use selective caching rather than blanket caching
Ensure publish workflows trigger appropriate cache invalidation
Measure editorial UI performance during load testing

Performance should be evaluated under both visitor load and editorial activity.

Conclusion

Authoring-time and runtime performance are distinct but interconnected dimensions of performance in Optimizely CMS 12 (PaaS).

Runtime performance focuses on rendering speed, caching efficiency, and CDN distribution. Authoring-time performance focuses on CMS UI responsiveness, publishing latency, indexing efficiency, and editorial workflows.

Effective optimization requires understanding how caching, indexing, event handling, and infrastructure configuration influence both contexts. By designing solutions that respect editorial workflows while maximizing delivery performance, developers can build scalable, maintainable CMS 12 solutions suitable for enterprise environments.