Wherein we discuss the burdens of loading SharePoint site pages, and the third-party Intranet-in-a-box vendors who have found innovative solutions to the slowness.
A few years ago, Microsoft rolled out the Modern Experience of SharePoint Online to coexist with the Classic Experience. Modern sites (Communication Sites and Team Sites) are designed to be much more visually appealing, fully responsive and mobile-first. The UI is a near-rewrite from the ground up, as the Classic pages evolved over years to become a bit of a Frankenstein's monster under the hood. Since most of the logic on Modern pages takes place on the client side, and the look and feel has been streamlined to account for thousands of tenants being hosted on shared hardware, the pages are leaner. They should load faster on all devices.
That was the theory, anyway. Any Office 365 partner or user will tell you that SharePoint Online is still quite slow — especially using the measure known as User-Perceived Latency.
If end users perceive the pages as slow to load (especially compared to well-known public properties like Google or Facebook, which are massively cached for performance), they will complain. And possibly abandon (or refuse to start using) your intranet.
There are things you can do to tune your SharePoint Online page performance, including caching, optimizing the portions of the network journey that are in your power to optimize, and deploying artifacts to Content Delivery Networks. However, since Microsoft fully controls the hardware and the software, there is only so far you can go; like a guest of a hotel, you are somewhat at the host's mercy.
Tool: Microsoft Page Diagnostics for SharePoint Online (https://docs.microsoft.com/en-us/office365/enterprise/page-diagnostics-for-spo)
SharePoint Online and Office 365 are very much "one size fits all", and do not claim to be otherwise. Microsoft has always pursued the strategy of laying down a broad framework on which its rich partner ecosystem and customer base can build tailored solutions to close requirements gaps.
Much of this blog series will discuss the third-party accelerators known as "Intranets-in-a-box." There are thirty or forty companies out there that have come forward with turnkey solutions to close the Office 365/SharePoint Online requirements gaps. Though Modern SharePoint comes with site templates, lists and prefab web parts, these are very much a starter kit. I can think of no size of deployment in the real world that would not require at least a few custom features, whether they are created with PowerApps and Flow or the SharePoint Framework (web parts and application extensions).
Slater Hill has had experience deploying and extending several different "Intranet-in-a-box" (IiiB) products: Live Tiles, Powell 365 and Valo Intranet, most recently. As of late have now added Swedish offering Omnia Intranet to that list, and our consultants/developers have also had exposure to the popular Unily product.
Along the way, we have noticed that all IiiB vendors have a major design decision to make up front:
1. to apply their templates, web parts and other custom bits within the existing SharePoint page infrastructure; or
2. to use SharePoint essentially as a data store, and architect their own user interface from scratch. This is the decision we call "to re-UI or not to re-UI", and the re-UI camp has various platforms, such as ASP.NET and NodeJS (among many others), at its disposal.
Valo Intranet and Powell 365 (with its flagship product) fall into the "not to re-UI" camp, and when you view the pages of their solution you are browsing native SharePoint screens. Omnia and Unily, on the other hand (and now Powell 365 with its new Hub offering) have chosen to roll their own front ends.
