Standard vs Shared Blocks

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

Average rating: 0 No reviews

Outline

At a glance

Storage logic: Local blocks live in the parent's property blob; shared blocks are independent IContent items.
Performance: Local blocks are lightweight; shared blocks require extra lookups and permission checks.
Lifecycle: Shared blocks offer independent versioning and global updates across multiple pages.
Best practice: Use local blocks for page-specific structure to prevent asset tree clutter and "content sprawl."

In Optimizely CMS 12, blocks are flexible content components that allow for modular page construction. While both "Standard" (local) and "Shared" blocks often utilize the same underlying BlockData class definitions, their storage architecture, lifecycle management, and performance characteristics differ significantly. Understanding these distinctions is vital for building scalable, high-performance PaaS solutions.

1. Local Blocks (Standard Blocks)

A local block is a block used as a direct property on a Page Type or another Block Type. It is technically a component of its parent container rather than an independent entity.

Architectural Characteristics

No IContent Implementation: Local blocks do not implement the IContent interface directly. They lack independent identifiers like ContentLink or ContentGuid unless cast at runtime.
Shared Lifecycle: The lifecycle of a local block is bound to its parent page. It is stored, versioned, and published as part of the page's data.
Storage: Data for local blocks is stored within the page's property blob in the database, meaning it is not accessible through the shared assets pane.

Technical Implementation Example

To define a local block, first create the block model, then add it as a property to a page.

// The Block Definition
[ContentType(DisplayName = "Contact Block", GUID = "...", AvailableInEditMode = false)]
public class ContactBlock : BlockData
{
    public virtual string Name { get; set; }
    public virtual string Email { get; set; }
}

// The Page Definition utilizing the block as a property
public class StandardPage : PageData
{
    [Display(Name = "Contact Person", GroupName = SystemTabNames.Content)]
    public virtual ContactBlock ContactInfo { get; set; }
}

Important note

In the example above, AvailableInEditMode = false ensures this block is only used as a property and cannot be created as a standalone shared instance, facilitating better governance.

2. Shared Blocks

Shared blocks are independent content items that exist in the CMS assets tree. They are designed for high reusability across multiple pages and sites.

Architectural Characteristics

Independent IContent: Shared blocks are full-fledged content items. They have their own lifecycle, permissions, and versions.
Asset Tree Storage: They are organized in folders within the "Blocks" tab of the assets pane.
Global Updates: Changes to a shared block instance are automatically reflected everywhere that instance is referenced (e.g., within a ContentArea).

Implementation and Usage

Shared blocks are typically utilized within a ContentArea, allowing editors to drag and drop instances from the asset library.

public class StandardPage : PageData
{
    [AllowedTypes(typeof(TeaserBlock))]
    public virtual ContentArea MainContent { get; set; }
}

3. Comparative Matrix: Local vs. Shared

Aspect	Local Blocks (Property)	Shared Blocks (IContent)
Reusability	None (Single page use)	High (Cross-page/Cross-site)
Versioning	Tied to parent page	Independent version history
Permissions	Inherited from parent	Independent access control
Storage	Embedded in property blob	Independent database entry
Rendering	Lightweight (Direct access)	Heavier (ContentArea initialization)

4. Performance and Scalability Considerations

The choice between local and shared blocks directly impacts the rendering performance and database load of an Optimizely CMS 12 PaaS instance.

Rendering Overhead

Local Blocks: Rendering a local block property is computationally inexpensive because the data is already loaded along with the parent page.
Shared Blocks: In a ContentArea, each block is an independent IContent object. The system must perform lookups, check permissions (via FilteredItems), and handle fragment caching for each item.

Database Impact

Frequent updates to a shared block create new versions in the database. If a shared block is included on 1,000 pages, a single update affects all of them simultaneously. Conversely, local blocks increase the size of the parent page's data blob, which can impact performance if hundreds of properties are added.

5. Governance and Editorial Workflow

Maintaining a clean content model requires a strategic approach to block usage to prevent "content sprawl."

Enforcing Structure: Use [AllowedTypes] on ContentArea properties to ensure editors can only provide specific shared blocks that fit the design intent.
Preventing Sprawl: For simple, page-specific components like an "Author Signature" or "Footer Column," use local blocks. This prevents the shared assets tree from becoming cluttered with thousands of single-use blocks.
Global Control: Use shared blocks for information that must be legally compliant or brand-consistent across the entire platform, such as "Global Footer Disclaimers."

Conclusion

Determining whether to implement a component as a local or shared block is a critical design step in Optimizely CMS 12. Local blocks provide simplicity and performance for page-specific content, while shared blocks offer the reusability and independent lifecycle management required for enterprise-scale operations. For high-performance PaaS environments, developers should prioritize local blocks for structural schemas and reserved shared blocks for truly global, reusable elements to ensure optimal rendering speed and a clean editorial experience.