12 ms·

Performant Front-End Architecture

305 points by mostlystatic 7y ago

deleted 7y ago
[deleted]
corentin88 7y ago
> 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.
- ChrisCinelli 7y ago
  But even better: 1) Use a framework/language that is optimized by default instead one that is slow by default. Ex: Svelte only recalculate only the part of the UI affected by a change. Most of the other frameworks recalculate the whole virtual DOM. 2) When you can write something fast or slow in the same amount of time go for the fast one. It seems trivial even mentioning it but sometimes people with "make it work first, make it better later" do not even spend few seconds pondering this.
  - JMTQp8lwXL 7y ago
    Practically, not much can be quickly built in Svelte. There's thousands of React components I can download right now to solve my problems. Shipping features to users has a much bigger impact on a business than subpar page load times.
    - tobr 7y ago
      “not much can be quickly built in Svelte” - is this an experience you actually have from trying it? Because it’s very far from what I’ve experienced. So many things in Svelte can be done with surprisingly little code. Also in my experience, those thousands of React components are going to be a source of new problems. The more of them you have, the more likely you’ll run into frustrating limitations that contorts your code to an unmanageable mess.
      - JMTQp8lwXL 7y ago
        I do not. However, I have used React and Angular and they all take roughly some baseline amount of effort to achieve anything. And in all of them, I've had a times the need to rely on the community to ship product features faster. Have you tried implementing accessible drag-and-drop lists? Atlassian, for example, has spent years working on that problem, making a well-polished, enterprise-grade, cross-browser dnd solution (react-beautiful-dnd). And DND might be just a small feature of any otherwise much larger app. Foregoing all of these existing tools to start with a new UI framework is not a decision to be made lightly.
- zzzcpan 7y ago
  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 7y ago
    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.
    - ignoramous 7y ago
      > Is it worthwhile making a page load 10x faster? I get your point. This is an outlier, but hear me out: For some of the workloads I run on https://workers.dev https://workers.dev, I can tell you that going from 100ms to 10ms is something I look for every single day. I am also very interested in anything that takes the memory usage down into KBs from high MBs, say.
    - otabdeveloper4 7y ago
      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 7y ago
        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 7y ago
- bcrosby95 7y ago
  In my experience it does. A place I worked once had a mysterious dip in user activity with a deploy, and the deploy only included a shadow feature that nonetheless still loaded the required, but not optimized assets. When we removed the loading of the assets user activity went back up. This was a decade ago so I don't remember the exact specifics. The dip was high enough that we basically stopped everything else and immediately investigated.
lbj 7y ago
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 7y ago
  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...
  - ChrisCinelli 7y ago
    There are boilerplates that encapsulate best practices for some use cases but they may end up obsolete after a year or so...
  - chucksmash 7y ago
    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.
- deleted 7y ago
  [deleted]
- newhotelowner 7y ago
  > so many built on outdated/inferior tech So you update all your apps/websites to the latest/superior tech?
  - PZ81JUXJE7uJ 7y ago
    Also, a simple jQuery + HTML frontend is in most cases way more performant then the "modern" mess that webpack generates.
jmeyer2k 7y ago
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.
- ChrisCinelli 7y ago
  Good job. Just a minor nit: I assume most website these days have HTTP2 support. Otherwise considering the ROI I would work on that first so that should be optimization #1.
- FailMore 7y ago
  Just for balance, the company behind the blog post is also a developer-ran performance monitoring service: https://www.debugbear.com/ https://www.debugbear.com/ (Disclosure: this person is not me, but I have used the service and I do know the person)
- thrower123 7y ago
  It's so much easier to profile and optimize backend requests and the tooling is so much better. So many fewer moving parts to corral.
- duhi88 7y ago
  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.
  - deleted 7y ago
    [deleted]
  - mattmanser 7y ago
    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.
