31 07 2013
Anatomy of Office 365 public blog
As I found no easy ways how to make public blog on Office 365 more user and SEO friendly I tried to find other and more technical ways how to accomplish problems. Although it seems like there is not much to do about usability I still found some interesting details about technical side of public blog. Let’s dig deeper.
I just wanted… to make some minor modifications to how my blog is shown to visitors plus some SEO improvements but I discovered whole new world of unexpected mysteries that are still interesting enough to blog about. My main goal was making post lists show only first paragraph of posts but it turned out to be mission impossible.
Anatomy of blog front page
As blog on public site doesn’t live in separate web it maybe interesting to find out how it is implemented. But first let’s edit blog front page in browser:
If you click on image and see it at original size you can see two web part areas – left column and right column. All visible blocks on page are actually web parts. This holds true also for other blog pages (in red boxes on following screenshot):
So, we have pages with web parts and some URL rewriting here. All these pieces come together on web part level as I think but let’s go further and see what kind of disaster is waiting for us by default.
With only some small content available in blog (about 4 short posts that are fully loaded to main page) we get the size of first request 517KB. There’s 28 requests (one to image in blog post) and page loading time is almost 6 seconds. It’s not normal result on 30 megas download speed and fast quad-core CPU.
This disaster is comes with client-side rendering and this is because the front page of my blog is huge and slow.
What is alternative to client-side rendering?
The alternative to client-side rendering is server-side rendering. We can easily switch web parts to server-side rendering by using web part properties but then we fallt o bad and nasty trap – forced defaults we cannot change. Let’s move to server-side rendering and see what’s happening.
Okay, we have a little bit different layout – it’s default one you see in SharePoint – and it’s just shown on our nice layout. Not just what we need.
The post list web part is XsltListViewWebPart and this web part in normal cases supports two sets of XSL-transformations:
- ones defined by web part,
- ones defined by view that web part uses.
I went through the following steps:
- Copied default XSL for web part to separate XSL-file.
- Made some modifications to make sure that my XSL is used.
- Uploaded my XSL-file to SharePoint site.
- Set posts web part XSL-file property to point to my new XSL-file.
- Saved everything.
And guess what? No result. Fancy thing is that when I open web part properties I see this kind of URL there:
Full location is:
Well… whatever we say in web part settings we always get this location for XSL-file. There’s no way to use your own XSL as I found out.
In this point I made new support ticket to Office 365 support to find out what the hell is going on and why I cannot tune my blog to be optimized better. Not being able to control the output makes Office 365 blogs almost unusable for professional bloggers who must work in context of business blogging when different rules apply. After all these struggles I decided to write one negative point to Office 365 public blogs as they are not able to compete with other paid blogging services.