DEV Community

Mikhail Karan
Mikhail Karan

Posted on • Originally published at htmlallthethings.com

Does speed really matter? Bun, Node.js, Vite, Webpack

What is HTML All The Things?

HTML All The Things is a web development podcast and discord community which was started by Matt and Mike, developers based in Ontario, Canada.

The podcast speaks to web development topics as well as running a small business, self-employment and time management. You can join them for both their successes and their struggles as they try to manage expanding their Web Development business without stretching themselves too thin.


What's This One About?

This week, Matt and Mike discussed the importance (or lack thereof) of website performance. We all know that Google PageSpeed Insights are used frequently across the industry, but are all those changes necessary? Should you spend time optimizing things that only change your load time by a second or two?

Topic Timestamps

Introduction | 00:01:35
Bun vs Node | 00:03:41

  • Improving site performance with Bun and how that stacks up against Node's performance Vite vs Webpack + Developer Time vs Load Time | 00:23:05
  • Matured frameworks and tools
  • The importance of lower load times on slower internet
  • Should lower load times take priority when a lot of us have broadband+ internet speeds? Frontend Optimizations | 00:46:40
  • font-display CSS property
  • Image optimizations (compression, resizing, etc.)
  • CMS training & limiting users so they don't cause issues without their knowledge

Show Notes

  • New frameworks and runtimes come out and constantly claim to be “the fastest one”, but does that really matter?
  • Let's talk about how speed really affects our industry in different categories
    • Development environment hot reloading/building
    • Production environment build speed
    • Customer facing UX/UI loading and interactions

Bun vs node

  • The reason I started down this topic was because of the release of Bun
  • Bun is a new server side javascript runtime that has a built in transpiler, task runner and npm client
  • It’s built using lower level code (Zig) and ontop of the WebKit JavaScriptCore engine (safari’s javascript engine) [Googles JS engine is V8 and notable slower then JScore]
  • Bun will make your Server side rendered pages a lot faster to generate compared to Node
  • It does not affect client side javascript code as that is determined by the browser you are using
  • End of the day, it allows JavaScript code to run closer to the metal and compare to lower level platforms like Rust
  • Does bun being faster (up to 3x faster then node) mean that node and deno are now too slow?
    • No, it highly depends on what you’re looking for but for the most part, Node can be very fast in almost all situations
  • Bun is a big step up though and is worth keeping an eye on as it will make building more performant, process heavy apps easier in the JavaScript ecosystem

Vite vs Webpack

  • Similar comparison between Bun and node
  • Two bundlers/build tools that have similar features
  • Vite is significantly faster and newer.
  • This is mostly about developer experience
  • A small react app on webpack can take 1-2 seconds to build
  • Compare that to vite it will be down to about 300-500ms
  • Other frameworks like Svelte can build even faster with vite
  • Although those build times don’t seem like much, the larger and more dependency driven an application gets, the longer the build times. These builds need to happen after every save of a file
  • HMR (hot module reloading) which is natively supported in vite, can make the builds on save even faster as it only reloads the files that have changed

Customer facing UI/UX and page loading speed

  • Webpages today are expected to load fast
  • Not just load but whatever workflow needs to be snappy
    • I.e add to car to checkout experience
  • That said the difference between 200ms - 600ms is not one that will usually cause major problems
  • A 2-3 second difference will

[Matt] Frontend Optimizations, Finishing Touches, Google PageSpeed Insights

  • PageSpeed Insights

    • Google’s PageSpeed Insights is a great way to measure your site’s performance and show it off to clients with something easily measured and shared
    • It can even help you detect issues with your site, like scripts that you didn’t mean to load, or when something routine is done incorrectly (ie a small image is uploaded as a massive 4k image)
    • There are a variety of issues that can plague websites’ performance, lowering their PageSpeed scores, especially on the mobile side of things
    • In my experience many of these issues come down to finishing touches not being polished up too well, including images that were left at full size from the development/design phase, old fonts loading when they’re no longer in use, or full on libraries being loaded small additions to the site that may have even been cut during production
    • The top 3 small, but important updates that I see often missed (or not polished well) are:

      • Font-Display
        • Font-display is a CSS property that controls how a font is displayed on your site. Specifically how much blocking time you allow a font to have when loading a page, and how much time you allow for swapping to that font in the event that the blocking time is over and the font is still not loaded
      • Image Optimizations
        • Images are very large in comparison to text, and therefore should be closely controlled as much as possible
      • CMS training and limitations
        • When you hand over a CMS to someone who is not tech savvy you’re giving them control over assets and content that they have no idea how to optimize from a technical perspective

Thank you!

If you're enjoying the podcast consider giving us a review on Apple Podcasts or checking out our Patreon to get a shoutout on the podcast.

Support us on Patreon

You can find us on all the podcast platforms out there as well as

Instagram (@htmlallthethings)
Twitter (@htmleverything)
TikTok

Top comments (0)