[Solved] Why Filament pages slow taking 10s to load initial html?

[christoferd]

What have I done wrong? Filament pages running extremely slow.
Note that all the load times examples are 2nd attempts with server cache (apcu) and browser cache enabled (unless the image shows cache disabled).

TLDR; Update 5-Apr-2023

Filament Dashboard (Debug & Debug Bar = true):
Local PC & Staging servers: ~1.6s

Other dashboard (no Filament)
Local PC & Staging servers: ~0.8s

• Filament page takes 2x longer to load with just the base layout view including navigation. Why?

Noting differences between Local PC and Remote Server

• Remote runs FPM/FastCGI - local PC doesn't
• Remote runs Thread-Safe disabled - local PC runs Thread Safe
• Remote server CPU is probably much faster
• Remote server is not Windows

Filament Table/List:
10 records per page
3 columns, each cell is related information from another table.
Local PC (Debug & Debug Bar On):

• 174 models!
• 41MB!
• 11.32s!
  

Local PC (Debug & Debug Bar Off):

• 7s!

Staging Server (Debug & Debug Bar Off):

• 1.3s
  Why is the remote server running faster? What tools are there to troubleshoot this?
  Note that changing APP_ENV=local to something else, has no effect on the load times.

Everything is setup following instructions from the Filament documentation site. I'm new to this, so I've only been following the instructions.

I would like to set this to 50 records per page, but then it will reach the 40+seconds load time 👎
I'm guessing there's a better way to do this, by overriding the query used to grab the records, but it goes against the principle reason for using this Filament tool/framework. And then if I did try do it, I can see issues when I want to use ordering, filters etc.

Staging Server 5-Apr-2023

This runs similar to local PC. Weird though, because debug bar is off, so I'd expect it to go much faster!
APP_DEBUG=true
DEBUGBAR_ENABLED=false

Filament Dashboard - blank, without Widgets

My dashboard - no Filament

Local Windows 11

This is a new app, Laravel v10.5.1
PHP 8.1.17
Windows 11
Server using CLI: php artisan serve running on 127.0.0.1:8000
Laravel cache "apc"
No memcached
No redis
Database local Maria 10.x

I have reached 1590 views in a single request! 48MB! So looking at other discussions, this may be something to do with DebugBar?... but Filament is definitely doing something to slow down the app.

Notice that it took 42s to load. That's on my development notebook. Recently purchased, running M.2 drive.
All other apps run very quick.

As I add more resources, the loading time increases. I don't understand why.

I can post some pages of content, but I can't just dump all my code for public view.

With APP_DEBUG=false & DEBUGBAR_ENABLED=false...

This is one of my own routes that doesn't use filament. Notice the 390ms initial file load... now compare that to the previous one!

Composer

More troubleshooting...

No Debug, after setting google_fonts to NULL, it still takes the same amount of time, 10s to load first html.

