Achieve high frontend performances with LiveView?

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

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

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.

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.

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.

3 Likes

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?

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!

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

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?

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.

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

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

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