
Performant Front-End Architecture - mostlystatic
https://www.debugbear.com/blog/performant-front-end-architecture
======
robgibbons
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.

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.

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.

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.

~~~
otabdeveloper4
> 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.

I disagree. SPA frameworks attempt to re-implement browser UI and DOM within
Javascript. _Of course_ the result is buggy and slow.

The browser already has a UI and DOM framework. Use it. (Yes, I know it's
ugly. Such is life.)

~~~
nickserv
Depends on the target audience. Many customers will be sold on how pretty an
app is, sometimes to the point of overlooking missing features. Having a good
looking app becomes a competitive advantage, and therefore important to spend
time on. Such is life.

~~~
otabdeveloper4
Your point is orthogonal, even if true. My point is that SPA frameworks are
necessarily buggy and inefficient - after all, their whole point is to
reimplement in a bespoke fashion the stuff that the browser already
implemented.

Buggy and inefficient stuff sometimes makes sense to a business, this is true.

~~~
jiofih
That’s a common misunderstanding and absolutely not true. They are
abstractions and not reimplementation, and in practice can help achieve way
better performance than what would naively come out. React is _not_ a
particularly good example of that.

They also solve problems like state synchronization and mutations that the
browser has zero facilities for. As mentioned in another comment above, in any
medium sized project you’ll have implemented more than half a framework
abstracting the DOM already.

------
neya
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.

~~~
brylie
Semi-related and backend agnostic is Intercooler.js:

[https://intercoolerjs.org/](https://intercoolerjs.org/)

It's just AJAX and HTML fragments.

------
jmeyer2k
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.

~~~
duhi88
In my experience, it's OK to have a (slightly) longer load time for content
behind a login wall. I also spend extra effort caching whatever I can for
return visits. Refreshing the page should give you an almost instant load
time.

~~~
mattmanser
I wonder if you've actually talked to any users, or this is just your personal
opinion.

I hate load times for apps, especially as I know it should be instant and all
sites I architecture load instantly.

~~~
duhi88
Yea, I've run user feedback sessions. Page loads never come up as a complaint
(plenty of other things to complain about :P)

The goal was to keep an average of <3.0s for the first meaningful paint, after
login. Before login, all pages were treated with the same respect you'd treat
any marketing page; render what you can as fast as you can.

Back with AngularJS, when code-splitting and lazy-loading modules/controllers
wasn't an option, you had to get creative. Since moving to Vue, initial page
load has never been an issue.

------
corentin88
> 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.

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.

~~~
zzzcpan
This is very shallow short term view on things. Performance also impacts
customer retention, loyalty, satisfaction and word of mouth advertising
because of that, makes engineers feel good and proud about the things they do,
rewarded and motivated to keep going and not leaving to do something else,
etc. Hardly "a waste of resources".

~~~
ChrisCinelli
Is it worthwhile making a page load 10x faster?

If you go from 10sec to 1 sec, absolutely.

If you go from 1sec to 100ms, maybe.

If you go from 100ms to 10ms, unlikely.

Assuming "fast enough for a good user experience", expecially early on in a
product lifecycle, I prefer to focus on development speed than product speed.

~~~
otabdeveloper4
In 2020, a webpage that "only" takes 10 seconds to load is a miracle of
performance and user-friendliness. Load times of up to a minute are the new
normal.

I'm pretty sure dismissive comments such as yours lead us to this bad place.

~~~
librish
What webpage that you frequently use takes up to a minute to load? I can't
think of a single one I've used over the past year.

~~~
otabdeveloper4
Open the developer tools and see for yourself.

Of course by "load" I don't mean TTFB, I mean actually loading the full page,
including all the spinners, reflows, banners and toolbars popping into your
page, images, etc.

~~~
librish
Why does that matter?

------
nojvek
I spent the last 6 months optimizing front end performance at my last
workplace.

What I can say is measure before just blindly following a checklist.

Chrome devtools performance and audit tools are awesome.

Measure, fix biggest bottleneck, repeat.

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.

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.

------
lbj
What a goldmine. We should put together an endless checklist of best practices
for all parts of webdevelopment.

So many apps are lacking, so many built on outdated/inferior tech. Currently
there's just too much knowledge to consume.

~~~
ChrisCinelli
I love checklists but you may end up with people dumbly following them.

That may be good when a checklist is accurate.

Unfortunately models work in the constraints and simplifing assumptions they
were built in.

"Web development" it is a pretty large subject to cover. Best practices for
dynimic site that is image heavy do not match best practice for systems that
is heavy in static content.

A check list for web delopment is going to be pretty messy if you want to
account of all cases.

But maybe it is worth giving it a try...

~~~
chucksmash
Include an item on the performance checklist about not blindly following items
on the performance checklist.

Now nobody who follows the checklist completely could be doing so blindly.

------
ficklepickle
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.

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.

Service workers & PWA stuff, code splitting and dynamic routes, its all made
pretty easy.

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.

------
musicale
I greatly dislike the use of "performant" as an adjective.

The first sentence uses "fast and user-friendly" which is much clearer.

~~~
amatecha
Oh man, I hate to be negative, but this word is my #1 pet peeve in tech today.
It's becoming more and more prevalent and is driving me crazy. Why do people
keep using this non-word? What do they think it means, and why? It's pure
jargon, at best. The word's meaning is completely ambiguous and loosely
implies numerous qualities without actually committing to any of those
potential meanings. Does it load fast? Consume little memory? Respond
promptly/clearly to user input? Do an acrobatic dance?

When someone uses this word, I can't help but feel that they are trying to
gain the approval/validation of people who like to hear that something
"performs well", without having to support the assertion with any concrete
substantiation.

~~~
neurobro
It is a word _because_ people keep using it. That's where words come from.
Apart from the number of characters, it is no better or worse than other
words/phrases having the same meaning. Sometimes the precise meaning is clear
from the background context. Sometimes additional details need to be supplied
outside of the title or bullet point where it is used.

What does "it" mean above? Devoid of context, it could be just about anything.

~~~
amatecha
I understand the concept of "it's a word because people use it" \- but what
does it actually mean? No one can give a consistent defininition because it's
nebulous jargon with no clear or specific meaning. Without fail, every single
usage is obfuscating or otherwise hiding the intended meaning.

Check out this Unity blog post I just came across: "Achieve beautiful,
scalable, and performant graphics with the Universal Render Pipeline"

What exactly are "performant graphics"? Does that mean high frame-rate? High-
poly? Extremely vibrant colors? HDR? Can run on a 486 with software rendering?

It doesn't tell me anything, and is essentially "vocabulary clickbait" \- it
"sounds good", without really communicating anything. This is why I despise
this word.

~~~
neurobro
In context, I would expect "performance" to refer to how quickly a scene can
be rendered, and another buzzword, "scalable", to refer to the size and
complexity of scenes that can be drawn. "Beautiful" probably means "lots of
detail and snazzy effects."

Actually, the article says "scalable across platforms", which is confusing to
me. Maybe they mean scalable to different screen sizes?

------
drej
My favourite performance advice, regardless of context: just do less stuff.

In this case - load fewer and/or smaller resources.

~~~
BubRoss
As sensible as that is in a general sense, this article is actually heavily
about dependencies and making sure the latency between when the browser knows
about dependencies is small.

------
jupp0r
“Establishing a new server connection usually takes 3 round trips between the
browser a server:

DNS lookup

Establishing a TCP connection

Establishing an SSL connection”

This takes more than three roundtrips and I wish the author would have
mentioned 0-RTT options in quic and TLS 1.3

------
4ec0755f5522
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.

------
Kiro
> The service worker below caches the HTML and CSS that's needed to render the
> page.

Why would you need a service worker for this? Doesn't the regular browser
cache achieve the same thing?

~~~
hoten
With a service worker, you can stream the header part of a new document
instantly from the service worker, while fetching the content. That
essentially makes an instance first paint.

I don't think that's what the example is showing, though.

~~~
mostlystatic
Oh interesting, I didn't know about stitching the streams together in the
service worker!

Do you know what the advantage of that is over serving the full cached HTML
page layout and then fetching the content HTML from inside the page?

------
jdmg94
last year the React team presented a pattern called fetch on render, combined
with proper code-splitting, I see this as a win-win for webapps

~~~
amatecha
Do you happen to have any link on a presentation or post about that? I did a
quick search and couldn't find more about it, though maybe it has a more
specific name or something? No worries if you don't know offhand, just curious
:)

