Intro: This post shares how and why you might like to introduce a YML linter into the build process for your next Sitecore JSS project. Particularly if you are relying on the YML import process when building a new application. Shout out to David Huby (Solutions Architect) for introducing team Aceik to yaml-lint.
Why would you want to do this on a JSS project?
When running the JSS application and testing latest changes, we sometimes discovered some strange behaviour with dictionary items, or a page might not load properly.
This can be caused by a small (incorrect) change in YML breaking individual routes. For example, lets say you have an incorrect tab or character in the wrong place. The YML syntax requires correct spacing and line returns to be valid but this is not always so obvious when done incorrectly. Sometimes only after you run the JSS application and test out the changes do you discover some strange behaviours or the page not loading properly.
To avoid this we found it handy to introduce a YML linter into the JSS build process. This solves the issue of someone making a small change to the YML files and breaking individual routes.
Here are the steps needed to introduce a YML linter into a node-based JSS project:
In part 1 of this Sitecore page speed blog, we covered off:
The Google Page Speed Insights tool.
We looked at a node tool called critical that could generate above the fold (critical viewport) CSS code that is minified.
We referenced the way in which Google recommends deferring CSS loading.
In this second part of the Sitecore Page Speed series, I am going to cover off how I would go about achieving this in my Sitecore layout.
Before we dive in I have committed the sample code for this blog into a fork of the helix habitat example project. You can find the sample here. For a direct comparison of changes made to achieve these page load enhancements, view a side by side comparison here.
For each page that you want to render above the fold CSS we take the minimised code (we generated in the first blog) and put it on the page within the CMS.
Inside the CMS we also create some new renderings in the common project.
These renderings are used in the default.cshtml layout.
They point to the CSS rendering code.
This wrapping technique provides the ability to cache the rendering so that the code in RenderAssetsService.cs does not need to be executed on every single page load.
Take note of the IDs of each rendering you will need to copy them over to the CachedRendering IDs shown in step 3 below.
Update the default.cshtml layout with two key renderings.
One in the <head> tag that points to /Views/Common/Assets/InlineStyles.cshtml
StylesDeferred.cshtml contains logic that will check for inline CSS on every page. If the page contains Inline CSS then the main CSS files will have their network download deferred until later. On the other hand, if the page does not contain any inline CSS then the main CSS files will be loaded as blocking assets. Doing so ensures that the page displays normally in both situations.
The cacheKey variable passed to our CachedRendering is simply something to identify the page as unique. You could use the Sitecore context item ID or path for example.
If done correctly you should end up with pages that look normal even with the main CSS files deleted (only do this as a test). The CSS will no longer load via another network that blocks the page and your Google Page Speed rank should recieve a boost.