Filament•16mo ago

Table performance improvements tips?

Building a new app with v3 and loving it so far 👍 For this app performance isn't much of an issue, but I have some other things I'd like to use Filament on where performance is critical. Table rending is very slow at 50 rows x 15 columns. Debubar shows 3500 views being rendered. I know about turning off debugbar, but even with it off rendering takes a long time in this empty shell of an app with a few hundred rows of test data. Often over 1 second. I've searched through Discord a bit but haven't found much. Are there any known techniques for improving the rendering speed?

23 Replies

Patrick Boivin•16mo ago

Can you share a bit more on what's happening in your 15 columns? Are you computing values there or simply displaying raw values?

SteelheartOP•16mo ago

It's just raw values from the database. I used the generate option on a resource just to test it out.

SteelheartOP•16mo ago

There's 3 of these columns it generated but everything else is just text

Thijmen•16mo ago

We noticed it becoming slower with these columns so our solution was to store these values in redis

Patrick Boivin•16mo ago

@Steelheart (Ian Landsman) Something you can try is to defer the loading of the table with ->deferLoading(). Maybe it can help the perceived loading time of the page.

SteelheartOP•16mo ago

There's only a few hundred rows of data, it's not the database it's the view rendering Hmm yeah. I could give that a shot. I wonder if there's some way to pre-compile the blade template as ultimately rendering 3,000 views on every request is just going to be slow.

Patrick Boivin•16mo ago

Are you thinking about Blade view caching? (php artisan view:cache)

SteelheartOP•16mo ago

That won't fix it, it would probably need to be something more custom. Since every cell/column/etc in the table is a component they all need to be rendered. I guess I am curious if nobody else sees this speed issue? Perhaps it's something else? I'm assuming it's the thousands of views being rendered but perhaps it's something else.

Patrick Boivin•16mo ago

My biggest projects are still on 2.x, but I haven't experienced problems like this on 3.x yet... I'm not sure. Let's see, maybe other folks will chime in with some ideas.

awcodes•16mo ago

Did you cache the icons?

SteelheartOP•16mo ago

I did try that yeah.

awcodes•16mo ago

That’s the only thing that’s really standing out to me. Views can slow things down since livewire has to dom diff them all, but even that many shouldn’t slow you down that much. Even 1000+ views I’m getting sub 150ms responses locally.

Thijmen•16mo ago

What is your column code? We did thid:

IconColumn::make('leverbaar')
                            ->label('Leverbaar')
                            ->getStateUsing(fn ($record) => (Cache::get('instock_' . $record->soer)))->boolean(),

IconColumn::make('leverbaar')
                            ->label('Leverbaar')
                            ->getStateUsing(fn ($record) => (Cache::get('instock_' . $record->soer)))->boolean(),

This makes rendering a lot faster

SteelheartOP•16mo ago

Very much doubt it's the database as there are only a few hundred seeded rows. Column code is whatever generator produced for the resource automatically. Will look when I get home.

awcodes•16mo ago

The amount of data could be irrelevant to how the data is being queried. For example, not your specific use case, but not using callbacks on select options can cause unintended n+1 queries. And I know you’re not a noob Ian. Lol. Sorry if it sounds that way. Just trying to help track it down.

SteelheartOP•16mo ago

I am a noob at this 🙂 But this is a plain vanilla Laravel/Filament install and all I did was run php artisan make:filament-resource Job --generate the job table has maybe 18 columns total. For this use case it's fine really, even if it takes 1 second to load as it's just the admin side of Larajobs. Trying to make Livewire/Filament work for a much larger project that I've been going back and forth on tech stack on though. I'm not too worried about it for now. There's really only a few key spots in that app where maximum speed is critical and I could always use a custom table for those cases to avoid this while still using Filament tables for the standard crud actions throughout the app that are super annoying to build and Filament would make go much faster.

awcodes•16mo ago

Spoken like a true noob. Lol. Sorry I don’t have a more definitive answer for you.

Daniel Plomp•9mo ago

Is this a boolean column? I tried your code, because I also have issues with performance, but it didn't work for me. The icon doesn't show when I use caching.

Thijmen•9mo ago

I am not sure exactly. Cant access the redis server so i have no way to check it

Daniel Plomp•9mo ago

Ah ok. Btw. you have experience with a separate Redis Server for e.g. Horizon tasks?

Thijmen•9mo ago

No, my colleague is the one who manages the servers

Daniel Plomp•9mo ago

Any chance I can get into contact? Dutch, I presume? 😉

Thijmen•9mo ago

Yeah Dutch 🙂

Gaming

Programming

Table performance improvements tips?