Are you following best practices in your Sitecore SXA implementation? If not, there can be consequences down the road in the form of technical debt or a full re-implementation down the road sooner than expected if the best practices were never adhered to in the beginning of development. A Sitecore SXA audit is the way to go up front, during, and after your implementation to ensure that your Sitecore SXA development team are giving you the most robust implementation that will stand the test of time with upgrades to SXA and Sitecore while providing your Content Authors the flexibility they need to author content.
Preparing for a Sitecore SXA audit can help you to examine the current architecture for your client, then compare to the best practices recommended by the Sitecore SXA Team, then make recommendations based on your findings. These findings can, and should, steer development efforts after going through your audit. If there is a commitment to adhere to best practices, based on the audit, then there may be low – high impact to your solution and Sitecore architecture based on the technical debt accumulated over SXA development efforts in the past.
Below in each of the recommended practices, I will provide my thoughts on what may be necessary to bring the solution and Sitecore architecture to be in line with Sitecore SXA best practices before, during, and post development.
These best practices came from the SXA Team via an SXA Recommended Practices document that was put together awhile back by Adam Najmanowicz. This original documentation was used as the basis for the documentation that is in place now as official Sitecore documentation on SXA recommended practices. Big ups to Adam for putting that initial documentation together that we can use today as a baseline for a solid SXA implementation for clients!
Page Structure
-
Design page layout in Partial Designs
Partial designs will be your best friend with SXA along with Page Designs. Just think of a partial design as the old Standard Values for Page Types. You will use Partial Designs and then use them with Page Designs to create your pages. Using Standard Values is not recommended so you will need to get out of that thinking. Standard Values will still work, but it’s NOT considered best practice.
Partial Designs Folder
If you revert to this best practice down the road you are looking at medium level of rework but high level of regression testing.
-
Put complex reusable structures in Partial Designs or composite components
The point of SXA is to make your life easier not harder so put complex reusable into composite renderings like SXA has Carousel, Accordion, and Tabs out of the box. Those are typically complex components so if you have one that you are set to create then put it into a composite component like a Snippet, which has many components in one. These are things you will want to teach your developers as you build your SXA site out to be aware of. Snippets are very powerful so use them!
-
Remove unnecessary components from your site’s “Available renderings” to allow usage of styled components only
This is basically to only show what your Content Editors will actually use, that of which is styled and looking good. If it’s not pull it out so nobody uses it. Be kind to your Content Authors.
Available Renderings Folder
There is no real impact on what has already been done here so low level of rework here.
-
Set up placeholder restrictions
This is so you can stop your Content Authors from inserting a component into a placeholder that they shouldn’t causing confusion and introducing possible bugs when the component should never have even been allowed in the first place.
Placeholder Settings Folder
Your Content Authors will love you for helping them help themselves and is low effort to fix.
-
Do not use Standard Values to set up presentation details on your pages
As I stated earlier, use Partial designs instead or possibly Snippets. Standard Values are a thing of the past with SXA.
If you revert to this best practice down the road you are looking at medium level of rework but high level of regression testing.
-
Make use of Partial Design inheritance where it makes sense
This should be thought out up front BEFORE development as changing this down the road can be erroneous and lead to data loss if you try to inherit from base partial designs post-development.
Base Partial Design Inheritance on Partial Design Item
If you revert to this best practice down the road you are looking at medium level of rework but high level of regression testing.
-
Prioritize setting component size directly on the component over using splitters
This is more of a Content Author activity that can enhance the speed of the Experience Editor. Ensure that the Content Authors know this approach and the Front-End developers can account for this in CSS/JS and such. No need to change anything here, but good to know as a best practice.
Component Sizing
Use of Renderings
-
Use proper renderings for the job
This should be thought out up front with your developers on how best to put together the component in question. A lot of the times the OOTB components can work for a lot of the needs. When there is a one-off then clone a very similar OOTB component and extend it for your needs. With that being said, though shalt not clone everything and make everything custom in my honest opinion. Take a hard look at the OOTB componets and see if you can get what you need accomplished with OOTB components and/or a Rendering Variant and then if you can’t make it happen ONLY then go custom with cloning. There is not a need to refactor every single rendering down the road as that would be a high level of effort, but do adjust to this best practice by knowing it up front and preach it to your SXA Development Team.
SXA Out of the Box Examples
-
Use Snippet rendering to prepare sets of components
Snippets are able to house multiple components essentially so if you have pages that use the same set of components then consider using a Snippet. The same snippet can be used with many different pages and all point the same datasource so changing the original Snippet will change them for all referencing that datasource.
Snippet Component
There is no hard and fast rule on this one I think, it’s based on the project, but if you do go down this path later to use as a best practice it can be a medium level of effort with high regression testing.
-
Do not use Plain HTML component for content that is edited by Authors
This is almost always a bad idea unless truly warranted. Don’t let the Content Author have the whole rope, they may hang themselves. Hence, think about if there is a better alternative that will restrict them a little the help them from frustration and mistakes.
Plain HTML and Plain HTML (Reusable)
Modifying this down the road to refactor open components like this would be a low level of effort with better results for Content Authors.
-
Rich Text field content should be fully editable using the Design view
This one is great and is a great bang for your buck with your Content Authors, which is giving them the ability to choose a CSS class from within the Rich Text Editor keeping them from using the HTML tab to have to add in a CSS class in the other interface.
Rich Text Editor using Class Drop-Down
This is very low effort to implement to help out your Content Authors. Here is a link to instructions on how easy it is to Add Custom Classes to the Rich Text Editor.
-
Provide previews for rendering variants
This is subject to opinion, but I am firm proponent of all preview images that help the Content Authors make their job easier, and a picture is worth a thousand words! The ability for the Author to see what it is that they are about to add as a component leads to less confusion and can go a long way in keeping our Content Authors, who are our end user as a developer, very happy!
This is considered low-moderate effort to go back and do but is well worth it!
Proper use of Rendering Variants
-
Limit the number of rendering variants to 15 (preferably below 10)
This is going to be a task you will want to work with at the beginning of development of the components at hand to ensure you DO have some variants, but don’t overdo it. But DO make sure to give meaningful names to your variants when you have many. Make it easy for your Content Authors to understand what the variant is directly from the drop-down in the Experience Editor!
Development
-
Never put any custom items in SXA controlled branches of the tree
This is simple, never do it, and preach it to your SXA development team! During your PR reviews ensure that this violation is not happening, otherwise your SXA components will be defaulted back to the original state and/or worse your SXA instance is broken.
Experience Accelerator Folders
This is a must do item in any SXA audit and is moderate effort that can lead to high effort to rectify so best to adhere to and have knowledge of from day 1!
-
Do not modify the OOBT SXA items
This is simple, never do it, and preach it to your SXA development team! During your PR reviews ensure that this violation is not happening, otherwise your SXA components will be defaulted back to the original state and/or worse your SXA instance is broken.
Experience Accelerator Folders
This is a must do item in any SXA audit and is moderate effort that can lead to high effort to rectify so best to adhere to and have knowledge of from day 1!
-
Do not replace the SXA “MVC Layout” with a custom implementation
This is directly from the words of the SXA Team, “By replacing the layout with your custom implementation, you risk losing compatibility with future versions of SXA thus increasing the maintenance cost for the site owner in the future considerably.”
SXA MVC Layout
Hence, heed the warning, and to go back and fix this would be in my opinion high effort in regression testing every component that would now go back to using the default version.
-
Create an SXA module for your components
For simplicity’s sake this will aid in adding in custom components via an SXA module, and will help with new sites / tenants. May be on a case by case basis depending on your implementation but keep in mind that if you choose to go down a custom path for a component then this would be considered a best practice.
Adding a Site Module
This is considered low effort, but will help with future tenant / site implementations.
-
Follow Helix principles when adding functionality to your solution
Make no mistake about it, SXA follows the Helix Patterns, Principles, and Conventions, and your development team should as well in working with SXA. When working inside Sitecore, ensure you are following Helix by creating sibling folders to the Experience Accelerator folders. If you have never worked before with Helix this is your opportunity to see exactly how Helix is used widely in the Sitecore architecture as well as in the solution. You can even gain an immense amount of knowledge from reflecting on the .dll’s with DotPeek or .NET Reflector to see what’s going on under the covers! Learn from those at the SXA Team that have come before you, and adhere. SXA is built to take full advantage of Helix!
-
Consider using existing renderings before building a new one
This is not only a recommendation, but it should be a standard practice for an SXA Development Team to sit down with the Architect, or the Architect to provide guidance on the “how to” build for the component. One of the major benefits of SXA is that you have out-of-the-box components that truly are good enough to get a lot of what you need done. Hence, ALWAYS consider using the OOTB components versus reinventing the wheel. It will save you time and the client money. Once they are built, they are now Technical Debt if you come to find out later that you could have used an OOTB component for what you built a custom component for so be diligent in these efforts and put this down as a sub-task on the User Story to research the OOTB component to see if it will work for your component requirements unless your Architect had the time to give the direction and/or component stubbed out ahead of time to make that decision for you. Rendering Variants and Snippets are your best friend!
SXA Out of the Box Examples
-
Consider cloning existing renderings before building a new one
If you MUST go custom for your component, choose the component that is closest to yours and clone it. Cloning is the way to go always, as this will do everything behind the scenes for you. You CAN do this via reflection using your favorite tool, but it is considered a best practice to use the cloning feature provided by SXA.
-
Limit scope of fields linking to items
One of the coolest features that you can take advantage of with SXA are the tokens that limit the scope of items that Content Authors can choose. You can use these tokens in most data source fields and they are powerful to help you give the best experience to your Content Authors to place them in the correct folder the minute they attempt to choose any data source for the component!
Examples of SXA Tokens in Datasource Fields
To fix this is considered low effort for a big win with Content Authors!
Theming
-
Do not modify platform themes
This is simple, never do it, and preach it to your SXA development team! During your PR reviews ensure that this violation is not happening, otherwise your SXA components will be defaulted back to the original state and/or worse your SXA instance is broken. This is a must do item in any SXA audit and is moderate effort that can lead to high effort to rectify so best to adhere to and have knowledge of from day 1!
-
Assign custom styles to components
This is similar to setting up Allowed Renderings or for only Allowed Components to use a Placeholder. With SXA you can setup a Style to only be used with certain components, otherwise it will be available to all components (which is a no-go). You definitely don’t want Content Authors to use a style that is NOT made for their components leading to a bug, confusion, etc. so make sure to set this and have your FE Team aware of this. Going back to do this would be a low effort, but is definitely worth it in terms of less bugs, questions, and Content Author happiness.
-
Clean your styles folder of unused styles
Simply stated this cleans up unused styles and is another big win for your Content Authors so use it, so the Content Author happiness remains in bliss. This is extremely low effort at any time.
-
Place your style items in sub-folders of your site’s Styles folder
Honestly, what can be easier than this? SXA even organizing things for you, awesome! You can simply click on “Organize Styles” button and it takes care of everything! Yes, use it for Content Author bliss. This is extremely low effort at any time.
Data sources and media
-
Don’t put media items directly under the site’s Media folder
Here is what is also nice about SXA is that your Media folder is in the main content tree available at any time for your given site. It has it’s own set of folders to be used and those are expected to be used by SXA, not the typical folders you can use in a traditional Sitecore implementation. Use them, they are there to make your life during development easier, as well as the Content Author’s life easier as well. Fixing this if it hasn’t been done is low effort, but definitely should be done as an SXA best practice.
Media Folder in SXA Site
-
Give site data sources meaningful names
If you have a multi-site implementation for SXA, then make sure to enforce a “meaningful name” convention policy with your Content Authoring team so they can adopt best practices for Content Authoring when data sources are shared across sites. This is a best practice overall in my honest opinion, both locally at the page level as well as shared, but most definitely at the shared level. A data source that says, “FAQ Accordion for 2019” is much more valuable than “Accordion 1” that nobody has a clue what is in it until they open it, and start looking through the item details. Set this standard at the Content Governance level with the Content Authoring team early. Depending on how many data sources there are in shared, this can be low – moderate effort to change all the names, but is definitely worth it for Content Author bliss.
-
Organize site data sources in folders
This is very similar to organizing your styles to keep things nice and tidy for Content Authors. Again, if you think of your Content Authors as your end user, you will succeed in your Sitecore efforts most, if not all, of the time. This is extremely low effort at any time.
-
Clean up unused site data sources
This is made simple with the Cleanup Data Folder script provided by SXA. Use it to ensure that your Content Authors are not selecting unused data sources by accident, that are no longer valid, etc. in your shared site Data folder. This is extremely low effort at any time.
SXA Data Folder Cleanup
Multisite & content sharing
-
Consider using Shared site as the exclusive style container in a tenant
Nobody likes duplication so when you are in a multi-site SXA implementation be sure to remove styles from other sites, and use the shared site styles so there is no duplication in the Styles section of your components. If you need to do this after an SXA site is up, but this hasn’t been done, I would work with your FE team to first Cleanup the Styles, then start removing. This would be considered low-moderate effort after setup, so best to think about up front during SXA implementation.
-
Consider defining your rendering variants in the shared site and remove their redundant versions from the local sites.
This is definitely considered in my opinion a definite to-do when using multi-site. I have seen the duplicates in the Experience Editor, and leads to confusion and can be considered a bug. This is low-moderate effort to fix, but should definitely be a top priority!
-
Consider using delegated areas for pages that share content across multiple sites
This is considered a best practice, and is very similar to the cloning in traditional Sitecore development initiatives. A great example is blogs. Modify a blog post in your main delegated area, and it propagates to all the sites that are using it. Very effective for content used across multiple sites. To do this after an SXA implementation is setup you I would consider this low-moderate effort based on the content and how many sites are going to reuse the content.
-
Consider creation of blueprint/master site to be cloned for roll out to new markets
This is considered a best practice when starting up new sites, and seems like a dream, but is achievable after you have your components and architecture in place in one site. you can then clone it, and you have a site setup with all the basics. Think about this when you know that you will be bringing in other sites / tenants to make life easy!
-
Consider defining your Page Designs and Partial design in the shared site and reuse them in other sites in a tenant
This is definitely a best practice when you know you can use your Page Designs and Partial Designs across sites. Make use of this as it will help with the next site you build out so you can reuse instead of reinvent the wheel. You can move your Page Designs and Partial Designs to your shared site later, but you will need to regression test all the pages and components after doing this just to ensure all is working correctly as intended, so I would consider this a high amount of effort. Think of this up front when you know you are bringing on a new site / tenant.
Language & Globalization
-
Always configure and create items in the language of the content
Simply stated above. Even if you create the site in a single language it’s considered a best practice.
Performance
-
Limit the number of components directly on a page to under 30
Too many components will contribute to slow Experience Editor issues so the recommendation is to put common elements in the Partial Designs so they are not directly design-able. Well, in order to do this after an SXA site is up I would consider this to be moderate effort to analyze those common elements, and then get them into Partial Designs.
-
Disable Content Testing for editors that do not require the functionality
Speed up time in the Experience Editor! No brainer here. This is extremely low effort at any time.
-
Consider configuring HTML Caching settings for components
Truly this should be considered across the board with your components along. Caching can really help out with performance optimization, and SXA provides 4 different ways of caching. Use them up front during architecture setup, and component development as well. To enable after an SXA site implementation is considered low effort, but is a “must-do” in my opinion.
-
Verify that Asset optimizer is enabled for your site
This is recommended to be enabled and used in Production, and while I can’t verify the performance increase gained by the usage, I would recommend as well and is considered a low amount of effort for a good gain in performance with concatenation of files into one asset and caching.
To summarize, you have things to think about up front with your SXA implementation/s. Think early, and often when working with SXA about best practices as their is an adherence with SXA that ensures that you will have a successful implementation each and every time, maintain that SXA implementation all the while making your Content Authors excited to work with SXA. Happy SXA’ing Sitecore community!
Sitecore Sandbox 