How would you approach optimizing a web application for performance, considering factors like page load speed, responsiveness, and overall user experience?

Don't use a frontend framework :)

find the hotspots, trace them to analyse where the performance problems are, fix the problems.

Use more RGB. If it's not optimized yet, you aren't using enough RGB.

First step: think whether you really have a web application. Facebook qualifies, Discord qualifies, Reddit doesn't, and even devRant doesn't.

devRant doesn't use a frontend framework, only jQuery, and that's because devRant is old. Today, you don't even need jQuery anymore because you'd use vanilla JS.

Second step: don't abuse JS to do CSS' or even HTML's job.

Third step: cut out unnecessary cruft such as web fonts.

Fourth step: optimisations such as properly sized images in appropriate image formats. Don't use 2MB 1080p PNGs scaled down to 200px in the browser.

Fifth step: eliminate dependencies in the request chain such as images loaded as CSS backgrounds by using link rel preload.

Fast-Nop (especially the latter half) is mostly accurate.

Personally, ive put in some basic af indicators of likely issues on client side... for example, ping and hop rates, dev specs, etc so it loads in a more tailored way. If someone is 30+ hops away, going through multiple proxies/relays, on a dev with 600x400px screen... you shouldn't be sending them 4k videos even if they say they want it... it's likely impossible for their dev to handle it... certainly impossible to display it. So you send them 300x200px content and when they click the 4k video button, they get 600x400px. Everyone's happy. You can pare down shiny generated graphics and such too.

Biggest overlooked thing imo... the client side "desktop view" switch. Yeah, it can tell your html/css/js that they arent on a mobile device... dont trust it. The vast majority of the time, a 600x400px screen will still read as 600x400px while insisting its a real computer.

You can be really lazy and force portrait or landscape too.

Reduce the number of HTTP requests by combining CSS and JavaScript files. Utilize CSS sprites for small images and icons to minimize the number of image requests.

SALs

@awesomeest Layout switches shouldn't even be in terms of px, that's just broken, it should be in em or rem because that works also if the user hasn't set 16px as minimum font size, but e.g. 28px.

@Fast-Nop i was only using px to reference the end-user-side... i use em/rem and in some cases viewport vh/vw (im fully aware of the pandemic of poor viewport unit usage as a horrid one-size-fits-all approach)

Progressive enhancement, HTML-based, lightweight JavaScript.

@retoor Thank you for making this the top comment.

Don't use JavaScript

@aviophille

Shut up and learn. Valuable advice in this thread which can make you a marginally better dev than your "I can only project my own insecurity" usual self.

@awesomeest

I'm a bit dumbfounded about what you said about hops and such.

As far as I know, all a site can do is measuring bandwidth (easy enough), but hop count?

Sure, could run a tracert for each request but seems a little overkill, especially when nothing guarantees that the route you get *in different connections* from A to B and B to A are the same.

@aviophille

@aviophille It's even immediate inefficiency with the usual FE dev pattern of COOTB (crap out of the box).

Arguably, the only thing FE is efficient at is introducing inefficiency.

@aviophille Sort of, though not every FE is as dumb as you.

@CoreFusionX why would it be for each request? No sessions?

Also, tracert is much more verbose and using more processing power than just counting the ttl/hops and sending 1 packet back.

@awesomeest Because even within the same TCP connection, the individual IP packets don't have to take the same path. Also, do you really evaluate the TTL in web applications?

Not to mention that this would only inform you about the latency, but wether or not to send large amounts of data depends on bandwidth, which is independent of latency.

@Fast-Nop there's a big difference between getting a general gauge of latency with a couple reporting packets vs recording/wasting resources/factoring in every request.

Ofc they take different paths... that said, are you suggesting that there's major discrepancies in hops that cant be simply accounted for??? If so id be very interested in why you are.

Also, bandwidth is ofc a factor, but most people/systems naturally account for that.

@Fast-Nop and yes, i do evaluate these factors unless its reeeeally simple web dev. Honestly, i have some cookie-esq tools and manually written packet systems ive been using/re-tuning for nearly 20yrs. It's always a balancing act between efficiency and need for that efficiency.

That said... im also aware that im a chronic over-engineerer and essentially a dinosaur... but my preferred tools don't have an unnecessary byte (and not being able to say "bit" wiith certainty annoys me)

@awesomeest Each packet is routed independently - whether that does influence latency, will heavily depend on many other factors such as momentary load in relevant network parts.

But even then, about the only useful application for evaluating latency is probably video/audio streaming for finding a useful buffer length.

Because even if you evaluate that, it's hard to see what other actionable conclusion you can draw. I guess that's why people don't do that.

@Fast-Nop the only example i could give to explain how i see it would be essentially invalidating the NDAs that ive been annoyingly using for ~2yrs.

I basically run on algorithms and have insane innate pattern recognition beyond my own conscious comprehension... so i just know how it's panned out over the years... and also get why youre saying/thinking what you are.

@awesomeest

Was gonna answer but @Fast-Nop already did a great job. Kudos.

@aviophille I'm delighted to hear that your ego is so fragile that me taking a harmless jab at you is enough to sour your morning. Keep going, iron fist, crystal jaw.