5 ms·

I hate hearing these sorts of arguments when you have an inhouse business app served to a handful of repeat users. Reducing the payload size will make very litt

by xupybd 4y ago

I hate hearing these sorts of arguments when you have an inhouse business app served to a handful of repeat users. Reducing the payload size will make very little difference to most users as they visit the site every day and have most of it in cache. Also, speeding up the initial load times for internal users often does little to increase profits. Until it does it's hard to justify the work. That said it's worth aiming to keeps things as small as possible from the start. Just not investing in a rewrite.

LAC-Tech 4y ago
Ironically in house web apps would be the easiest to make lightweight. No ones going to complain that your dropdowns aren't sexy enough, so you can largely just use the browser.
bastawhiz 4y ago
> 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-work-comes-together https://blog.box.com/introducing-all-new-box-where-all-your-...
- SPBesui 4y ago
  This is an interesting and thorough response, and I liked reading it, but GP was talking about internal, captive-audience stuff. Box is an app you sell. B2B, yes, not B2C, so your users are “enterprise.” But it’s still a product that competes with others and that seems very unrelated to GP’s point.
  - bastawhiz 4y ago
    In that case, who is concerned with page size for those apps? The apps with bundle sizes that people complain about are almost exclusively from third parties. I've worked on some big internal apps, and almost none of them have payloads big enough to notice. If it ain't broken don't fix it.
    - SPBesui 4y ago
      > who is concerned with page size for those apps? That was kind of their point: No one is, so why bother with a lot of effort? > The apps with bundle sizes that people complain about are almost exclusively from third parties. Right, like Box. Not the internal apps they were referring to. > I've worked on some big internal apps, and almost none of them have payloads big enough to notice. That echoes my own experience. > If it ain't broken don't fix it. I think you’re agreeing with the person you responded to. It was just that Box wasn’t the kind of app they were talking about. All I was saying was that your response, while interesting, was not 100% relevant. It was still interesting, though!
- mxuribe 4y ago
  > ...Bad business software—contrary to popular belief—does eventually get phased out, just not on a short timescale... So true! But, man, that not-so-short timescale often is painful! :-)
- xupybd 4y ago
  Your points are all true but box is not at all the kind of app I was talking about. Box must be deployed to tens of thousands of users and likely operates in a competitive environment. I'm talking about the kind of app that exists in one organization, has 1 - 10 users, and is not a huge part of one persons job. Something like an EDI tool that sends invoices to that one creditor that requires some strange EDI format and only just makes up enough of your business for it to be worth while. Where the EDI was written 15 years ago and no one knows much about it. Then you get a new dev asked to make a small a change and comes back saying they need a week to improve its performance or shrink it's binary.

by xupybd 4y ago

LAC-Tech 4y ago

Ironically in house web apps would be the easiest to make lightweight. No ones going to complain that your dropdowns aren't sexy enough, so you can largely just use the browser.

bastawhiz 4y ago

> 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-work-comes-together https://blog.box.com/introducing-all-new-box-where-all-your-...

SPBesui 4y ago
This is an interesting and thorough response, and I liked reading it, but GP was talking about internal, captive-audience stuff. Box is an app you sell. B2B, yes, not B2C, so your users are “enterprise.” But it’s still a product that competes with others and that seems very unrelated to GP’s point.
- bastawhiz 4y ago
  In that case, who is concerned with page size for those apps? The apps with bundle sizes that people complain about are almost exclusively from third parties. I've worked on some big internal apps, and almost none of them have payloads big enough to notice. If it ain't broken don't fix it.
  - SPBesui 4y ago
    > who is concerned with page size for those apps? That was kind of their point: No one is, so why bother with a lot of effort? > The apps with bundle sizes that people complain about are almost exclusively from third parties. Right, like Box. Not the internal apps they were referring to. > I've worked on some big internal apps, and almost none of them have payloads big enough to notice. That echoes my own experience. > If it ain't broken don't fix it. I think you’re agreeing with the person you responded to. It was just that Box wasn’t the kind of app they were talking about. All I was saying was that your response, while interesting, was not 100% relevant. It was still interesting, though!
mxuribe 4y ago
> ...Bad business software—contrary to popular belief—does eventually get phased out, just not on a short timescale... So true! But, man, that not-so-short timescale often is painful! :-)
xupybd 4y ago
Your points are all true but box is not at all the kind of app I was talking about. Box must be deployed to tens of thousands of users and likely operates in a competitive environment. I'm talking about the kind of app that exists in one organization, has 1 - 10 users, and is not a huge part of one persons job. Something like an EDI tool that sends invoices to that one creditor that requires some strange EDI format and only just makes up enough of your business for it to be worth while. Where the EDI was written 15 years ago and no one knows much about it. Then you get a new dev asked to make a small a change and comes back saying they need a week to improve its performance or shrink it's binary.