Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fastly S-1

sec.gov

Post reply on HN
Print view View original

111–120 of 181 posts

Re: Fastly S-1

#111

Post by kyledrake »

Fastly's bandwidth prices are high to me: $0.12-$0.28/GB is 2007 rates for transit. Perhaps this is why when GitHub pages started capping bandwidth to lower limits they had also switched to Fastly? For a comparison, I pay less than $0.01/GB for a CDN right now, and the price of transit on average drops 40%/year so even that's above market rate now.

A lot of people (including Cloudflare) just give it out for free, making this really a space for enterprise plays, which at their size, have the clout to push for better rates across many similar competitors, or just running their own infrastructure.

I honestly just don't get the value add here. It really doesn't feel like an IPO play.

Re: Fastly S-1

#112

Post by jjeaff »

wongarsu wrote: post #105
icedchai wrote: post #98

Earlier quoted context omitted.

How do you know the 7% increase was due to Fastly and not some other small unrelated change to your web site? A few 10 ms makes no difference.

> A few 10 ms makes no difference. About a 1-2% difference per 100 ms seems well supported (e.g. [1]), at least if your page load time is already low enough. 7% is very high, but some effect is expected. 1: https://developers.google.com/web/fundamentals/performance/w...

I don't buy it. So what you are saying is 2% for every 100ms. So that means if we decrease page load time by 1ms, then we should expect to to see .02% increase in sales?

So if we do $10m annually, 1ms decrease in sales should boost sales by $2,000!

We would all probably agree that 1ms will make no statistical difference.

The problem with these studies is that most are dealing with much longer load times. Like 3 seconds vs 19 seconds! Obviously, that will make a HUGE difference. You can't then extrapolate that down to the millisecond.

The other problem is that many of these studies are basing their numbers on average load times. So they are comparing two groups and averaging load time. Group A averages 100ms faster than group B. And group B increased sales by 2%.

But what really happened is group A had 800ms load times across the board. And group be had 800ms load times for 98% of their page loads and 20,000ms on the remaining 2%.

So working with averages can be largely misleading.

I can't see the details of the 1 study that claims 100ms increments, but I'm very skeptical.

Re: Fastly S-1

#113

Post by dna_polymerase »

tylermenezes wrote: post #96
onlyrealcuzzo wrote: post #67

Earlier quoted context omitted.

Everything about what the top comment said seems like Fastly marketing propaganda. 7% increase in sales? With what sample size? With what confidence? How did you isolate variables? For reference, I work at a company with $110M in annual sales. We were planning to start using Fastly. For obvious reasons, we wanted to know how much of a net positive that would be for the business. So we wanted to A/B test it. For us, a…

