Website slow loading time to first byte

they showed that a simple html page on the root of the site loads very fast…

The slow TTFB is an issue with the webhost. Their servers – or network infrastructure – are slow.

A simple HTML page will load fast, because it’s not using the database server or the php parser of the server like your WordPress site does.

Ah I see, this will be a difficult thing to test I gather. Thanks very much for the response, I will go back to them again and see if they can investigate this further. They keep pointing to plugins or the theme…I think I will ask them to create a sub-domain with a fresh wordpress install, I’ll do the basics of setup and then test it’s results. If it’s still slow TTFB then clearly it’s not the customizations of my site.

Thanks again for the response, I will report back and mark as resolved once I have a response from the webhost.

I’m marking this as resolved although nothing ever really was resolved. I ended up migrating the website from a Windows IIS server to Apache, and that combined with a caching plugin has yielded good results. So, I’m not sure why the TTFB was/is slow without a caching plugin, but I gave up.

Hi,

When you had the slowness problem, was it every click? I have a speed problem, but it’s just on the first viewing of the site, regardless which page. Maybe 20 seconds to open. Then all subsequent pages come up fine. Then after a day not viewing, the first page is slow again.

Is that the same problem you had?

Yes actually. The first time after a “while” would have a very long TTFB (the first GET when you look at a waterfall view of the resources which load), and then often subsequent tests made shortly thereafter would not show the issue.

There are several things my webhost tried, one of which was specifying the database location by IP instead of “localhost” which apparently can cause a delay on windows servers. In my case, once I had moved from windows IIS to apache AND enabled a caching plugin like W3TC, the issue went away as if by magic.

So, unfortunately I have no idea what causes/caused this issue. Noone was able to figure it out. I was just lucky to find a server/CMS configuration which avoids it.

Do you have a caching plugin enabled? Does it use browser cache? Maybe the browser cache has a short expiry so overnight it expires and the following day the first time you load the page it’s downloading all the resources again? Do you use page caching and if so, what is the expiry and does it rebuild automatically (i.e. could it be the first time you visit triggers it to build the page cache and then subsequent views load from the page cache, then overnight it tears down and you start over?

I doubt any of those are the issue, but make sure you do have a caching plugin enabled and configured well (my experience is that without a caching plugin, wordpress simply will not perform quickly enough no matter what else you try to optimize). Failing that, assuming you are on an Apache server and your webhost has already investigated the TTFB issue…I have no idea, sorry. If you figure it out, please let me know, I spent a lot of time trying to identify the cause so I would LOVE to know what it was!

Very interesting! We’re already on an Apache server, hosted by Network Solutions. I’m wondering, when you switched from Windows IIS to Apache, did you also change host company?

Well, I tried our site on Pingdom, HERE . Got a 16 second wait! For a total of about 18 seconds to load the page. (So clearly, as you suspected, it’s not a question of optimizing images or minimizing css.)

Then on a few subsequent tests, got an average of about 3 seconds to load the full page.

Later got another 16s wait.

On the DNS tests with Pingdom, I see a few issues with not being able to reverse lookup. I have no idea, but could it be that when switching servers, you also switched your DNS lookup provider?

Other thoughts I have are, could the server be having trouble establishing a new database connection object, which then gets cached for that session. I don’t think so, but who knows. The reason I doubt that is because it seems like the “subsequent” requests can even come from a different ip. At least, I think it can….

Anyway, I appreciate your lengthy explanation. Yours was the first support question I found that really described the exact issue we’re experiencing!

No it was the same host and they also handle the DNS/domain registration, etc. But obviously it was a different server, and in fact a completely different infrastructure so it was as if it was a new host.

Are you sure you are on apache? That pingdom test you linked above shows

DateMon, 07 Nov 2016 18:06:57 GMT
Server: Microsoft-IIS/8.5
X-Powered-By: PHP/5.6.22 ASP.NET
Link: <https://alps-tours.com/wp-json/&gt;; rel=”https://api.w.org/&#8221; <https://wp.me/P7GjG1-1c&gt;; rel=shortlink
Content-Length: 28051
Content-Type: text/html; charset=UTF-8

Microsoft IIS makes me think it’s actually on a windows box.

Also I have another thread in here where I was asking if anyone thought it could be related to wp-json (since that is the link for that first call) but it didn’t go anywhere.

So, are you using page caching? The last thought I had before I abandoned this search (due to the issue going away) was that which you mention above, that perhaps it is that first database query that is taking so long, then the query is cached so that subsequent requests are fast until that database query expires. I was unable to verify if that was the case, but if you have page caching enabled with a plugin (W3TC, etc) or at the server level (Varnish, etc) then I think it would avoid the need for that first GET to require a database query, hence your TTFB issue would disappear entirely.

Last thought, maybe upgrade from PHP5.6 to PHP7, I hear there are some substantial performance optimizations, a friend told me relating to database caching as well…

HOLY MACKEREL! I just assumed we were on Apache/Unix. Well … hmm. At least that suggests a possible “fix.” Wow. Thank you for noticing that! I built this site for someone a few months ago but I don’t have access to the hosting control panel.

Yeah, we already have the W3 caching plugin and Jetpack with some other optimizing tools. (Not using CloudFlare, but some other comment I saw suggest removing CloudFlare to speed things up!) One last suggestion was gzip compression. Again, though, that’s clearly not causing the 16s wait on the server.

But looking at the pingdom test, the problem is waiting for the server. I’d like to know what the problem really is, but like you, I’d be happy just to speed up the site. I’ll have them try Apache.

Thanks!

By the way, are you by any chance hosted on Network Solutions?

No problem, glad to help, yeah the move to a cloud linux plan vs windows really helped. If you do and it helps, let me know. In either case I’d love to hear how you make out. I spent many long hours arguing with the webhost and running tests, disabling plugins, etc. I even spun up a blank wordpress and it still showed the issue (just not to the same extent) in an attempt to prove to the webhost it was on their end…to no avail. I just tried going to your friends site and experienced the same very long (15+seconds) blank screen waiting, then it loads nice and fast once the first byte comes through, same issue I was having for sure.

No, I’ve never used Network Solutions before. Checked out their website just now, don’t see much that would entice me to use them, speaking personally.

Your friend may also want to move from WordPress 4.5.4 to 4.6.1, not that it will change performance but best to stay on the latest stable release. ??