Last week, I shared a couple tips on making queries faster and using realistic datasets locally during development to surface performance issues before shipping to prod.
But today I'll answer the question: How do you know something is slow?
Let's discuss the most obvious scenario: You know it's slow because you clicked on a page, and it took longer to load than you expected. Running the app locally on your high-powered dev machine, with a single user and no round-trip to a server, everything should load almost instantly. If you find a page that doesn't, that's definitely worth exploring. Here again, it's important to use a realistic dataset. 10 rows in a table will behave much differently than 500,000 rows will.
I recommend using Laravel Telescope to dig into what is making a particular request slower than you would like. It sits behind the scenes logging all sorts of data about each request coming in to your application. You can then visit the Telescope UI to inspect individual requests (or even commands, jobs, etc). One of the main metrics it surfaces is Duration. My rule of thumb is anything over 1 second is worth digging into.
Instead of walking you through all the features of Telescope, I highly recommend reading the docs and just trying it in your app. As a side note, I strongly recommend not installing Telescope in production. It may seem like a convenient thing to have, but it really is a developer-focused tool, and you can very quickly log gigabytes of data to your database in even a moderately-busy production application. As a general rule, do not enable developer tools in production. They can often serve as an attack vector to your application.
In a future tip or two, I'll share some alternate strategies for finding and diagnosing performance issues in production.
Here to help,
Joel
P.S. Laravel is pretty secure by default, but Aaron published a course to go even deeper on Laravel security.