musicale 7y ago
I greatly dislike the use of "performant" as an adjective. The first sentence uses "fast and user-friendly" which is much clearer.
- amatecha 7y ago
  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.
  - tabtab 7y ago
    My pet peeve is "monolithic". It implies that anything without microservices is Flintstones technology, encouraging clueless managers to bloat up software with microservices to get things like "separation of concerns". It's often separation of productivity from reality. A lot of IT press is "fake news".
    - closeparen 7y ago
      The IT press is unnerving. It implies a whole ecosystem: managers making technical decisions they don't begin to understand, and predators grooming the managers' egos in order to pounce on their budgets. I get that the right person to lead a large organization might not be technical, but you'd hope they'd delegate those calls to someone who is. Not try to figure it out personally based on what they read in a trade publication for "visionary thought leaders."
  - musicale 7y ago
    ^ This. "Performs well" doing... what, exactly? And how is "performance" measured? (Some basic and often conflicting measures include latency, throughput, power/cooling, reliability, cost...)
tylerjwilk00 7y ago
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 7y ago
  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 7y ago
    “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 7y ago
      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.
      - csande17 7y ago
        It's a shame more companies don't keep the old version of their website around when they launch a redesign. It's pretty easy to visit https://i.reddit.com/ https://i.reddit.com/ and https://m.reddit.com/ https://m.reddit.com/ on your phone to see which one feels faster.
        acdha 7y ago
        Forget “feels faster”, I use that for stability every time new reddit hangs - usually 2-3 times a day I have to do that because they don’t handle errors yet, and they recently added a new bug where you can’t tell whether a reply was sent.
neya 7y ago
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 7y ago
  Semi-related and backend agnostic is Intercooler.js: https://intercoolerjs.org/ https://intercoolerjs.org/ It's just AJAX and HTML fragments.
jdmg94 7y ago
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 7y ago
  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 7y ago
    Try the first four videos here: https://www.youtube.com/playlist?list=PLPxbbTqCLbGHPxZpw4xj_Wwg8-fdNxJRh https://www.youtube.com/playlist?list=PLPxbbTqCLbGHPxZpw4xj_...
    - amatecha 7y ago
      Ah nice, thanks!!
Supermancho 7y ago
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 7y ago
  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-latency-cost-them-1-in-sales/ https://www.gigaspaces.com/blog/amazon-found-every-100ms-of-....
  - Supermancho 7y ago
    > 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 7y ago
      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.
jupp0r 7y ago
“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
robgibbons 7y ago
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.
- GoblinSlayer 7y ago
  It's elitism against low quality. Webdev inflated dramatically and cuts the costs to absolute minimum, so quality drops severely. It's not only javascript, everything in webdev is low quality, it's not a fundamental trait, it's a real life trait. Turing complete part is just more sensitive to low quality. Flash is what web 2.0 really wants, but has to emulate it with enormous hacks, while having similar security implications, it repeats history.
  - smt88 7y ago
    Browsers already have a full-featured Flash alternative: canvas
- scarmig 7y ago
  A SPA is predictive of a web application that has substantial performance, UX, and accessibility issues. A high schooler can build a page with some simple HTML and some jQuery sprinkled in that makes for a substantially more pleasant experience than teams of professional developers regularly manage to do with SPAs. I'm sure there are SPAs that are pleasant and add value above the alternative, but they are clearly very hard to build correctly, as evidenced by how many multi-million dollar SPAs are pieces of shit. It's kind of besides the point whether that's an organizational or engineering failing, because the very fact that SPAs lend themselves to those kinds of failings is an indictment of them.
Kiro 7y ago
> 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 7y ago
  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 7y ago
    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?
