Slow website; what's your take on this?

Web Performance Discuss Test Results
1

Hi,

I’m dissatisfied with my website performance, especially the first view time:

Pingdom:
7.21s: Website Speed Test | Pingdom Tools
2.25s: Website Speed Test | Pingdom Tools

Webpagetest:
From Amsterdam (as baseline, since the webserver is located in the same county), first views 4.1, 1.5, and 1.6 seconds: http://www.webpagetest.org/result/140329_KC_78M/

From Moscow: first views 6.4, 2.8, and 3.1 seconds: http://www.webpagetest.org/result/140329_YY_707/

From Tokyo: first views 4.7, 1.2, and 1.3 seconds: http://www.webpagetest.org/result/140329_CJ_709/

Pingdom RUM:
These are the average page load times for the last two days according to Pingdom’s RUM:

Because CloudFlare caches content at data centres after being request by a visitor (if it is not already cached), a somewhat higher first view time is expected I guess. But since I’ve set CloudFlare to cache everything for 1 week (Edge cache expire TTL), I’d would expect that the subsequent load times were much lower, especially since my website is only 290kb big.

After all, in case of the Moscow test, it will probably not take 3 seconds to serve a cached HTML file of that size from CloudFlare’s Warsaw data centre to Moscow. So something along the way is probably going wrong.

From my side, I’ve done already the things that I’m aware of to increase the speed. The WordPress website uses the WP-Super Cache plugin which preloads all webpages into static HTML content. Furthermore, I’ve removed all redundant plugins, and replaced slow plugins by quicker, more lightweight versions. According to the WordPress P3 performance profiler plugin, the site load time is 0.641 seconds.

If I look at Webpagetest’s waterfalls, my novice mind gets the impression that something is wrong with the communication between CloudFlare and the original webserver, since most of the worse performance seems to be due to these two waiting on each other.

I’ve already asked my hosting provider and CloudFlare themselves why the first view times, and especially the TTFBs, are so high, but so far I’ve not gotten a clear answer – though I may have asked the wrong questions.

My question:
Do you guys might have an idea how I can improve the website speed?

Thanks in advance for any insights.

[size=x-small]Note: The browser cache is set deliberately to 1 day for now, since I’m working on the layout, so that gives a lower performance grade in the test reports.[/size]

2

JMTC, that sounds weird, when you ask why it is slow 2014-04-01_0831

you show a waterfall for Russia and Tokyo, of course, it must take lots of time for the bytes to fly almost half the world from USA server to RUSSIA or TOKYO servers )))

As for generic performance there is much room for improvements :

  1. I would add DNS prefetch for these guys ajax.cloudflare.com, http://themes.googleusercontent.com, http://www.google-analytics.com/, http://rum-collector.pingdom.net to avoid dns looksups or I harder way put your fonts and scripts in your main root site

2 - I would inline couple of your images in CSS - base 64

3 - I would think one more time if you need custom fonts, if need, then remove glyphs and use this service Create Your Own @font-face Kits » Font Squirrel

some dirty thing)
4 - I would remove Accept encoding line, cookie and referral from your Header request

3

[quote=“Funkerman88, post:2, topic:8647”]
JMTC, that sounds weird, when you ask why it is slow 2014-04-01_0831

you show a waterfall for Russia and Tokyo, of course, it must take lots of time for the bytes to fly almost half the world from USA server to RUSSIA or TOKYO servers )))[/quote]
That also surprised me when I looked into the waterfalls, but discarded it since, according to IPLocationfinder, that IP is based in San Francisco, California. Since Cloudflare has no data centre in that city*, while its offices are in San Francisco, I thought that was an “administrative IP” from CloudFlare (if such a thing exists).

Does that reasoning make sense or should the IP address from CloudFlare’s data centre show up in the test results?

[size=x-small]*: There is a data centre in San Jose, which is practically a neighbour of San Francisco. Don’t know if that counts?[/size]

Thank you for these suggestions! :slight_smile: I’ll work on implementing these later this week.

4

[quote=“JMTC, post:3, topic:8647”]

I contacted CloudFlare support regarding this, and they directed me to the following help page: What do the CloudFlare location codes mean?

If I do a traceroute to the website from my location, the IP at which the traceroute ends is an California IP address. But if I follow the approach outlined in that help article, it shows that I’m redirected to the most nearby European data centre. So that seems to work correctly.

