4 ms·

These clubs remind me of this tweet (as someone that has always been the perf guy wherever I worked): --- Also, hot take: users care way less about performanc

These clubs remind me of this tweet (as someone that has always been the perf guy wherever I worked): --- Also, hot take: users care way less about performance than you think. They want "fast enough", but we're over-indexing on "as fast as possible" instead of caring about other things that matter more to users. Source: https://mobile.twitter.com/DavidKPiano/status/1578740370997153792 https://mobile.twitter.com/DavidKPiano/status/15787403709971...

saagarjha 4y ago
I have seen very little code that is written to be "as fast as possible" and a lot of code that aims to be "fast enough" and fails to meet that bar. Perhaps still worth being mindful about it?
- rozenmd 4y ago
  Depends where you work I guess. There are still folks that deploy their React app in "dev mode" after all.
  - postalrat 4y ago
    Hardly matters when almost every time it's slow server performance.
    - throwup 4y ago
      Based on this comment I'm almost certain you have faster hardware than most of your users.
      - postalrat 4y ago
        I do and am aware of it. But most of the time it's still server performance. Show me a slow site and most of the time it's still the server holding it back on old hardware.
        tasuki 4y ago
        > Show me a slow site and most of the time it's still the server holding it back on old hardware. I was with you but mostly it really isn't hardware. Mostly it's missing database indexes, n queries instead of a join, and sometimes just one small piece of code that's doing something very inefficiently on every request.
    - NavinF 4y ago
      It's not just that. I'm 10ms from most CDNs on a 1.2gbps connection and half the sites I use load instantly (within a couple of refresh cycles on a 120Hz monitor) while the other half take several seconds. The number of round trips the latter sites need just to load some text is insane. Same goes for the 95%ile latency of their servers. You really need to fuck up both parts to achieve such high average latency.
    - saagarjha 4y ago
      I worked as a client performance engineer in a former life. It is not slow server performance “almost every time”.
luckylion 4y ago
I agree completely regarding "users want fast enough". Also: for regular sites, html/css/js optimization is less important than server location. If your server is in Europe and your user is in the US, that's the big one, not your HTML, CSS or JS. And if you're fetishizing over Lighthouse scores, stop. It's only a very rough measure and shouldn't be treated as a goal itself.
- pastage 4y ago
  I agree if the website does lots of new connections with no cache, the users have a slow last mile internet, and we are talking about LA to Moscow. Otherwise trans Atlantic is fine, 80-150ms max ping is not that bad. EDIT max ping of each of our recurring American users on websockets, about a thousand of them. No difference in usage pattern there between Europe and US, but sure we do not have many that have worse ping.
  - luckylion 4y ago
    For us, effective page load time increases annoyingly when you're more than 1500km from the server. Fortunately most of our traffic can easily be cached, so having a caching server on US East and US West works fine.
- lelandfe 4y ago
  > It's only a very rough measure and shouldn't be treated as a goal itself Lighthouse is a synthetic testing tool. It can be incredibly useful when you connect it to your CI build process and track scores over time – revealing how code changes affect (some) front-end performance metrics.[0] Of course, some scores are non-deterministic so you'll need to run it multiple times.[1] And you should be tracking real user data as well to validate it. Using PageSpeed Insights to benchmark a site is akin to loading your website a single time on a single device and saying "wow, my site is slow" Using Lighthouse in your browser to benchmark a site is akin to wasting your time. [0] https://github.com/GoogleChrome/lighthouse-ci https://github.com/GoogleChrome/lighthouse-ci [1] https://developers.google.com/web/tools/lighthouse/variability https://developers.google.com/web/tools/lighthouse/variabili...
