I Feel The Need For Speed
Posted on : 09-03-2008 | By : Jim Lynch | In : Blogs and blogging, Site News, WordPress
Tags: Optimization, Site News, Speed
18
It’s Sunday, which must mean that it’s time to play around with the site again. Today’s project is speed. Specifically, what makes bRight & Early load faster. More specifically, removing or tweaking things that could slow the site down.
So far I’ve switched off the TTF Titles plugin. I like the graphic titles on each post, and the images that are generated are small and cached. Still, with that many additional graphics on the front page it’s bound to make things a bit slower. I also reduced the number of posts on the main page. For some reason (I don’t remember why now) I had the most recent 21 posts displayed. Way too many. I’ve reduced that number to 14.
I’ve also removed the “most recent posts” widget. If you are already on the main page you can see the most recent posts. If you’re not, you either don’t want to see anything else, or you can click on the home page and see them.
Now I’m taking a look at the plugins page. I believe I have a few activated that I don’t even use. That can slow things down as well.
Now it’s your turn. What suggestions do you have? Is there anything else in the sidebar that can be removed?
UPDATE: JustADude took a look and left several ideas in the comments. It seems as if TTLB is creating a bit of a bottle neck.
One tool he mentioned was the page test tool at Pingdom Tools. It is showing that the main page loads in an average of 13.80 seconds without TTLB script calls. With the call the time nearly doubles to over 21 seconds.
UPDATE II: Looking at some sites on my blogroll:
Liberty Pundit — 6 secs.
The Jawa Report — Timed out at more than 30 secs.
Blue Crab Boulevard — Timed out over 15 secs.
Support Your Local Gunfighter (A Blogspot blog) — 3 Secs.
No Runny Eggs — 21 secs., including a long call to TTLB like here.
Loading ...
For a full analysis of what is loading and how long it takes I just ran a test off a site on the net that tells you down to the nitty gritty what is going on with your page loadings.
It might point you to areas to tune.
The Saved Test Results are here
I just did a refresh of your page for this post and I tried it several times and I got a very long delay in the load waiting on your data pointed to at Truthlaidbear
http://www.truthlaidbear.com/MyDetails.php?url=http://www.brightandearlyblog.com/&style=javascript
onStateChange – 16422ms: start, 25766ms: redirecting, 25782ms: stop
Connecting to http://www.truthlaidbear.com...
onStatusChange – 16469ms: status Connecting to http://www.truthlaidbear.com...
Waiting for http://www.truthlaidbear.com...
onStatusChange – 16485ms: status Waiting for http://www.truthlaidbear.com...
http://truthlaidbear.com/MyDetails.php?url=http://www.brightandearlyblog.com/&style=javascript
onStateChange – 25782ms: start, 92032ms: transferring, 92063ms: stop
Connecting to truthlaidbear.com…
onStatusChange – 25797ms: status Connecting to truthlaidbear.com…
Waiting for truthlaidbear.com…
onStatusChange – 25844ms: status Waiting for truthlaidbear.com…
Transferring data from truthlaidbear.com…
NOTE The LONG LONG hang here
onStatusChange – 92032ms: status Transferring data from truthlaidbear.com…
255 bytes (178363 bytes total)
onProgressChange – 92032ms: progress 255 bytes (178363 bytes total)
This data is from a diagnostic plug in I have for FireFox called Load time analyzer
https://addons.mozilla.org/en-US/firefox/addon/3371
It is written by Google and is very detailed in what is happening inside your page loading
Another tool I find handy is a FireFox extension called JSVIEW
https://addons.mozilla.org/en-US/firefox/addon/2076
It not only allows me to see all your html coding like viewsource in your browser would, but it also shows all the CSS stuff and Java Scripts and such that are run here at the client end when your page loads.
I just did several more refreshes of your page and the truthlaidbear hang is intermittent , but when it does hang it is a long delay.
Right now an average time over 5 refreshes of this page is running at 19.32 seconds.
That is some great information. Thanks for the help. I have commented out the TTLB script for now. Once again, thanks for taking a look!
Ok
Just did a sequence of 5 refreshes of this page
Total elapsed time (from my first byte of the html request to the last byte received from your site or a referenced source) was 173953 ms.
That works out to an average refresh of 34.79 seconds which is slow because of all the external calls and the total bytes the page is loading.
Most web metric places will tell you to try to keep your load times under 8 seconds.
I would have to look at all the various scripts/css/and php stuff you are running, but go back to that original test I linked and see the total bytes transferred to load the page up and it gets really large.
If you use fire fox with the addons I do you can test against other sites you are familiar with to see what your tradeoffs are.
That can also be done from the original test site I linked.
Remember it’s total size served plus the largest impact is usually external sites you have your css and js refer to from the clients machine.
I really recommend load time analyzer. It is actually listed under extensions in the section of web developers tools.
There is also a more complex total web development toolbar extension which actually allows you to alter the css scripts and such on your own client to see effects dynamically.
Don’t just kneejerk it look at the whole spectrum of what is being done in the load and just how many bytes are being served by you and how many by others.
Get an idea for the whole flow and how it ties together.
Some sites I have worked with have done things like replace long blogrolls on the side bar with widgets that don’t display the entire listing but wrapper it in a picklist box. That depends on if you have such and add on for your blogging software and I believe wordpress has some of those.
You do several blogroll calls due to the groupings. Just how dynamic is that list or can you pull it in as something static. Or even better host the list dynamically on your site and periodically update it from the original source of the rolls.
Obviously I am showing much longer load times than the first test site I pointed you to.
I would have to look at the data myself, but in the past that usually means there is one of your external called sites that is having a very slow ping time from me and not from the test site.
We are very likely using different routes and it all depends on how many hops and who is hosting what along the way that causes issues.
Believe me I have seen some very strange routings just because of the way some providers peer with each other.
Target Name: brightandearlyblog.com
IP: 72.22.69.119
Date/Time: 3/9/2008 1:33:33 PM to 3/9/2008 1:38:18 PM
Hop Sent Err PL% Min Max Avg Host Name / [IP]
2 16 0 0.0 14 58 37 [68.152.181.208]
3 16 0 0.0 16 57 31 [65.14.195.153]
4 20 2 10.0 25 112 46 ixc00jax-ge-1-0-7.bellsouth.net [205.152.70.144] <————————-Jacksonville , FL
5 20 0 0.0 24 66 45 axr00asm-so-2-0-0.bellsouth.net [65.83.239.74]<——————————Atlanta
6 19 0 0.0 25 68 40 pxr00asm-2-0-0.bellsouth.net [65.83.236.2]
7 18 0 0.0 25 74 42 te7-2.mpd01.atl04.atlas.cogentco.com [154.54.10.233]<——————–Greer , SC
8 18 1 5.6 25 84 55 te3-4.ccr01.atl01.atlas.cogentco.com [154.54.6.113]
9 20 0 0.0 2 84 56 te9-2.mpd01.iah01.atlas.cogentco.com [154.54.24.2]
10 20 0 0.0 33 115 85 te4-1.ccr01.sna02.atlas.cogentco.com [154.54.1.65]
11 20 0 0.0 33 126 94 te3-4.mpd01.lax01.atlas.cogentco.com [154.54.3.38]
12 20 0 0.0 33 114 83 gi2-0-0.core01.lax01.atlas.cogentco.com [154.54.2.101]
13 20 0 0.0 34 114 79 vl3878.na23.b001202-3.lax01.atlas.cogentco.com [38.20.35.114]<——- Los Angeles
14 20 0 0.0 34 116 82 ipowerweb-inc.demarc.cogentco.com [38.99.220.30]<————————–LA
15 20 0 0.0 35 115 90 [72.22.95.246]<——————————————————————————–NYC
16 20 0 0.0 34 114 78 brightan.accountsupport.com [72.22.69.119]<————————————–NYC
Ok that’s 20 traceroutes to your blog at 15 sec intervals.
Note that for some reason congentco routes me from SC to CA to get to NYC
min 34 seconds
max 114 seconds
avg 78 seconds round trip
looks like you are hosted by ipowerweb from the host name.
and if I geotrack it correctly your server is in NYC or close by.
My blog had been down for the better part of a day and a half because of the TTLB problem. I removed the link (for now), and I’m getting hits again. Wish I knew this earlier.
Now this is one crazy routing
My packets go from here to
Jacksonville, Fl
Atlanta,GA
back to Jacksonville,FL
Greer, SC
Muskegon,Mi
NYC
Genoa,Ill
Manasquan,NJ
Los Angeles,CA
NYC
Then they make the round trip back
Now why Ipowerweb is not peered to take the packet when it reached 154.54.1.65 you would have to ask them. It’s all contained on congentoco’s network and is not a handoff.
That one stop at 154.54.24.2 doesn’t come back with a geolocation, so I don’t know where it is physically.
Jax>Atl>Jax>Greer>Muskegon>NYC>Genoa>Manasquan>LA>NYC
What a routing
I’ve been having problems too. So it’s TTLB’s problem, should have known. I hope that’s all it is. I don’t have a technical bone in my body, so all I do is hope for the best.
Now tracing to you from the west coast
TraceRoute to 72.22.69.119 [brightandearlyblog.com]
Hop (ms) (ms) (ms) IP Address Host name
1 2 1 0 66.98.244.1 gphou-66-98-244-1.ev1servers.net<—————————-Altadena,CA
2 0 0 0 66.98.241.6 gphou-66-98-241-6.ev1servers.net<—————————-Chantilly,VA
3 2 0 0 66.98.240.4 gphou-66-98-240-4.ev1servers.net<—————————-Lakewood,CA
4 1 1 1 129.250.10.105 ge-1-12.r03.hstntx01.us.bb.gin.ntt.net<———————Englewood,CO
5 1 3 3 129.250.2.228 xe-0-1-0.r20.hstntx01.us.bb.gin.ntt.net<———————Los Angeles,Ca
6 11 20 11 129.250.3.129 as-0.r20.dllstx09.us.bb.gin.ntt.net<—————————Englewood,CO
7 6 6 6 129.250.2.59 ae-0.r21.dllstx09.us.bb.gin.ntt.net<—————————Los Angeles,CA
8 6 9 9 154.54.11.193 te3-4.mpd01.dfw03.atlas.cogentco.com<——————DeKalb, IL (say hi to NIU)
9 7 6 9 154.54.6.65 te2-4.mpd01.dfw01.atlas.cogentco.com<——————-Muskegon,Mi
10 11 6 7 154.54.2.13 te8-3.mpd01.iah01.atlas.cogentco.com<——————-Manasquan,NJ
11 42 40 40 154.54.1.65 te4-1.ccr01.sna02.atlas.cogentco.com<——————–NYC
12 42 43 40 154.54.3.38 te3-4.mpd01.lax01.atlas.cogentco.com<——————-Genoa,Ill
13 40 42 40 154.54.2.101 gi2-0-0.core01.lax01.atlas.cogentco.com<—————-Manasquan,NJ
14 40 43 40 66.28.65.70 gi0-3.na23.b001202-3.lax01.atlas.cogentco.com<—–Manasquan,NJ
15 41 39 39 38.99.217.202 ipowerwebinc.demarc.cogentco.com<———————-Washington,DC
16 41 40 42 72.22.95.250 -????????????????????????
17 39 42 41 72.22.69.119 brightan.accountsupport.com<———————————Santa Monica,CA
Trace complete
Two entirely different locations showing up for the same destination IP. Looks like what is happening is the ip is being mirrored on the east and the west coast and alised out with the border routing protocol.
Either that or I have two different Geo servers giving different locations.
Ok checked with a 3rd and 4th geoserver it looks like your host is in Santa Monica. The NYC location was a bogus record hit by the original geolocation server
Target Name: truthlaidbear.com
IP: 63.247.135.218
Date/Time: 3/9/2008 3:28:38 PM to 3/9/2008 3:33:23 PM
Hop Sent Err PL% Min Max Avg Host Name / [IP]
2 16 0 0.0 13 68 44 [68.152.181.208]<——————————————————————Atlanta,GA
3 17 0 0.0 15 69 25 [65.14.195.153]<——————————————————————–Atlanta,GA
4 16 0 0.0 24 78 31 ixc00jax-ge-1-0-1.bellsouth.net [205.152.70.25]<———————–Atlanta,GA
5 20 0 0.0 24 79 35 axr00asm-so-2-0-0.bellsouth.net [65.83.239.74]<———————-Atlanta,GA
6 20 0 0.0 25 78 72 axr00msy-0-3-1.bellsouth.net [65.83.236.46]<—————————Atlanta,GA
7 18 0 0.0 31 95 47 so-7-1-3.edge1.Atlanta2.Level3.net [4.71.192.17]<———————Atlanta,GA
8 2 0 0.0 32 34 33 ae-12-51.car2.Atlanta1.Level3.net [4.68.103.3]<————————-Atlanta,GA
9 7 0 0.0 47 184 89 ge-10-4.car1.Jacksonville1.Level3.net [4.68.107.198]<—————-Jacksonville,FL
10 19 0 0.0 42 99 68 jax-main.dnsquest.com [64.31.151.230]<———————————Jacksonville,FL
11 20 0 0.0 42 99 65 polar.truthlaidbear.com [63.247.135.218]<——————————–Jacksonville,FL
Based on these trace times, the bottleneck from my place is split between the bellsouth to level3 handoff in Atlanta and the level3 to dnsquest handoff in Jacksonville with another big response delay by TTLB itself at the end.
Guess it’s time to put TTLB on the shelf for a while.
The speed problem no longer seems to be TTLB. My site is back to more-or-less normal, with only embedded video sometimes causing pain.
Back to you; there is still a very slow load here. I’m thinking the database needs some optimization.
8.3 seconds.
That Manasquan one is weird. That is the town I grew up next to.