The displayed IP address in Webpagetest’s results, when one is using CloudFlare, therefore do not seem to reflect the CDN data centre that was used.

5

Have you set super cache to preload the site in the preload tab?

6

Thanks for responding. Yes, I have, automatically pre-loading every 24 hours.

I’ve made the following changes to the website this week:
[list]
[]Removed Google font;
[]Replaced Google Analytics script with the asynchronous one;
[]Added DNS prefetch;
[]Displayed often requested images inline.
[/list]

Repeat views are now around half a second, but the first view can still be above 3 seconds:
Moscow: WebPageTest Test - Running web page performance and optimization tests...
Chicago: WebPageTest Test - Running web page performance and optimization tests...
Amsterdam: WebPageTest Test - Running web page performance and optimization tests...
Amsterdam: Website Speed Test | Pingdom Tools

Since a lot of time is wasted with DNS lookup and TTFB, I asked Cloudflare what I could do about that. They referred me to their blog message which said TTFB is meaningless and also pointed to my hosting.

However, when I asked my hosting provider if there were any issues or performance bottlenecks on the shared server, they brushed that off as causing these slow first view times.

Luckily, the first view times have become better so it’s not very troubling any more. PingDom RUM data is still somewhat troubling (for example, average page load from Canada above 6 seconds), so if anyone has a suggestion. :slight_smile:

7

[quote=“JMTC, post:6, topic:8647”]

Since a lot of time is wasted with DNS lookup and TTFB, I asked Cloudflare what I could do about that. They referred me to their blog message which said TTFB is meaningless and also pointed to my hosting. [/quote]That’s their canned response to this and it is a lie. CF nor any other CDN can do anything at all to improve TTFB. I used CF for over two years and it did not improve speed, security or anything at all really. I did not get TTFB improvement until I ditched CF and went to work seriously this time, on optimization. And then?

[quote]However, when I asked my hosting provider if there were any issues or performance bottlenecks on the shared server, they brushed that off as causing these slow first view times.[/quote]What finally solved this for me was being able to convince the host it was them and their oversold, overcrowded shared machine, not me. When they finally seriously investigated they found i was on a really old, tired machine and they moved me to what they said was a “newer machine” and BAM, TTFB is a A grade every time for me now. Your site loads only just over 230kb on a browser, with only 17 requests. There is no way your site is the TTFB problem.

Slow first byte time is going to be shared hosting every time, and is going to be a oversold overcrowded machine at the host, every time. AND IT IS SIMPLE TO PROVE to your host - simply create a simple HTML page with nothing but the words “Hello There” and watch the TTFB STILL be bad for testing just that page!

All that said, try this for getting rid of that F grade for leverage browser caching:

In .htaccess add:[php]
ExpiresActive On
ExpiresByType text/css A2628000
ExpiresByType text/richtext A3600
ExpiresByType image/svg+xml A3600
ExpiresByType text/plain A3600
ExpiresByType text/xsd A3600
ExpiresByType text/xsl A3600
ExpiresByType video/asf A2628000
ExpiresByType video/avi A2628000
ExpiresByType image/bmp A2628000
ExpiresByType application/java A2628000
ExpiresByType video/divx A2628000
ExpiresByType application/msword A2628000
ExpiresByType application/x-msdownload A2628000
ExpiresByType image/gif A2628000
ExpiresByType application/x-gzip A2628000
ExpiresByType image/x-icon A2628000
ExpiresByType image/jpeg A2628000
ExpiresByType application/vnd.ms-access A2628000
ExpiresByType audio/midi A2628000
ExpiresByType video/quicktime A2628000
ExpiresByType audio/mpeg A2628000
ExpiresByType video/mp4 A2628000
ExpiresByType video/mpeg A2628000
ExpiresByType application/javascript A2628000
ExpiresByType application/x-javascript A2628000
ExpiresByType application/vnd.ms-project A2628000
ExpiresByType application/vnd.oasis.opendocument.database A2628000
ExpiresByType application/vnd.oasis.opendocument.chart A2628000
ExpiresByType application/vnd.oasis.opendocument.formula A2628000
ExpiresByType application/vnd.oasis.opendocument.graphics A2628000
ExpiresByType application/vnd.oasis.opendocument.presentation A2628000
ExpiresByType application/vnd.oasis.opendocument.spreadsheet A2628000
ExpiresByType application/vnd.oasis.opendocument.text A2628000
ExpiresByType audio/ogg A2628000
ExpiresByType application/pdf A2628000
ExpiresByType image/png A2628000
ExpiresByType application/vnd.ms-powerpoint A2628000
ExpiresByType audio/x-realaudio A2628000
ExpiresByType application/x-shockwave-flash A2628000
ExpiresByType application/x-tar A2628000
ExpiresByType image/tiff A2628000
ExpiresByType audio/wav A2628000
ExpiresByType audio/wma A2628000
ExpiresByType application/vnd.ms-write A2628000
ExpiresByType application/vnd.ms-excel A2628000
ExpiresByType application/zip A2628000
[/php]
[hr]
You’re actually looking pretty darn good right here, in this test using IE 10. Only a couple of F grades, easy fixes.

