
Can You Afford It? Real-World Web Performance Budgets - josephscott
https://infrequently.org/2017/10/can-you-afford-it-real-world-web-performance-budgets/
======
virmundi
Do we need all this JS? I’m starting to look back at classic web development
where you had a server rendered mvc style app. There was a controller and
templates populated on the server. Every page was a full rerender, but it was
small html. Proper caching kept the minimal CSS and images on the client for a
regular session under 30 minutes. This seems better.

I know we switched because front end experts told us that users found the full
refreshes annoying. They said that users really wanted native desktop like
seamless change pages. Never did I see proof of these claimed. Is the modern
JS based design our cubicle moment? Did we get suckered in by experts making
productivity claims with nothing to back them up?

~~~
feelin_googley
"Do we need all this JS?"

I know at least one user who is asking this same question. He does not believe
it is needed.

Is it possible that "what users want" and what developers want may be two
different things? Could developers have wants that are unique to developers?

Purely anecdotal but I do not know any fellow users who "want javascript". I
know many who do not want a number of common annoyances though. And I know
these hassles are in many cases enabled via javascript.

The tactic leveraged against users is to tell them they _need_ javascript for
some thing to work. Then users want it. But I think really they just want the
thing to work. They have no particular affection for javascript, let alone any
knowledge of _why_ they need it.

One thing I have observed over the years the web has existed early 1990's to
today is that users can adapt to anything. Whether it was learning keyboard
shortcuts on the console and using text-only programs like Pine, or running
www searches that took minutes to finish, or communicating with 140 characters
or less, or working with tiny touchscreens and horribly slow web pages and
mobile apps. Many more examples if I gave it some more thought. From what I
have seen, users accept what they are given and find a way to make it work.

~~~
aaron-lebo
How do you notify a user of errors in input without a complete page refresh if
you do not use Javascript (ignoring the most basic HTML stuff)? Without at
least some scripting capability, you're talking about making the experience
worse for the user to the benefit (ease of the request/response model) of the
developer.

Don't throw the baby out with the bathwater. It is the responsibility of devs
to use technology well. You don't want all of this JS, but you do want some of
it.

Too many people are making their assumptions about what is possible and what
JS is capable of based upon views of web development that are 5-10 years out
of date or based on bad software. Bad software is endemic to the industry,
it's not representative of any single tech stack.

~~~
ehnto
You just let the page refresh. It's really not that much different. I am not
saying don't use JS for UX improvements mind you. But your comment suggests
that any other approach makes no sense. If you have a massive form that has 12
fields then it would be a huge help, but just a couple of text fields? Why
replicate the backend validation in client side JS when it's already there on
the backend? Then you would have to maintain two code pathways in two
different languages in two different locations if you need to update the
validation rules. Where simple works, pick simple.

5 years ago was 2013, there were some pretty great things going on in the web
in 2013. Don't lose sight of lessons learned by previous work either. A new
shiny framework doesn't automatically make it better practice.

While we are reinventing the wheel in client side JS we should make sure to
remember that it has probably been done before, software has been around for
decades, the web as well, and to think the best of it has only just happened
in the last five years is a bit misguided.

~~~
TeMPOraL
This. You can't trust client-side validation anyway, so you need to have some
server-side. So why not just let the page refresh, and then add a _tiny bit_
of JavaScript that'll send off the form via AJAX to validation?

Suddenly, the site becomes solid, lightweight, and supports everyone. That's
what I think people used to call "progressive enhancement".

~~~
mrighele
I would love to have a way to tell the browser "don't throw away the current
DOM, Just apply the differences". It would work nicely in non-js page to make
the experience smooth (and would probably work terribly if there was a lot of
J's, of course)

~~~
pcmaffey
This is exactly what React's virtual DOM does. Maybe the future is making the
virtual DOM native to the browser?

Bundle React with Chrome? Or how about a browser package manager that could
cache and reuse all these common js libraries used on so many sites?

~~~
discreditable
DecentralEyes does just that.

------
saas_co_de
> 45% of mobile connections occur over 2G worldwide > 75% of of connections
> occur on either 2G or 3G

this is so important. if you want growth you need to be making a product for
growing markets.

~~~
adventured
No, you need to assess where your customers are and focus there. Just because
a market is growing, it doesn't mean that market contains customers for your
product. That depends on numerous variables including pricing.

The US will add ~$570 billion to its GDP this year. That's equal to 25% of
India's entire economy. An increasingly large part of Europe is back to
generating solid growth again. Even Japan is showing signs of life. You don't
need to focus on 2G markets if there are few customers there for your
products.

~~~
jcelerier
> You don't need to focus on 2G markets if there are few customers there for
> your products.

as someone who used to have a poor internet access, rest assured that I will
have no sleep until every review website and comment section has something
about how slow your website / app / whatever is. These ones generally don't
lag.

------
raverbashing
Meanwhile, HN loads like a charm and time to interactive seems to be less than
0.5s

Seems like that's what happens when you are too deep in the js bog, and you
forget what is below the thick js cover

~~~
sgk284
I recently launched the landing page[1] for my startup and the designer gave
us a crazy animated design.

All of my personal sites never required JS and have always worked just fine in
Lynx. I didn't want any JS on the landing page (not even for analytics, we can
do that server side), so decided to see what HTML + CSS can do these days.