- mostlystatic 7y ago
  That's a good point, I didn't consider having the browser cache the document. That means you can achieve the same thing with the HTTP cache. (I'm not sure if the retention logic between the service worker cache and the HTTP cache differs much.) Service workers give you more control about what's in the cache, for example you can serve a stale version of the HTML and then fetch an up-to-date version in the background. But since last year you can also use `Cache-Control: max-age=1234, stale-while-revalidate=86400`, so it should be possible with the HTTP cache as well now.
drej 7y ago
My favourite performance advice, regardless of context: just do less stuff. In this case - load fewer and/or smaller resources.
- BubRoss 7y ago
  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.
ficklepickle 7y ago
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.
nojvek 7y ago
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.
4ec0755f5522 7y ago
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.

305 points by mostlystatic 7y ago

deleted 7y ago

[deleted]

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

ChrisCinelli 7y ago
But even better: 1) Use a framework/language that is optimized by default instead one that is slow by default. Ex: Svelte only recalculate only the part of the UI affected by a change. Most of the other frameworks recalculate the whole virtual DOM. 2) When you can write something fast or slow in the same amount of time go for the fast one. It seems trivial even mentioning it but sometimes people with "make it work first, make it better later" do not even spend few seconds pondering this.
- JMTQp8lwXL 7y ago
  Practically, not much can be quickly built in Svelte. There's thousands of React components I can download right now to solve my problems. Shipping features to users has a much bigger impact on a business than subpar page load times.
  - tobr 7y ago
    “not much can be quickly built in Svelte” - is this an experience you actually have from trying it? Because it’s very far from what I’ve experienced. So many things in Svelte can be done with surprisingly little code. Also in my experience, those thousands of React components are going to be a source of new problems. The more of them you have, the more likely you’ll run into frustrating limitations that contorts your code to an unmanageable mess.
    - JMTQp8lwXL 7y ago
      I do not. However, I have used React and Angular and they all take roughly some baseline amount of effort to achieve anything. And in all of them, I've had a times the need to rely on the community to ship product features faster. Have you tried implementing accessible drag-and-drop lists? Atlassian, for example, has spent years working on that problem, making a well-polished, enterprise-grade, cross-browser dnd solution (react-beautiful-dnd). And DND might be just a small feature of any otherwise much larger app. Foregoing all of these existing tools to start with a new UI framework is not a decision to be made lightly.
zzzcpan 7y ago
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 7y ago
  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.
  - ignoramous 7y ago
    > Is it worthwhile making a page load 10x faster? I get your point. This is an outlier, but hear me out: For some of the workloads I run on https://workers.dev https://workers.dev, I can tell you that going from 100ms to 10ms is something I look for every single day. I am also very interested in anything that takes the memory usage down into KBs from high MBs, say.
  - otabdeveloper4 7y ago
    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 7y ago
      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 7y ago
bcrosby95 7y ago
In my experience it does. A place I worked once had a mysterious dip in user activity with a deploy, and the deploy only included a shadow feature that nonetheless still loaded the required, but not optimized assets. When we removed the loading of the assets user activity went back up. This was a decade ago so I don't remember the exact specifics. The dip was high enough that we basically stopped everything else and immediately investigated.

lbj 7y ago

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 7y ago
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...
- ChrisCinelli 7y ago
  There are boilerplates that encapsulate best practices for some use cases but they may end up obsolete after a year or so...
- chucksmash 7y ago
  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.
deleted 7y ago
[deleted]
newhotelowner 7y ago
> so many built on outdated/inferior tech So you update all your apps/websites to the latest/superior tech?
- PZ81JUXJE7uJ 7y ago
  Also, a simple jQuery + HTML frontend is in most cases way more performant then the "modern" mess that webpack generates.

jmeyer2k 7y ago

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.

ChrisCinelli 7y ago
Good job. Just a minor nit: I assume most website these days have HTTP2 support. Otherwise considering the ROI I would work on that first so that should be optimization #1.
FailMore 7y ago
Just for balance, the company behind the blog post is also a developer-ran performance monitoring service: https://www.debugbear.com/ https://www.debugbear.com/ (Disclosure: this person is not me, but I have used the service and I do know the person)
thrower123 7y ago
It's so much easier to profile and optimize backend requests and the tooling is so much better. So many fewer moving parts to corral.
duhi88 7y ago
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.
- deleted 7y ago
  [deleted]
- mattmanser 7y ago
  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.

musicale 7y ago

I greatly dislike the use of "performant" as an adjective. The first sentence uses "fast and user-friendly" which is much clearer.

