Frontend assets optimization technics

Usually I’m not interested in FE aspects of web development.

Amount of pain that I experienced from having to spend 2 hours to setup SCSS with jQuery every time I start a new toy project turns me back from everything related to Webpack and friends for as long as it can only possibly be.

A little bit later I usually come across posts/articles where people describe how they optimize their assets (like https://twitter.com/dhh/status/1265718008191709185 or https://pragmaticstudio.com/tutorials/adding-tailwind-css-to-phoenix) and with a mixed feeling of a deep pain, guilt and curiosity trying a thing or two to not send 300kb of JS down to the browser on an initial page load.

And usually all those attempts are good for nothing.

That’s why I want to reach out to all people in our community who know their ways around frontend stuff and ask to share their recipes that can be applied to out-of-the-box Phoenix apps to deliver a snappier UX.

Most importantly:

  • How do you remove unused CSS, especially with Bootstrap?
  • How do you remove unused JS code, especially with Bootstrap?
  • How do you send down to a client only minimum amount of JS that will be used on viewed page exactly?
  • All your favorite tips & tricks.

I remember my experience working with Ember.js which was really awesome and took care for most of the problems for me so I could focus on writing code. It would be great to have similar experience (think Channels or Presence level of automation) with frontend assets.

God bless you.

1 Like

This is a very limited and partial answer but one thing people do in many projects (or so I heard) is to plug PurgeCSS in their webpack pipeline.

2 Likes

I found https://www.snowpack.dev/posts/2020-05-26-snowpack-2-0-release/ today.
Gonna try to experiment with Snowpack + Parcel and see if those are easier to comprehend than Webpack.

1 Like

What was your experience with Snowpack? I’m thinking about trying it out.

1 Like

Unfortunately my answer is likely to sound flippant and dismissive, but it genuinely isn’t meant to be. This is the approach that I’ve landed on after many years of FE work.

I don’t use Bootstrap, I write the CSS the project needs and nothing more.

I don’t use Bootstrap, I write the JS the project needs and nothing more.

I use a shared app.js file that is loaded across pages. This does general purpose tasks but tends to be small and rarely used.

I then write JS files by functionality rather than pages, pretty much as you would write a module. The difference is that I don’t import them, but load them on the pages they are needed with script tags.

If you wanted concatenation then I’d opt for a simple makefile (using cat) over Webpack or any other bundler.


I’ll try to sound less flippant now…

I came to this approach after years of trying all the different CSS frameworks (including Tailwind), build tools and JS frameworks. I don’t use SCSS anymore, instead opting for a few CSS variables. I use plain ES5 JS where I need it (which is increasingly rare thanks to CSS and HTML improvements) and there’s no build tool, transpiler, etc. Image assets are optimised ahead of build time in a dedicated tool and FE is generally very simple to understand.

I recognise this approach won’t be right for every project or team, but I’ve found it the most stable, predictable, time-efficient and performant solution. It makes working with others easy as there’s less on boarding and assets can pretty much be copied from one project to another as there’s no dependencies and the code is already very modular. This has actually increased efficiency in a group of related projects I’ve been working on lately vs. using Tailwind with StimulusJS and Webpack prior. I took this approach because Webpack was a step too far for the team I’m working with, but I’ve found it to be a much better approach overall.

Having no package.json ls oddly liberating and there’s nothing to go wrong when coming back a project after a few months and all the dependencies need updating.

My CSS and JS are open for anyone to read and learn from. Could they be smaller with minification? Absolutely, but this way allows people to learn as I did by “viewing source”. Equally, authoring your FE assets yourself, rather than letting a framework or build tool do it for you results in much smaller assets to begin with. Things like HTTP2 mean that loading multiple files (from the same domain) is actually preferable now to one large monolithic bundle.

As I said, it’s not an approach everyone can use and feel comfortable with but I’ve found the quality of my work has improved since adopting this method, along with my enjoyment of it. Building a website seems fun once again, with much less yak-shaving.

2 Likes

Didin’t actually tryit yet but it looks promising. Mainly, I’m thinking about combining it with Svelte, so that there will be one Svetle component per page acting as an entry-point to the all underlying logic.

If it works out, that will be a stellar combo!

1 Like

The ultimate answer to JS fatigue :smiley: !