Why Filament v3 Tables are Slow: Dan Harrin Explains

One of the Filament criticisms is its slowness, specifically for tables with a lot of rows/columns.

Dan Harrin, creator of Filament, explained the reasons on the Bright Ideas podcast in December 2024, also talking about what he has improved for the upcoming Filament 4.

Here's the transcript of that podcast section, formatted for better readability and with screenshot examples added. You can listen to the full 58-minute episode here (topics on tables starts at 7:50).

Why Filament v3 Tables Are Slow?

Tables are slow, mainly because of how we've structured the Blade views that actually render the table.

Eloquent is not really something that really slows your app down unless you use it badly. However, when we're rendering the tables in Filament v3, we're using a lot of Blade views to render that table.

Here's a screenshot from a Laravel Debugbar showing Views for a table with 100 rows.

Each cell in the table is its own Blade view. That renders the actual cell container and the cell element. And that's reused across a lot of different parts of Filament.

We also have an element within the cell that then adds a URL or a button to that cell. Because you can't add a URL to an entire row in a table in HTML, you have to do it per cell.

And also then you have the content of each cell in the table builder. So that's also another Blade view that you have to render.

So that's about three views per cell that you're rendering in a table.

You then also have actions. So, each action has its own view that, decides which type of button you want to render, like a link or a button or an icon button. And that view then renders the actual view for the button. So that's two views. And then you also have for each action cell, you then have that same cell element, and an additional element inside that actually renders the actions in a loop. So that's then at least four views per action cell.

You then have the selection cells, which are, a checkbox view and another cell view and a check and the thing that actually renders the checkbox. That's also a view.

So essentially for the more columns that you add to a Filament table and the more rows, the more Blade views you're rendering.

And we like to follow the Laravel best practices when we are extracting out Blade components to make sure that we're not duplicating HTML across multiple parts of our code base that's the same.

Blade Isn't Slow. It's PHP and File System.

Specifically, the slowness is not actually about rendering the view. The Blade compiler will compile the Blade code down into raw PHP code. So running that is not really the slow part. Cause once you've actually compiled the view, it then gets cached by Blade.

The slow part that I've found is actually the PHP include that imports the PHP file from the view cache and renders it. So it's not really the actual process of generating the HTML from the PHP code. It's more about the file operations that are required.

So then I guess theoretically, the faster the file system, the less noticeable this would be. That's why I think there's quite a large discretion between different environments when rendering a Filament table.

I've also heard reports that on Windows, for example, Windows Defender will sometimes scan every single file before it gets opened. And you have to disable that on your code bases, because otherwise, before each blade view gets rendered, it has to be scanned. So yeah, I think it's very OS specific, but generally it's still pretty slow to have to then render these Blade components because of the fact that they are each a PHP include.

Solution for V4

I have refactored the Table Builder already to NOT render Blade components unless it really, really has to.

For example, instead of having a cell view and a link view and the actual content of the cell, it's all just done within one Blade view, and that's all raw within the view of the actual table.

The different columns have different contents, so it might be text, icon, color, image. That is all dictated by code within the column class itself now, so the text column has a method on it that generates HTML and returns it back to the main Blade view.

So you're not really including a new file, you are just running a method that generates the HTML, instead.

So this is really not a Laravel best practice. It is definitely not as maintainable as using Blade views in the traditional way. However, it's allowed us to really speed up the rendering of the table. Now there aren't any extra Blade views being rendered for each cell, unless you have a custom column with a Blade view.

And for the Actions, the only Blade components that being rendered there are the actual blade components that render the button, link, icon button.

How Fast Is It Now?

So from my experience, the tables are now rendering about twice as fast, which is, I think, a good improvement.

And as a reminder, we've still got all of the improvements we had earlier on in v4, with things like partial rendering that we're implementing in version 4 as well, which will also improve table performance, especially when using things like actions and deferred filters.

So hopefully you'll see a large improvement, especially if you opt in to a lot of these new settings that we're providing you with, to really help you with those large data sets and the clients that want to see 200 records on one page without any pagination.

V4 When?

At the time of writing this article in March 2025, there's no official date for Filament 4 release.

It has been announced that Dan will speak at Laravel Live UK, with the topic of "Exploring Filament 4":

However, it's not clear whether v4 will be launched before that date, at the conference, or afterwards.

At this moment, the public GitHub Roadmap looks like this:

Quite a few items left to finish, so you can participate and help to get the v4 out faster!