I agree with this, but if I were going to debate anything it might be that conflating performance and usability with "doesn't work without Javascript". This is a possible consequence for some apps, but on the web, as it has evolved, delivering a fully-functional JS-free web experience seems like a reach.
For many sites, sure, it is silly to glob on all this JS. Probably most even, but many applications are built in a way to use the web as a JavaScript platform. So I think you have to distinguish between these use cases.
The conflation was accidental on my part. The main point I was trying to drive was the over-emphasis on time to first byte can end up with teams ignoring other factors (like number of resources to fetch) and also the proposed solutions to improve time to first byte can also hurt the other performance metrics I mentioned.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I agree with this, but if I were going to debate anything it might be that conflating performance and usability with "doesn't work without Javascript". This is a possible consequence for some apps, but on the web, as it has evolved, delivering a fully-functional JS-free web experience seems like a reach.
For many sites, sure, it is silly to glob on all this JS. Probably most even, but many applications are built in a way to use the web as a JavaScript platform. So I think you have to distinguish between these use cases.
The conflation was accidental on my part. The main point I was trying to drive was the over-emphasis on time to first byte can end up with teams ignoring other factors (like number of resources to fetch) and also the proposed solutions to improve time to first byte can also hurt the other performance metrics I mentioned.