Search code examples
phplaravelperformancelaravel-livewire

Performance Issue on Laravel 9 Application Using TALL Stack (not in Docker or WSL)

I am facing serious performance issues on my Laravel 9 and 10 applications. I'm using a TALL stack (Tailwind, Alpine, Livewire, Laravel), and I've noticed significant lag when loading my assets, which I'm struggling to explain.

Specifically, each of my JS and CSS files take approximately 2 seconds to load if I keep them in the 'vendor' directory. However, if I manually move these files to the 'public' directory, the load times improve significantly.

This issue occurs both in my development environment (PHP FPM 8.1.2, Nginx, Valet Linux, Ubuntu 22.04 (not in a VM), Intel Core i5, 16Go RAM, SSD M.2 NVMe) and in production (PHP FPM 8.2, Apache, Debian 11) even after cache:view, cache:config, etc.

As a temporary solution, I've moved the files to the public folder, but the application itself (excluding assets) also takes about 2 seconds to load. This makes it challenging to make it responsive with Livewire without experiencing form refresh delays of around 2 seconds each.

Loading from "vendor" directory :

/admin/oncalls           ████████████████████████████ 1.54s
/livewire/livewire.js                                ██████████████████████████████ 1.54s
/filament/assets/app.js                              █████████████████████████████ 1.37s
/filament/assets/echo.js                             ███████████████████████████████████████████████ 2.32s

Loading from "public" directory :

/admin/oncalls           ████████████████████████████ 1.54s
/livewire/livewire.js                                █ 9ms
/filament/assets/app.js                              █ 6ms
/filament/assets/echo.js                             █ 6ms

Loading from "vendor" directory

The application loading time issue doesn't seem to be related to database queries since the Laravel Debugbar shows rapid queries. Debugbar

Memory usage seems quite high however. Don't know how to find out why is that so high.

Access right do not seems to be the problem either

drwxrwxr-x  81 david david   4096 mai   17 10:30 vendor
drwxrwxr-x   5 david david   4096 mai   25 13:44 public

I've been looking for a solution for several months now but to no avail.

In order to bring more details, I add this xdebug profiling displayed from Clockwork :

enter image description here

Its truncated because the time consumming part is displayed on top but if the rest of the list is necessary to understand the problem I will add it.

I looked into the vendor dir to find where is uasort() called and commented it in /vendor/symfony/finder/Iterator/SortableIterator.php in the method getIterator() at line 105 and the loading time dropped from 2.36s to 0.935s. The backtrace shows that it is Filament that calls it indirectly :

vendor/symfony/finder/Iterator/SortableIterator.php:116
Composer\Autoload\includeFile

Composer/Autoload/ClassLoader:428
loadClass

Symfony/Component/Finder/Finder:454
sortByName

Illuminate/Filesystem/Filesystem:599
allFiles

Filament/FilamentServiceProvider:152
registerComponents

Any insights or suggestions would be greatly appreciated. Thank you in advance.

Solution 
  • php artisan icons:cache

    solved the problem. Thank you Clément Baconnier for the solution.