5 ms·

>> "If I can't make your worst-performing page load 50% faster, you don't have to pay the bill." Unlikely that the worst performing page is the most valuable p

• jstanley 11y ago
  Fair point. A page that takes 10s to load that you never look at is a much worse candidate than one that takes 8s to load and you look at 20 times a day.
  • DiabloD3 11y ago
    I'm sorry, but if I had to look at a page 20 times a day that took 8 seconds to load, I would help that web app commit suicide. There is absolutely no call for a web app that badly written to exist in 2016. Period.
    • JangoSteve 11y ago
      No piece of code is written perfectly the first time. A software application (web or otherwise) tends to be a bundle of validations and compromises when written under the constraints of budgets, deadlines, and priorities. There are many scenarios where a page used 20 times a day takes 8 seconds to load. For example, an admin dashboard page that shows some statistics on some aspect of customer usage written early on in a startup's life might only need to be looked at once a month by one of the founders (since it app has little traction, they have bigger things to worry about than seeing statistics from an n of 3). So, it's hammered out with inefficient queries, improper indexes, etc. (after all, we don't even have a clear enough view of actual usage yet to know what indexes or queries we should really be doing). Time goes on, the startup picks up traction, and before you know it, it's April 15, 2016, and the application handles millions interactions a week across its users. Someone on the support team at some point in the near past realized that they should be looking at these usage statistics to help drive improvements to the interface of the application, but the page now takes 8 seconds to load, because of all the data stored in that table, and because of the inefficient queries, improper indexes, etc. Due to the nature of the business and the aforementioned constraints of budgets, deadlines, and priorities, this person has spent the last month or so just dealing with the 8-second page load. But now, it's a priority, and someone can go in, look at the data that's actually there, and figure out the best way to refactor, optimize, and improve it. The point is, there are many scenarios where a web app can have a page checked 20 times a day that takes 8 seconds to load without assuming it's so badly written, and it certainly has a reason to exist (after all, it is partially the success of the app and value it provides to people that has caused this issue in the first place), and it doesn't need to die, it needs to adapt.
    • mseebach 11y ago
      OK, that's fair. So how about this: You go over there (points to corner) and make angry and dogmatic proclamations of what should and shouldn't be, while the rest of us go out into the world, where these apps do exist in large numbers and see heavy usage supporting very valuable workflows, and collect obscene salaries making them better.
    • mdpopescu 11y ago
      All the way back to 2015, I got a job that said "we have a page (in a Windows app) that loads in 5 hours; we'd like that to be much faster, preferably in under a minute". I got it down to a few seconds, but that's not the important part: that was an application that was being used, daily. That page would just take 5 hours to load.
    • bpicolo 11y ago
      There's actually a really good reason: As data gets bigger, so do page speeds. Take a look at Google Analytics. Their "slow result" takes quite a bit to process. If you're just rendering a couple database fields to a page? Sure, that's easy
    • MichaelBurge 11y ago
      I used to work at a place where the front-end guys had a big push to get the page load times down below a minute. People paid tens of thousands of dollars for a subscription to it. The alternative was that you pay another company a couple million and wait 6 months for a binder to arrive in the mail, so the customers were content with the page load times. The backend team was more worried about keeping daily processing and offline reports below 24 hours. The offline reports were essentially SQL queries.
• jeffasinger 11y ago
  Also, I wouldn't necessarily limit yourself to a single page. Lots of companies have offline processes that are painfully slow, and are very good candidates for optimization. I once worked at a company where I noticed an employee would come in over an hour earlier than normal on Monday mornings. It turns out she got in early to run a report that the CEO liked to see every Monday morning. An hour or two later I added an index, and refactored some SQL so that we could do more in a single query rather than N queries, and the report time went down from 45 minutes to 3 minutes.
• doodpants 11y ago
  He's not saying that he won't work to improve the performance of the entire application. He's merely limiting the conditions under which he won't get paid to the worst performing page.
• dagw 11y ago
  Reminds me of one of my very first jobs where I was to optimize some MATLAB code. I found a function that looked obviously inefficient and after a days work I'd managed to get a ~10-20x speedup on that function. I was super proud of myself until it dawned on me that all I'd really achieved was to knock 30-60 seconds of a 6-8 hours process.