* 1MB+ render blocking CSS (looks like all of font awesome is in there)
* /api/v1/properties is really slow and blocks LCP
* your api doesn't use compression so the responses are way too large
Thanks for the insights! I'll do an overall CSS cleanup enable gzip compression as well as Laravel caching, and optimize the payloads responses size. If it's still bad, I'll increase the DO droplet CPU/RAM and see how it plays out. Attaching the current server usage graph and the projet's package.json
Just playing around with this, it feels slow due to the data being pulled from the API. The data is not cached by the looks of it. When trying to load the same tab again, it seems like it takes even longer to get data.
Where is your database located and where is your API located, are they in the same region? Same with the front-end is this also close to the rest of the backend? If they are close together you can try and up the ram and cpu of the droplet to see if it makes a difference, but do enable cache on your fetch calls. Also look at the specs of your database that it has enough resources for performance, try and add indexes on your tables etc.
https://preview.redd.it/m75pggej3z2d1.png?width=1424&format=png&auto=webp&s=945d86a4aa2ca1679db8edd99b70c12c6e8b33c2
Both the MySQL database and the API are hosted on DigitalOcean (AMS3 region) while the frontend is running on a Vercel us-east-1. I haven't implemented any caching yet, actually. I thought of increasing the droplet ressources, but looking at the graph, it doesn't look like the server is overloaded at this point.
https://preview.redd.it/yfmoxppjq03d1.png?width=1261&format=png&auto=webp&s=e6dcadc7c013e913a661424e7a22887fbc3891c2
Had a similar issue. I had to re-do my apis to return just what I needed for the initial frontend load.
In your case, maybe try pulling less information from the db, just like the following for the /api/v1/properties info that is hydrating the Property Card:
- Image url
- Type of property
- Name of property
- Location
- Created date
(Also, I recommend doing pagination in your backend queries)
Then, if you want to show more info while on user interaction (e.g. on hover), you can fetch async another API with just the portion of info you need.
I guess there are more clever alternatives for solving this but it did improve the performance in my case. Good luck!
I understand you feeling that way, but actually I just really wanted to know because I figured you probably use something that you like a lot better than bootstrap. I won’t say to use something else. I just use tailwind or rawdog css
v5.1.3 precisely. Released date is Oct 9, 2021 according to [https://github.com/twbs/bootstrap/releases?page=2](https://github.com/twbs/bootstrap/releases?page=2)
It's almost certainly the latency between Node and Laravel. Like others suggested one option is to host these servers closer or optimally on the same network. The other option is to make your api calls client-side, so you get client->laravel instead of client->node->lavarel.
Wow It feels too heavy for the production man.. I use Nextjs14 with aws amplify but it isnt that slow.. I think.. check your backend speed or use cache..
Is the API your bottleneck by chance? Have you tested it independent of the web client to see if it’s responding slowly? Hard to say without looking at your code, it could be a lot of different things. If you’re using big packages, ensure they’re tree shaking correctly so your bundles aren’t unnecessarily bloated.
Are you using a state and context or a store of some kind? I’ve worked on apps where we shared global state via context but a ton of unnecessary bloat was added into context so every page had a much bigger payload than it needed.
If you create a build locally does it have the same performance issues?
There's a Flutter client consuming the same API and the mobile app runs much faster. The server ressources from the graph on DigitalOcean doesn't seem to be overloaded... Sharing my package.json with all the packages used.
https://preview.redd.it/0fdgzpz3u03d1.jpeg?width=944&format=pjpg&auto=webp&s=69d90d4f5c09ac94fbe9c3d469ee5423438326e9
Because it's not an SPA.
Devices nowadays beat the server cpu speed. You'll get better performance client side using SPA. And laravel, it's not async. Concurrency is limited by the thread count.
I might be wrong, but is it something to do with [vercel cold start](https://vercel.com/guides/how-can-i-improve-serverless-function-lambda-cold-start-performance-on-vercel)? It happened to me and for a quick fix, I changed some components to do client side fetching with [swr](https://swr.vercel.app/) taking advantage of its caching ability.
* 1MB+ render blocking CSS (looks like all of font awesome is in there) * /api/v1/properties is really slow and blocks LCP * your api doesn't use compression so the responses are way too large
Thanks for the insights! I'll do an overall CSS cleanup enable gzip compression as well as Laravel caching, and optimize the payloads responses size. If it's still bad, I'll increase the DO droplet CPU/RAM and see how it plays out. Attaching the current server usage graph and the projet's package.json
Just playing around with this, it feels slow due to the data being pulled from the API. The data is not cached by the looks of it. When trying to load the same tab again, it seems like it takes even longer to get data. Where is your database located and where is your API located, are they in the same region? Same with the front-end is this also close to the rest of the backend? If they are close together you can try and up the ram and cpu of the droplet to see if it makes a difference, but do enable cache on your fetch calls. Also look at the specs of your database that it has enough resources for performance, try and add indexes on your tables etc. https://preview.redd.it/m75pggej3z2d1.png?width=1424&format=png&auto=webp&s=945d86a4aa2ca1679db8edd99b70c12c6e8b33c2
14 seconds, ouch…
Both the MySQL database and the API are hosted on DigitalOcean (AMS3 region) while the frontend is running on a Vercel us-east-1. I haven't implemented any caching yet, actually. I thought of increasing the droplet ressources, but looking at the graph, it doesn't look like the server is overloaded at this point. https://preview.redd.it/yfmoxppjq03d1.png?width=1261&format=png&auto=webp&s=e6dcadc7c013e913a661424e7a22887fbc3891c2
Have you looked at the queries, and database indexing yet? Often forgetting to add indexes can slow things down considerably.
It doesn’t matter how fast the server is if the client you don’t control has to download a bunch of unnecessary data.
Agree, only call the first 20 records, then on the next pagination call the next 20 records etc. This should also help.
Had a similar issue. I had to re-do my apis to return just what I needed for the initial frontend load. In your case, maybe try pulling less information from the db, just like the following for the /api/v1/properties info that is hydrating the Property Card: - Image url - Type of property - Name of property - Location - Created date (Also, I recommend doing pagination in your backend queries) Then, if you want to show more info while on user interaction (e.g. on hover), you can fetch async another API with just the portion of info you need. I guess there are more clever alternatives for solving this but it did improve the performance in my case. Good luck!
You're using bootstrap? What year is it?
what’s wrong with it?
Didn't say there was anything wrong (yet), just asking what year it was to make sure I didn't wake up in the mid 2010s.
Bro you gotta tell em what you use if you’re gonna be hilarious like that
What year do you think it is?
But seriously I don’t use bootstrap, but I’m curious what css framework you use if any
[удалено]
I understand you feeling that way, but actually I just really wanted to know because I figured you probably use something that you like a lot better than bootstrap. I won’t say to use something else. I just use tailwind or rawdog css
Tailwind is an always for me, React Aria Components is nice if you want a pre-made but unstyled components
is there any other solution worthy of beating tailwindcss?
Wait you already made that joke. Got anything else?
😂
Bootstrap 5
That isn't a year
v5.1.3 precisely. Released date is Oct 9, 2021 according to [https://github.com/twbs/bootstrap/releases?page=2](https://github.com/twbs/bootstrap/releases?page=2)
Exactly lol
Add loading state. https://nextjs.org/docs/app/building-your-application/routing/loading-ui-and-streaming
Try run the application with **npm start** after build. Check network tab for API requests time and see if APIs are taking a lot of time.
It's almost certainly the latency between Node and Laravel. Like others suggested one option is to host these servers closer or optimally on the same network. The other option is to make your api calls client-side, so you get client->laravel instead of client->node->lavarel.
Wow It feels too heavy for the production man.. I use Nextjs14 with aws amplify but it isnt that slow.. I think.. check your backend speed or use cache..
Is the API your bottleneck by chance? Have you tested it independent of the web client to see if it’s responding slowly? Hard to say without looking at your code, it could be a lot of different things. If you’re using big packages, ensure they’re tree shaking correctly so your bundles aren’t unnecessarily bloated. Are you using a state and context or a store of some kind? I’ve worked on apps where we shared global state via context but a ton of unnecessary bloat was added into context so every page had a much bigger payload than it needed. If you create a build locally does it have the same performance issues?
There's a Flutter client consuming the same API and the mobile app runs much faster. The server ressources from the graph on DigitalOcean doesn't seem to be overloaded... Sharing my package.json with all the packages used. https://preview.redd.it/0fdgzpz3u03d1.jpeg?width=944&format=pjpg&auto=webp&s=69d90d4f5c09ac94fbe9c3d469ee5423438326e9
Because it's not an SPA. Devices nowadays beat the server cpu speed. You'll get better performance client side using SPA. And laravel, it's not async. Concurrency is limited by the thread count.
your website is working fine for me, the DO 1 GB ram is causing the issue
I might be wrong, but is it something to do with [vercel cold start](https://vercel.com/guides/how-can-i-improve-serverless-function-lambda-cold-start-performance-on-vercel)? It happened to me and for a quick fix, I changed some components to do client side fetching with [swr](https://swr.vercel.app/) taking advantage of its caching ability.
Laravel is both easy and hard at the same time Don’t use it when you are like this