> Also, speeding up the initial load times for internal users often does little to increase profits.
I used to be on the Performance team at Box. Our charter was to get the files page to load in under 1s for the median domestic (US) user.
Box is largely sold to CTOs, not the people using it. The folks demoing/testing/evaluating are almost always on fast computers with fast internet. That didn't negate our goal, though, for a few reasons:
1. It turns out that lots of business users fly on airplanes. If you have to store/send a file and the app loads too slowly, you'll just use Dropbox or GDrive, or the OneDrive that Microsoft threw into your Office365 contract for free instead. And when _that_ loads instead, you'll remember it come contract negotiation time.
2. If all of the people who are supposed to use the app hate it, they'll actively avoid using it. If they have no choice, they'll complain and make sure decision makers are well-aware of how bad it sucks. That does eventually trickle up. With Box, folks would switch to email or flash drives, which makes security/compliance orgs salty, which introduces new, stricter limitations on your USB ports and email, which pisses off the execs paying for Box. Bad business software—contrary to popular belief—does eventually get phased out, just not on a short timescale.
3. Geography does matter. One project to bring the files page on Box from ~3s to ~2.3s ended up improving EU load times by multiple seconds in some cases. Companies who would have previously ruled Box after testing it once suddenly became meaningful prospects.
4. Sites that load slowly usually load slowly because of underlying complexity. That complexity makes the code harder to change. The slowness and the ability to make meaningful improvements to the site in other areas are directly linked. In 2014, I realized we'd picked almost all of our low-hanging (performance) fruit and pushed a full rewrite/redesign. It turned out to be one of the biggest software ships Box has had in the last decade (see "All New Box" [0]), and was a huge boon for sales and marketing. Something something life gives you lemons. Nobody plans on making their site slow, "not investing in a rewrite" makes no sense in the real world.
It's also worth calling out that this is woefully inaccurate:
> make very little difference to most users as they visit the site every day and have most of it in cache
If you're a serious company that releases software changes regularly (Box had ~nightly releases when I worked there), no, your users will not have the assets cached. One small JavaScript change (bug fix, feature, whatever) invalidates the cache.
We spent many man months getting our third party libraries into a "vendor" bundle that didn't change with meaningful frequency, but that accounted for less than 30% of total JS payload. With the exception of weekends and Mondays, you could be guaranteed to load a few hundred kilobytes of fresh JavaScript every morning. Organizations with CD would be in a worse situation.
But in the real world, the experience feels worse than it is: the times your cache is the least fresh are the times when you're most likely to notice the slowness. You just paid for Gogo in-flight wifi, you just came back from vacation or sick leave, you just opened your laptop at a customer site.
[0] https://blog.box.com/introducing-all-new-box-where-all-your-...
I used to be on the Performance team at Box. Our charter was to get the files page to load in under 1s for the median domestic (US) user.
Box is largely sold to CTOs, not the people using it. The folks demoing/testing/evaluating are almost always on fast computers with fast internet. That didn't negate our goal, though, for a few reasons:
1. It turns out that lots of business users fly on airplanes. If you have to store/send a file and the app loads too slowly, you'll just use Dropbox or GDrive, or the OneDrive that Microsoft threw into your Office365 contract for free instead. And when _that_ loads instead, you'll remember it come contract negotiation time.
2. If all of the people who are supposed to use the app hate it, they'll actively avoid using it. If they have no choice, they'll complain and make sure decision makers are well-aware of how bad it sucks. That does eventually trickle up. With Box, folks would switch to email or flash drives, which makes security/compliance orgs salty, which introduces new, stricter limitations on your USB ports and email, which pisses off the execs paying for Box. Bad business software—contrary to popular belief—does eventually get phased out, just not on a short timescale.
3. Geography does matter. One project to bring the files page on Box from ~3s to ~2.3s ended up improving EU load times by multiple seconds in some cases. Companies who would have previously ruled Box after testing it once suddenly became meaningful prospects.
4. Sites that load slowly usually load slowly because of underlying complexity. That complexity makes the code harder to change. The slowness and the ability to make meaningful improvements to the site in other areas are directly linked. In 2014, I realized we'd picked almost all of our low-hanging (performance) fruit and pushed a full rewrite/redesign. It turned out to be one of the biggest software ships Box has had in the last decade (see "All New Box" [0]), and was a huge boon for sales and marketing. Something something life gives you lemons. Nobody plans on making their site slow, "not investing in a rewrite" makes no sense in the real world.
It's also worth calling out that this is woefully inaccurate:
> make very little difference to most users as they visit the site every day and have most of it in cache
If you're a serious company that releases software changes regularly (Box had ~nightly releases when I worked there), no, your users will not have the assets cached. One small JavaScript change (bug fix, feature, whatever) invalidates the cache.
We spent many man months getting our third party libraries into a "vendor" bundle that didn't change with meaningful frequency, but that accounted for less than 30% of total JS payload. With the exception of weekends and Mondays, you could be guaranteed to load a few hundred kilobytes of fresh JavaScript every morning. Organizations with CD would be in a worse situation.
But in the real world, the experience feels worse than it is: the times your cache is the least fresh are the times when you're most likely to notice the slowness. You just paid for Gogo in-flight wifi, you just came back from vacation or sick leave, you just opened your laptop at a customer site.
[0] https://blog.box.com/introducing-all-new-box-where-all-your-...