Ok, I’m back from my short vacation and returning with some useful content 😄 As you know, from time to time I write posts for you in the style of a...
For further actions, you may consider blocking this person and/or reporting abuse
Great advice, as always! And this is something nobody thinks about: performance isn't just about well-structured code and optimized SQL queries, but also about best practices that we all tend to forget. I try to apply the principles you mention, and generally, my sites have Lighthouse scores above 90. And yet, guess what: I still sometimes forget to optimize the size and file size of an image, or to defer the loading of a script or a font…
Thanks, Pascal 😄 Oh yes, images were often one of the last things I optimized too 😀
Although a few years ago I worked on an app that had to function both in Western Europe and somewhere in the middle of Africa, sometimes in libraries with extremely poor internet connections. That project really trained me hard in these kinds of performance issues 😅
Performance must be a top-tier checklist item for any eco-conscious developer. Every kilobyte saved in a bundle and every millisecond saved in execution is energy that isn't being wasted.
"Sometimes the fastest image is simply… no image 😀"
I really love this perspective 🙂 Exactly, performance isn’t only about happier users or better business metrics. It’s also about efficiency and avoiding unnecessary waste. Every oversized bundle, unnecessary request, or giant image means extra energy consumption somewhere in the chain. And when millions of users open an app, those “tiny” decisions suddenly stop being tiny!
These are really nice tips for improving performance quickly and without huge effort 👍
I usually put code quality and readability before raw performance. Highly optimized code is great, but if the team is afraid to touch it because nobody fully understands it, that’s a highway to hell. So the code splitting example sounds way too familiar to me, but shh 😄
Oh, absolutely 😄 Premature optimization can become a complete nightmare for maintainability. And honestly, on the frontend, good practices plus modern ESNext/browser features already solve a huge amount of problems.
Also… the “theoretical code splitting” situation is incredibly common 😄
Welcome back home @sylwia-lask
Hahaha thanks 😄 I missed you guys too 🙂
"OPTIONS requests appearing before almost every API call" - I noticed that in a project of mine, and then we decided (in the end) to simply host the API and the "app" (SPA) on the same subdomain - meaning, no CORS ...
But reading your article makes me think it might actually have been solvable with CORS (so with the two separate subdomains) ...
P.S. if it's because of a "custom header" (but what exactly is that?) then it might have had something to do with the AWS environment we were running in (Cloudfront etc) and maybe there wasn't much we could do ...
Yeah, in your case moving everything under the same origin may honestly have been the safest and simplest solution.
And by “custom header” I mean headers we add ourselves in the frontend, often globally in some interceptor, things like X-Feature-Flag, X-Client-Version, X-Debug, etc. Those can trigger preflight requests even for normal GET calls.
But to be fair, preflights can also happen because of things like Authorization headers, PUT/PATCH/DELETE methods, or even application/json, so depending on your setup there may indeed not have been much you could realistically avoid 🙂
Thanks! That more or less confirms what I thought (well, based on what you explained in the article) - we do indeed have those auth headers, and probably some other ones as well, so there might indeed not be that much we could do ...
Our backend was/is hosted in the US (East coast), and I'm located somewhere half around the globe, and I could REALLY notice an annoying amount of latency in UI responses and API requests - so then I started checking the network tab, and saw those pre-flight requests ...
In the end, apart from getting rid of CORS, we optimized a lot of other things, almost eliminating all of that lag - so that made the difference between an "annoying" UX and a fairly pleasant one ...
Yeah, that’s exactly how it usually goes 😄 At first it’s very easy to blame “the network” or “the backend,” but once you start digging into the details, all kinds of weird little things suddenly appear.
And honestly, I think this is also why AI probably won’t replace us that quickly 😀 Real-world performance issues are often this messy mix of infrastructure, browser behavior, historical decisions, accidental complexity, and random enterprise archaeology 😄
Hopefully we survive until retirement 😂
Yes, we will survive! Isn't that the title of a famous song? No, it's "I will survive"! :-)
This is such a sharp, practical list. It’s easy to focus on the 'big' architectural decisions and completely overlook how quickly these 'tiny' mistakes compound into a sluggish user experience.
Your points on image optimization and excessive re-renders hit home particularly hard. I’m reminded of a conference talk I gave where I accidentally included a few of these mistakes in a single demo. It ran like a dream on my local machine, but the moment I hit the conference Wi-Fi, the app basically turned into a very expensive slideshow.
There’s nothing like 'real-world' latency to turn a developer’s 'minor oversight' into a performance post-mortem! Thanks for the great reminders to keep us honest.
Thanks so much for the great comment 😄 And ohhh yes, conference Wi-Fi is always an adventure 😀
I totally relate to that fear. Before my last conference talk, I literally added service workers to everything the day before and ended up running the demo remotely/offline-ready just to save myself from disaster 😅 It absolutely saved my ass in the end 😀
Your posts always amaze me ♥️
AWWW thank you so much ❤️😄
Great breakdown .!
The death by a thousand cutsanalogy is spot on - individually, these seem harmless, but together they can make an app feel terrible on real-world devices.Exactly 😄 There’s rarely a single silver bullet in performance work, you usually have to dig into lots of tiny details.
And honestly, this isn’t only about user satisfaction anymore. Performance is also a form of accessibility. Not everybody has a powerful laptop, fast internet, or a modern phone 🙂
Performance bugs are basically archaeological artifacts. You remove one random
X-Legacy-Feature-Flagheader and suddenly Lighthouse goes from ‘needs improvement’ to ‘who touched production?’ 😄Hahahaha exactly 😄 It’s the same with code splitting sometimes. Suddenly the app loads way faster and everybody starts asking: “Wait… are we sure something isn’t missing?” 😀
That’s the universal performance optimization panic 😄
“App is 40% faster now.”
“Great.”
“…but what did we accidentally break?” 😂
Hahaha 100% 😄 And the worst part is when something suddenly starts working “by itself” after the optimization 😀
I've definitely been guilty of at least one of these 😅
The one that hit closest was #2 I spent an embarrassing amount of time debugging a slow list component last month Turned out I was missing a proper key Two hours Because of one line
That's the thing about tiny mistakes They're tiny to write They're not tiny to debug.
Thanks for the checklist bookmarking this for the next time I wonder why is this slow?🙌
Hahahaha exactly 😄 Honestly, two hours is still pretty good 😀 Sometimes people spend weeks trying to figure out why something feels slow.
And that’s what makes performance issues so tricky. The actual mistake is often tiny, but the debugging journey absolutely isn’t 😅 Thanks for the great comment!!!