Understanding JS performance

#1

Dear Livewire experts,

I’m test building a new website in Livewire but I’m very keen on JS performance because of high SEO requirements and the fact that Google is starting to incorporate LCP, TTI/TBT and CLS into pageranking beginning of May '21.

Now I worked out 2 scenario’s, I have a long select/filter sidebar with 13 types of filters. HTML/PHP wise they’re nearly exactly the same.

Scenario 1) one livewire component for the whole sidebar. Click one checkbox or dropdown and the whole component refreshes
Scenario 2) 13 seperate livewire components, that emit events to an additional 14th livewire component who’s gathering results. Click one checkbox or select and 1 of the 13 components refreshes and then emits an event so that the 14th component also refreshes.

Using Lighthouse I get pretty bad scores on both when running the in the simulated mobile device (that’s a 4 year old Moto 4G with fast 3G internet and CPU slowdown). Interesting though, scenario 2) is roughly 2x faster than scenario 1) in terms of JS main thread time consumption.

I first thought that the http requests bouncing back and forth would be more constraining but, regardless whether you’re updating 2 small (12kb, 3kb gzipped) or 1 big component (150kb, 15kb gzipped) the http requests aren’t the problem. It’s the JS main thread consumption…

I can see both Livewire and Alpine.JS placing over a hundred setTimeout() calls and doing a bunch of other stuff I’m having trouble to understand at first glance.

Can anyone explain a bit how the logics of the Livewire JS works and what would be the most efficient way to deisgn components.

It appears that it doesn’t matter how many wire:model/wire:click calls I have (I tried escaping them, no changes). It appears as if the DOM size is the factor which determines the JS main thread load. If that’s true, would it be worth considering a different framework that does use a virtual DOM or is that pointless / not the cause of the JS main thread consumption?

Coming from an all back-end world here (-: Thanks in advance for your thoughts!

3 Likes
#2

Following.

I’d love to know if there are any performance tweaks that can be implemented :sweat_smile:

#3

I don’t think that livewire is designed to be fast. I saw a few sites made with laravel and livewire beeing pretty slow.

When you really care about speed then I would prefer to use Laravel/Livewire to design a nice backend for you/your client. And then build a nice frontend with plain blade or even a static site generator like https://github.com/tighten/jigsaw or https://www.gatsbyjs.com/. With gatsby (I know) - you get sites that deliver 100 points and full pwa in a Lighthouse test.

#4

Hmm, quite interesting, I just got my new laptop yesterday and suddenly all the scores went up in Lighthouse… and they’re now in line with the scores of web.dev/measure. I think my 2011 XPS 15 wasn’t fast enough to simulate a throttled down Moto 4G? :grimacing: :grimacing: My brand new XPS 15 is yielding excellent results, similar to web.dev/measure.

I guess livewire is very swift after all (-: Still interested in how the way Livewire alters the DOM is different from the way a virtual dom utilizing JS framework does and what that should mean on speed.

@Slowwie, thanks for your reply, Gatsby also looks interesting, though doesn’t offer the blazingly fast dev exp that Livewire does but if speed would still be a problem, I might’ve changed my mind.