14 ms·

Can You Afford It? Real-World Web Performance Budgets

214 points by josephscott 9y ago

osrec 9y ago
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 9y ago
  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.
  - osrec 9y ago
    It's in development, so we know it's on the cards (https://webkit.org/status/#?search=servi&status=in https://webkit.org/status/#?search=servi&status=in development)
  - rictic 9y ago
    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/implementation_considerations.md#event-driven-workers https://github.com/w3c/ServiceWorker/blob/master/implementat...
justin_d 9y ago
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 9y ago
  Tree shaking should help... eventually.
  - megaman22 9y ago
    Next year, in Jerusalem
    - briantakita 9y ago
      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.
- codingdave 9y ago
  Even for the example of a drawing app, there is no need for huge libraries. The basic code of putting up a canvas and enabling some drawing on it is pretty small. Most of the apps I've seen with lots of Javascript are still doing it for extras in the UI, not the drawing itself. But many developers would rather grab an existing library than think out the simplest, smallest code that does the job.
saas_co_de 9y ago
> 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 9y ago
  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 9y ago
    > 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.
virmundi 9y ago
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?
- scientistem 9y ago
  I think there is (limited) semantic value to single page forms. They also encourage api first design. Is this always worth it? Certainly not. But it does have value.
- cabaalis 9y ago
  I think the problem is in all the data-binding of JSON responses to the front end. I don't care what anyone says, it's slow.
  - andrewstuart2 9y ago
    If you don't care what anyone says, then I guess there's no point in presenting data.
  - osrec 9y ago
    Slow in what sense? I mean, for almost all actual use cases, it seems to be quick enough when done right.
- andrewstuart2 9y ago
  Good single-page app development is just as clean (I've done both), and will be faster over the long term, and scales out better. It keeps all the components cacheable and DRY. The benefits are all about data locality. If your code and data are cached on the client, then the only the minimal subset that has changed needs to be invalidated and updated. If it's only data that has changed, that's all that's retrieved. If it's only code, same goes here. For old-school MVC, if a single character has changed, the whole page is invalidated and must be re-rendered. The tangible benefits when done right (there's lots of crappy code in every language and system) are greatly reduced user-perceived latency (the system reacts immediately, indicating that something is currently being updated, etc).
idlewords 9y ago
It's 2017. It's shameful that our expectations for web speed should be this low.
- ianamartin 9y ago
  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 9y ago
    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 9y ago
      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.
  - 9y ago
JepZ 9y ago
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.
swyx 9y ago
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)
raverbashing 9y ago
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
- jaggederest 9y ago
  And works largely the same without Javascript enabled, last I checked. Edit: Yup, can still view pages, up/down/flag in essentially the same flows.
- sgk284 9y ago
  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
  - azeirah 9y ago
    You can even define glsl shaders in css nowadays :x
  - FajitaNachos 9y ago
    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.
- endless1234 9y ago
  Yeah, if only all web apps could be text only with almost no interactivity, am I right?
emp_ 9y ago
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 9y ago
  Couldn't you load babylon only in case the browser lacks the desired features?
- lastofus 9y ago
  I ran into the exact same issue not too long ago. As an alternative, check out: https://polyfill.io/v2/docs/ https://polyfill.io/v2/docs/
z3t4 9y ago
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.
fastball 9y ago
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
olegkikin 9y ago
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 9y ago
  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 9y ago
    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.
- youngtaff 9y ago
  JS at the end of the body is quite an out of date approach these days the recommendation is to use defer or async attributes. Challenge is will all these approaches is JS will generally still delay Time To Interactive
deepakkarki 9y ago
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)
caseymarquis 9y ago
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.
- deleted 9y ago
  [deleted]
tboyd47 9y ago
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 9y ago
  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 9y ago
    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?
cvshane 9y ago
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/

214 points by josephscott 9y ago

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 9y ago
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.
- osrec 9y ago
  It's in development, so we know it's on the cards (https://webkit.org/status/#?search=servi&status=in https://webkit.org/status/#?search=servi&status=in development)
- rictic 9y ago
  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/implementation_considerations.md#event-driven-workers https://github.com/w3c/ServiceWorker/blob/master/implementat...

justin_d 9y ago

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 9y ago
Tree shaking should help... eventually.
- megaman22 9y ago
  Next year, in Jerusalem
  - briantakita 9y ago
    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.
codingdave 9y ago
Even for the example of a drawing app, there is no need for huge libraries. The basic code of putting up a canvas and enabling some drawing on it is pretty small. Most of the apps I've seen with lots of Javascript are still doing it for extras in the UI, not the drawing itself. But many developers would rather grab an existing library than think out the simplest, smallest code that does the job.

saas_co_de 9y ago

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

virmundi 9y ago

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?

scientistem 9y ago
I think there is (limited) semantic value to single page forms. They also encourage api first design. Is this always worth it? Certainly not. But it does have value.
cabaalis 9y ago
I think the problem is in all the data-binding of JSON responses to the front end. I don't care what anyone says, it's slow.
- andrewstuart2 9y ago
  If you don't care what anyone says, then I guess there's no point in presenting data.
- osrec 9y ago
  Slow in what sense? I mean, for almost all actual use cases, it seems to be quick enough when done right.
andrewstuart2 9y ago
Good single-page app development is just as clean (I've done both), and will be faster over the long term, and scales out better. It keeps all the components cacheable and DRY. The benefits are all about data locality. If your code and data are cached on the client, then the only the minimal subset that has changed needs to be invalidated and updated. If it's only data that has changed, that's all that's retrieved. If it's only code, same goes here. For old-school MVC, if a single character has changed, the whole page is invalidated and must be re-rendered. The tangible benefits when done right (there's lots of crappy code in every language and system) are greatly reduced user-perceived latency (the system reacts immediately, indicating that something is currently being updated, etc).

idlewords 9y ago

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

ianamartin 9y ago
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 9y ago
  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 9y ago
    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.
- 9y ago

JepZ 9y ago

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.

swyx 9y ago

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)

raverbashing 9y ago

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

jaggederest 9y ago
And works largely the same without Javascript enabled, last I checked. Edit: Yup, can still view pages, up/down/flag in essentially the same flows.
sgk284 9y ago
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
- azeirah 9y ago
  You can even define glsl shaders in css nowadays :x
- FajitaNachos 9y ago
  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.
endless1234 9y ago
Yeah, if only all web apps could be text only with almost no interactivity, am I right?

emp_ 9y ago

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 9y ago
Couldn't you load babylon only in case the browser lacks the desired features?
lastofus 9y ago
I ran into the exact same issue not too long ago. As an alternative, check out: https://polyfill.io/v2/docs/ https://polyfill.io/v2/docs/

z3t4 9y ago

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.

fastball 9y ago

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

olegkikin 9y ago

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 9y ago
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 9y ago
  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.
youngtaff 9y ago
JS at the end of the body is quite an out of date approach these days the recommendation is to use defer or async attributes. Challenge is will all these approaches is JS will generally still delay Time To Interactive

deepakkarki 9y ago

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)

caseymarquis 9y ago

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.

deleted 9y ago
[deleted]

tboyd47 9y ago

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 9y ago
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 9y ago
  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?

cvshane 9y ago

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/