- 4y ago
2pEXgD0fZ5cF 4y ago
> we're over-indexing on "as fast as possible" Solid research on this exists, so there is not much to deny, at least when your goal is selling to the average user. But: where is this magical place where people put heavy emphasis on performance? It certainly isn't here, and I would like to visit it for once. Companies caring, or giving their programmer the time to care, about performance are absolutely a rare sight. Unless they work in areas in which they are forced to care about it, and even then many stick to the minimum. Snappy, low latency software is such a delight to encounter because it is just so damn rare. Especially on the web, I constantly feel like I'm wading through molasses, and the only reason I am able to endure this constant, agonizing pain is that I've gotten so used to it...
- vbezhenar 4y ago
  Web is inherently slow. You need to try hard to build a slow desktop app (using native libraries). There're some simple rules to follow if you want a snappy desktop app (like running heavy or I/O tasks in a separate thread). If your app is huge (like MS word), it might be slow, but that's another level of the problem. There're no simple rules if you want to build a snappy web app. You need to think about performance on all levels. You need to think about TLS handshake. Does your certificate fits into first TCP packet? Does your entire conversation fits into first ten TCP packets? That's hard stuff. Is your CSS layout fast enough? Did you think about every resource your website uses? That's just an observation. I don't know what to do. I don't even know how would I make it better. Web stack is mostly reasonable. Sometimes web stack goes to great lengths in pursue of performance, like replacing TCP with QUIC. That's huge technical accomplishment. WebAssembly is pretty fast for a sandboxed VM. JS is crazy fast for a dynamic language. Yet some startup webapp will make 60 HTTP queries on its first page and that's considered a norm.
  - 2pEXgD0fZ5cF 4y ago
    > Web is inherently slow. Absolutely, still there is "normal web latency" slow, "regular website" slow and then there is "reddit redesign" (and other popular sites) slow. Taking the latter as an example, it is easy to check how much faster it could be by using old.reddit.com instead. For that type of slowness I have very little understanding, it's just a regression.
tjoff 4y ago
That fast enough is good enough shouldn't be a hot take? But if you are implying that the web today is fast enough that for sure is a hot take. Our industry most certainly don't care the slightest about performance nor user experience. Popups alone are proof of that.
anderspitman 4y ago
https://64.ms/ https://64.ms/
dspillett 4y ago
A lot of people worry about super-scale prematurely, thinking that "fast enough" for each individual user means needing to be as far as possible because your have a great many users making concurrent requests. Somewhat counter-intuitively to some: this way if thinking can actually make things needlessly less responsive for the individual users because of the "over-architecting" it can cause.

saagarjha 4y ago

I have seen very little code that is written to be "as fast as possible" and a lot of code that aims to be "fast enough" and fails to meet that bar. Perhaps still worth being mindful about it?

rozenmd 4y ago
Depends where you work I guess. There are still folks that deploy their React app in "dev mode" after all.
- postalrat 4y ago
  Hardly matters when almost every time it's slow server performance.
  - throwup 4y ago
    Based on this comment I'm almost certain you have faster hardware than most of your users.
    - postalrat 4y ago
      I do and am aware of it. But most of the time it's still server performance. Show me a slow site and most of the time it's still the server holding it back on old hardware.
      - tasuki 4y ago
        > Show me a slow site and most of the time it's still the server holding it back on old hardware. I was with you but mostly it really isn't hardware. Mostly it's missing database indexes, n queries instead of a join, and sometimes just one small piece of code that's doing something very inefficiently on every request.
  - NavinF 4y ago
    It's not just that. I'm 10ms from most CDNs on a 1.2gbps connection and half the sites I use load instantly (within a couple of refresh cycles on a 120Hz monitor) while the other half take several seconds. The number of round trips the latter sites need just to load some text is insane. Same goes for the 95%ile latency of their servers. You really need to fuck up both parts to achieve such high average latency.
  - saagarjha 4y ago
    I worked as a client performance engineer in a former life. It is not slow server performance “almost every time”.

luckylion 4y ago

I agree completely regarding "users want fast enough". Also: for regular sites, html/css/js optimization is less important than server location. If your server is in Europe and your user is in the US, that's the big one, not your HTML, CSS or JS. And if you're fetishizing over Lighthouse scores, stop. It's only a very rough measure and shouldn't be treated as a goal itself.