You can Google my name if you think I'm working for Fastly. The only connection I have is that they are our CDN. They donate it, as we're a nonprofit, but I have zero obligation to say anything about them either way. 7% increase represents an increase in the number of students/parents purchasing tickets to our events. (It's not like they're spending more individually, but more people have been willing to give us mone…

> 7% increase represents an increase in the number of students/parents purchasing tickets to our events. (It's not like they're spending more individually, but more people have been willing to give us money.)

We got that part, but correlation doesn't always imply causation. Maybe that change was seasonal or just plain old growth not accounted for in your 7%?

Re: Fastly S-1

#114

Post by treis »

an_account_name wrote: post #99
sjwright wrote: post #58

Earlier quoted context omitted.

I find it difficult to believe that sales would be affected by a latency drop less than one tenth of a second. How did you isolate the variables?

No, this absolutely checks with my experience - I chase 5 and 10ms improvements all the time because we've measured and know it increases conversion. But it makes sense, too: if the metric here is average latency, that doesn't mean that some users didn't see a much more dramatic increase. Every tiny bit of frustration removed from the experience adds up.

>No, this absolutely checks with my experience - I chase 5 and 10ms improvements all the time because we've measured and know it increases conversion.

You've measured and know that a user seeing a 905ms load time converts more than one seeing 915ms?

Re: Fastly S-1

#115

Post by cagenut »

treis wrote: post #108
bogomipz wrote: post #93

Earlier quoted context omitted.

That statement is categorically false. One simple example is online gaming/MMOGs where a latency of 200 ms would be be a miserable experience. The upper bound often targeted for "acceptable interactivity" is somewhere between 100-130ms.

(1) I excluded gaming as something that is legitimately ping dependent (2) You can achieve 100-130 ms latency with a "like one data center per continent" sort of network. You don't need edge computing on hundreds or thousands of edge sites to achieve that.

I'm sorry but what are you talking about? Fastly has about 60 PoPs (physical locations). No one is talking about hundreds of thousands of sites. Even akamai, who made it one of their primary marketing metrics, only ever got into the thousands.

Re: Fastly S-1

#116

Post by anonymoushn »

tylermenezes wrote: post #97
foobarbazetc wrote: post #70

Earlier quoted context omitted.

CDNPerf is an okay way to get an overview, but not a great way to actually compare CDNs. That said, it’s not 10x or whatever. Maybe like 5-10% depending on location.

There are a number of features Fastly has which others (excluding eg Akmai) don't which make head-to-head comparisons more difficult. I have no doubt that Cloudflare is very fast in perfect conditions, but there were a much higher number of cache misses because there's less flexible configuration which did literally make the difference between 20ms vs 200ms in production.

Can you elaborate on this?

Enterprise customers are generally able to get their SE to set whatever cache key they like, and if that is insufficient they can use the worker cache API: https://developers.cloudflare.com/workers/reference/cache-ap...

As I understand it a charity may get the former thing for free through https://www.cloudflare.com/galileo/ , but the latter probably still has usage-based billing.

Disclosure: I work for Cloudflare.

Re: Fastly S-1

#117

Post by cagenut »

treis wrote: post #60
gmanley wrote: post #54

Earlier quoted context omitted.

It may not make sense if all your customers are in the US but locations like Australia and others very much have an issue with latency. Especially if the server they are hitting is around the globe.

NYC to Sydney is still only ~200 ms. That's probably in the realm of being noticeable but only barely. Even then, the real need is more like one server per continent rather than every cell tower.

Your numbers are wrong but your line of reasoning is actually the basis of how Fastly's network was designed to be different from Akamai's. There's a graph about it at the 2:40 mark in this video: https://vimeo.com/132842124

Re: Fastly S-1

#118

Post by Jgrubb »

kyledrake wrote: post #111

Fastly's bandwidth prices are high to me: $0.12-$0.28/GB is 2007 rates for transit. Perhaps this is why when GitHub pages started capping bandwidth to lower limits they had also switched to Fastly? For a comparison, I pay less than $0.01/GB for a CDN right now, and the price of transit on average drops 40%/year so even that's above market rate now. A lot of people (including Cloudflare) just give it out for free, mak…

That's the card rate. Their bigger customers aren't paying that.

Re: Fastly S-1

#119

Post by treis »

cagenut wrote: post #115
treis wrote: post #108

Earlier quoted context omitted.

(1) I excluded gaming as something that is legitimately ping dependent (2) You can achieve 100-130 ms latency with a "like one data center per continent" sort of network. You don't need edge computing on hundreds or thousands of edge sites to achieve that.

I'm sorry but what are you talking about? Fastly has about 60 PoPs (physical locations). No one is talking about hundreds of thousands of sites. Even akamai, who made it one of their primary marketing metrics, only ever got into the thousands.

The GP is talking about putting them in cell phone towers.

Re: Fastly S-1

#120

Post by edmundsauto »

treis wrote: post #114
an_account_name wrote: post #99

Earlier quoted context omitted.

No, this absolutely checks with my experience - I chase 5 and 10ms improvements all the time because we've measured and know it increases conversion. But it makes sense, too: if the metric here is average latency, that doesn't mean that some users didn't see a much more dramatic increase. Every tiny bit of frustration removed from the experience adds up.

>No, this absolutely checks with my experience - I chase 5 and 10ms improvements all the time because we've measured and know it increases conversion. You've measured and know that a user seeing a 905ms load time converts more than one seeing 915ms?

A 10ms average improvement could mean 1 in 1000 customers went from 10s to 1s without any other change to other customers.

This is easily possible if you have a highly distributed customer base, and/or some small segment of your customers don't have good upstream peering with your provider.

Post reply on HN