First of all, there is no free lunch when it comes to Phoenix and LiveView. I’ve done multiple iteration where I would do mostly custom diffing client side to increase rendering and avoid morphdom, but in my latest iteration I’m mainly using streams, function components in one LV, I never use LiveComponents.
You also want to pay attention to CSS, layout shift, painting etc. lighthouse will give you a decent report, but there is nothing like production.
With everything in software, performance comes by reducing the amount of work. So if you can cut down on unnecessary elements, classes, styles, data, chatter and code. Then you can see gains.
You probably don’t need your form rendered in the initial page load anyway (and even less if your app requires authentication anyway), so is the initial page load a concern if you use live_vue for the forms?
After reading @tmjoen’s suggestion, I was thinking if something like that could be part of LiveView. Basically a way to say that a form is embedded in another form, and we could automatically stitch it back together. In pseudo-code:
<form id="parent" phx-embeddable>
<input name="posts" />
...
<!-- there may be a better tag -->
</form>
<form phx-embed-at="#parent" phx-embed-as="posts[comments][0]">
...
</form>
Then LiveView would put everything under the comments at “posts[comments][0]” for you, so you don’t have to do anything. Can you please tell us about how your solution looks like? What have you tried, what worked and what didn’t?
Also, please try compression on your websocket if you are concerned with payload sizes. IIRC I had 60-70% reduction when I tried it out.
Oh, what a great find! @tmbb, did you profile the performance across browsers? Is it the same in Chrome and Firefox? Also, is there a way for you to temporarily replace the form tag by div and see if it changes anything? You can open up deps/phoenix_live_view, change the .form component, do mix deps.compile phoenix_live_view, and try it out.
I do cross browser testing, Safari is the best, and Chrome and Firefox is equal.
When it comes to highly optimized website with a lot of elements, like a database management tool, then the browser is less important, since the issues you are going to be hit by first is the browsers rendering engine.
So special attention on HTML construction and CSS is important. Tools like TailwindCSS and what not tend to get in the way, and hand written CSS and HTML tends to out win, due to the reduction of code needed to be written.
I mentioned Google Lighthouse, since it’s a fast and easy way to gain some insight. Vs having to spend time on interpreting a flamegraph.
FWIW, I asked Claude to build this small HTML page from the issue and I changed it to render inputs inside form. Firefox is about 5-6x slower when dealing with inputs (30ms for 1000 inputs), Chrome handles it about the same as everything else. However, Chrome is indeed much, much slower for forms.
I also asked it to generate a React app and the numbers are pretty much the same (slower for inputs), although I have no idea if the React app is decent or not: react-app-patching.js · GitHub
Compression is the first thing I turn on, my only issue with it (not Phoenix related) is that it’s incredibly hard to get an actual size of the payload without using packet inspectors, web browsers just show the decompressed payloads
To be honest, every solution I’ve tried has ending up being too complex for it to be worth it, and I’ve worked around it in terms of the product rather than the technical solution (as an example, disabled validation and only do it on save, partial forms where you only render one piece of the schema, make everything a livecomponent). I think a lot of it stems from not being able to to partial changesets, and I get why, but a lot of data comes in a list and most of the time you only change one of the list items, but you get it all back, and that is what causes the confusion I believe, the granularity of something like React doesn’t exist, again, I’m not saying it should, just that it’s not all that clear.
There’s also some strange things that happen that you would think shouldn’t. I have this super trivial components as an example.
def fa_icon(assigns) do
~H"""
{App.Components.SVGIconLibrary.icon("fontawesome", @category, @name, class: @class)}
"""
end
It just takes a name, a category and some classes, but even when nothing has changed you still get the entire element in the diff (see below), I understand it’s flagged as dynamic, but my initial understanding was that components that doesn’t change doesn’t get re-rendered, but maybe that’s just me
Now if you have a list of 100 items you get a 100 icons, which are all identical to the ones already in the markup.
Then you also have things like this coming from just form handling in general
Those will always be dynamic and that is quite the payload for something extremely basic. I get that they’re variables and considered dirty, but it’s frustrating to not be able to do anything about it. This is a classic example from a schema with “has_many” and using inputs_for, pretty standard. Now if you have a 100 threshold values even the absolute bare minimum on every validation call gets quite big.
“proper css” sound fun, how do you write proper css for customizable components? This is not about simple things like “hidden” etc.
The core components are extremely dynamic, that’s why we have this entire thread… I don’t think there’s a single one that doesn’t re-render heavily actually.
This is how core component icons look
<span class={[@name, @class]} />
Literally a list with variables
The idea with “few dynamic parts” sounds great in theory, but nobody has shown me it in reality in a Phoenix project.
Great point, and you’re right that the core components has a lot of dynamic parts when it comes to classes, that is mostly due to the use of TailwindCSS, you can match your CSS on pretty much anything Attribute selectors - CSS | MDN
Tailwind is great as a learning resource and small projects, but you would be hard pressed by avoiding to learn CSS it is an essential part in understanding how the browser works.
