>> "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 page; which is to say that offers should focus on providing value.
Unlikely that the worst performing page is the most valuable page; which is to say that offers should focus on providing value.
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.
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.
There is absolutely no call for a web app that badly written to exist in 2016. Period.
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.
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.
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.
If you're just rendering a couple database fields to a page? Sure, that's easy
The backend team was more worried about keeping daily processing and offline reports below 24 hours. The offline reports were essentially SQL queries.