
Why App Speed Matters: Revenue - jpsaccount
https://fly.io/articles/why-fast-pages-are-important/
======
birken
If fly.io is serious about their marketing, this is not the way to do it. Find
a really slow website that sells something, give them your service for free
and run half the traffic through your fast version vs their slow version. Show
me how much money they made in increased sales vs the amount of time it took
to implement and the ongoing costs of your service. I'm pretty confident the
math won't work out, but I'd be open to being convinced. Trotting out the 10
year old Google and Amazon studies about sub-1% gains isn't the way to do it.

For the vast majority of startups or websites, there should be 50 things on
your to-do list that have the potential to increase your conversions more than
1-2%, and your time is almost certainly better spent working on those things
than adopting a service like this. I know engineers like taking the same thing
and making it faster, it is fun and satisfying, but it almost certainly isn't
the best use of your time when it comes to the bottom line. And that is
assuming making your site faster actually will increase conversions by any
meaningful amount, which is a big _if_ (very old and very specific studies be
damned!).

~~~
mrkurt
(disclaimer, I work on fly)

This is really just meant to be decent content, not a sales pitch. We
obviously want to grow our business so we write about stuff that's close to
what we do. Most people are really uninformed about site performance (still),
you'd be shocked how many people don't even know about the 10 year old
studies.

Also note, Amazon's -1% per 100ms of latency holds up for the ecommerce
companies I've worked with. It's not a small number for any company, and we're
actually really cheap for companies with a high value per user (like
ecommerce! or saas!). You probably wouldn't serve billions of page views
through fly with very cheap ads, though.

That said, I pretty much agree with you. We'll only succeed if we can keep
proving that we're valuable. It's part of why we give enough traffic away for
free that you can legitimately test us out. I don't particularly want people
using us if they don't get any value out of it.

~~~
sokoloff
About 5 years ago, I undertook a significant web performance effort on an IR
top 100 e-commerce property. We sped the site up significantly and, being the
good data nerds that we were, split-ran the hell out of it and found a zero-
point-zero (sub-noise) difference in average session value, conversion rate,
and average order value.

Believing those then 5-year old studies, we went in the opposite direction and
intentionally slowed the site down in multi-variate testing. Out to 1000ms of
intentional slowdown per dynamic page, we saw zero-point-zero change in ASV,
CR%, and AOV.

We kept the faster experience, because "hey, why not?" and we'd paid all the
NRE for it anyway, but the project was a technical success but a big bust
versus business case.

~~~
gingerlime
That's really fascinating! What about things like Google ranking that's
supposedly also affected by page speed? (Or maybe it's not? I have a very
limited SEO knowledge)

~~~
hayksaakian
it's only really affected from a negative perspective (think: so slow that
google can't crawl your website or load it).

Anything faster than 2-3 seconds has very diminishing if not 0 returns.

------
misterbowfinger
Not true. Faster isn't _always_ better. If some features seem to take a lot of
time, it appears to the user that it's "working". Take a website I hate a lot
- TurboTax. A lot of the wait times between transitions is incredibly long.
But I'd bet money that it increased conversions.

Yes, it's more of a UX issue than an engineering one. But users don't give a
shit. If something appears slow, no one knows/cares if it's an animation or a
slow server.

~~~
kornish
While you're right that people sometimes value operations that take time,
that's certainly an edge case - in general, snappiness leads to a better user
experience.

Also: if an operation is fast, you always have the option to make it appear
slower. The inverse is not true.

~~~
misterbowfinger
> in general, faster operations leads to a better user experience

That's just too general of a statement. That's like saying a landing page with
a hero image is, generally, a better page. It's a good place to start, but
it's just bad advice in the long-term.

I agree that response times from the _backend_ should be fast, especially the
initial response (as the article mentions). But anything on the frontend
experience should be judged on a case-by-case basis.

~~~
BinaryIdiot
> That's just too general of a statement.

Every time I've ever conducted user experience testing the results have always
been _far_ more positive the faster the app or page is. In fact, while it's
still only anecdotal, I have never seen a decrease in any of the overall
measurements of a user study where, between two versions, the speed of the app
or page improved and little else changed.

Honestly I think it's a great general statement. I'm sure there are exceptions
but that's the case with almost any general rule of thumb.

> That's like saying a landing page with a hero image is, generally, a better
> page.

No, not at all. Speed isn't everything and no one was suggesting that. A
faster application, however, is always better than a slow one _as long as_ you
are comparing apples to apples.

With the way technology works nowadays it's actually very doable to get the
75th percentile to load really, really fast. But it's not without effort and
earlier work may need to be redone, something many avoid at all costs.

