WebPagetest Forums

Our new Wordpress crashed on the high-traffic 4th of July weekend. After a week of developer-side optimization, it occasionally bogs down, but things have improved, at least from the user perspective.

Time to first byte, however, remains an "F". A blank page get an A. Sometimes the DNS is slow.

http://www.webpagetest.org/result/150713...1/details/ BAD TEST
http://www.webpagetest.org/result/150713...1/details/ RELATIVELY GOOD
http://www.webpagetest.org/result/150714...1/details/ SLOW DNS

The host is a local company that handled similar traffic on an older Coldfusion site without. It's the only site on the server. I don't know the specs except for it's a new box with 4GB RAM.

- Is the server is under-resourced for the traffic (125,000 visits in July)?
- Do we have an application problem?
- Is that just the way it is for a resource-intensive site?

Thanks.

Hmm, I was typing up a long reply about how your static and dynamic responses where both showing issues and I was going to recommend putting nginx or varnish in front of your web server but then I looked closer and it looks like you are having issues with cloudflare. I'd recommend opening a ticket with them to have them have a look. A bunch of the static resources that are taking a long time to serve are showing "CF-Cache-Status: HIT" response headers which means it came directly from cloudflare's cache and never hit your server.

Try disabling or putting cloudflare in bypass mode to see how performance looks and do your debugging there first before turning it back on.

As far as traffic goes, you should be easily able to handle 125k visits over a month on that hardware given that the site is mostly published content (assuming decent application-side logic, caches, tuning, etc).

Thanks. Checking this out. No word yet.

The host put Cloudflare in developer mode, and on the user end it seems to have speeded things up dramatically, at least from a user perspective. Thanks for that advice.

With WebPageTest, however, the TTFB is still a big F -- about 3000 ms this morning.
http://www.webpagetest.org/result/150717.../#request1

What can be made of that?

Cloudflare is listed as the server in the response header. Does that mean anything?

Maybe but looking at the rest of the requests it looks like CF's portion is largely under control and you're now at a point where you can debug the actual application.

Since you're on dedicated infrastructure I'd recommend installing New Relic and have it tell you what the slow parts of the back-end are.

"WP-Super-Cache: Served supercache file from PHP"

That makes me think the server response was cached on your server so most of the application logic didn't have to run so it may be as simple as the web server/php configuration and tuning (which may not show up in New Relic).

(07-17-2015 11:26 PM)pmeenan Wrote: [ -> ]>> looking at the rest of the requests it looks like CF's portion is largely under control

>> so it may be as simple as the web server/php configuration and tuning (which may not show up in New Relic).

Cloudflare is under control in the sense that it is turned off.

... Right, much of the page is cached locally with WP Total Cache. When you say "as simple as web server/php configuration and tuning," that's the job of the host, isn't it?

Yeah, you'd think so - if they're good at what they do (and depends on what kind of hosting you are using). If you're running a managed dedicated server then that's the "managed" part. I usually do my own management though and use bare servers so it kind of depends.

(07-17-2015 11:49 PM)zpinhead Wrote: [ -> ]Cloudflare is under control in the sense that it is turned off.

It is? Testing shows it is still active. You're never going to improve TTFB while using CF.

The target TTFB is just a silly number and I see this every time on sites using CF - 168ms and this skews the results. In the test I just ran here you have .990ms as TTFB. Typically what I see on all of my sites is a target somewhere around 240-350ms, and 'A' grades for this follow. You're never going to have a TTFB of 168ms. It's unattainable. Unless of course you're just loading blank pages. The target FBT will be a much more realistic number once you completely get rid of CF, and so will the total FBT you actually get.

I always use IE11 as a tester, for worst case scenario. You'll notice on your Chrome test, it's only 61 requests. With IE 11 you're seeing all 65 requests. Chrome ignores certain types of requests to give you the illusion that it's "faster." Okay I guess for the casual PC end-user, but not accurate for real world testing. You're not getting the entire picture.

When you look at the details for the 'C' grade for leverage browser cache of static assets, you can see most of it is 3rd party, google. Really nothing you can do about that.

However you can shave 140kb off every page load by optimizing the images located at calls 5, 9, 13-15, 17, and 29-34. Details here and WPT will even optimize the images for you when you click on "analyze JPG" for each one.

In the above you can see CF does not optimize your site. It merely delivers your un-optimized content from a location ostensibly closer to the user than your actual host server. It's not a magic bullet for performance, it's actually a lead balloon on it.

I've fixed literally dozens of sites with results like yours, getting straight A grades across the board no matter test browser or location. Ditch the magic bullet and do some more real optimization work in addition to what you've already done.

By the way your host really can't do much for you, with CF in the way.

>> Cloudflare is under control in the sense that it is turned off.
>> It is? Testing shows it is still active.

Right, it was in developer mode, which ends automatically after 3 hours, so I've learned. The site does about the same or better with CF turned off. Things start to bog down with more traffic.

>> However you can shave 140kb off every page load by optimizing the images

About half that is in the slider images. Since only one shows at a time, from a visual, above the fold, perspective, it seems okay. "Optimizing" also has often led to less than stellar photo quality.

The other images in the content boxes change dynamically with every page load, and unfortunately there are about 8000 images on the site. One-by-one optimization to maintain quality is not practical. Reportedly, there's a WP plugin that may reduce file size w/o reducing quality.

Re: further optimization, unless it's done by the host, who doesn't seem inclined, we're reaching the end of the line. We've done quite a bit within the limits of our knowledge and the budget. Both are running out.

Quote:Re: further optimization, unless it's done by the host, who doesn't seem inclined, we're reaching the end of the line. We've done quite a bit within the limits of our knowledge and the budget. Both are running out.

Ditch CF completely and watch your first byte time dramatically improve.

Quote:About half that is in the slider images. Since only one shows at a time, from a visual, above the fold, perspective, it seems okay. "Optimizing" also has often led to less than stellar photo quality.

This is wrong. You are loading ALL of the slideshow images no matter what a user actually sees. Look at the WPT and see all the calls. "Stellar" photo quality - nobody's going to notice the difference.

And again - since your site is on CF nameservers, your host can't do much to help you.