~~~
sophiebits
Try the first four videos here:

[https://www.youtube.com/playlist?list=PLPxbbTqCLbGHPxZpw4xj_...](https://www.youtube.com/playlist?list=PLPxbbTqCLbGHPxZpw4xj_Wwg8-fdNxJRh)

~~~
amatecha
Ah nice, thanks!!

------
tylerjwilk00
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!

~~~
warent
This is such a tired old meme that conflates bad architecture with current
professional standards. Bad architecture of anything has existed since forever
but some bad apples don't spoil the barrel. Page render should occur within
the first 300ms and page load should be complete in a second.

~~~
acdha
“Should” being the key part of your comment: it’s quite rare in practice. Most
SPAs are lucky to have page render in 2-3 seconds, or fully loaded in 10 - and
my experience is using the latest iPhone in a major metro area around 10 ms
from most major CDNs.

~~~
scottmotte
Yeah it would be great to see some numbers from anyone who might have them.
I'd put money on SPAs being slower, inside the bell curve than, than the
average traditional page load app.

~~~
toastal
SPAs don't make sense if it's not an 'application', but wouldn't a SPA be
faster over time not having to reload the whole page and all that duplicate
markup? Wouldn't the simple JSON calls be smaller than refetching and
rerendering all of the HTML? Front-end application offer more than just no-
reload though, like push notifications, real-time data, and offline caches.

~~~
acdha
It’s not that simple: you need to factor in size and latency, too. If my SPA
loads 2MB of JavaScript and then makes 50 API calls, it’s going to be a lot
slower than the server sending 20kb of HTML in a single response.

JSON may or may not be smaller or faster: if you have to load data you don’t
need or, worse, chase links it’ll be worse. GraphQL may help but that’s
bringing it closer to server-side performance, not exceeding it.

Things which aren’t possible otherwise are the best argument for SPAs, but
another approach is progressive enhancement: you can load quickly and then
load features as needed rather than locking in a big up-front cost if all you
need are real-time updates or push notifications. There’s a spectrum of
capabilities here and there won’t be a single right answer for every project.

------
Supermancho
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.

~~~
why_only_15
5 second page load is not fine. Having the page load in 5 seconds is an
annoying experience that causes you to lose users -- Amazon lost 1% revenue
for every 100ms in page load time: [https://www.gigaspaces.com/blog/amazon-
found-every-100ms-of-...](https://www.gigaspaces.com/blog/amazon-found-
every-100ms-of-latency-cost-them-1-in-sales/).

~~~
Supermancho
> 5 second page load is not fine.

That analysis is from 10 years ago. Again, the landscape is different and
spending time on this is a borderline foolish discussion (interesting from a
technical perspective). It matters if you are the owners of a business, in the
mass-retail space. Save yourself the time, add to your features or verticals.

Yes, 5s is still fine.

~~~
brailsafe
5s is a pretty shit standard to set and in general customers or visitors that
you lose to poor website won't tell you about it unless it directly impacts
them. Also laughable that 5s should somehow become more acceptable even though
we have better tools, faster networks, and faster hardware on all fronts.

It seems like your argument isn't that it's fine across the board, but rather
that it's tolerable in a few circumstances. If I try and load a website that
is packed with _features_ but loads slowly and maybe has a choppy experience,
I'm going to go somewhere else if I can. It's only in the few circumstances
that you can't go somewhere else will you be relatively fine.

~~~
Roboprog
Is 5 seconds an initial load, or every time the user clicks a button or menu
item?

Business to business app, or sales site?

YMMV. 5 seconds could be intolerable, or a big improvement.

~~~
brailsafe
That's kind of what I was trying to describe there.

