How Facebook can avoid losing revenue when they switch to always-on SSL
unmitigatedrisk.com
unmitigatedrisk.com
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.
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.
It introduces request latency, which could certainly add latency to Facebook's infinite scrolling.
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.
That said I doubt anyone would argue that performance doesnt have an impact on their bottom line, more over the three changes I mentioned would have a real and positive impact on their performance.
As for measuring performance on first visit, that's pretty standard stuff but again I made note in the article of the bu that later visits would be faster due to caching and session re-use.
In the end the goal was to get people thinking about how their SSL configuration choices affect their sites performance not just their security -- there just isn't enough conversation about this stuff.