Authoring-time VS Runtime

Runtime performance refers to the performance characteristics of the public-facing application - what visitors, customers, and search engines experience:

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

Authoring-time performance refers to the responsiveness of the editorial and administrative interfaces. Poor authoring-time performance reduces editorial efficiency and increases operational friction:

• 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

Although these two contexts share infrastructure, they are not optimized in the same way - and changes to one can degrade the other.

Response caching at the controller level reduces repeated rendering cost, but must only be applied to content that is identical for all users:

Fragment caching in Razor views is applied using the built-in <cache> tag helper, improving performance for shared components without affecting the entire page:

Serving static resources via a CDN significantly reduces origin load and latency for globally distributed audiences. Configure the client resource base path in appsettings.json:

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

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 simultaneously - a problem that spans both performance contexts.

Large hierarchical content structures increase load time in the editorial interface. Deep trees impact UI rendering and navigation speed. Best practices include:

• Avoiding more than 100 child nodes under a single parent (see the 100-item rule)
• Structuring content into logical segments with date or category buckets
• Archiving unused content to keep the active tree lean

Complex property types and heavy initialization logic inside content types can slow down the editing interface. Authoring performance is sensitive to what happens inside content type constructors and property getters. Developers should avoid:

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

Publishing triggers indexing, cache invalidation, and event pipelines. If event handlers perform expensive operations - external API calls, heavy recalculations - publishing latency increases directly for editors. Developers should:

• Keep publish event handlers lightweight and fast
• Offload heavy processing to background scheduled jobs
• Avoid synchronous remote calls during content save or publish events

Unoptimized media storage can slow media browsing in the CMS UI. Recommendations for large media repositories:

• Apply logical folder segmentation rather than flat directories
• Avoid extremely large flat media directories that require scrolling thousands of items
• Use structured naming conventions to aid search and navigation