

How Facebook can avoid losing revenue when they switch to always-on SSL - rmhrisk
http://unmitigatedrisk.com/?p=255

======
aes
Not really; as they say in the post itself, "Facebook’s business is different
than Amazons and the impact on their business will be different."

Amazon's core business is selling stuff to customers: additional latency might
occasionally turn away a customer. In Amazon's scale, that's a million-dollar
opportunity.

Facebook's core business is having users click on ads: at first, latency's
role there might seem insignificant, but it is an interesting intellectual
exercise to figure out whether it really matters in Facebook's scale.

Even more interesting would be if you had some data to show precisely how
much.

------
fleitz
Testing one piece of an overall picture and extrapolating from that is a great
way to produce wildly inaccurate data.

Amazon may lose 1% of sales for every 100 ms, but I doubt Facebook will lose
1% of logins for an extra 100 ms on the landing page.

Since Facebook makes most of it's money from people scrolling down the feed,
and SSL doesn't introduce scroll latency, this should have exactly zero impact
on revenue.

Also, 4111 ms is insane, I have SSL enabled on Facebook and it certainly does
not take 4 seconds to load. Maybe maybe perhaps it might take 4 seconds on a
completely fresh install of a browser, but in that case you're also going to
be downloading a huge amount of assets.

This post is typical link bait, wildly inaccurate numbers, bs extrapolations,
and tangental references to real data followed by a mea culpa. Frankly, the
post can't possibly save Facebook 100 million because there's no data to
support the idea that Facebook would ever lose $100 million from this switch.

~~~
eurleif
>SSL doesn't introduce scroll latency

It introduces request latency, which could certainly add latency to Facebook's
infinite scrolling.

~~~
fleitz
Which would be a problem if you couldn't trigger infinite scroll before the
bottom of the page is reached.

Facebook is largely push driven, so one cleverly placed SSL gif in an email,
or simply opening a connection when receiving a push notification would
largely eliminate even these issues.

I'm dealing with similar issues right now with some of my projects and once
you start thinking you can eliminate a lot of SSL latency, for example in the
apps you can make a connection to the webserver immediately on app start up to
ensure DNS, SSL, etc latency is already taken care of, it's funny but the app
is probably faster because the predominant view that 'SSL is slow' causes
those who advocate for it to go the extra mile to ensure any latency is
effectively hidden.

Login has to occur over SSL anyway there's virtually no difference between SSL
and non-SSL as the vast majority of latency is caused by the first connection,
when you really get down to it and implement proper latency hiding techniques
there's virtually no difference between SSL and non-SSL, and especially not
for high traffic frequently visited sites with touch points across the web.

