Standard vs Shared Blocks
Outline
- 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 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
IContentinterface directly. They lack independent identifiers likeContentLinkorContentGuidunless cast at runtime. - Shared Lifecycle: The lifecycle of a local block is bound entirely to its parent page. It is stored, versioned, and published as part of the parent's data.
- Storage: Data is stored within the page's property blob in the database and is not accessible through the shared assets pane.
Technical Implementation
To define a local block, first create the block model, then add it as a typed property on the page. Note the use of AvailableInEditMode = false to prevent editors from creating standalone instances of this block in the assets pane.
Note: Setting AvailableInEditMode = false ensures this block type can only be used as a page property and cannot be independently created or placed in a ContentArea, facilitating better editorial 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 with their own lifecycle, permissions, and version history.
- Asset Tree Storage: They are organized in folders within the "Blocks" tab of the assets pane, browsable and manageable by editors.
-
Global Updates: Changes to a shared block instance are automatically reflected everywhere that instance is referenced, such as within a
ContentArea.
Implementation and Usage
Shared blocks are typically placed within a ContentArea, allowing editors to drag and drop instances from the asset library. Use [AllowedTypes] to restrict which block types editors can place in a given area.
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 rendering performance and database load on 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 - no additional database calls are required.
-
Shared Blocks: In a
ContentArea, each block is an independentIContentobject. The system must perform lookups, check permissions viaFilteredItems, and handle fragment caching for each item individually.
Database Impact
Frequent updates to a shared block create new versions in the database. If a shared block is referenced on 1,000 pages, a single content update affects all of them simultaneously - which is powerful for global changes but carries risk if applied carelessly. Conversely, local blocks increase the size of the parent page's data blob, which can impact performance if large numbers of properties are added to a single page type.
Pro tip: For high-traffic pages, prefer local blocks for structural layout elements. Reserve shared blocks for genuinely global content where propagation of a single change across many pages is the intended behavior.
5. Governance and Editorial Workflow
Maintaining a clean content model requires a strategic approach to block usage to prevent "content sprawl" in the asset tree.
-
Enforcing Structure: Use
[AllowedTypes]onContentAreaproperties to ensure editors can only place specific shared block types that fit the design intent of each area. - Preventing Sprawl: For simple, page-specific components like an "Author Signature" or "Footer Column," use local blocks. This prevents the shared assets tree from accumulating thousands of single-use blocks that editors must navigate around.
- Global Control: Use shared blocks for information that must be legally compliant or brand-consistent across the entire platform, such as "Global Footer Disclaimers" or regulatory notices that need a single source of truth.
Conclusion
Determining whether to implement a component as a local or shared block is a critical design decision 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, prioritize local blocks for structural schemas and reserve shared blocks for truly global, reusable elements - ensuring optimal rendering speed and a clean editorial experience.