Hi,
Please look into the report of my my website http://www.webpagetest.org/result/140506_YX_EB3/1/details/. I ran the test approx. 10 times and got that this is the best load time because sometimes it increases to approx. 1 minutes. Please let me know the pain areas and what to do to resolve them.
Also can someone help me to understand DNS Lookup,Initial Connection,SSL Negotiation,Time to First Byte,Content Download,3xx response,4xx+ response terminologies.
So… You want nearly 2 MEGABYTES of information to properly render and display on browsers in what? Less then 4 seconds? How fast do you think this fat page should load?
You are loading 109 images, most of them not optimized.
All that said, I suspect you might be on a shared hosting server that is way oversold, has too many sites on it. Problem is, if you bring this up with your host the first thing they are going to do is blame you, for the 100+ images and the 2 megabyte page size.
So first, I suggest you slim it down as much as possible. In the link I gave above, click under every image where it says “Analyze JEPG” and WPT will give you the properly optimized version of the image in question. (It’s usually the third image shown, the one with the smallest KB size) Save it to your computer, rename it to match what is on the server, then upload to overwrite. Do this for every one you see on that page that needs optimized.
This will get rid of the F and D grades you have for image compression and use of progressive JPEGS and will improve load time. Because in the process of doing this you will be trimming nearly 400kb of fat off your site without losing any content.
Look at the A grade you get here, loading just one of your images. The server responds very quickly here - because it’s just over 1kb not 2 megabytes.
Show me a fat site and I will show you a slow site, every time. Not trying to be snarky or mean, I’m just giving it to you straight from a guy who has optimized dozens of sites for people. The first thing you have to do is trim the fat everywhere you can.
You’re also testing a site based in India from Chicago. If your intended audience is in the USA, then I recommend that you host it there. This is far more important than @Anton’s comments re: images, which really aren’t that bad - sure they need addressing if you’re after every last ounce of performance. However, it would be simpler just to use a decent CDN to deliver them for you.
Much more importantly, your time to first byte is terrible. I can’t comment on the server config, as I know nothing about tuning IIS, but this is where your bottleneck is.
Also looking at the code it seems that you’ve written the app from scratch. The insertion of javascript all over the place makes it hard to read, and I don’t know what effect this will make on the performance.
You also normally set the web server to compress html… 150kb will compress down to under 20kb but from the download times, I’d say this isn’t being done.
So… look at compression, clean code, look at using a CDN and test from a local node.
[quote=“GreenGecko, post:3, topic:8710”]
So… look at compression, clean code, look at using a CDN and test from a local node.
[/quote]CDNs cannot improve performance of a site that isn’t optimized, and if you do optimize it, you don’t need a CDN.
Testing from a local node isn’t revealing - it really doesn’t make that much difference. Plus you have no way of knowing if that actually improves the number of “hops” and you have no way of knowing if any of the relays are inherently slow.
Taking 400kb off the fat page by optimizing the images isn’t a minor thing at all - it usually improves all the other problems as well. It is a basic MUST of page optimization. It’s the FIRST thing anyone who wants to optimize their site, needs to do.
2 MB of data isn’t going to load and render fast. Fat sites are slow sites. He needs to SLIM IT DOWN first, then see what his situation is.
Yes they do. They deliver with a high bandwidth from a close location, thereby making use of the CDN’s fatter pipe and lower latency, as well as helping ensure your own network connection doesn’t get flooded by offloading the bandwidth.
Yes it is. You’re testing your site configuration, not any inherent issues added by the vagaries of the internet.
As an example, here’s my site, tested from Wellington, NZ (local) and London, UK (remote).
My 26KB image takes over a second to load, as opposed to 100ms, and the whole page 5 seconds instead of 1!
Slimming the site down will help, sure. But nowhere near as much as the 5 second TTFB, and compressing the 150KB home page down to c. 15KB ( if that’s not already being done ).
You need to realise that there are 2 separate parts to getting a site to perform well. The TTFB is all about server performance, where tuning and resources are paramount. You have completely ignored this… the NINE SECONDS it takes to download the html framework.
The total size of the page is another part entirely, and can be improved by reducing latency, number of files, size of files and network performance. Apart from image optimisation / resizing, a decent CDN affects and can make a huge difference to the time it takes to load.
My lowly ADSL connection down here in rural New Zealand can download at 1.5MB/s on a good day. I’m sure you can add up how long it takes for me to load this page if size is the only factor. All other things ignored, a saving of 400kB = 0.3 seconds in this scenario. On a 17s page load, it’s really going to be the top of nobodies list.
(Yes, I agree there are a number of simplifications in this post, but the conclusions are valid)
[quote=“GreenGecko, post:5, topic:8710”]
[size=xx-small]Yes they do. They deliver with a high bandwidth from a close location, thereby making use of the CDN’s fatter pipe and lower latency, as well as helping ensure your own network connection doesn’t get flooded by offloading the bandwidth.[/size][/quote]BUT… When your site is down. the CDN can’t load a page. And when the CDN is down, you are down. And in either event, if your site is not optimized none of the things a CDN does, helps much. And if your site IS optimized, you really don’t need a CDN. And you REALLY don’t need one if you’re a small site on shared hosting.
[quote]
[size=xx-small]Yes it is. You’re testing your site configuration, not any inherent issues added by the vagaries of the internet.
As an example, here’s my site, tested from Wellington, NZ (local) and London, UK (remote).
http://www.webpagetest.org/result/140508_VA_JG/
http://www.webpagetest.org/result/140508_6F_JR/
My 26KB image takes over a second to load, as opposed to 100ms, and the whole page 5 seconds instead of 1![/size][/quote]You didn’t notice that for some reason, the Wellington browser is only loading 88kb of your site, compared to the 162kb London sees? Think that might account for alot of the difference in the results? I sure do.
In my experience of optimizing a BUNCH of sites for people, location of the test browser just hasn’t been a relevant factor. My advice always has been, find ONE test site and parameter in WPT that works reliably and consistently (I use IE10 in Virginia exclusively) and optimize your site to that test.
[quote]
[size=xx-small]Slimming the site down will help, sure. But nowhere near as much as the 5 second TTFB, and compressing the 150KB home page down to c. 15KB ( if that’s not already being done ).
You need to realise that there are 2 separate parts to getting a site to perform well. The TTFB is all about server performance, where tuning and resources are paramount. You have completely ignored this… the NINE SECONDS it takes to download the html framework.
The total size of the page is another part entirely, and can be improved by reducing latency, number of files, size of files and network performance. Apart from image optimisation / resizing, a decent CDN affects and can make a huge difference to the time it takes to load.
My lowly ADSL connection down here in rural New Zealand can download at 1.5MB/s on a good day. I’m sure you can add up how long it takes for me to load this page if size is the only factor. All other things ignored, a saving of 400kB = 0.3 seconds in this scenario. On a 17s page load, it’s really going to be the top of nobodies list.[/size]
[/quote]You will be amazed what slimming down a site does for TTFB and everything else. As I said, it is the FIRST STEP that should be done before anything else - particularly when we are talking about half a megabyte of totally unnecessary fat. Then after you have done that you can see a much more clear picture of what is going on - and you will actually be able to stop the host’s blame shifting when/if the time comes to confront them about their slow, oversold and overloaded machine. There is simply NO compelling reason to have a extra half megabyte of load that’s not needed.
In addition, use of a CDN gives the host yet another place to blame shift when the user is confronting them about their slow server.
If this OP is on a shared host, bandwidth is likely limited and/or allocated, and half a megabyte per pageload of unnecessary data NEEDS to be addressed immediately. First, before doing anything else.
That’s all I’m saying. Take care of the simple and easy stuff first. Slim down the site and note the improvement, then go from there. The OP wants to get to the “root cause” and I believe, from experience - the root cause is the fat page.
The suggestions and replies are appreciable. We have started working on the page size and optimizing the JSS files, Images and the CSS files.
Also i am inquiring about the bandwidth I have been provided from the network management people.
Apart from that there was some discussion going on for the location which I am choosing to run this page. Why I am choosing any other location apart from India because my website is live and anyone can use it from any location, so i need to always check for the worst scenario. Taking this consideration in my mind i use to run the tests from different -2 locations of the globe.
I have run the test today after combining the microsoft ajax requests and compressing the Images. http://www.webpagetest.org/result/140508_KD_DWF/1/details/ please analyze the report and let me know what is pending.
You still have quite a bit of work to do with the images, still 150kb left on the table there but you’ve made some progress.
In the link I gave in post #2, click under every image where it says “Analyze JEPG” and WPT will give you the properly optimized version of the image in question. (It’s usually the third image shown, the one with the smallest KB size) Save it to your computer, rename it to match what is on the server, then upload to overwrite. Do this for every one you see on that page that needs optimized.
This will get rid of the F and D grades you have for image compression and use of progressive JPEGS and will further improve load time.
I test against IE 10 or 11, not chrome or firefox. because IE compliance is by far most challenging.
This file:http://www.finalaya.com/Javascripts/combine.jsIs almost 500kb in size and is slowing you down greatly, as you can see in the waterfall chart here. It’s call item #7 and takes 5 seconds to download, in this particular test scenario.
Item #47 shown here - do you really need this 176kb png image that loads on browsers whether it is displayed or not? If so you have a good example in item #70 on how many kb you can save by turning item #47 into a gif instead of a png, if it’s really compelling to have it at all.
Here’s a easy 60kb of savings on another image. Use the third image you see at the link, overwrite the one that’s there.
You should be able to get the total load for this page down around the 1mb mark without losing any content.
Once you get slimmed down as much as possible, I think it is time to confront this host about its slow machine it has your site on. FBT is bad even on test browsers which are very close to the server, for what that’s worth.
I noticed that your website is on a Windows server.
You know I am not really want to remove the whole question by my suggestion but if you really want to have an optimized website try to switch to Wordpress, hosted on an optimized Linux based server powered with LiteSpeed or NGiNX.
There are some great plugins for wordpress which will make it really easy for you to optimize your website as fast as possible.
Plus there is a great Theme Framework out there called Genesis which takes care of more than 50% of your page load time.
Good Luck.
“Even a fool, when he holdeth his peace, is counted wise: and he that shutteth his lips is esteemed a man of understanding.” Proverbs 17:28.
I hope that your continued bad advice and skewed logic isn’t treated as truth by anyone out there. stick to the dayjob, and keep flipping that coin.
[quote=“GreenGecko, post:10, topic:8710”]
[size=xx-small]@Anton.
“Even a fool, when he holdeth his peace, is counted wise: and he that shutteth his lips is esteemed a man of understanding.” Proverbs 17:28.
I hope that your continued bad advice and skewed logic isn’t treated as truth by anyone out there. stick to the dayjob, and keep flipping that coin.[/size]
[/quote]Let’s not be silly with hyperbole. Show me one piece of BAD advice I am giving. Remember, BAD advice is your meter. Advice that if taken would do harm. Let’s see it. I’m not knocking your suggestions, we’re both just trying to help the best we can.
[hr]
[quote=“a.chakery, post:9, topic:8710”]
I noticed that your website is on a Windows server.
You know I am not really want to remove the whole question by my suggestion but if you really want to have an optimized website try to switch to Wordpress, hosted on an optimized Linux based server powered with LiteSpeed or NGiNX.
There are some great plugins for wordpress which will make it really easy for you to optimize your website as fast as possible.
Plus there is a great Theme Framework out there called Genesis which takes care of more than 50% of your page load time.
Good Luck.
[/quote]Nice post, I really really hate a windows server.
Hey Thanks a ton for your suggestion but the problem is that we cannot switch the server as of now. But please elaborate more on this that if I am moving from Windows to Linux then what all i need to do and all the changes and amount of work in details. This will help me to talk in the team and come to some conclusion.
[quote=“Anton_Chigurh, post:11, topic:8710”]
You:
Those are the worst bits of advice you’ve given… all either outright lies or completely missing the point.
Your focus is only on content - static files - whereas in this case
a) the html framework generation ( so server sizing and tuning issues ) and
b) the delivery ( location and possibly available bandwidth )
are far more where the problem lies.
[quote=“GreenGecko, post:13, topic:8710”]
[size=xx-small]You:
Those are the worst bits of advice you’ve given… all either outright lies or completely missing the point.
Your focus is only on content - static files - whereas in this case
a) the html framework generation ( so server sizing and tuning issues ) and
b) the delivery ( location and possibly available bandwidth )
are far more where the problem lies.[/size]
[/quote]First of all, NONE of what you list above is ADVICE. It is merely disagreement on your part and apparently lack of even rudimentary reading comprehension.
I have given NO bad advice. I have advised for the OP to take care of the easy and basic tasks FIRST. NOT to ignore other suggestions. “Trim the fat site” is NOT bad advice.
Now, to your list of laments:
I proved here that your example of location making a difference was false, and you ignored the fact that your testing was inherently faulty - since the location nearer you was only loading half the KB of the same page, therefore totally skewing the results and making the example invalid. You seemed to just ignore that little detail. The reality is: LOCATION of the test browser really does NOT make all that much difference.quote state that CDNs make at best no difference, and at worst make things worse[/quote]That is completely a falsehood. My statement is that if your site is not optimized, a CDN can’t do much for you (true) and if it IS optimized, you don’t really need a CDN (also true.)quote ignore the 9 second delay generating and delivering the html framework[/quote]Nonsense. Part of the delay IS all the extra fat and baggage in the site itself. My suggestion is to first reduce the baggage and the fat, then see what happens to this delay. I have seen it improved vastly many times, in the dozens of sites i have optimized for people, or have helped them with, just by this simple and basic thing alone.quote only concentrate on reducing payload[/quote]Untrue - but I see how you might think that by either not reading well or not comprehending what you read. My suggestions about minimizing the KB footprint as much as possible are coming because that is the first, most basic thing everyone should do when trying to optimize their site. And one of the easiest things they can do.
We’ve shown the location of the test browser isn’t relevant for this case, I’ve no idea why you continue to harp on it.
The OP has improved his site greatly by slimming it down, I’ve no idea why you can’t see that. He took the one piece of advice I offered, and it helped.
You have your panties in a knot for no apparent reason, since I have not suggested or advised that the OP ignore your suggestions, advice and tips. And I have not attacked your positions or said you gave bad advice.
I am giving very good advice, which works every time it is tried. That you don’t like the advice is exclusively your personal problem and if you don’t like my posts you are invited to place me on ignore. Instead of helping the OP you’re just a nattering nabob of negativism.
OK, I’ve been writing English natively now since I was about 5… so just on half a century. I’ve got the hang of it now.
I’ll take just one of your statements:
“CDNs cannot improve performance of a site that isn’t optimized, and if you do optimize it, you don’t need a CDN.”
Well, yes they can, and yes you do. By…
So yes, you do need a CDN to deliver graphically rich content. You’ve handed the job over to a supplier who specialises in it.
And yes, you do need a CDN to protect the available bandwidth on your server.
Maybe you’re based in the USA, and don’t see these things. It would explain your quoting Spiro Agnew at me. However, the OP - and myself - certainly aren’t.
You are wrong. Maybe it’s you who should learn to read. And learn a wee bit more about server tuning and content delivery to extend the scope and relevance of your advice.
[quote=“GreenGecko, post:15, topic:8710”][size=xx-small]
OK, I’ve been writing English natively now since I was about 5… so just on half a century. I’ve got the hang of it now.
I’ll take just one of your statements:
“CDNs cannot improve performance of a site that isn’t optimized, and if you do optimize it, you don’t need a CDN.”
Well, yes they can, and yes you do. By…
So yes, you do need a CDN to deliver graphically rich content. You’ve handed the job over to a supplier who specialises in it.
And yes, you do need a CDN to protect the available bandwidth on your server.
Maybe you’re based in the USA, and don’t see these things. It would explain your quoting Spiro Agnew at me. However, the OP - and myself - certainly aren’t.
You are wrong. Maybe it’s you who should learn to read. And learn a wee bit more about server tuning and content delivery to extend the scope and relevance of your advice.[/size]
[/quote]You’re quoting CloudFlare propaganda almost verbatim. And completely ignoring the fact that if a site is on a slow machine, the CDN does little to help speed. I’ve yet to see any CDN improve first byte time. That is because it cannot do that.
It is my opinion based on EXPERIENCE that you don’t NEED a CDN. Notice the operative word, NEED.
You DO need to slim down a fat page, every time as a first step to fixing a slow website problem. Hopefully we can agree on that very simple, common sense basic.
I concentrate on the basic, simple things a typical site owner can do, first. At NO time have I told anyone not to take your advice as well. But cleaning up a fat site does much more than might meet the eye at first.
Good example: When a site owner complains to his shared hosting about his slow site, you well know the first thing they are going to do is find ways to blame HIM. But if the site is optimized, is svelte and is taking advantage of caching and compression, that’s a BIG area of blame they try to use, gone. I’ve even seen on many occasions, hosts blaming use of a CDN for their slow machine!
I try to help people eliminate the simple stuff first. Works every time it is tried.
And the quote was William Safire, incidentally.
No, a CDN will not affect TTFB, but - once again - the locality and size of pipe will affect delivery performance. Some parts of the functionality of a basic CDN aren’t propaganda, but physics… speed of light and all that.
By the way, lowering the size of static resources won’t change the TTFB either: the client’ll still be waiting just as long for the html to be generated, then getting it delivered (along with the same number of files in parallel - as soon as it knows what others to get).
This is a graph of internet traffic: the slashdot effect… well mainly twitter in this case, but you know what I mean. Just think what that would be performing like if this server wasn’t using a CDN. Registering nearly 200Mbit/s over a 5 minute average, and yet still delivering a hefty 3MB page (using over 200 files) to a (local!) client inside 5 seconds.
No I didn’t write it, I just deliver it in a timely manner.
ngx_pagespeed is next for this site, but the resources will still be delivered via a CDN. It might slow the TTFB by the odd few MS ( and the extra admin involved is terrible with a non-technical client ), but the html will still be the same size. However, the 1.3MB/page saving to the client is where postprocessing their images is really worthwhile - 1 second off 5, rather than your 0.5 off 17 seconds.
And the improvements are above the fold, too.
As far as Windows vs Linux, they can both perform well. Scaling Nginx is a lot easier for ME but that’s mostly because I don’t have a lot of experience tuning an IIS install. It looks like the site has a lot of custom back-end application logic so I’d recommend just looking into instrumenting and improving that. New Relic has a Windows agent that can probably tell you what in the code is the slow parts. Wordpress is NOT a solution. Yes, they may have a theme that is lightweight but if you’ve hand-built an app then it makes no sense whatsoever.
We should probably fork the CDN discussion off to a separate thread but I’ll weigh in with my 2c based on a lot of history running huge global sites as well as small regional ones.
If you are serving content to a fairly small region (within just the US, Just within Europe or even a single country) and your server is hosted fairly centrally to that region then a CDN isn’t necessary and may actually hurt things. If you are serving traffic globally then a CDN is CRITICAL to performance.
When you start talking about India (or Australia) → US you start getting round trip times on the order of 1/4 second. Every socket connect and request has to pay that round trip cost but the real killer is in TCP slow start. For each new connection you can only deliver 4-15KB (depending on server TCP config) before having to make another round trip and it doubles for each additional round trip. Delivering a useful amount of content ends up requiring a lot of those round trips and your get fetch times measured in seconds even for small resources.
CDNs can also provide a lot of other helpful services that aren’t directly related to the perf of serving a single page but do seriously affect the scalability of the system. If you serve a lot of static content you can offload all of that bandwidth (and qps) onto a CDN which gives you a lot fewer servers to manage. They can also provide “evergreen” failovers to static pages in the case that your origins go down.
Yes, you are handing off some responsibility and adding a dependency but all of the major CDN’s tend to have better uptime than individual hosting (or your upstream providers).
You shouldn’t use them as a crutch because they can’t solve the “10MB and 400requests” problem (though they will make it look better in something like keynote or gomez) but they are an absolutely critical part of a high performance global site.
[quote=“GreenGecko, post:17, topic:8710”]
No, a CDN will not affect TTFB, but - once again - the locality and size of pipe will affect delivery performance.
[/quote]We can tit for tat all day, but the main point you seem to still be missing is I am saying if your site is optimized, and it’s a small site anyway, you don’t NEED a CDN. NEED being the operative word.
And the size of the pipe really is irrelevant if the internet service of the visitor is small pipe, and especially if there is a TTFB problem needing addressed. If you know a CDN won’t help TTFB, why recommend it then? Let’s fix the fat site and the TTFB problem first, is my idea.
I do not deal in theoretical, ephemeral high brow concepts when it comes to helping someone with their slow site. I stick to the objective concrete, nuts and bolts, SIMPLE things the person can do himself - right away - to improve performance. I do not say stuff like, “I don’t know, maybe it’s this maybe it’s that” like you had in your first reply to this thread. I go right to the meat of a situation with things I KNOW about, that help.
I could show you a dozen examples of sites I have optimized for people which had CDNs on them when the work started and were terrible performers, which now are excellent performers globally and don’t use a CDN any longer. I am not speaking from theory, I am speaking from experience of actually optimizing many sites.
There’s no reason for us to quibble and fight, we’re both trying to help people, volunteering our time and asking for nothing in return. Hopefully you can respect that too.[quote=“pmeenan, post:18, topic:8710”]If you are serving content to a fairly small region (within just the US, Just within Europe or even a single country) and your server is hosted fairly centrally to that region then a CDN isn’t necessary and may actually hurt things. If you are serving traffic globally then a CDN is CRITICAL to performance.
When you start talking about India (or Australia) → US you start getting round trip times on the order of 1/4 second. Every socket connect and request has to pay that round trip cost but the real killer is in TCP slow start. For each new connection you can only deliver 4-15KB (depending on server TCP config) before having to make another round trip and it doubles for each additional round trip. Delivering a useful amount of content ends up requiring a lot of those round trips and your get fetch times measured in seconds even for small resources.
CDNs can also provide a lot of other helpful services that aren’t directly related to the perf of serving a single page but do seriously affect the scalability of the system. If you serve a lot of static content you can offload all of that bandwidth (and qps) onto a CDN which gives you a lot fewer servers to manage. They can also provide “evergreen” failovers to static pages in the case that your origins go down.
Yes, you are handing off some responsibility and adding a dependency but all of the major CDN’s tend to have better uptime than individual hosting (or your upstream providers).
You shouldn’t use them as a crutch because they can’t solve the “10MB and 400requests” problem (though they will make it look better in something like keynote or gomez) but they are an absolutely critical part of a high performance global site. [/quote]Thanks for this clear and informative, objective assessment of the CDN situation Patrick. You went right to the heart of the matter for me - way too many people think a CDN is a “magic bullet” for every ill a site might have, recommend a CDN in knee-jerk fashion, and too many people take that advice thinking they fixed everything. People tend to gravitate towards the quick and easy solution when really they need to roll up their sleeves and go to work actually optimizing their site.
The OP wanted to know the root cause of his problems. I defined the root cause correctly, as a fat page. He slimmed the page down and improved the issues - he need only slim it down some more to see further improvement.
Hi All,
http://www.webpagetest.org/result/140515_57_7GD/ this is my newest report where I have compressed the images but still the load time is very high. I have also noticed that combine.js file is taking a lot of time. This is the same file where we have combines our all js files as per the recommendation. Let me know what to do now.