I was pretty blown away with how easily I was able to have a half-dozen
animations running in parallel with 3 videos playing and being transformed in
a 3D space.

Even better, the page works perfectly fine in Lynx! I recognize that there are
times with the modern web where JS is required, but I try my damnedest to
minimize it. And modern web standards make it easier in ways that were
impossible a decade ago (e.g. no more $.fadeIn()).

[1] [https://banter.fm](https://banter.fm)

~~~
FajitaNachos
If you add an overflow:hidden to your content section, you won't have that
wonky extra space to the right. That's just a quick fix. I didn't look into
why it was happening.

------
idlewords
It's 2017. It's shameful that our expectations for web speed should be this
low.

~~~
ianamartin
I was going to say this but wanted to read the comments first to see if anyone
else did.

The constraints on global technology sever for this budget. But I have a
personal standard of 200ms for TTI on my projects, and I push hard against any
requirements or suggested libs or UI features that broach this.

5 secs? You can get away with that if you’re a global brand that people are
already hooked into, I guess. The amazon iOS app is infuriating on a brand new
iPhone 8 on gigabit WiFi. And that’s an app where every second of load time is
lost revenue. They do not, apparently have any kind of budget concept.

Facebook is similarly awful. They can afford to blow their load budgets
because users are already locked into the network. Or at least they think they
can.

When I’m bringing a new app to market, speed is my highest priority feature.
And the feature backlog is organized by cost of speed, not by difficulty or
time to market.

And like another poster said above, most of this is completely unnecessary. Be
a dinosaur. Write “MVC” apps with server side rendering and deal with Ajax
where you have to for as long as you can. Write the very little bit of js you
need, and rock on.

It’s not hip, and it’s not always fun. But it’s fucking fast.

~~~
swyx
sorry, but 200ms for TTI on the web? are you measuring the same way that he
is? he includes 1600ms just for dns lookup and tls handshake

~~~
ianamartin
Sorry I wasn’t clear about that.

The article is using some very heavy constraints on networking and hardware
based on a global, mobile audience.

My constraints do not take that into account. But they would only add a max of
200ms on top of that minimum the article is talking about.

Not anything near ~4 secs. 4 secs to do anything on a web app is malpractice.

------
tboyd47
Front-end developers could solve all of this by just learning the base
technologies of HTML, HTTP, CSS, and JS really well and ignoring everything
else.

We're at a beautiful point in web development where browsers are finally
unified on open standards, and we're all too locked into these outdated JS
frameworks to take advantage of it.

~~~
kakarot
It's important to strike a healthy balance between reinventing the wheel and
locking yourself into a bulky framework. Whether you are building a personal
project, or working on another's time, in the early phases your #1 concern
should be speed of development. If a compact, properly modularized, battle-
tested tool that completes your desired task is readily available, should you
really be wasting your time writing something that's been done a thousand
times before?

I've been around the block with popular front-end frameworks. The first one
I've truly found to be a joy to use is Mithril.

Unlike React, a framework that's gotten a lot of buzz here lately, it's more
than just a view library. There is a routing paradigm in place along with a
few other goodies. Yet it all weighs in at <8kb gzipped and generally performs
faster than React. It really feels like it hands you just the things you need
to get started and steps out of the way.

Check out its performance compared to a few other popular frameworks:

[https://mithril.js.org/framework-
comparison.html](https://mithril.js.org/framework-comparison.html)

~~~
tboyd47
But you are missing my main point: what are all these frameworks for?

I bet if you asked any front-end developer what the main benefit of their
chosen framework is, they will say something like code organization or file
structure.

It used to be that you _needed_ a framework to abstract away all the browser
incompatibilities. But that was in 2009 -- look up any given W3 standard on
CanIUse these days and you will find support across all major browsers.

What if we could just get by without a framework? And just organize our own
code? Is that so far-fetched?

------
z3t4
It's nice of you to make your web presence work for someone with 400Kbps link
with a 400ms round-trip-time (“RTT”), while you're at it, also make sure it
works with JavaScript turned off! And browsers with limited CSS support. And
is readable on a terminal browser. And 600x400 px resolution.

------
justin_d
It's remarkable how much js gets loaded onto a page (mainly due to libraries)
vs. how much of its functions are needed for what the web developer is trying
to do. There just is not a whole lot of use cases for the big libraries unless
you're doing something really intensive like a drawing app.

~~~
crooked-v
Tree shaking should help... eventually.

~~~
megaman22
Next year, in Jerusalem

~~~
briantakita
You can have tree-shaking right now, with rollup.js. You can also have purely
transpiled isomorphic component library (no runtime download) running at near
vanillajs speeds with svelte.js.

------
olegkikin
His argument is based on an example where he puts JS in <head>, when it's been
a recommendation for ages to put JS at the very end of <body>.

~~~
aphexairlines
It looks like he needs the JS to load first for the browser to make sense of
his custom elements: "If our example document wasn’t reliant on JavaScript to
construct the <my-app> custom element, the contents of the document would
likely be interactive as soon as enough CSS and content was available to
render meaningfully."

~~~
slightlyoff
Howdy; author of the article here.

TTI would be pushed back _regardless_ of where the script was included so long
as it executed for more than 50ms (very likely). I used a trivial document
that contains many pathologies I see in traces to illustrate the point, not to
suggest what ideal apps will do.

------
caseymarquis
I'm sure there are niches out there where complex web apps are best built
without an SPA framework, but use the right tool for the job! If I'm writing
an embedded interrupt routine, I don't use slow clunky C, I use assembly. If
I'm writing a complex web application, I use an SPA framework like Vue. If I'm
delivering static content, I use minified html and css.

Everything comes with a tradeoff. If you pick the wrong tool, it's a big
headache.

Learn to use all the tools.

------
fastball
Most of the requirements for Google's AMP project help bring down TTI by a
large margin if you follow them as well.

[https://www.ampproject.org/docs/tutorials/create](https://www.ampproject.org/docs/tutorials/create)

------
osrec
I think the article makes some valid points, but it's important to remember
that PWAs are just getting going. The existing SPA frameworks are still a
little crude at the moment, but there is definite progress. For my own app
([https://usebx.com](https://usebx.com)), I eventually ended up writing my own
front end framework, as existing frameworks at the time felt rather bloated.
Now, however, things are starting to look better with the likes of Vue.js etc
coming on the scene. I also feel that PWA development will explode once Apple
ships service workers with Safari, and that will bring along with it even more
motivation to innovate in this space.

~~~
crooked-v
Given how much iOS restricts any kind of background thread and how service
workers require being run independent of a specific page context, I would be
really shocked if iOS literally ever provides support for them.

~~~
rictic
The service worker spec was deliberately designed to give the browser, not the
site, control over resource consumption. The browser is permitted and
encouraged to keep them on a tight leash on behalf of the user's experience.
See e.g.
[https://github.com/w3c/ServiceWorker/blob/master/implementat...](https://github.com/w3c/ServiceWorker/blob/master/implementation_considerations.md#event-
driven-workers)

------
JepZ
Actually, I think it is more important to be aware of the issues and handle
them than to set strict size limits. For example, a few years ago I lead a
redesign project for a mobile web shop and the designer told me he was not
allowed to include icons as our CIO had set the limit of the page size to 100k
(including all images).

By the end of the project the page size was about 200k, but when the sales
were ~20% higher (multi million $ shop) nobody asked about the size limit
anymore.

So yeah, page size/load time is important, but please keep reflecting what you
are doing. The best load times are no good, if (as a result) the UX is poor.

------
deepakkarki
It's also funny how many of my friends use $TrendyJSFramework for a portfolio
site! Personally prefer to have all my content statically served unless I'm
building some sort of an interactive single page application.

I run [https://discoverdev.io](https://discoverdev.io) for which I wrote my
own SSG framework in python+jinja, I spit out html and push it to netlify's
CDN network. It's smooth, I don't have to worry about scaling and it works
like a charm! (I could still do a lot of optimisation wrt image compression
and minification though)

------
emp_
Just pushed live an app today that I had to cave and add babylon-polyfill so
it would work in IE 11 after trying to polyfill a dozen missing es6 runtime
features from various sources.

That made the final JS output 25% larger, a 90kb increase from the polyfill
library alone, so here's a serious optimization waiting to happen (the natural
dying of an older browser).

~~~
TekMol
Couldn't you load babylon only in case the browser lacks the desired features?

------
cvshane
How come no one monitors their speed as much as they should?

SpeedCurve and Calibre are great options listed in that article. Also suggest
MachMetrics [https://www.machmetrics.com/](https://www.machmetrics.com/)

------
swyx
i cut my personal site's TTI by 62% after reading this. I just was lazy about
performance when there were some real easy wins. i do wish for more guidance
on how to do PRPL in React (without necessarily doing full Next.js which is
too opinionated for some of the stuff I want to do)

