If we accept that our optimization decisions should be made based on data then what kind of data will we use?
When told to pick three apples from a tree you do not need to factor in that a volcano is erupting a couple of thousand miles away. In the same vane, there are a lot of different types and sources of data we could use when optimizing. However, the real question is "What is it that really matters?"
To start with there are different answers for different web applications depending on how your system is setup.
On the front-end, our browser is our most significant friend. Modern browsers allow everything from watching traffic to and from your computer for the website to how long it is spending processing individual functions in the code. They also provide throttling options to limit bandwidth and processor performance to give you an idea of what it will feel like for visitors with lower performing hardware.
To see front-end performance out in the wild there are third-party services that can be setup to monitor front-end performance and how users interact with your site. Tracking front-end performance could be useful if you are encountering isolated situations where only a few users are experiencing slow-downs, but they are hard to replicate on your own devices.
Tracking how users interact with your site is essential to making the right performance decisions. If there is one area of your application that tends to get the bulk of the site usage that might be the right place to focus on tweaks to performance. There is more to it than just working where the traffic is as other areas could be getting avoided because of how slow they are.
For the front-end, we can often get side-tracked into graphic design issues. These are important in their own right, but they aren't part of performance issues. If you are a small team running the entire project it can be easy to see something that you don't like and spend your time on that and lose focus on improving your performance. If you are responsible for graphic design, make a to do for it and deal with it later, if you aren't accountable make a to do and then report it later.
On the back-end, we don't have a single tool that provides all the answers. It is also an area where there can be a significant number of things slowing you down. However, for measuring performance, it is relatively easy to see if you have a problem. You merely need to know how long it takes from request to response. Measuring timing can even be as simple as logging some metrics to the console or a log file.
There are many more things that can be analyzed that are just conditions or causes of that initial measurement. Some additional considerations could include:
Third-party API calls
Authenticating a request
The list goes on and on, but that is enough for now.
One more data source you should never ignore, and ultimately the most valuable of all data, is what your users feel while on the site. There are some technical ways to collect data, eye-tracking, mouse tracking, etc. Those can be helpful but ultimately just providing a feedback link on the page, getting beta testers to try it out and provide feedback, or sending out a survey are all ways to find out areas of the application that is annoyingly slow.
One warning here is that performance isn't often something people think of when they are trying out an application unless it is ridiculously slow. It is as users use the it that those performance issues start to annoy most users. So make sure when you are asking for feedback to ask them specifically about performance.