With three test records everything is fast. With real data and users, the project crawls. It is not bad luck: these are known problems that only show up when there is volume.
Measure first
Don’t optimize blindly. Find out where the time goes:
- In the browser: Lighthouse and the network tab show the page weight and what takes long to load.
- On the server: the database’s slow query log and the time per request.
The most common causes
- Queries without indexes. A search that takes milliseconds with a hundred rows can take seconds with a hundred thousand.
- Repeated queries. Loading a list and running an extra query for each item (the N+1 problem) multiplies the time.
- Nothing paginated. Fetching thousands of records when the user sees ten.
- Heavy images and JavaScript. Unoptimized photos and huge code bundles delay the first load.
- Heavy work inside the request. Sending emails, generating a PDF or calling an external service while the user waits.
- No cache. Recalculating on every visit something that almost never changes.
- Server far from the database. Every query pays for the distance.
How it gets fixed
- Add indexes on the columns you search and sort by.
- Load relations in bulk, not one by one.
- Paginate and limit the results.
- Optimize images and split the code that gets downloaded.
- Move heavy work to queues processed in the background.
- Cache what doesn’t change often.
About moving to a bigger server
It almost never fixes this. It is usually a few well-aimed corrections, which is why you measure first.
Is your project slow in production? Tell me and I’ll review it.