I enabled OpCache, it now loads first html in 9.3 seconds :(

Switched to Apache 2.4

Using XAMPP instead now, same PHP v8.1.X
APP_DEBUG=false & DEBUGBAR_ENABLED=false
It takes 1.2 seconds to load initial html. That is still very slow compare to the other page within the same app.

Debug back on

APP_DEBUG=true & DEBUGBAR_ENABLED=true
5.89s

vs my own dashboard route that doesn't use Filament...
0.69s

Queries
What happens if I keep going and add another 20 resources?

Why is Filament acting so differently with artisan serve (PHP CLI server) vs Apache?

[danharrin]

In your service providers, do you have any code that shares data with all views?

The reason why there is a high view count is because we use Blade components, but simply rendering them should not take that long.

[christoferd]

Hi Dan, thanks for response. This app is fairly new. AppServiceProvider is bare.
PS: I'm updating original post with more information after publishing as a Staging test on Cloudways server

[danharrin]

What other packages and plugins have you installed

[pathros]

In my case, the installation and use of several blade icons packages were causing the FilamentPHP to get extremely slow. As @relayer464 reported, the execution of php artisan icons:cache fixed the slowness problem.

[TilsonM17]

In my case, the installation and use of several blade icons packages were causing the FilamentPHP to get extremely slow. As @relayer464 reported, the execution of php artisan icons:cache fixed the slowness problem.

Man, god bless you, you save my life.

[argolian]

Worked for me too, thanks!

[christoferd]

Hi Dan,
These are the only Plugins I can think of - but they don't affect the Filament pages from what I can see:

As I'm now running through Apache, I don't have npm watching files. I actually don't have anything watching files.

Packages
See composer.json screenshots in the original post.
It's been updated so they should be the latest stable versions. (phpStorm has displayed the current installed version numbers)

To add a Tip for other Windows users... make sure to exclude your development folders from Windows Defender (and any other Anti-Virus / anti-Malware, etc.)

• I did this today, but it didn't speed up Filament pages enough to merit any updates to page load times

I can see why my PC not running FastCGI is slower than the staging server, but I cannot work out why a blank Filament page would take over 1 second to load, while another admin page in the same app takes under a second.

[christoferd]

##Solved

Solution: disable zend_extension Xdebug in php.ini

Using the Performance Monitor I could track what was reading/writing the most data to my drive.
"cachegrind" ... which I found out is used by the Zend Extension Xdebug!

Okay, but I can't be the only one using X-Debug. Do other people only enable it when it's absolutely necessary?

PS: Filament pages still take 2x longer to load, though now at 500ms, so that's much better.
Or the page with 3 columns of all relational data, 10 records, takes 630ms

[mlategan]

php artisan icons:cache
Amen to this! 10s down to few milliseconds.

[rahmap]

Thanks Bro

[vortechron]

@mlategan thanks, its work, hoping filamentphp has some sort of mechanism that show prompt to cache this icons on dev mode, putting on docs is easy to miss and hard to debug.

[bilogic]

anyone knows why php artisan icons:cache helped?

[mlategan]

anyone knows why php artisan icons:cache helped?

In Blade Icons' Factory.php file, the registerComponents function attempts to load all icons needed for component registration from a Manifest class by calling its getManifest method. The Manifest class first checks its cache array, called manifest for the value requested. If the icon is present there, it returns it immediately, avoiding any further scanning. However, if the icon isn’t found in the cache, the build method is triggered, which iterates through all icon sets registered with the package. This method traverses each registered path in each set, scanning through all files in the paths and then building the manifest.

On subsequent calls within the same request, icons will then resolve directly from this manifest.

However, with Livewire components (such as Filament forms, fields, etc.), multiple calls are made to the server to dynamically update parts of the page, resulting in multiple requests. Consequently, the manifest may be rebuilt for each request, leading to performance slowdowns.

This happens if component registration is switched on in Blade Icons, because the Provider for the package must register all these components with blade before blade can resolve them. If only the @svg function is used and component registration is disabled, it simply resolves each icon at the point in time at which it is rendered.

Running php artisan icons:cache pre-generates the manifest and saves it to a file in the application’s cache directory. This approach ensures that, instead of rebuilding the manifest repeatedly, Blade Icons can simply read from the cached manifest file, significantly improving performance.

Blade Icons and recently also Filament's documentation both inform the user of this performance issue.

Refer to:
https://github.com/blade-ui-kit/blade-icons?tab=readme-ov-file#caching
https://filamentphp.com/docs/3.x/panels/installation#caching-blade-icons
https://filamentphp.com/docs/3.x/panels/upgrade-guide#blade-icon-components-have-been-disabled

And the sources:
https://github.com/blade-ui-kit/blade-icons/blob/1.x/src/Factory.php
https://github.com/blade-ui-kit/blade-icons/blob/1.x/src/IconsManifest.php

[bhdbhd]

I am getting desperate. I have the same issue. Tried all mentioned methods: disabling xdebug and caching icons, also disabled observing views in debugbar.

Still on my local environment initial response takes 9-11 seconds and loading scripts takes 2 seconds each. My queries are trivial and take less than 3ms.

[sergiuprt]

I'm actually in the same situation. Don't know what to try anymore...

[bhdbhd]

Try turning opcache on in php.ini. I was banging my head against the wall but this seems to work with all the rest of suggestions

[christoferd]

@bhdbhd @sergiuprt Are you using Windows? Did you add your web project's root folder to Windows Defender Exclusions list?

• Make sure Windows Defender is not scanning every single file when accessing
• Add the project's root web folder to Windows Defender Exclusions list

[catative]

I also encountered this problem. On a completely clean installation of Laravel 10.40.0 and Filament 3.1.42, I created one simple model, one migration for it with one custom text field and one Filament resource. Going (in UI) to the section of the created resource or using any action, for example, creating a new model record in DB, took a very long time (about 10 seconds). Disabling the Laravel debug panel (barryvdh/laravel-debugbar) or xDebug did not result in success. The problem was on both the Apache and Nginx servers (on Ubuntu 22.04).

Experiencedly, I noticed that this problem began to occur with Filament 3.0.28 version (in 3.0.27 everything worked quickly). It turned out that in my case the problem was due to the Adblock Plus extension for the Google Chrome browser. When I turned it off, everything immediately began to work quickly even in the latest versions of Filament and even with enabled xDebug.

[Sjoerd24]

Thank you so much! This also solved my problem! So strange that adblocker is interfering so much..

[danharrin]

Its a recent change, Adblock used to be fine. Now, its fighting with normal JavaScript in Chrome.

[geowrgetudor]

Maybe related, but not sure. I've came across a similar issue, but on the frontend side on LOCAL env (even with a similar setup as production - caching, etc.).

It turned out the issue was barryvdh's debugbar which was causing UI to freeze sometimes even for 6-7s. It's probably of the high amount of views Filament uses because it tries to trace them all.

[scottzirkel]

You can disable the views from the debugbar in config/debugbar.php. set collectors['views'] to false.

[ivl04]

I've implemented several optimizations, including caching icons, disabling the debugger bar, removing unnecessary packages, and performing a fresh Composer installation. Additionally, I disabled the Zend extension in the 'php.ini' file. Despite these efforts, the performance issue persists. Specifically, the /livewire/update is being called twice initially on every page/route. Even for simple view pages with only one record, it takes more than 15 seconds to load. On listing pages with only 10 paginated records, it takes around 20 seconds to load, with some JavaScript taking additional time after the page is fully rendered. Any advice on how to address these performance issues?

[sv-hmelevsky]

The problem has not been solved and still exists. Clean installation of PHP8.2, Laravel 11, Filament 3.2, laravel-debugbar. OPcache is enabled. Xdebug not installed. Disabled all extensions in the browser, ran: php artisan icons:cache && php artisan filament:cache-components && php artisan optimize. The cold basic load is 11-12sec, subsequent 3-8sec. And this is on a top-end PC on Local with an empty database and zero load! It’s scary to imagine what will happen in production! What to do? Any advice?

[krekas]

As I said do a research. There is 100% others with such problem. This has nothing to do with filament or even laravel.

[ctoma]

@sv-hmelevsky I am guessing you have your project files under the windows mount instead of under WSL2. That's probably the cause of the slowness and is what krekas is referring to.

Move all your project files into WSL2 and access them from phpstorm/vscode using WSL.

For reference I am using WSL2 + Docker and load my empty Filament dashboard in 50ms. Other pages depend a lot on the # of rows and columns, but for me 10 rows & 10 columns load in about 200ms.

[christoferd]

FYI - This was marked as [Solved] as I was not using Docker.
I avoid using Docker due to all the reasons above, I just cannot find a way to make it run as fast as I like on Windows. Then having to map a folder to edit the files etc. It's extra overhead I don't need at the moment and would only manage a project like that if it is 100% necessary.
I am however using Windows 11, and "php artisan serve" as it's much easier and fast enough.

[artulance]

Hi, I was recently experiencing the same problems as described in this thread. I am using windows 10, php artisan serve and php-8.2.4-Win32-vs16-x64.
I tried everything when caching laravel, icons etc but it was still taking too long sometimes 15 seconds.
The solution was to add the project folder to the windows defender exclusion, now it only takes milliseconds, it's incredible.

[Darnes1958]

Hi, I was recently experiencing the same problems as described in this thread. I am using windows 10, php artisan serve and php-8.2.4-Win32-vs16-x64. I tried everything when caching laravel, icons etc but it was still taking too long sometimes 15 seconds. The solution was to add the project folder to the windows defender exclusion, now it only takes milliseconds, it's incredible.

Yes I add the folder to "windows defender exclusion" , I do it in the local and in the server and the two is good speed , thank you .
And also when run "filament:optimize" in the product and do OPcache it change to better with me.

[Hamza-crypto]

I blocked the font CDN request (in chrome dev tools) which was taking too long to load

Now it is super fast.

[Darnes1958]

I blocked the font CDN request (in chrome dev tools) which was taking too long to load

Now it is super fast.

how to do that

[Hamza-crypto]

Here I described the method in details
https://stackoverflow.com/a/78908426/25138504

[christoferd]

Windows developers should note one of the tips here
"The solution was to add the project folder to the windows defender exclusion, now it only takes milliseconds, it's incredible." - artulance

[emmanpbarrameda]

UP FOR THIS!

[sv-hmelevsky]

@ctoma Move all your project files into WSL2 and access them from phpstorm/vscode using WSL.

I did a little "research" in this area, you were right! The problem was in the file system between Windows and WSL. I moved the files to WSL, now Filament loads very quickly! Here is a small "guide".

I will say right away that I work with WSL as root, so I created it as root. The practice is not very good, but you can always do this for a separate user, replacing the directories with your own.

1. Created a directory for projects in WSL: mkdir -p /root/projects
2. Installed inotify-tools and rsync in WSL. This will help us synchronize our working folder with projects on Windows with the project folder on WSL.
3. Created a script file for automatic synchronization between Windows and WSL: mkdir -p /root/scripts && nano /root/scripts/sync_projects.sh

#!/bin/bash

# Path to projects in the Windows file system
WINDOWS_PROJECTS_PATH="/mnt/e/server/domains/"
# Path to projects in WSL
WSL_PROJECTS_PATH="/root/projects/"

# Launch inotifywait to track changes
inotifywait -m -r -e modify,create,delete $WINDOWS_PROJECTS_PATH | while read path _ file; do
    # Synchronizing changes via rsync
    rsync -av --delete $WINDOWS_PROJECTS_PATH $WSL_PROJECTS_PATH
done

5. Made the script executable: chmod +x /root/scripts/sync_projects.sh and ran it. Waited for the synchronization to finish (it could take some time).
6. Added background script launch: echo "nohup /root/scripts/sync_projects.sh &" >> /root/.bashrc
7. Added additional (local) docker-compose config to the project: docker-compose.override.yml and redefined the paths in it, from this: - ./client-service/app:/var/www/client-service to this: - ~/projects/atb-client/client-service/app:/var/www/client-service
8. Made a DB dump!
9. Rebuilt docker: docker-compose down && docker-compose build && docker-compose up -d
10. That's it! Now any changes in the project files on Windows cause synchronization with WSL and everything works very quickly! In theory, you can not use synchronization, but work in the IDE directly with the WSL directory. But I don't really like this concept. :\ I hope this "guide" will be useful to someone. :)

[InfinityXTech]

One thing on this topic, I had same issue that none of above answers solved. Weirdly ->blocks(fn () => [elements]) was causing it but ->blocks([elements]) worked very fast. So maybe check where you use fallbacks, that may be an issue