Lots of personal development as well as work for our clients lately. Big projects are being rolled out.
One of the ones that we’ve done is an information architecture review of Practice Tree Online.
This just means that we have been evaluating how the information on the site is navigated to. Seems fairly simple for a web application but it is amazing when you discover that you’ve had things wrong.
When new visitors to the app or site don’t know what to do – you’ve got a communication problem. And much of what you are communicating can be revealed in how your navigation is formated and how you drive people to the content you want them to see.
We’ve taken this very seriously and while the net result may not be impressive – the effort to get there is non-trivial.
We’re not going to go over all that has happened but many times things like card-sorts and user experience testing is done to capture this information.
This isn’t really supposed to be web development 101 but it is boiling down to it, isn’t it? We started out with dead simple DOM (our html markup) and now we are adding to it.
The point is that we have some good speeds right now, but we don’t have any utility. We don’t have any functionality. So the speed is worthless. What we really want is to have high speed AND utility, functionality and reliability.
So let’s get our branding on this relatively blank canvas as well as some text.
Adding a GIF image to the top and increasing our DOM elements by double (from 8 to 16) we still have a pretty speedy page.
- Load Time: 0.439s
- TTFB (First Byte): 0.153s
- Start Render: 0.394s
- Speed Index: 396
Pretty decent. But we really only have one image, and no conveyence of our purpose for existing. Haha. We better continue adding our core elements of purpose (utility, functionality and reliability)
I was looking at what was causing the slow down, and it was the favicon.
I hadn’t defined its location, name or anything about it and the results were going out and looking for it on its own. And including it in the test.
I moved it off to a CloudFront CDN and made both the .ico and .png versions available using the CDN, and then also put in a “dns-prefetch” link so that it can resolve that CDN as quickly as possible and our TTFB went down by a single MS. No big deal.
But at least the favicon (which is typically called upon by the browser AFTER the page is loaded) won’t get in the way of our tests.
I moved the blog to a sub directory and sure enough – huge gains!
The problem is – the new landing page doesn’t have anything on it. So this is a worthless test. But it does show us how minimal we CAN be.
- Load Time: 0.255s
- TTFB (First Byte): 0.151s
- Start Render: 0.389s
- Speed Index: 389
Super fast and gets us an “A” in the TTFB rating.
But I wonder if we can do better…
To begin, we are going to use the metrics highlighted on WebPageTest.org.
Running a test there, we see a few things that stand out:
- Load Time: 4.438s
- TTFB (First Byte): 0.968s
- Start Render: 2.589s
- Speed Index: 2636
Total weight of the page was 0.99 Megs; which makes the home page actually pretty expensive as far as downloading on a mobile device.
Luckily our hosting provider has done somethings to help our performance out of the box. They have allowed keep-alive and compress files for transfer. This is good. It gives us a few “A”s.
Clearly we have our work cut out for us as far as time to first byte. Let’s start there.
I spent some time yesterday formulating a plan and today marks the beginning of the engagement.
I’m moving the blog to a subdirectory of the website because we are going to be doing some experiments related to performance tuning and the first step is to baseline with static files. Our WP site has some backend processing when it loads which makes it a bad candidate to have as our landing home page.
The plan is to journal through this process so that wherever we end up, we have a repeatable path and have a proven plan for success as well as lessons learned. So over the next few days, the site is likely going to be a little wonky. Bear with me …
Taking WordPress Custom Taxonomies to the Next Level | Wptuts+.
This is a great post. Over a year old, I know – but I found it helpful today. Consider it a great archive of how this works in WordPress!
Huge attack on WordPress sites could spawn never-before-seen super botnet | Ars Technica.
I think it is worthwhile to review your security risk mitigation plans and consider updating all passwords on your WP installation given that all of our wordpress sites are currently, or will in the future, be under attack.