Replies: 3 comments
-
|
Yep, tried converting Twig template to Blade in my project and got 3x slowdown. |
Beta Was this translation helpful? Give feedback.
-
|
I'm having the same problems. You want to use blade to make your development easier - but you now need to make sure to NOT use blade components, because it makes your site painfully slow. That's a huge reason, not to use Laravel or Blade-Components in following projects. Any fix for this? |
Beta Was this translation helpful? Give feedback.
-
|
Hello everyone, I'm currently in a similar situation. Maybe this talk can help all of you: https://youtu.be/M60-nxlrePc?t=1855 Caleb refers to livewire blaze. It seems to fix the issues we have. I'm going to refactor some of my code this week and see where I can use blaze to solve my very slow page load. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
First up – we love Laravel. We just launched our new rebrand (gigsalad.com, check us out!) using Laravel 11.x.
But unfortunately, we've discovered that utilizing Blade components is far slower than alternatives – and we're having to consider some major refactoring to reduce TTFB.
We're obviously not the first to find this. For some good reading, see the following:
Inspired by the benchmarking in the latter thread, we put together our own suite of benchmarks, including the use of a third-party caching directive (blade-boost-directive) and a custom
@loop(as in the Laravel News article).Here are our results when rendering 100 instances of Filament 3.x's badge component:
As you can see, the
<x-badge>component takes 27x the length of time to render as does the vanilla HTML.To test whether this was a result of the PHP overhead inherent to the Filament components themselves, we put together the following sandbox environment comparing 100x empty elements included as a component: https://phpsandbox.io/e/x/irrm9?layout=EditorPreview&defaultPath=%2F&theme=dark&showExplorer=no&openedFiles=
As you can see,
<x-empty-component>takes approximately 11x as long to be included 100x as the outputting of 100 empty<div>s.What is responsible for this overhead? How can it be improved? This isn't a purely academic pursuit – we're spending significantly more time on Blade rendering overhead than on database querying, booting, and other significant aspects of the application. Our Blade component usage (utilizing multiple components within loops for product listings) is not uncommon for a marketplace or e-commerce app like ours.
Beta Was this translation helpful? Give feedback.
All reactions