http://www.webpagetest.org/result/140405_ZH_E8R/

Fix that F grade for “compress images” by uploading this image I am providing, to overwrite the one that’s in your files here:[php] http://www.tradingcode.net/wp-content/uploads/tnMouseAndKeyboardKeys.jpg[/php]

Rename it to match, upload to overwrite. I compressed it for you, shaving off 14kb.

8

Given that the page is only 200kb in size - great! - I’d dump cloudflare. If you want to use a CDN, the use something like maxcdn… at least if the ttfb is still slow, you can do something about it!

@Anton said it all, really. IMO CF is all marketing hype.

Steve

9

[quote=“Anton_Chigurh, post:7, topic:8647”]
That’s their canned response to this and it is a lie. CF nor any other CDN can do anything at all to improve TTFB. I used CF for over two years and it did not improve speed, security or anything at all really. I did not get TTFB improvement until I ditched CF and went to work seriously this time, on optimization. And then?

(…)

You’re actually looking pretty darn good right here, in this test using IE 10. Only a couple of F grades, easy fixes.

http://www.webpagetest.org/result/140405_ZH_E8R/[/quote]
Thanks for your reply. I thought a CDN would make the website quicker since, after all, the geographic distance should be less for non-European visitors in my case.

I’m not sure if dropping CloudFlare in my situation is also the best idea, since the original webserver might not be quick enough. For example, if I disable CloudFlare the performance is much worse:

From Dulles: WebPageTest Test - Running web page performance and optimization tests...
From Chicago: WebPageTest Test - Running web page performance and optimization tests...
From Moscow: WebPageTest Test - Running web page performance and optimization tests...

quote=“Anton_Chigurh, post:7, topic:8647” Your site loads only just over 230kb on a browser, with only 17 requests. There is no way your site is the TTFB problem.
Slow first byte time is going to be shared hosting every time, and is going to be a oversold overcrowded machine at the host, every time. AND IT IS SIMPLE TO PROVE to your host - simply create a simple HTML page with nothing but the words “Hello There” and watch the TTFB STILL be bad for testing just that page!

(…)

You’re actually looking pretty darn good right here, in this test using IE 10.[/quote]
Thanks for the TTFB measurement suggestion. With CloudFlare disabled:

From Dulles: WebPageTest Test - Running web page performance and optimization tests...
From Moscow: WebPageTest Test - Running web page performance and optimization tests...

Thank you; added to the file.

Thanks; replaced.

[hr]

Thanks for your reply. I looked into MaxCDN, but they do not, in comparison to CloudFlare and Incapsula, offer entire page caching (unless you’re an enterprise).

Wouldn’t that negatively impact the website speed for non-European visitors, since I have only a few small images and one css file that can be served by MaxCDN. The page itself would still need to be served from the webserver in Europe, giving slow DNS and TTFB times for non-European visitors?

10

Maybe you should dump Wordpress. I never used it, but your page is all text and there’s no reason for 7.21s load time. Quick comparison: your site 19 request, size 281.3kB; our site 56 requests, size 632.3kB, yet our load time is 1.57s. I believe CDN for a page of just 281.3kB is really not needed. Just my two cents.

11

To some extent, suggesting dumping a product that you’ve never used is not really the best! After all, 10% of the websites on the web do use it, so it must be possible to get decent performance out of it surely???

To the best of my understanding, the basic CF just delivers your site as a proxy server, so it’s still accessing your site to get the html behind the scenes ( you can easily prove that by looking in your weblogs ). As such, it will be slower, not faster than the original, and as I suggested an oldschool CDN will deliver the static content as well if not better, and you get to understand what is working and where the bottlenecks are: something that CF hides completely from you.

12

