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
Sylwia you always found some really interesting point like now a custom header, congratulation I never know that is exsist.
I did the file splitting in my - no framework - solution, thanks for the build, tailwind and the minimal rective code size, split a program to independent html pages.
This is actually a beautiful example that you can still achieve a very elegant bundle structure even without a framework 😄 Those sizes look really nice.
And yeah, the preflight/CORS behavior is one of those things that surprisingly many developers never really hear about in detail. I honestly feel like it’s discussed way too rarely, and the comments under this post kind of confirm that 😀
Definitely
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 😅
I think this covers 99% of everything. The problems with deciding whether to split your giant JS bundle go away if you don't use it, because unless you're writing a DAW or an office suite or something, you're almost certainly solving problems that don't exist.
There’s definitely some truth to that 😄 Thankfully, it does feel like the industry is slowly moving back toward minimalism again.
And honestly, loading giant fancy images everywhere is often pretty absurd nowadays 😀 The early-2000s “every website must look like a movie intro” era should probably stay in the past 😅
I only read the first two mistakes mentioned; I know i don't need to read the rest. I've messed up. Custom headers are often used in developer mode to bypass CROSS, but are often forgotten to be properly set up on the move. Once I write a function that calls auth for the whole apps, and when it called it runs the other function in the background with the idea it will be ready anytime i want. But the startup is as slow as a snail.
Exactly 😄 Sometimes it’s just one tiny thing somebody added, forgot about, or “temporarily” hacked together… and suddenly the whole app feels weirdly slow 😀
And then the entire team spends days staring at the network tab wondering what on earth is going on 😅
and right now... vibe coding makes it worse... I mean, i join one volunteer project, many are students, and many just use full AI from drafting to deployment using agent, and when some thing wrong... you know that it is like finding a nail in a haystsack.
Yeah, exactly 😅 And it becomes even worse when people don’t really have the theoretical foundations yet, because then debugging turns into absolute chaos.
If you fully rely on agents from drafting to deployment, but don’t really understand what’s happening underneath, performance issues become a complete nightmare to untangle 😀
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!
"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"! :-)
Hahahaha this just reminded me of a story 😄 A Polish couple I know once wanted to use “I Will Survive” as their first dance song at their wedding xDDDD
When I explained to them that the song is literally about a breakup, they suddenly looked very concerned and decided to search for another one instead 😀
Less is more sometimes. This is a good reminder that performance problems usually don’t start as huge failures, they stack up from tiny choices.
Exactly 😄 One small mistake here, one tiny oversight there… and suddenly the whole application starts feeling sluggish 😀
Welcome back home @sylwia-lask
Hahaha thanks 😄 I missed you guys too 🙂
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 😄
This is a really practical breakdown.
The “death by a thousand cuts” point is exactly how many production problems actually happen. One old custom header, one shared module that quietly pulls half the app, one unnecessary dependency, one huge hero image — none of them looks catastrophic alone, but together they shape the user experience.
I’m seeing a similar pattern while building NEES Core Engine, but on the AI runtime side. Small unmanaged choices around context, memory, tools, fallbacks, and traceability don’t look dangerous individually, but over time they turn into reliability problems in production AI products.
For frontend performance, we use network tabs, bundle analyzers, and real-device testing. For AI products, I think we need the same mindset: runtime visibility, governance, and traceability around what actually happens after deployment.
Great article — very practical and grounded.
Thanks for this comment. Honestly, this is such a great contribution to the discussion!
And I think you’re absolutely right. AI products already have — or soon will have — very similar kinds of problems. Different technology, but the same “death by a thousand cuts” effect caused by lots of tiny unmanaged decisions.
Which is honestly kind of fascinating 😀 We move forward technologically, but a lot of the old engineering knowledge still turns out to be extremely useful in these new environments too 🙂
Thank you — I really liked the way you framed the original post.
That “death by a thousand cuts” pattern is exactly what I think AI products are starting to face too.
In normal apps, tiny unmanaged decisions can slowly damage performance, reliability, and user experience.
In AI products, the same thing can happen through:
Individually, each issue looks minor. But together, they create drift, unpredictability, and trust problems.
That is why I think a lot of old engineering lessons still matter in AI systems. Observability, boundaries, reviewability, and clear contracts are becoming just as important as model quality.
Different technology, same engineering truth: small unmanaged decisions eventually become system-level failures.
The custom headers triggering OPTIONS preflight requests is a detail I had completely overlooked, and it explains a lot about the latency I have been seeing. Your point about lazy loading being defeated by a bloated shared module hit home, since our codebase likely has the exact same trap. I need to stop assuming tree shaking will automatically save us from importing entire libraries. That oversized hero image silently killing LCP is another mistake I am probably guilty of.
Hahaha honestly, I think every developer who actually ships real applications has been guilty of at least one performance disaster 😄 Probably the only people who never make these mistakes are the ones who never build anything 😀
Love this breakdown — it’s the perfect reminder that performance issues are rarely one giant bug, but rather a pile of “tiny cuts” that add up.
The preflight request example especially hits home. I’ve seen teams chasing backend latency for weeks only to discover it was an immortal custom header triggering OPTIONS calls. Same story with code splitting — looks great in theory, but if everything funnels through a bloated shared module, you’re just shipping one giant bundle in disguise.
Your point on dependencies is gold too. I once audited a React app that had three different date libraries plus Lodash imported wholesale. The bundle was basically a museum of developer preferences.
And the background image example is the classic “works fine on my machine” trap. On a fiber connection it’s invisible, but on a cheap Android over 3G it’s the difference between usable and abandoned.
The way you framed it — death by a thousand cuts — is exactly right. Individually harmless, collectively devastating. Thanks for surfacing these; they’re the kind of practical lessons that save real users pain.
Thank you so much for this comment 😄 And honestly, I think it perfectly shows how incredibly common these problems really are.
Almost every larger application seems to accumulate some combination of “immortal” headers, giant shared modules, forgotten dependencies, or oversized assets over time 😀
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 😀
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 🙂
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 ❤️😄
Reading this felt way too relatable 😅
Sometimes in tech and honestly in life too, it’s never one huge mistake, but hundreds of small ignored things that slowly create bigger problems over time.
Really loved how this article turns simple performance lessons into something every developer can connect with personally
Thank you 😄 And honestly, that’s exactly why I wanted to write it this way. Performance problems are often very technical… but the pattern behind them feels surprisingly universal 😀
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!!!
Wow, a blast of knowledge this was for me.
I've always had a strong focus on images, and I've definitely experienced the frustration of images loading slowly on e-commerce and government websites.
In one of my projects (which I've since abandoned 😅), I learned heavily about the importance of effective image loading. Using formats like WebP and AVIF really helps reduce image sizes while ensuring the quality remains intact.
Hahaha, I worked with WordPress sites a long time ago, so I was basically trained in image optimization by force 😄
And yes, WebP and AVIF can make such a huge difference, especially on image-heavy websites 🙂
This is one of those posts that should be bookmarked. The practical examples really help bridge the gap between 'I know the syntax' and 'I can use this in production.'