Achieve high frontend performances with LiveView?

Phoenix Forum Questions / Help
,
1

Hi all,

I’m currently evaluating solutions for several projects I maintain (clients websites) and I need to modernize those.

Those projects have a technical debt:

  • Built 5 to 8 years ago,
  • LAMP stack using Drupal 8 (now migrated to 9),
  • Front end using Twig templating engine augmented with VueJS.

The not a problem: backend

My clients are happy having Drupal as a contribution platform, and so are we in my agency. It provides great value for community maintained features (content management, roles & permissions, workflow, etc.). We’ve been using Drupal since version 4, which is prehistory in the CMS world, so we know it pretty well (features, modules, APIs, hosting, security advisories processes, etc). Those websites are mainly static once the content is contributed, everything is cached in Varnish and response time is good. There are few forms (15 to 20 depending on the project), but no user account as of now. So it’s basically cached/static website browsing (Drupal handles cache invalidation pretty well). With a few exceptions here and there of course, that’s about it.

The problem: frontend performances

Today, the problem we’re facing is frontend performances. Nothing to eccentric here, some big images, long scrolling pages, with complex CSS gradients, animations, etc. But the pain point is the JavaScript, which is heavy, because it is bundled as single file, includes dozens of Vue components, still has lots of polyfills and workarounds for older browsers. Parsing time is a issue. So yes, it’s become a giant spaghetti soup and Lighthouse performances are bad, especially on mobile devices: 20 ~ 30 out of 100 :-/. Lighthouse is not God, but still, we have to face reality, mobile navigation is bad unless you have a last generation device. SEO is impacted and is becoming an issue, because Google takes into account Lighthouse scores for its ranking.

Strategy: decoupled CMS with Drupal

We are thinking of decoupling the frontend from Drupal. Keeping the CMS as a contribution platform, exposing the content through either JSON:API, REST, GraphQL… well you know anything like that.

And use COOL_TECH_HERE for the frontend.

I’ve done my research, and come up with a short list:

  • Gatsby not sure I like the full static philosophy.
  • NEXT.js the goto framework nowadays? Good mix between static and dynamic.
  • Phoenix and LiveView ?

Gatsby and NEXT.js share the same philosophy at frontend performance. Reducing bundle sizes by splitting JavaScript files, and loading them as needed. Make the website feel extremely fast using <Link> React component for prefetching data. They also have <Image> component which could be very handy. Next.js is also integrating React Server Component which looks promising.

I’ve been lurking on Elixir for 6 months now, and thoughts maybe Phoenix and LiveView could be a good fit.

I could be wrong, but my understanding is that LiveView could allow us to reduce even more JavaScript size, because some rendering could be computed on the server and applied on demand without having a JS component needing fetching and loading with HTTP roundtrips. I know it doesn’t make sense to do everything on the server, and I would still have some JS on the client side for UI only widgets and the likes.

My goal is to achieve more than 90/100 in Lighthouse performance score with a visually complex website. It’s pretty clear to me how I would achieve this with — let say: Next.js. But do you think it would make sense to go the LiveView way?

For example, I like the idea of link prefetching (shared by Next.js and Gatsby). It’s not clear to me if Phoenix’s live_session is related? Or is there anything similar in the Phoenix world?

Elixir and Phoenix are appealing to me, because, as it’s running as an application, I could have processes fetching data from the CMS, checking regularly for updates, build chunks of caches in the background. All the cool things we can implement with OTP.

I’d love to hear from you guys on that topic. And if you have examples of websites performing insanely high performances scores on Lighthouse it would help me make a choice, ahah!

Thank so much,
Jérémy

1 Like
2

This book might be of interest to you. You might want to start trying to improve what you have in the weak spots you’ve identified? What would be the advantage in ditching Vue?

Kill It with Fire | No Starch Press

1 Like
3

This is not the only solution, You can split into multiple bundles, and optimize your javascript code.

I don’t think You will gain speed by replacing JS by Liveview, but You might gain dev speed.

4

My recommendation is to try it out - build a minimal Phoenix app that pulls content from Drupal and displays it with Liveview, then get it deployed to a realistic production configuration. You’re definitely going to be facing a rough learning curve deploying BEAM vs deploying LAMP.

1 Like
5

I’d say if it ain’t broken, don’'t fix it.

Porting old code is a thankless job. It is far better to build a new thing and let the old things gradually fade into irrelevancy.

4 Likes
6

You’re definitely going to be facing a rough learning curve deploying BEAM vs deploying LAMP.

Oh, I didn’t think this was such a matter. Is it that complex?

7

