Page Speed often gets confused for a few things. Here's how it really breaks down:
1) App Server Response. How long it takes your application to issue a successful response?
2) Network Speed. A server response for a 500MB file is fast, but downloading it isn't
3) DOM Processing. Great, you've reached the user's browser, now how long does it take the page to load into the DOM
4) Page Rendering. Only done after all the "assets" are downloaded. This is usually the final state of the page.
Yes, if your Google Page Speed number is super high, you've got a problem. But it helps to be able to break down each step of that number, to identify where the bottleneck is.
Also, as the author mentioned, be aware that every computer is different. One really slow internet connection will drastically affect your page speed averages.
A small benchmark for you, one of my applications has an average app server response time of about 350ms. But, one page has an average Page Speed of 5 seconds. I'm diagnosing why that page is so slow, it looks like a few external assets are causing the slowdown.
The hard numbers don't tell the whole story, though.
For example, something like Kayak.com takes a very long time (~10-15 seconds) to load a results list. However, the whole experience feels very fast because the data layer is separated from the presentation layer, and the presentation layer comes up very quickly, with data allowed to load incrementally "below the fold".
Put another way, part of "page speed" is also how fast the user can start interacting with any of it, even if it's just to start looking at the initial search results.
There are a couple of thing missing in your list, and those are quite important:
Number of requests needed to load all your assets, latency and blocking.
Browsers only load limited number of assets in parallel, so if you have a lot they will wait. Latency makes things bad (especially on mobile), but in case you have a lot of assets it makes it even worse. Also, keep in mind, that most often it is the latency that kills the speed of the loading. It does not really matter if it takes 20 or 60ms to download your asset if the latency is 10x that.
Blocking: your #4 is not exactly right, browsers can start rendering the page at once, but if you try to load scripts first they will block rendering. Hence the importance of understanding where to request your css and js and how to load them.
Agreed, my list was more of a general view of the whole process. Asset latency, blocking and requests all fit in Page Rendering in my mind. Actually, DOM processing and Page Rendering are very closely related.
Actually, using your logic, #4 is right. I worded it wrong, "Only done after all the "assets" are downloaded" should be "Only completed after all the "assets" are downloaded". More often that not, you'll see high (6 seconds+) Page Speed scores because Page Rendering isn't completed due to missing or slow assets.
There are a lot of issues with using Google Analytics for collecting performance data. As mentioned, their use of averages leads to a lot of problems and issues from outliers. GA heavily samples (1% by default) & only collects timing data from browsers that support Nav Timing. If you're looking for a way to collect more accurate timing data, Torbit Insight (http://torbit.com) is free and offers 100% sampling, histograms, medians, percentiles, and lots of breakdowns by browser, geography, etc.
I try to keeps our numbers under 1 second, although we only target the USA.
The biggest improvement to our page load speed came from using a php cache (xcache) and specifying client cache lifetimes. The first got us to around 1 second and the second meant that the best case (which happened often) was about 0.5s
I personally think that even one second is way too long. Especially if it's about web shopping or any other service which actually requires user to browse content, and not read long articles or so.
I just complained to one online cartoon about this, changing from strip to strip takes 1,5 seconds and that's super slow afaik. It really annoys users.
I think he means server -> client full rendering over "3000ms rendering by the server" (for example if you were using PHP a page taking 3000ms to load before even starting to render on the client is insane).
The discussion actually misses two critical aspects - network topology and device usage in 3rd world countries.
Where is the speed issue coming into play? There are 3 areas of concern
1) App server and backbone speed
- This what the discussion is centering on. CDN is good.
2) Connection speed between client and ISP
- This is a critical issue when dealing with performance in
3rd world countries. CDN will NOT help here!
- As an example, there is likely a 200-300ms roundtrip from
your servers to the CDN and customer ISP. By using a CDN,
you remove this 200-300ms. If the customer is using GRPS
with 5000ms latency, your CDN has done almost nothing!
3) Customer's processing speed
- If your customer is using an old blackberry phone, and your
page is using complicated javascript, it could take 30+
seconds for the page to render for the user, even if the
content were local.
A way to get a grasp of the situation is not to filter your page load speed by country, but to drill down further and also use the user agent. Filter by country + user agent should let you know if the slowdown is caused by old Nokia phones, or if it's across Firefox and Chrome also.
In many cases, the solution is often to have a mobile WAP-alike site that has no fancy resources and just text and html fields. You can use javascript to detect if the page is loading slowly (15+ secs), and pop up a link to the special wap site.
1. Is there any tool where I can check the page speed of a website.
2. for a site like http://syncfin.com where i have to use 4 bright images, is there any particular format I should keep the images in. Basically when there are multiple heavy images to be loaded , what would be the best strategy to optimize the page speed.
thanks in advance for any pointers to relevant articles and tips.
you could load a small placeholder (1x1 solid-white .gif, etc.), load the massive images with javascript, then animate them in once they are loaded. still have to stick with the current setup when javascript is disabled though!
If you're having a problem with cache expiration use a remote monitoring app like CopperEgg[1] (free) or Pingdom[2] (paid). Not only will it monitor your site and send alerts if it goes down or is slow, it will keep your cache fresh and full.
Well...... for some reason I'm yet to even begin to understand (I have mailed the site, got no reply at all, but even so I assume its something my end, but it doesn't happen on any other site, weird...), HN takes about 30 secs to load any page, and I don't get the CSS either, but I still use the site regularly as I value the content.
Note that I'm on a broadband connection, but on the other hand I'm connecting from Romania, so about 100-300ms of latency come from my non-US ___location if the website doesn't use some kind of CDN.
You've been slowbanned. A moderator didn't like something you said and wants you to leave HN, but didn't feel that hellbanning you was appropriate. Instead, they want you to get frustrated with the slowness and give up.
I dont think so. I clicked logout, took 30 ish secs to log out. Loaded a new page, 30 secs, as "normal". Clicked log in, that simple page loaded very fast. Logging in took ages though. Nothing changed, except that login page loads as fast as any page should.
Most weird. I think it might be a problem getting the CSS, but I simply cant see why.
Edit:
Should add, I have not been notified in any way that this has or might have happened. I know of know reason why it should, I have always tried to respect this community. If it has happened behind my back, then I would be quite appalled. At the very, very least, I would expect to be told. And yes, I use a proper email account. Besides, I emailed the site and got no reply.
It is, so is hellbanning (which means your posts don't show up to anyone but you). If you suspect having been slowbanned, just log out; if the site suddenly loads super fast consistently, and slow when you log in, you know it's that. It's petty, and rather random, which is why there is zero process I guess (no "you have been banned because you broke rule X" etc., and zero moderator accountability). When I don't get a reply to posts of mine for a while, I usually to log out and look at my posts to make sure it's not yet another hellban. If you get hellbanned, just make a new account, but make sure you deleted all ycombinator cookies before you do. Be sure to get a laugh out of it, too, or the terrorists won.
That's pretty pathetic if true. If you're going to ban someone, just man up and ban them. Passive-aggressive methods like that feel like they're straight out of a playground. Although I guess some of silicon valley acts like a playground, so that makes sense.
I could prove it to you, I still should have the credentials for 5+ hellbanned accounts. I will admit I tended to be flamey at times, so I'm not saying it was entirely unfair; but it also made me feel like one-upping HN at times. I think a message along the lines of "your account has been suspended for a week, stop being a dick" would have worked much better than being punished in such a low way, without even knowing for what exactly. But I stuck around and realized there's plenty of great posters here, and looking how long an account lasts before stepping over some invisible line or other has become kind of a game for me. I got used to it ^^ The way I see it, if what you say doesn't make a person with power/privileges feel sore every now and then you're too tame :)
The point of hell-banning would be to make the user leave the community without him noticing that he was banned, because if he does notice, all he has to do would be to create a new account. This works by not showing his comments to others, which in return means that the user will not get any conversations going or any upvotes and pretty soon he'll start thinking that the others are ignoring him completely, which is in general a good incentive for someone to leave a community.
The problem with hell-banning is that for users that post a lot of comments, they'll soon realize that they are hell-banned and trolls (in particular) can only be stopped if they are genuinely ignored.
For this reason, if you want to stop trolls, slow-banning could be a good alternative by making usage of the site unpleasant. This way they can still interact with others, but it will be painful for them to do so.
I agree that these methods are passive-aggressive and shouldn't be used on non-trolls, even if such people do not comply with the community's guidelines. The problem with this site is that user accounts do not have emails attached ... as a much more effective method for making most users behave according to guidelines would be to send them a warning.
The only difference between a troll and someone who is misinformed or sloppy is intention; a troll is dense/wrong/mean on purpose, and not because they're actually ignorant or annoyed. It's an action a person can engage in; it's not really a type of person. But these days, "troll" often enough seems to just mean "too stupid to reason with", or is even just a cop out to not reason at all.. it's quite the convenient catch-all label that way.
"why did that user get banned?"
"they were a troll"
"ah, okay. that's fine then, seeing how I am not banned this must be totally legit. damn trolls!"
trolls (in particular) can only be stopped if they are genuinely ignored.
What if users had a killfile for their account? Seems more meritocratic than hellbanning at least, if I can just choose who I want to ignore or not, and if you can tolerate someone, then they're alive for you.
> The problem with this site is that user accounts do not have emails attached ... as a much more effective method for making most users behave according to guidelines would be to send them a warning.
Most sites have a capability where they can flash a message to a user the next time they log in. Such a message could link to the flagged comment in question and point out what was wrong about the comment.
But really, HN is not a democracy, or transparent, or really anything other than pg's playground. So it's up to him, and clearly he's chosen to put avoiding confrontation first.
This article is a great promotion for Cloudflare, but it does not really explain WHY page speed matters. Of course we all want our websites to load fast. I'd be more curious to see how the speed correlates with your conversion rates.
Google and Amazon have put out studies on this, and I wouldn't be surprised if Cloudflare has done so as well. Speed absolutely ties in to conversions.
Amazon's report: "Every 100ms delay costs 1% of sales"
Well, I understand it matters for Amazon and Google, but I'd be curious to see how it works in case of OP's website. Obviously it's going to be different from Amazon. I guess the subject is a little bit misleading.
I find myself visiting slow loading sites less often than snappy ones. The slow load times are one of the two big reasons why I stopped visiting The Verge.
1) App Server Response. How long it takes your application to issue a successful response?
2) Network Speed. A server response for a 500MB file is fast, but downloading it isn't
3) DOM Processing. Great, you've reached the user's browser, now how long does it take the page to load into the DOM
4) Page Rendering. Only done after all the "assets" are downloaded. This is usually the final state of the page.
Yes, if your Google Page Speed number is super high, you've got a problem. But it helps to be able to break down each step of that number, to identify where the bottleneck is.
Also, as the author mentioned, be aware that every computer is different. One really slow internet connection will drastically affect your page speed averages.
A small benchmark for you, one of my applications has an average app server response time of about 350ms. But, one page has an average Page Speed of 5 seconds. I'm diagnosing why that page is so slow, it looks like a few external assets are causing the slowdown.