pastage 4y ago
I agree if the website does lots of new connections with no cache, the users have a slow last mile internet, and we are talking about LA to Moscow. Otherwise trans Atlantic is fine, 80-150ms max ping is not that bad. EDIT max ping of each of our recurring American users on websockets, about a thousand of them. No difference in usage pattern there between Europe and US, but sure we do not have many that have worse ping.
- luckylion 4y ago
  For us, effective page load time increases annoyingly when you're more than 1500km from the server. Fortunately most of our traffic can easily be cached, so having a caching server on US East and US West works fine.
lelandfe 4y ago
> It's only a very rough measure and shouldn't be treated as a goal itself Lighthouse is a synthetic testing tool. It can be incredibly useful when you connect it to your CI build process and track scores over time – revealing how code changes affect (some) front-end performance metrics.[0] Of course, some scores are non-deterministic so you'll need to run it multiple times.[1] And you should be tracking real user data as well to validate it. Using PageSpeed Insights to benchmark a site is akin to loading your website a single time on a single device and saying "wow, my site is slow" Using Lighthouse in your browser to benchmark a site is akin to wasting your time. [0] https://github.com/GoogleChrome/lighthouse-ci https://github.com/GoogleChrome/lighthouse-ci [1] https://developers.google.com/web/tools/lighthouse/variability https://developers.google.com/web/tools/lighthouse/variabili...
4y ago

2pEXgD0fZ5cF 4y ago

> we're over-indexing on "as fast as possible" Solid research on this exists, so there is not much to deny, at least when your goal is selling to the average user. But: where is this magical place where people put heavy emphasis on performance? It certainly isn't here, and I would like to visit it for once. Companies caring, or giving their programmer the time to care, about performance are absolutely a rare sight. Unless they work in areas in which they are forced to care about it, and even then many stick to the minimum. Snappy, low latency software is such a delight to encounter because it is just so damn rare. Especially on the web, I constantly feel like I'm wading through molasses, and the only reason I am able to endure this constant, agonizing pain is that I've gotten so used to it...

vbezhenar 4y ago
Web is inherently slow. You need to try hard to build a slow desktop app (using native libraries). There're some simple rules to follow if you want a snappy desktop app (like running heavy or I/O tasks in a separate thread). If your app is huge (like MS word), it might be slow, but that's another level of the problem. There're no simple rules if you want to build a snappy web app. You need to think about performance on all levels. You need to think about TLS handshake. Does your certificate fits into first TCP packet? Does your entire conversation fits into first ten TCP packets? That's hard stuff. Is your CSS layout fast enough? Did you think about every resource your website uses? That's just an observation. I don't know what to do. I don't even know how would I make it better. Web stack is mostly reasonable. Sometimes web stack goes to great lengths in pursue of performance, like replacing TCP with QUIC. That's huge technical accomplishment. WebAssembly is pretty fast for a sandboxed VM. JS is crazy fast for a dynamic language. Yet some startup webapp will make 60 HTTP queries on its first page and that's considered a norm.
- 2pEXgD0fZ5cF 4y ago
  > Web is inherently slow. Absolutely, still there is "normal web latency" slow, "regular website" slow and then there is "reddit redesign" (and other popular sites) slow. Taking the latter as an example, it is easy to check how much faster it could be by using old.reddit.com instead. For that type of slowness I have very little understanding, it's just a regression.

tjoff 4y ago

That fast enough is good enough shouldn't be a hot take? But if you are implying that the web today is fast enough that for sure is a hot take. Our industry most certainly don't care the slightest about performance nor user experience. Popups alone are proof of that.

anderspitman 4y ago

https://64.ms/ https://64.ms/

dspillett 4y ago

A lot of people worry about super-scale prematurely, thinking that "fast enough" for each individual user means needing to be as far as possible because your have a great many users making concurrent requests. Somewhat counter-intuitively to some: this way if thinking can actually make things needlessly less responsive for the individual users because of the "over-architecting" it can cause.