Yeah I share your point, but from our (and clients) point of view, the front end IS broken, performance wise. So anyhow, I need to rebuild it, from the ground up!

8

It’s nothing impossible, but it’s significantly more complicated than LAMP’s “FTP a PHP file into the web server’s directory and It Just Works” minimal approach.

Check out things around mix release for more details.

1 Like
9

Can you post some links to those sites you’re talking about? You say they’re mostly static, but a lot of JS/Vue. What kind of content are we talking about and what is Vue used for?

10

I would need to ask my clients of they agree publishing here their website.

Vuejs is used intensely by Vuetify, Lightboxes, Forms, Carousels, Expansion panels, revealing and hiding content, small effects here and there, scroll detection, overlays… Context switching on the page, which could redraw some components.

11

Ahah, you know, PHP is not really about firing an FTP client anymore. It’s about git pull, installing dependencies, dumping the autoload, synchronizing the code on 3 different webservers. Clearing the cages, warming up those caches, etc.

:slightly_smiling_face:

1 Like
12

How about you try first to rewrite the frontend without all this junk, vast majority of this stuff is already available in html5 and css, and if you hit limits, then try something minimal like https://alpinejs.dev/

Of course you can also try to write the frontend with LiveView. It sounds like you want to try it and are looking for excuse :slight_smile: So I do encourage you to try it :slight_smile: It is additional complexity initially, but it might end up being better solution than the above, that really depends on specific details of the websites in question.

3 Likes
13

Yeah you’re right, I’ve been reading a lot recently about Elixir and Phoenix, and I’m really seduced, so I would love to try it out.

But of course, I want it to make sense, project wise.

Thank you all for your feedbacks. I’ll be keeping on digging, maybe make a poc to help me decide.

Cheers,
Jérémy

1 Like
14

@jchatard I’ve been through something completely similar. Have an e-commerce website that started on a PHP stack and had to change the front end for performance reason.
It went through multiple iterations:

  • Normal PHP + Riotjs ( Vue like JS framework )
  • PHP on the backend + Elixir for the frontend + Riotjs
  • PHP + Phoenix and Liveview
    I basically rebuilt the whole model layer of the PHP app on Elixir and I plug directly to the DB of the ecommerce platform. Cart operations are handled in liveview and then the elixir layer “simulate” the user session and communicate with the ajax api of the ecommerce layer.
    Only things still served directly by PHP to the end users is the payment page.

Results: Between 95 to 100 pagespeed score on desktop and mobile. My rankings in terms of SEO have increased 4 fold.

3 Likes
15

Wouah super nice!

I’m actually in a different zone, I’m keeping the back-end in PHP, and rebuilding the front-end using SolidJS ! It’s still early in the process, but I’m at 98 in Lighthouse as of writing. Which I’m super happy about.

Thanks for your feedback!

Cheers,
Jérémy

16

Great to hear @jchatard . I’m personally trying to keep JS to the bare minimum in my life :wink:

2 Likes
17

I would vouch for you to do it, because in the long run will be a wise decision.

Deployment

Its not that hard now, but it was a little more complex in the past, but some of the complexity its just people not being used to deploy an application built with a compiled language, at least it was for me (PHP Developer before).

You need to take your time to understand the differences between a compiled language and a dynamic compiled language:

  • Compiled time configuration vs bootime and runtime configuration.
  • Code that you write in some parts are only exercised at compile time, not at runtime. This can bite you when trying to configure the application with runtime configuration.
  • More exist, and others may contribute to the list.

After you understand this bit deployment will not bite you on configuration, thus you just can use mix release to build one and deploy. You can learn more with the book from @miguelcoba:

You can also use the built-in Phoenix command to deploy to fly.io and have your app running distributed across the globe.

Elixir

Elixir is a compiled language, but most of all is a functional programming language and your brain needs to make the switch on how to think about coding in a functional way, and the only course that clicked for me was this one:

I have release the result of following it:

hangman.exadra37.com

The repo: GitHub - Exadra37/elixir-for-programmers-2_learning: The hangman game is the result of following this awesome course

Live View

Don’t dive into coding on it without understanding the programming model and how things work, and the free chapters on this course do an excellent job on it:

You can even go and subscribe the paid version to master LiveView.

Performance and LiveView websites

I am always amazed how developers forget on very important bit in the performance equation of a website, the hardware and internet connection of the end user. It’s fast for you on localhost and even in production, but the chances of you using the latest hardware and a fast internet connection are great, plus you may be very near of your servers location (speed of light is slow for users in the other side of the world). I invite you to read this discussion:

By the end of it some websites using live view are shared.

2 Likes