Office 365 Site Performance
I had a colleague once that invested in old classic Mercedes and worked in his free time on replacing the old worn out parts with the new ones. New white leader seats, new bulbs, breaks, seat belts… After some time, we were talking about the car. I asked him about the color.
December 16, 2014
I had a colleague once that invested in old classic Mercedes and, in his free time, worked on replacing the old, worn-out parts with new ones. New white leather seats, new bulbs, breaks, seat belts, and more. When talking about the car with this friend, I asked him about the color.
That was already in place. The car got a double coat of Mercedes Diamond white, which matches the white leather seats and sheepskin. I asked him about the engine, and, it turns out, he had forgotten to invest in a new engine. He was aware that he needed one, but somehow, he'd forgotten to buy it. He forgot the engine! I was amazed at that.
Still today, I'm astonished by that fact. I just can’t grasp the logic behind it. I understand that appearance and looks are important—driving a Mercedes with top down through the town wouldn't be the same if it looked like a beater. But you can’t just forget the engine.
It's the same way with SharePoint and Office 365. It may look good, but don't forget about the 'engine', the driving force behind these services. I'll only be able to scratch the surface with this geeky stuff, so don’t worry—this is not going to be intense, in-depth information.
Getting Started
I got a new Office tenant, named Tough Cookie, and I created a brand new Publishing site and I opened it in Chrome browser.
Open Developer Tools with F12 or Ctrl+Shift+I.
Developer Tools in Chrome has two windows. The upper window has the panels Elements, Network, Sources, Timeline, Profiles, Resources, Audits, and Console. The lower window has the Console panel that shows JavaScript errors.
Network
The Network panel records information about timing data, HTTP request and response headers, cookies, WebSocket data that load on our page. I chose "Network" and refreshed the page.
The page loaded in 2 seconds. That doesn’t seem as a long time. It is an empty page with no web parts, no pictures, and no customizations. I don’t have the world’s fastest network. It is not the world’s slowest one either.
Insert figure 2
I clicked on toughcookie.sharepoint.com. The “Timing” tab show that more time is used on Blocking, Waiting, and Connecting than the time spent on Sending the request. Receiving is the time spent on receiving the response data, and it is a sum of all the above. Receiving takes less than a second.
Insert figure 3
Down in the bottom, I can see the link to OWA, link to Outlook.
Inser Figure 4
The size of the content is 2.2KB and it takes wobbling 5.3 minutes to execute.
The OWA request is not done after 5.3 minutes, the request is repeated and continues in the background for more than 8 minutes. I looked it up again - for more than 10 minutes.
Figure 5
It looks like the request is running in background as long as my page is open. What does it do? All I need there is a link to Outlook. Why is Outlook wasting my broadband width?
I clicked on one of the OWA events. Receiving took 5.3 minutes.
Figure 6
Audits
Audits panel analyzes and recommends actions for decreasing page load time and increase perceived (and real) responsiveness.
I chose "Audits" panel and clicked on the "Run" button.
Figure 7
After a few seconds, I got a report about "Network Utilization" and "Web Page Performance". Some of the findings are marked with red, some of them are marked with orange color.
Figure 8
Network Utilization report recommends:
Combining the external stylesheets and JavaScript files into as few files as possible. There are 22 separate JavaScript files from cdn.sharepoint.com. That’s a lot of JavaScript.
Figure 9
Enabling gzip compression would reduce the transfer size with around two thirds, around 67.4 KB.
Figure 10
3. Browser caching: It looks like a lot of images are explicitly non-cacheable.
Figure 11
I found the site icon, siteIcon.png in the Network panel and Cache max-age is set to 0.
Figure 12
Let's drill into the performance part.
The report says:
1. Move these .css files before external JavaScript files. That should be easy.
2. 40 inline scripts should be moved before .css file references. That should also be piece of cake
Figure 13
3. "Put CSS in the document head". What is CSS doing in the body anyway?
4. This one is the best one. This is only an "orange" warning and not a serious "red" problem as the previous ones. "Remove unused CSS rules (3614)".
Figure 14
Apparently, 93% of CSS is not used. I can click on "Network" tab and pinpoint the corev15.css that is barely used and layouts.css that is not used at all. They load fast, but they do take time to load. Most of the load time is spent on blocking and waiting. “Blocking” is the time the request spent waiting before it could be sent. “Waiting” is the time spent on a round trip to the server in addition to the time spent waiting for the server to deliver the response.
Figure 15
Timeline
The Timeline panel allows you to record and analyze each event that occurs. I recorded a page refresh, and I drilled down to load page events.
Figure 16
The thing that puzzled me was the yellow triangles next to the events
Figure 17
Yellow triangles are marking the “forced asynchronous layouts”. Events forced by the SharePoint. Events that can be a big performance bottleneck if they happen frequently or performed for large DOM tree.
Rendering
Lower window has a Rendering panel. I chose "Rendering" panel and clicked on "Show potential scroll bottlenecks"
Figure 18
The bottlenecks are marked on the page. The "repaints on scroll" is telling us that browser repaints logo when you scroll. Touch and mousewheel event listeners can delay scrolling.
Figure 19
Just about everything on the page is a bottleneck. Interesting.
Profiles
The Profiles panel shows execution time and memory usage on the page.
I chose "Profiles" and took a "Snapshot". I got an overview of functions and the time they take to load.
That is too geeky even for me, but it shows the code and how long does it take to load and execute the code.
Figure 20
In my opinion, in world of SharePoint and Office 365, the “engine” must be in place. I think that site performance and what happens backstage while the design, the suite bar, and site content is loaded is as important as the design and new features.
The site that I used as an example is a clean fresh site with no content, no web parts, and no custom code of any kind. I’m a geek. I’ve been doing audits on Office 365 from time to time in order to see if the continuous updates have changed what happens backstage. I haven’t seen the change until now. Unfortunately, I’ve only seen the changes in color coating and leather seats. Still waiting for someone to grease and tune the browser client-side engine.
About the Author
You May Also Like