Filament•3mo ago

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

Installation - Panel Builder - Filament

62 Replies

Povilas K•3mo ago

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".

awcodes•3mo ago

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.

adnn•3mo ago

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

toeknee•3mo ago

Please provide some code @adnn and also ensure all your filter options etc all use closures

adnn•3mo ago

@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.

GitHub

Css https://fonts.bunny.net unresponsive · Issue #7987 · filamentph...

Package filament/filament Package Version v3 Laravel Version v10 Livewire Version v3@beta PHP Version PHP 8.1 Problem description I was trying to login to filament admin dashboard but it takes long...

toeknee•3mo ago

Very helpful to know @adnn wondering @Dan Harrin if a deferrer should be loaded

Dan Harrin•3mo ago

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

toeknee•3mo ago

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?

Dan Harrin•3mo ago

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

awcodes•3mo ago

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.

adnn•3mo ago

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.

Dan Harrin•3mo ago

the default Inter font is also loaded through Bunny though

CT•3mo ago

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;

<link
    rel="stylesheet"
    href="https://fonts.googleapis.com/css2?family=Nunito+Sans:opsz@6..12&display=swap"
    media="print"
    onload="this.media='all'" />

<link
    rel="stylesheet"
    href="https://fonts.googleapis.com/css2?family=Nunito+Sans:opsz@6..12&display=swap"
    media="print"
    onload="this.media='all'" />

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.

RixzZ•3mo ago

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?

Dan Harrin•3mo ago

never seen this trick before, does it affect subsequent loads or just the first when caching?

awcodes•3mo ago

Does this not create FOUC issues?

CT•3mo ago

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 🙂

Dan Harrin•3mo ago

it sounds good tbf

CT•3mo ago

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 🙂

Dennis Koch•3mo ago

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:assets

Dan Harrin•3mo ago

eh, people should just use the spatie package then, i dont want to recreate that

CT•3mo ago

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?

class GoogleFontProvider implements Contracts\FontProvider
{
    public function getHtml(string $family, ?string $url = null): Htmlable
    {
        $family = str_replace(' ', '+', $family);
        $url ??= "https://fonts.googleapis.com/css2?family={$family}:wght@400;500;600;700&display=swap";

        return new HtmlString("
            <link rel=\"preconnect\" href=\"https://fonts.googleapis.com\">
            <link rel=\"preconnect\" href=\"https://fonts.gstatic.com\" crossorigin>
            <link href=\"{$url}\" rel=\"stylesheet\" />
        ");
    }
}

class GoogleFontProvider implements Contracts\FontProvider
{
    public function getHtml(string $family, ?string $url = null): Htmlable
    {
        $family = str_replace(' ', '+', $family);
        $url ??= "https://fonts.googleapis.com/css2?family={$family}:wght@400;500;600;700&display=swap";

        return new HtmlString("
            <link rel=\"preconnect\" href=\"https://fonts.googleapis.com\">
            <link rel=\"preconnect\" href=\"https://fonts.gstatic.com\" crossorigin>
            <link href=\"{$url}\" rel=\"stylesheet\" />
        ");
    }
}

You're still doing a request to Google always, nothing locally?

toeknee•3mo ago

Yes, Dennis was on about actually fetching and storing the font locally to avoid such issues

Dennis Koch•3mo ago

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?!

Dan Harrin•3mo ago

so its our fault 😁

Dennis Koch•3mo ago

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?

awcodes•3mo ago

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.

Dennis Koch•3mo ago

Okay CSS is render blocking so I am not sure how to fix this 🤔 @adnn Any suggestion how this could be improved?

adnn•3mo ago

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

Sjoerd24•3mo ago

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?

Dan Harrin•3mo ago

https://filamentphp.com/plugins/filament-google-fonts

Filament

Spatie Google Fonts by Filament - Filament

Filament support for Spatie's Laravel Google Fonts package.

Dennis Koch•3mo ago

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.

toeknee•3mo ago

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.

Dennis Koch•3mo ago

But local requires a plugin like spatie google fonts which is an extra package to add

toeknee•3mo ago

Correct

Dennis Koch•3mo ago

So each install of filament would require that plugin even people don’t use it

toeknee•3mo ago

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.

adnn•3mo ago

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

Dennis Koch•3mo ago

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

How 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.

adnn•3mo ago

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

Dennis Koch•3mo ago

if font in fonts/ try $url= asset('font') else use default cdn

Sure. But we are working with different FontProvider classes. It's not that easy then.

adnn•3mo ago

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

Sjoerd24•3mo ago

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.

IWBW•3mo ago

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?

Dan Harrin•3mo ago

nope

IWBW•3mo ago

That's what I thought, but I wasn't sure if I was overpromising to the client. Thank you.

Dan Harrin•3mo ago

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

jakeb•3mo ago

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

jakeb•3mo ago

in particular, pulling the response headers to identify the servers being hit (like this):

adnn•3mo ago

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.

Tetracyclic•3mo ago

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.

Dan Harrin•3mo ago

i dont think its unreasonable, no. i'll add it to my v4 list of things to discuss with Zep

Dennis Koch•3mo ago

If we don’t want to change the design we could just deliver the default font.

Dan Harrin•3mo ago

not sure i know what you mean?

awcodes•3mo ago

Just change the font stack in the tailwind preset. Guess it would still be loading in the head though. Nm lol

Dennis Koch•3mo ago

Including the font file for the default font into the Filament assets so it's served from the same server.

Dan Harrin•3mo ago

oh you mean serve Inter locally