amatecha 7y ago
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.
- tabtab 7y ago
  My pet peeve is "monolithic". It implies that anything without microservices is Flintstones technology, encouraging clueless managers to bloat up software with microservices to get things like "separation of concerns". It's often separation of productivity from reality. A lot of IT press is "fake news".
  - closeparen 7y ago
    The IT press is unnerving. It implies a whole ecosystem: managers making technical decisions they don't begin to understand, and predators grooming the managers' egos in order to pounce on their budgets. I get that the right person to lead a large organization might not be technical, but you'd hope they'd delegate those calls to someone who is. Not try to figure it out personally based on what they read in a trade publication for "visionary thought leaders."
- musicale 7y ago
  ^ This. "Performs well" doing... what, exactly? And how is "performance" measured? (Some basic and often conflicting measures include latency, throughput, power/cooling, reliability, cost...)

tylerjwilk00 7y ago

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 7y ago
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 7y ago
  “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 7y ago
    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.
    - csande17 7y ago
      It's a shame more companies don't keep the old version of their website around when they launch a redesign. It's pretty easy to visit https://i.reddit.com/ https://i.reddit.com/ and https://m.reddit.com/ https://m.reddit.com/ on your phone to see which one feels faster.
      - acdha 7y ago
        Forget “feels faster”, I use that for stability every time new reddit hangs - usually 2-3 times a day I have to do that because they don’t handle errors yet, and they recently added a new bug where you can’t tell whether a reply was sent.

neya 7y ago

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 7y ago
Semi-related and backend agnostic is Intercooler.js: https://intercoolerjs.org/ https://intercoolerjs.org/ It's just AJAX and HTML fragments.

jdmg94 7y ago

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 7y ago
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 7y ago
  Try the first four videos here: https://www.youtube.com/playlist?list=PLPxbbTqCLbGHPxZpw4xj_Wwg8-fdNxJRh https://www.youtube.com/playlist?list=PLPxbbTqCLbGHPxZpw4xj_...
  - amatecha 7y ago
    Ah nice, thanks!!

Supermancho 7y ago

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 7y ago
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-latency-cost-them-1-in-sales/ https://www.gigaspaces.com/blog/amazon-found-every-100ms-of-....
- Supermancho 7y ago
  > 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 7y ago
    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.

jupp0r 7y ago

“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

robgibbons 7y ago

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.

GoblinSlayer 7y ago
It's elitism against low quality. Webdev inflated dramatically and cuts the costs to absolute minimum, so quality drops severely. It's not only javascript, everything in webdev is low quality, it's not a fundamental trait, it's a real life trait. Turing complete part is just more sensitive to low quality. Flash is what web 2.0 really wants, but has to emulate it with enormous hacks, while having similar security implications, it repeats history.
- smt88 7y ago
  Browsers already have a full-featured Flash alternative: canvas
scarmig 7y ago
A SPA is predictive of a web application that has substantial performance, UX, and accessibility issues. A high schooler can build a page with some simple HTML and some jQuery sprinkled in that makes for a substantially more pleasant experience than teams of professional developers regularly manage to do with SPAs. I'm sure there are SPAs that are pleasant and add value above the alternative, but they are clearly very hard to build correctly, as evidenced by how many multi-million dollar SPAs are pieces of shit. It's kind of besides the point whether that's an organizational or engineering failing, because the very fact that SPAs lend themselves to those kinds of failings is an indictment of them.

Kiro 7y ago

> 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 7y ago
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 7y ago
  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?
mostlystatic 7y ago
That's a good point, I didn't consider having the browser cache the document. That means you can achieve the same thing with the HTTP cache. (I'm not sure if the retention logic between the service worker cache and the HTTP cache differs much.) Service workers give you more control about what's in the cache, for example you can serve a stale version of the HTML and then fetch an up-to-date version in the background. But since last year you can also use `Cache-Control: max-age=1234, stale-while-revalidate=86400`, so it should be possible with the HTTP cache as well now.

drej 7y ago

My favourite performance advice, regardless of context: just do less stuff. In this case - load fewer and/or smaller resources.

BubRoss 7y ago
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.

ficklepickle 7y ago

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.

nojvek 7y ago

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.

4ec0755f5522 7y ago

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.