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

121–130 of 181 posts

Re: Fastly S-1

#121

Post by AYBABTME »

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?

The latencies stack up for any web page. It's not like "oh this file was served 5ms sooner", it's an accumulation of latencies over all assets, and the interactions, that are required to present an experience to a user.

Also, latency measured at the server is amplified once its received by the browser. And when the user's connection isn't great, all this is worsened. It quickly adds up. In fact, it doesn't "adds" up, it "multiplies" up.

Re: Fastly S-1

#122

Post by nyc_pizzadev »

useful wrote: post #51
reza_n wrote: post #29

Earlier quoted context omitted.

Edge facilities are warehouses in regional locations with excellent backbone connectivity, basically your modern datacenter. Cellphone towers can probably host a few racks, that's not a profitable business and its not "internet scale". If the regional datacenter has a 15ms ping to each tower in the region, then you have pretty good coverage.

I think you underestimate what the edge will become. There are already startups trying to store your data at your house, cellphone tower, isp, etc. In ways where there is no central store or in ways that everything is eventually consistent. Computing at the edge is a very interesting topic.

For an edge to work, you need security. That means transport encryption which requires certs. I think this fact alone will keep the edge at modern secured datacenters. There is limited physical security at cell sites. Even less at the users home. This could mean there is no more transport encryption for this kind of edge. Or even worse, private key loss.

Not saying no here, just pointing out a very large concern.

Re: Fastly S-1

#123

Post by [deleted] »

tylermenezes wrote: post #52

As a user, Fastly is really, really good. Akamai is the only serious competitor, but they are a lot more traditional in their sales and configuration. (You can theoretically use Azure as a middleman as some have pointed out, but they don't support custom SSL, and configuration changes take literally hours-to-days to propagate.) Cloudflare is fine but they are still an order of magnitude slower, which is why we switch…

[deleted]

Re: Fastly S-1

#124

Post by [deleted] »

anonymoushn wrote: post #116
tylermenezes wrote: post #97

Earlier quoted context omitted.

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. Disclosur…

[deleted]

Re: Fastly S-1

#126

Post by treis »

edmundsauto wrote: post #120
treis wrote: post #114

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

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

Which is why I asked the question in the way that I did. I buy that a slimmed down webpage loading 10 ms faster on average will increase conversions because that makes the site usable for the visitors on bad connections. Moving to a CDN doesn't have that impact. It shaves off 10-100ms across the board.

Re: Fastly S-1

#127

Post by kyledrake »

Jgrubb wrote: post #118
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.

It's part of why I don't get it. Large companies have multiple competitors to negotiate with, driving down prices (and this does not look to change anytime soon, it's dropping 40%/year for transit).

We're talking about an S-1 here. Where's that growth going to come from? Cannibalizing Akamai is not a long term IPO strategy.

Re: Fastly S-1

#128

Post by sajal83 »

treis wrote: post #109
huac wrote: post #85

Earlier quoted context omitted.

200ms is human reaction time, you can definitely notice it; the rule of thumb is 100ms https://www.pubnub.com/blog/how-fast-is-realtime-human-perce...

Your cite says that < 1s is "for users to feel they are interacting freely with the information". Even a 400ms round trip is well within that limit.

Most, if not all websites require more than one round trip.

Re: Fastly S-1

#129

Post by [deleted] »

nyc_pizzadev wrote: post #122
useful wrote: post #51

Earlier quoted context omitted.

I think you underestimate what the edge will become. There are already startups trying to store your data at your house, cellphone tower, isp, etc. In ways where there is no central store or in ways that everything is eventually consistent. Computing at the edge is a very interesting topic.

For an edge to work, you need security. That means transport encryption which requires certs. I think this fact alone will keep the edge at modern secured datacenters. There is limited physical security at cell sites. Even less at the users home. This could mean there is no more transport encryption for this kind of edge. Or even worse, private key loss. Not saying no here, just pointing out a very large concern.

[deleted]

Re: Fastly S-1

#130

Post by doppel »

kyledrake wrote: post #127
Jgrubb wrote: post #118

Earlier quoted context omitted.

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

It's part of why I don't get it. Large companies have multiple competitors to negotiate with, driving down prices (and this does not look to change anytime soon, it's dropping 40%/year for transit). We're talking about an S-1 here. Where's that growth going to come from? Cannibalizing Akamai is not a long term IPO strategy.

At my previous job, we had Fastly as a potential new CDN provider set up against our existing CDN provider and two other new potentials. After a few rounds of calls for bids, Fastly won out.

Based on my experience with the other providers they were also, by a large margin, the most modern - it felt like moving from a 2008 integration to a modern, fully RESTful API with great documentation and decent UI.

This is all anecdotal, but they did combine a great technical platform with great support. If transit prices are the same or similar for all providers in that size category, they have to fight on features and support instead.

Post reply on HN