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.
There have been so many websites that we have been working on lately that it seems we haven’t had any time to write or update our own. Here are some client websites we have had the privilege to help out recently:
It has been a great summer – thanks to all who have helped support these efforts.
Well, as a geo nerd – I was excited when I heard about this. I was tempted to get it into all my websites that have any mapping capability at all but recently, I have been disappointed.
I tried installing this on a webpage that I can hit from my iPhone and from Firefox 3.5 easily (and also from many locations) to see it in action. What did I find?
location = undefined
Seems like no matter where I am, all I get is an undefined location. Bummer. Because I am in a heavily populated metropolitan area, where geolocating should be easy – but alas – if it doesn’t work for me and my testing, how will I ever get a client to buy into it. I’ll be traveling over the next few weeks and hopefully will see if this thing can work. For now – I am not convinced.