Not to be too negative, but I'm seeing a lot of purely anecdotal comments on HN with lots of fuzzy gut feelings and very little to back up what seemingly amounts to elitism against JavaScript.<p>It's very easy to write fast JavaScript, with React or pick-your-framework. I would argue that these frameworks go out of their way to help you do that. But carelessly throwing modules at your problem is not going to get you that.<p>There are many reasons why SPAs can be slow. Whether that is due to truly lazy developers, overly tight deadlines, or management that just doesn't care is often left out of these discussions.<p>Everyone likes to complain about SPAs, as if terrible load times are a fundamental trait of frontend frameworks. That is not at all the case.
How to optimise front end apps? Don't use pure javascript based frontend. Do all normal crud apps on regular server side code. Eg. A normal rails CRUD app is much faster even with the intermediate page loads factored in, than a heavy react app with a spinner to make it appear fast. Want to give the feel of a JS app? Use turbolinks. Really want to use something fancy and dynamically update your content from the server? Use something like Phonix Liveview. I love VueJS and React. But these days I've switched to using Liveview so much that I don't miss them at all. The benefits are also huge. Near instant updates with very little server load (scalable) and ultra-light frontend. Win win win.
Front-end performance optimization is surprisingly lacking when it comes to web apps. We focus so much on shaving off 50 ms when it comes to server response time, but we're fine with a 7 second load time for front-end. It's very surprising that there isn't as much focus on front-end architecture performance.
> In practice you'll rarely be able to optimize on all fronts. Find out what's having the biggest impact on your users and focus on that.<p>Can’t agree more. If your engineering team spent several sprints to focus on improving the app load time, it has to be something highly impactful on your conversion rate. Otherwise it’s just a waste of resources.
I spent the last 6 months optimizing front end performance at my last workplace.<p>What I can say is measure before just blindly following a checklist.<p>Chrome devtools performance and audit tools are awesome.<p>Measure, fix biggest bottleneck, repeat.<p>This post has some great recommendations but things could be simpler. Like use http cache headers instead of service workers. They help both the cdn and the browser. Use immutable urls for assets.<p>The best way to improve perf is to simply load less JS and CSS. Less is more. It’s not always possible but helps trim down large swaths of network load when you can keep things simple.
What a goldmine. We should put together an endless checklist of best practices for all parts of webdevelopment.<p>So many apps are lacking, so many built on outdated/inferior tech. Currently there's just too much knowledge to consume.
I'm surprised I haven't seen nuxt (an SSR framework for Vue.js) mentioned here. It makes many of these performance enhancements out of the box.<p>It enables some cool options, like pre-rendering static content with the generate flag. You can use it as a static site generator, or wrap dynamic stuff in a <client-only> component and only that portion will be rendered client-side.<p>Service workers & PWA stuff, code splitting and dynamic routes, its all made pretty easy.<p>I've been finding it quite easy to build performant front-ends with nuxt. It is opinionated, and it abstracts away the webpack config, so it certainly isn't perfect for everything. But for me, it has really been hitting a sweet spot.
I greatly dislike the use of "performant" as an adjective.<p>The first sentence uses "fast and user-friendly" which is much clearer.
“Establishing a new server connection usually takes 3 round trips between the browser a server:<p>DNS lookup<p>Establishing a TCP connection<p>Establishing an SSL connection”<p>This takes more than three roundtrips and I wish the author would have mentioned 0-RTT options in quic and TLS 1.3
I don't know what/how Fastmail does it but their front end is amazing. So fast. I assumed their name was about speedy delivery but the whole UX is the fastest I've ever seen.
> The service worker below caches the HTML and CSS that's needed to render the page.<p>Why would you need a service worker for this? Doesn't the regular browser cache achieve the same thing?
Modern front-end architecture has "fixed" the 1 second page load and replaced it with a 0.5 second page load... And a 3 second spinner... And a 1 second spinner... And a 4 second progress bar... But hey the TTFB is under 1s now!
5 second page load is fine. This endless tuning is a great analytical puzzle, but implementing a new feature trumps these complex micro-optimizations that the consumer less and less about, with mobile having already become the common case access (mobile access is already going to be slow from network anyway). It's rare that you get a complaint. Once it's loaded and you have cached as much as possible, you're fine for returning customers which matter more to appease.