Understanding my results: slow load times

pmeenan · January 8, 2016, 1:33pm

@Anton, that’s thow wordpress works. The server executes hundreds of php files on the back end, makes dozens of database queries and as a result of all of that work spits out a 17kb HTML file. You won’t see it in the waterfall (just shows up as delays to first byte) and the best way to get visibility into exactly where the time is going is to install something like New Relic on the server.

Cheap shared hosting is almost always the cause of the problem because they run hundreds of sites on the same server and database to get better server utilization and keep costs down (at the expense of performance).

Caching plugins can help hide the issues by saving a copy of the generated HTML or the database queries but it is best to fix the underlying problem first.

Since you are paying the developer to also do the hosting, it is entirely in his control to fix (and is very fixable). There are a lot of good hosting providers out there. Even the free tier of EC2 performs better than most shared hosts (though requires more effort to run). There are also Wordpress-specific hosts like WP Engine. These days there is no good reason not to be running SSD’s for the server which usually solves 90+% of the performance issues.

For example, I run a wordpress blog for my wife on a spare ancient laptop we had lying around and the first byte times are < 100ms consistently (and it is not caching since it doesn’t get a lot of traffic).

Anton_Chigurh · January 8, 2016, 7:51pm

[quote=“pmeenan, post:21, topic:9729”]
@Anton, that’s thow wordpress works. The server executes hundreds of php files on the back end, makes dozens of database queries and as a result of all of that work spits out a 17kb HTML file. You won’t see it in the waterfall (just shows up as delays to first byte) and the best way to get visibility into exactly where the time is going is to install something like New Relic on the server.
[/quote]I’m finding out most platforms do this - in fact I have found this today testing Joomla, XenForo, vBulletin and even facebook! Also, (re: the bolded) in the advanced settings we can get WPT to give us the actual contents of the file generated in request #1.

Before testing, click on “Advanced Settings” then choose the “Advanced” tab then click the checkbox for “Save response bodies.” When the waterfall populates, clicking on Request #1 now gives you a link titled, “Open response body in new window” and this opens in browser, showing you ALL of the code generated during the “first byte time.” It looks to be really, the source code for the site as you would see it if you were checking source code.

So I am assuming this is the server constructing the source code, which is downloaded and executed by the browser, and then you get all of your content downloads following starting with request #2 and so on down the line.

Here’s a example response body for a vBulletin 3.8.7 installation.

This becomes quickly obvious that testing in this way and checking content (reading the code) of Request #1 tells you what impact all of your add-ons, bells, whistles and extras have on the construction of this executable file and therefore, TTFB itself… It simply takes more TIME to find more stuff.

Here’s a link to the exact contents of Req. #1 of the OP’s site.

Even the most casual reading of this code shows there’s a lot of work being done here populating all of the extras and add-ons. This is why I would like to see the OP turn OFF all extras, plugins, add-ons, and run tests with all of these off. A baseline test of what this would be “out of the box” so to speak, so he can clearly see what effect all of the extra stuff has on TTFB.

I run all of my sites on godaddy deluxe shared hosting and always have, (12 years now) and don’t have FBT issues at all. But then again, I keep my sites svelte and light, not a lot of junk to clog up the pipeline.

[quote=“pmeenan, post:21, topic:9729”]
For example, I run a wordpress blog for my wife on a spare ancient laptop we had lying around and the first byte times are < 100ms consistently (and it is not caching since it doesn’t get a lot of traffic).
[/quote]I am willing to bet that site isn’t loading 4 megabytes of glut though.

pmeenan · January 8, 2016, 10:47pm

Actually, I hesitate to share the page because when I ran the test it was actually a 50MB page because all of the story photos where straight out of her DSLR so yes, it was loading WAY more bytes but that has nothing to do with the TTFB (as I’ve tried to point out before).

http://www.webpagetest.org/result/160108_BQ_09ab24191c61df7f6b2b8961e86c3955/

Anton_Chigurh · January 8, 2016, 10:57pm

[quote=“pmeenan, post:23, topic:9729”]
Actually, I hesitate to share the page because when I ran the test it was actually a 50MB page because all of the story photos where straight out of her DSLR so yes, it was loading WAY more bytes but that has nothing to do with the TTFB (as I’ve tried to point out before).

http://www.webpagetest.org/result/160108_BQ_09ab24191c61df7f6b2b8961e86c3955/
[/quote]I’m granting that content kb or mb isn’t a concern for TTFB, but clearly the amount of items needed to construct the executable page source file in request #1, sure is. It’s part and parcel.

And dude, I would post what that Meenan blog site looks like to IE 11, but I cannot get it to complete the test after several tries.

http://www.webpagetest.org/result/160108_XA_177P/

As you probably know I don’t like the Chrome test - Chrome skips too many requests to suit me.

pdibona · January 8, 2016, 11:17pm

I took a look at the results of 20 runs in WebPagetest and have come up with some findings:

The First byte times are relatively consistent, which means the hosting is most likely not the issue, at least not for the base page.

The Median TTFB was around 2.0 Seconds, not horrible, but could be better.

The Time to Start Render was highly variable, which had a median of 4.297 seconds.

http://imgur.com/4R1TCgZ

That’s 2.3 seconds spent from when the base page started downloading, to when the first image shows up.

This large time is spent doing all kinds of DOM thrashing from javascript. Doing a quick https://developers.google.com/speed/pagespeed/insights/?url=campvoyageur.com%2F&tab=desktop shows that there are 16 blocking Javascripts, of which most are pre-render time.

Here is the list:

This big mess of blocking JavaScript is probably due to too many add-ons.

I believe an audit and some iterative testing like Anton suggested would be the best approach.

I see a lot of marketing and social media add-ons, which might seem like a good idea, but they tend to be very problematic for page performance.

Removing add-ons will not only improve your first byte times (most likely) it will also most likely improve the page render time as well as improve the overall user experience.

I’d take a look at what happens when you turn off the marketing add-ons alone, and see what happens to the Dom Complete (Load Time) times, then go from there.

Pete

Topic		Replies	Views
My Test Result not looking good.. Discuss Test Results	3	135	December 1, 2013
I don't understand several results and any help is really appreciated. Discuss Test Results	3	154	March 8, 2013
Good score but extremely slow site!! Discuss Test Results	3	160	June 6, 2014
Good score but realllllly slow load time? Discuss Test Results	5	136	June 4, 2014
First Byte Time scores F Discuss Test Results	7	160	March 11, 2017

Understanding my results: slow load times

Related topics