Better performance?
I have employed all the suggestions in https://filamentphp.com/docs/3.x/panels/installation#deploying-to-production
however the load times for my tables are still unbelievably long, it feels like it's reading from the database every time a table is show, and even that is still longer than it should be
Is there anything that can be done to improve this? Does filament cache the queries? Is there a way to add redis in between?
I have a very beefy server on hetzner, the database is on the same server, and even so, a table with barely 200 records, showing only 10 , loads for good 2.7 seconds and I find it unacceptable for production
62 Replies
I don't think anyone would be able to answer this question without investigating your code, DB structure, etc. From my experience, every performance case is individual to investigate, it's impossible to "guess blindly".
One thing to check is to install debugbar and make sure you don’t have any n+1 queries going on. There can be issues with livewire and tables since it’s just a lot of html going back and forth and getting dom diffed, but id say 90% of the time it boils down to a query issue.
I'm not using any custom or complex queries, completely barebones setup straight from the documentation with a single Brand model, no relationships, and just a simple table showing 3 columns. That's why I'm so confused by it
Please provide some code @adnn and also ensure all your filter options etc all use closures
@awcodes @toeknee
Hey, I'm tagging you directly because I resolved this and believe the cause might be some sort of bug.
Initially my AdminPanel was set up with
->font('Poppins')
Which was trying to reach https://fonts.bunny.net/css?family=poppins:400,500,600,700&display=swap
For me this endpoint resolves in Firefox, but does not in Chrome or Brave (no blockers of any kind). Filament was waiting for the pending request until it timed out, and only then loaded the pages.
When I switched to
->font('Poppins', provider: GoogleFontProvider::class)
my performance improved drastically, literally 10x loading speed of tables. In any case, whether the issue is with Bunny, chrome or whatever, I think Filament should not be so hard dependant on an external CDN to the point that it bricks the entire app, especially not for a font of all things. It should fallback on Google fonts if the request is pending for too long.
I saw a similar issue from this guy on GitHub, https://github.com/filamentphp/filament/issues/7987 which was rather rudely closed by @Dan Harrin without any consideration.
Very helpful to know @adnn wondering @Dan Harrin if a deferrer should be loaded
sick and tired of low effort issues, I think the disrepsect for maintainers time is ruder than my reply, we ask very nicely for a reproduction repo and explained exactly why in the issue template
Totally agree with @Dan Harrin @adnn, would you be able to create a repo where we can reproduce the same issue and then tag that issue too?
i am more than happy to keep issues open if people spend a little bit of time reproducing, so i can give them my time for FREE in return
I personally don’t see the point of a fallback since this seems like an issue with the externally resource resolving. And as you showed you already have the ability to change the provider even to a local one if you don’t want to make external requests for the fonts.
Thank you for sharing your discovery and answers though.
There's nothing really for me to reproduce, as the issue is with the external CDN and Filament's handling of ->font and not some code I wrote. I already wrote what I found out in as much detail as I can.
@awcodes Sure but unless you have a specific reason to do it, you will not take a second look at the ->font which uses Bunny by default and is prominent in the documenation. This was such a pain to debug as it was happening in rare cases, costing us a lot of time for something so trivial. In any case, I think a font CDN of all things should not have such a vital role to the point that it is able to degrade the performance of the entire app, at the very least it should just go back to the default Inter font.
the default Inter font is also loaded through Bunny though
sounds to me like a simple DNS issue... normally when timeouts are exactly 5s or 10s that's the problem, hence why switching to Google fixed it. So it's not really a Filament issue I would say. Bunny already uses
font-display: swap but that only matters for the secondary request - if you can't access Bunny at all then it's irrelevant. So perhaps using the media print trick would fix this. It looks like this;
Would that be useful if I submit a PR or nah? Most of my projects I add that in anyway to speed up the first paint.Does the font load from the CDN if you already have it on your system? Inter is quite common recently, so maybe that's why only happened after changing it?
never seen this trick before, does it affect subsequent loads or just the first when caching?
Does this not create FOUC issues?
On the first page load yes sometimes FOUC, but on subsequent loads I've never experienced it, I believe because the swap to media=all happens before any painting has commenced.
Happy to test it more in depth and report back exactly if you guys want 🙂
it sounds good tbf
I'm quite busy for the next few days but I'll draw up a PR next week (with some proper testing regarding the different situations) and let you guys take a look and decide. If you approve great, if not, no problem 🙂
Not sure how this is relevant. Isn’t the issue that the FontProvider tries to cache the font file on the local system and fails to do so? @Dan Harrin maybe we should move this to
artisan filament:assetseh, people should just use the spatie package then, i dont want to recreate that
Maybe I've misunderstood something but all the caching would just be dictated by the browser + Google's cache headers, no? From what I can see swapping to
GoogleFontProvider only changes the URL you grab the font from?
You're still doing a request to Google always, nothing locally?Yes, Dennis was on about actually fetching and storing the font locally to avoid such issues
I thought we are already doing this. Or why are filament loads slow when it’s about the font file? @adnn
It sounded like all filament requests are slow. But filament is fast and it was just the font that wasn’t being loaded?!
so its our fault 😁
I am not sure I am getting the issue. Sounded like we were trying to cache the file and that didn’t work and every PHP request takes forever.
Why does a font file brick the app? Shouldn’t it just fallback to a different font then?
I think there is something unusual going on but I’m not sure what exactly. I have noticed that when my internet cuts out, my local dev site hangs waiting on fonts instead of loading the page and just not showing errors for not being able to process the requested font.
Okay CSS is render blocking so I am not sure how to fix this 🤔
@adnn Any suggestion how this could be improved?
Haha exactly my point. Every single navigation in Filament would call Bunny font CDN, which was not resolving properly and it was practically unusable because it was waiting for it to timeout before doing anything. Sometimes taking even 10 seconds for a view to load. It was also happening seemingly random, half of my team complained, the other half had no problems, so a pain to debug.
I started debugging queries and setups, until it happened to me, as soon as I switched to GoogleFonts, our performance skyrocketed. I'm not joking when I say it's 10x faster. So yes, Filament is fast, but for some reason a font is able to brick it completely.
I'd probably just have the Inter shipped as a static font and fallback to it
I have also noticed the same behaviour. Tbh most (if not all) of my performance issues where because of my ad blocker. But the font is an interesting option, last time i programmed this barely existed so new stuff for me. 😆 i sound old, do i understand correctly that there is a spatie package to cache fonts locally or on your own server?
Filament
Spatie Google Fonts by Filament - Filament
Filament support for Spatie's Laravel Google Fonts package.
But the same thing can happen with google fonts or any other CDN. What would be the solution? Ideally we only ship fonts locally but we can’t include them all into filament.
I just switched to local font's and it's way quicker than bunny without a doubt. It would make sense for filament to ship with either an extremely fast cdn as default or locally, that locally would have to be the default one we currently use and people can adjust it as they see fit later.
But local requires a plugin like spatie google fonts which is an extra package to add
Correct
So each install of filament would require that plugin even people don’t use it
It wouldn't be my preference to have it by default. I think for now we need to find a faster cdn than bunny personally, but also make a post about how localised font's are faster for performance.
I don't know enough about Laravel to understand why a new package is needed, can't you just ship files of one default font and import it url('fonts/whatever') or just use system fonts?
And then if you use a custom one, you choose a CDN or install it locally yourself and that's it. Bunny has a PoP here in Ljubljana, and it still doesn't work, I've never had issues with Google fonts but I know it comes with a privacy sacrifice.
Another solution could be just manually timing out the request instead of waiting, no font should be taking more than a second to load and even that's very high
Another solution could be just manually timing out the request instead of waiting, no font should be taking more than a second to load and even that's very highHow does this work with HTML?
can't you just ship files of one default font and import it url('fonts/whatever') or just use system fonts?Hm. It would change the current behaviour though. People expect it to "just work" so we probably can't ship that with v3.
How does this work with HTML?Yeah it'd have to be JS
Hm. It would change the current behaviour though. People expect it to "just work" so we probably can't ship that with v3.->font('Inter') if font in fonts/ try $url= asset('font') else use default cdn doesn't change any behaviour, and it's prefferable to use the local font if you have it
if font in fonts/ try $url= asset('font') else use default cdnSure. But we are working with different FontProvider classes. It's not that easy then.
Unfortunately I've only started using Laravel and Filament recently so am not familiar enough to offer any other concrete suggestions. Perhaps @ctoma's idea is a lot easier and simpler option
I think as long as this is mentioned on the performance tips page of filament that is enough right? I have implemented almost all of the tips and it take like 15 min to implement most of it. Just the fonts i haven’t done but tbh its now already very fast.
I'm going to have more than a million records in my MySQL database. I will still be displaying 10 at a time. Do I have a reason to worry about load times when my database grows beyond half a million records?
nope
That's what I thought, but I wasn't sure if I was overpromising to the client. Thank you.
as long as your database server can handle, it shouldnt change Filament at all
if you're not increasing the page size then db query speed is the only factor
just throwing in my 2c here - forcing use of the Google CDN for the default font also significantly improved the performance/speed of my own filament instance (located in Australia)
a friend of mine is an engineer at Bunny, so i'll also bring this up with him.
Bunny engineer has said he's happy to look at the issue but will need to pool a few examples of people getting hit with poor performance pulling the font for him to be able to check it out
in particular, pulling the response headers to identify the servers being hit (like this):
Here's mine, we're located in Ljubljana Slovenia. It seems to be working alright currently, still took 3 seconds for response. Haven't been keeping track of it since switching to Google, but when I made the post it was taking 10 seconds and timing out.
Is it heresy to suggest that out of the box Filament should just use the system font stack? Rather than relying on a CDN to pull in a font.
It's an admin panel, the major system fonts are all beautiful for rendering content on the web and they load instantly, causing no issues with blocking or font swapping.
i dont think its unreasonable, no. i'll add it to my v4 list of things to discuss with Zep
If we don’t want to change the design we could just deliver the default font.
not sure i know what you mean?
Just change the font stack in the tailwind preset.
Guess it would still be loading in the head though.
Nm lol
Including the font file for the default font into the Filament assets so it's served from the same server.
oh you mean serve Inter locally
Yes.
Inter is licensed under the OFL, so can be distributed with open source software.
Using OFL fonts
The website of the SIL Open Font License
done in v4