------
ultrasandwich
It's a little thing, but 14.4kb/s should really be stated as kbit/s.
14.4kbit/s is 1.8kB/s. Looking at this reminded me how fascinating the
Wikipedia entry for "modem" is [1]. Apparently "The first 9,600 bit/s modem
was developed in 1968, and sold for more than $20,000."

[1] -
[https://en.wikipedia.org/wiki/Modem](https://en.wikipedia.org/wiki/Modem)

~~~
goodroot
Thanks, ultrasandwich. I have fixed this in the OP.

------
skybrian
On the other hand if you want to reduce the time you spend online, as a user
you should prefer slower websites.

~~~
BinaryIdiot
I'm not sure I follow. If I can do what I want to do online and do it fast,
then I run out of things to do much faster and I can get off the internet for
a bit or do anything else.

~~~
skybrian
You mean you've reached the end of the Internet? What's it like? :-)

Entertainment websites tend to keep providing more things to do, so you never
run out. You can read them all day, like watching TV.

To help break the habit, It might be helpful to interrupt the temptation to
read just one more thing, by making it cost a bit more. You don't want it to
be effortless.

~~~
BinaryIdiot
Hmm. Fair enough.

------
rsp1984
Totally off-topic but I always take slight offense when headlines talk about
"apps" when the actual meaning is websites or web services.

For example I clicked on the headline expecting content about the speed of
Android / iOS apps (which is something I care about professionally), but then
was disappointed (and frustrated) to find that the actual content is all about
web stuff.

When you mean "Web App", say "Web App"!

~~~
goodroot
That's really great feedback. I wrote something about API building a couple
weeks ago without specifying I was referring to a _web_ API. I'll try to be
much more conscious of this going forward. Thanks for the expression.

------
sbov
Note that the fly.io docs let you know that the bandwidth price is per GB, but
the pricing page doesn't let you know that the price is per GB.

~~~
mrkurt
Whoops, something got chopped there that shouldn't have. Thanks for the heads
up.

------
skyisblue
What's the difference between fly.io and any other CDN? Can it serve dynamic
encrypted data from the backend to the edge faster?

~~~
mrkurt
We're designed specifically for dynamic apps. In fact, we tell people to use
traditional CDNs for static files. You can think of us as a combo load
balancer and edge.

This means we do things like handle unlimited ssl certs (for apps that support
custom hostnames), do load balancing on app instance, including geo load
balancing, and even run code at the edge.

My favorite thing we do is app friendly caching. We're "aware" of app users
and can handle caching logic well beyond the http cache control and vary
headers.

~~~
ollerac
Do you support Meteor.js as a back-end as long as it's hosted on Heroku?

------
dna_polymerase
Well how much do I gain by a bit more speed after you took your horrendous 18
cents per gb flowing out?

------
newzzy
your site (not blog) has a bad scrolling experience in Firefox on Android

~~~
mrkurt
I dug into this a little bit and can't figure out why. We don't actually do
anything with JS that would affect scrolling. If you feel like emailing me
with more details I'll keep lookin'.

~~~
pharrington
edit: i'm illiterate

from articles/assets/js/index.js:

    
    
        $.fn.arctic_scroll = function (options) {
    
            var defaults = {
                elem: $(this),
                speed: 500
            },
    
            allOptions = $.extend(defaults, options);
    
            allOptions.elem.click(function (event) {
                event.preventDefault();
                var $this = $(this),
                    $htmlBody = $('html, body'),
                    offset = ($this.attr('data-offset')) ? $this.attr('data-offset') : false,
                    position = ($this.attr('data-position')) ? $this.attr('data-position') : false,
                    toMove;
    
                if (offset) {
                    toMove = parseInt(offset);
                    $htmlBody.stop(true, false).animate({scrollTop: ($(this.hash).offset().top + toMove) }, allOptions.speed);
                } else if (position) {
                    toMove = parseInt(position);
                    $htmlBody.stop(true, false).animate({scrollTop: toMove }, allOptions.speed);
                } else {
                    $htmlBody.stop(true, false).animate({scrollTop: ($(this.hash).offset().top) }, allOptions.speed);
                }
            });
    
        };
    
      var $document = $(document);
    
        $document.ready(function () {
            ...
            $(".scroll-down").arctic_scroll();
            ...
        });

~~~
mrkurt
He said "not blog". :)

~~~
pharrington
oops

------
JosephRedfern
A minor thing, but it bugged me -- 0.74% of 3.5 billion searches is 25,900,000
searches, not 259,000,000 (as mentioned on 7th paragraph).

~~~
OriginalPenguin
That's not minor, it's an order of magnitude difference! ;)