Of course I never used it, heard enough stories and took a look at the code, and it never crossed my mind to deal with it.

“10% of the websites on the web do use it” You know as I do that the number of installation doesn’t mean the software is good, this is not the only one open source CMS in the world, just one with good marketing.

I just offered you my opinion backed by some number, if you are not a programmer just continue to use whatever you want, no need to jump on me.

13

[quote=“histerius, post:10, topic:8647”]
Maybe you should dump Wordpress. I never used it, but your page is all text and there’s no reason for 7.21s load time. Quick comparison: your site 19 request, size 281.3kB; our site 56 requests, size 632.3kB, yet our load time is 1.57s. I believe CDN for a page of just 281.3kB is really not needed. Just my two cents.[/quote]
Perhaps that might be an option. Ghost seems quick if I should believe this article, but I don’t know node.js so there’s a lot I should learn and change then. Other PHP based CMS (like Joomla or Drupal) seem less attractive than WordPress to me, so I’d rather stay with WordPress and fix the speed issue with better caching, CDN or a different server.

[quote=“GreenGecko, post:11, topic:8647”]
(…)
To the best of my understanding, the basic CF just delivers your site as a proxy server, so it’s still accessing your site to get the html behind the scenes ( you can easily prove that by looking in your weblogs ). As such, it will be slower, not faster than the original, (…)[/quote]
True, by default CF more or less acts as a proxy. However, I’ve defined page rules to cache everything (since I don’t have dynamic content). In theory, the website is cached at CF’s data centres from one week (for the HTML pages) to 6 months (images, css).

If I look at the server data statistics, the first CloudFlare IP with the highest traffic this month so far has only used 6,7mb, almost a half mb per day, so I suppose this edge caching works.

The average page load was this week 2,4 seconds. This average was significantly brought down by my own pageviews (which won’t be collected from now on).

The Pingdom loading states for the last week (averages, 1.147 page views) tell the following:

I read their explanation of loading states here but I’m not knowledgeable enough to interpret these data (frontend and network seem high, but don’t know if these are average or out of line).

What is your take on these loading states data?

14

Have no idea what you did but the website is loading very fast now. :slight_smile:

15

I didn’t do anything this week oddly enough. :slight_smile:

Performance from Moscow is reasonable good now ( WebPageTest Test - Running web page performance and optimization tests... ), from Amsterdam good ( WebPageTest Test - Running web page performance and optimization tests... ), though performance from Los Angeles relatively poor ( WebPageTest Test - Running web page performance and optimization tests... ).

In terms of Pingdom RUM data, there were 740 pageviews last week with an average load time of 3.0 seconds. Oddly enough, the pageload from Germany (avg. 6.3 seconds) is worse than from India (avg. 5.7 seconds), while this latter country is, in terms of geographical distance, around 17 times further away from the webserver than Germany is.

I’ll have to do some more digging. :]

16

Maybe something is wrong with LA, today I was unable to do any test with our website with it, although it works and works nicely, from fast to superfast :slight_smile: . So, I wouldn’t blame your website, there are obviously some bad network conditions.

17

I use Wordpress and it runs nice and fast. Have you taken Anton’s advice and added the expiry to your .htaccess? I have comeacross a number of slow sites using cloud. I am not convinced that they are as reliable as people had hoped it would be.

18

Thanks for your comment. Yes, I’ve specified cache control in the .htaccess file as suggested.

But your comment did make me realise something; the one week cache for HTML might be too low. In an extreme case, an unlucky visitor from a geographical region from which very little traffic comes can be presented with all slow pages because none of the pages he/she requests are in the most nearby CF data centre.

Don’t know if this can explain everything, but does probably play a role.

I’ve set HTML to expire in six weeks now (other resources @ 6 months).

19

OK, so it will be interesting to monitor the effect of the 6 week cache, and if possible test the site from different locations using Pingdom.

20

Yup, but so far I don’t see an improvement in the Pingdom data. But I’ll probably need to collect more data.

I just did a webpage speed test, which showed a 1,112 ms DNS Lookup time: WebPageTest Test - WebPageTest Details

What might cause that - is that CloudFlare or my webhosting? If I search on-line I only come across resources that talk about reducing the number of DNS lookups, which I already did. I could not find much about reducing the first DNS lookup time.

Webspeed tests from other locations, such as Germany (WebPageTest Test - WebPageTest Details), show a DNS lookup of 96ms.