

Page speed really does matter - gingerjoos
http://www.gigpeppers.com/page-speed-really-does-matter-2/

======
ericcholis
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.

~~~
rimantas
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.

~~~
ericcholis
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.

------
joshfraser
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.

~~~
Benferhat
Torbit looks great, thanks.

------
frozenport
Isn't 3 seconds a lot?

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

~~~
cleverjake
3 < 20, especially when talking about dialup/dsl lines in Nigeria

~~~
ohwp
But that only accounts for download size.

------
RyanZAG
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.

------
DrJokepu
Off topic, but the as the sidebar refuses to resize it's really difficult to
read this on the iPhone.

~~~
3825
This is not a perfect solution but if you use Pocket or InstaPaper, add this
to your reading list and you should be able to read much more easily. :)

------
sh_vipin
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.

~~~
youngtaff
Use a RUM tool - Google Analytics is the easiest one but up the sample rate -
Torbit, LogNormal and others are available.

Use WebPageTest.org to carry out spot tests.

~~~
sh_vipin
Thanks youngtaff. I also googled a bit and found out <http://loadimpact.com> .
It is very good . I did analysis of my site (
<http://loadimpact.com/test/view/1262390>) on this and that shows the effect
of shared hosting on it. !!

------
driverdan
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.

1: <http://copperegg.com/>

2: <https://www.pingdom.com/>

~~~
maczyx
Pingdom also has free option.

~~~
damniatx
for only one site.

------
alan_cx
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.

Make of that what you will.

~~~
badgar
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.

~~~
jh3
I can't tell if this is sarcasm. Is slowbanning a thing?

~~~
neumann_alfred
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.

~~~
RyanZAG
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.

~~~
bad_user
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.

~~~
neumann_alfred
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!"

------
isalmon
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.

~~~
SquareWheel
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"

[https://sites.google.com/site/glinden/Home/StanfordDataMinin...](https://sites.google.com/site/glinden/Home/StanfordDataMining.2006-11-28.ppt?attredirects=0)

~~~
isalmon
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.

~~~
SquareWheel
I'm sure it varies by market, so the only way to know for sure would be to set
up an A/B test and introduce artificial slowness.

------
rednukleus
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.

------
kmfrk
Speaking of which, is enabling gzip in S3 still a pain?

~~~
dmpatierno
With S3, yes. However, the CloudFront CDN works great for gzip now with web-
backed distributions, assuming things are configured properly on your end.

------
chacham15
What tool are you guys using to get the notifications?

~~~
Cherian
Google Analytics alerts

------
dotborg
over 2 seconds is quite bad result,

when you make new website today using modern tools, page load should be below
1 second,

