What can you do to speed up resource
I am searching for a solution. When editing a resource (just some text fields, checkboxes and a builder) it feels way slower to change fields then it feels like to be. Sometime the 'update' call in the network tab can take longer than 16 seconds.
How to make filament feel more snappy?
(No debugbar and other first google hits are present)
63 Replies
Sounds like you got a problem that isnt Filament. I have enormous forms that save pretty fast.
So what could be the problem? I have it in production as well in dev
Using debugbar, check the timeline to see the “booting” ms vs request ms, and also how long the db queries take
also are you on windows?
I am on mac using herd, production is linux. (laravel 12)
Opening the /pages/1/edit:
Booting 39.11ms Application 11.22s (s not ms) Request duration 80.47ms Peak Memory 10MB The database queries took 2.08msWhen adding a 'row' to a builder element. Request to /livewire/update
Booting 35.67ms Application 14.3s (s not ms!) 273x vies 0 Peak memory 26MB Database queries 1.99msWhere should I look to get application quicker.
absolutely no clue, those numbers are crazy
something is obviously seriously wrong but i dont think its filament
ive never seen numbers that high
when people complain about slowness it may be 1s, not 15s
I can handle 3 seconds or so but yeah one textbox 15 seconds is kinda killing 😂
But if not filament what else? Frontend is inertia and Vue, no issues there at all.
Maybe it's a reactive thing that's messing with the builder?
Relationships maybe?
can you remove each feature from the form one by one and work out which one is causing the problem?
i feel like it cant be an issue with it getting slower progressively
I will report back to you soon! I will get to the bottom of this.
Thanks
OPCache is enabled? Did you run
php filament:optimize (if that’s the right command 🙈)Caching didn't do much.
I feel like it's a compounding effect actually, each row added with different content just adds to the total views that needs to be rendered is my conclusion of the profiling. So I feel like it re-renders all the time with each update I do. So each row or content adds about 1.3 seconds.
Maybe what I do is too complex and I have to find a workaround.
Can you provide the form? have you ensure closures are used when using DB Queries etc for selects / options?
Do you have debug bar enabled by any chance? If so, disable view collection since that massively slows it down as per the docs.
how about using the builder "preview" feature, so the form doesnt render upfront
each block has a preview view, and is editable in a modal
1 second still sounds super slow for a block though, i wouldnt expect that to be more than 50ms
I think this is the way to go!
The rendering time is a bit deferred and split up but UX is way better.
On a bigger page (like 8 rows) each row takes still about 2 to 4 seconds to load.
Maybe I still did something wierd, but at least there is a workable workaround.
2-4 seconds is insane per row
fyi live() replaces reactive()
Can you also try loading your blocks into an array on mount of the page and then calling the blocks with $this->blocks. To save loading all the files each time on a refresh.
@Wesleyh can you create a full reproduction repository that I can install and test out the performance of on my machine?
or if your real project is easy to install, you can share it with me privately on github
i at least want to see this insane performance for myself, I feel like something must be seriously up lol
Send me a DM with your github I think that is the easiest
my username is danharrin
I invited you to the private repo, make sure to be on the "Rebrand" branch.
Please forgive me the WIP in general and now of the preview blade components.
System wise:
MacOS, 128GB, Herd, Yarn as package manager
ok so how many blocks are you using on this page?
feels pretty snappy to me
You should switch to the Rebrand branch
and what should i do?
🤷♂️
think its some php or server set up thing, or something on your machine
none of this feels slow
i am using macos & valet, but i think herd runs on valet anyway
No it feels insanely fast I never had it this fast for any filament project.
are you sure you have opcache enabled?
in php.ini
Im going to check!
make sure to restart php if you enable that
I have checked, opcache was already on, opcache_cli was turned off now turned it on, as well as restarted the whole machine to be sure.
what is your computers current ram usage
25 GB of 128GB
you have 128GB of ram? jesus
honestly when you first posted that i thought you were talking about storage
do you have antivirus software on your computer that scans all files before they get opened? we have this issue with windows defender sometimes
It's a mac
i know, im talking about equivalent mac software
No nothing that I am aware of
yeah its weird dude, but i think i can rule out it being anything wrong with filament tbh
my computer "only" has 32gb ram
and its clearly not got issues with perf for me
if you deploy it, the perf issues probably wont be there tbh
I understand, will investigate further, I can not be the only one that will face this
I am actually not sure, because I have deployed Filament projects in the past on VPS and it never was so fast as in your video which amazes me.
But for science I will try it out
Also ruled out firefox / chrome now
its def not a browser because its the server response time
You on PHP 8.3 or 8.4?
8.2
8.3 and above is broken on my machine and i need to format it i think lol
actually its only an issue with 8.3 and postgres, let me try 8.3 and another db
yeah no issues on 8.3
I will deploy this, see if it makes a difference.
Okay you were right, the thing with the previews likely did the job in production!
Wierd that it wont work locally, I will still try to figure out why for the next person.
Did you enable debug bar locally? or have xdebug enabled?
ah yeah, xdebug really slows things down
I have debugbar locally as far as I know? What should I check? I put the views thing to false in the config.
Never heard of xdebug honestly. I disabled it in Herd and set everything to no in the debug.ini.
I have to go now, I REALLY appreaciate the swiftness and all the help you already provided today.
I did some more testing and it has to be something to do with Herd.
when just using php artisan serve it's extremely fast.
I have disabled xdebug, opcache is enabled.
woop, I'm glad you narrowed it down
i bet if you tried valet instead of herd it would also be fast, thats what i use
Yeah I'll consider maybe switching now but shouldn't be needed. But I'm on herd pro
Actually reached out to the Herd developer because something's fishy about this. I'll investigate further.
@Wesleyh would you mind sharing the
ms for Herd vs artisan serve on this page?3.12s and 110ms 💀
lol, nice
i might add a note to the docs about herd then
please let me know if you figure out what the config issue is
Yeah I will do my best
What the wierd thing is: php is configured through herd as well as the database. Artisan serve uses that as well.
Which got me thinking maybe it's related to ngnix or something. Maybe a far stretch.
when youre telling me about performance, you're using numbers from debugbar instead of the network tab right?
the numbers from debugbar do not get affected by the server iirc, just the speed of php-fpm
Just for the record. I"m gettin the same speeds on Herd and Valet. 🤷
I reported earlier from the debugbar, tested now quickly again and in the network tab /livewire/update 3.41s in herd (just adding a row)
with serve 129.18 ms on the same endpoint.
Definitely something in your herd install then.
i wonder how many of your other apps will be faster too
Okay breakthrough, it has to do with https.
On http with herd it's also super fast. But it breaks uploaded images since they point towards https.
I did a cache:clear to try if filament maybe caches the https.
Then I wanted to benchmark it back on https and it was fast all of a sudden?
Reissuing the certificate somehow solved it?
lol wow, thats so weird
So I am testing a theory here. Maybe in a year something has changed with the way certificates are handled. I now test it out with another project that I considerd slow.
Observation 1: the portfolio site was not in apple keychain manager and is not there now as well.
Observation 2: the other site (created aug 2024) is there now and is slow.
Observation 3: removing the certificate from herd removes it from apple keychain manager.
Observation 4: reissuing doesn't add it to keychain manager.
This is so wierd, actually it's not fast anymore. I was too fast happy
Now I found it and it's replicable! Sorry for the confusion with https.
What I think happend is that for a little time Herd was not intercepting dumps but I just now noticed that in the herd is intercepting also views like debugbar it seems.
The old project triggered a dump and that opened a background window. It goes CRAZY when you do any action in filament.
Solution: disable views in the dumps view
Thanks @Dan Harrin @toeknee and @awcodes for the commitment, it was a great help!
I always thought Filament was just a tad slow and it was a tradeoff between speed and ease of use. Probably there is something in production that also logs something (telescope perhaps) that slows it down but that is now easily findable.