I love writing philosophical essays — thoughts about code, work, all that stuff. I also love deep technical dives. But I know you love my lists of ...
For further actions, you may consider blocking this person and/or reporting abuse
Casually mentioning that you almost won a national sci-fi competition right before diving into native browser APIs is an incredible flex. I am genuinely impressed by that combination of skills. 🥳
The technical list is spot on. The amount of heavy dependencies I have seen installed just to replicate that exact native dialog behavior is depressing. Also, your offline mode panic alert logic is exactly the kind of architecture the web needs more of.
Good luck with the conference this week. Try not to let the performance issues keep you up writing code all night. We both know exactly where that leads. Get some actual rest before the holidays, and let me know how the presentation goes. 😃
Haha, of course my first reaction was: “well… that’s a failure” because it wasn’t one of the top spots 😄 But after a moment I was like… hmm, maybe that’s actually not bad at all 😄
And thank you! The conference is exactly a week from now, so it’s the final stretch now!
Only a developer could beat out over a hundred and sixty other writers on their very first attempt and instinctively classify it as a failure. That exact brand of relentless perfectionism is probably why your technical work is so solid, but you have to admit it is a completely ridiculous standard to hold yourself to. You should absolutely just own that success. 😄
Good luck with the final stretch of preparations this week. Just try to resist the urge to rewrite your entire presentation the night before. By the way, is the conference going to be streamed anywhere? Let me know if there is a link. I would really like to tune in and watch you present.😊
Haha, you’re probably right about that 😄
As for the conference, it most likely won’t be streamed live, but it should be uploaded to YouTube afterward, so I’ll definitely share the link once it’s out! 😊
Wow the times os going ower my head, I don't know about voice input is aviable in browser.
( my Mac is know that by douple press fn by default)
Haha yeah, it’s one of those features that feels a bit like sci-fi creeping into everyday life 😄
You’re right though, the support is still a bit limited and not something you’d rely on everywhere in production yet. But things like what you mentioned on macOS show exactly where this is heading.
Feels like we’re slowly moving toward voice being just another normal input method in apps 👀
again awesome article, Sylwia. thanks
How was your conference, i hope all was as you expected.
Thanks a lot! 😊 The conference is actually this Thursday, so it’s still ahead of me — a mix of excitement and mild terror at this point 😄
I am sure it will be fine, I would like to read your observations and experience afterwards, if you like.
Good luck and have fun.
The
<dialog>one hits hard. I recently audited a site where the modal library alone added 14KB gzipped to the bundle — for something the browser does natively with better accessibility out of the box.The
loading="lazy"point is especially relevant for anyone running image-heavy pages at scale. I manage a site with thousands of pages across 12 languages and switching from a JS lazy-loading library to nativeloading="lazy"shaved ~200ms off LCP on mobile. That's the kind of win that directly impacts Core Web Vitals scores.Would love to see a follow-up on native CSS features that replace JS too —
scroll-snap,container queries, and@layerhave quietly eliminated a lot of JS-heavy patterns.Thanks a lot! 🙌 And that CSS-focused follow-up is a great idea, there’s definitely a lot to explore there 😄
Right? The CSS side is where most of the hidden bloat lives. I've seen projects pulling in entire utility frameworks just for a handful of layout patterns that
gridandhas()handle natively now. Would love to see someone benchmark the real-world performance delta between CSS-native approaches and popular UI kits.Haha true, that would be super interesting to see 😄 I’d love to see real numbers comparing CSS-native approaches vs full UI kits in real-world apps.
Would be a fascinating benchmark! On one of my projects I went Tailwind-only (no component library) for a data-heavy site with 100K+ pages — the CSS output is surprisingly small because utility classes deduplicate naturally at scale. The entire site ships under 30KB of CSS gzipped.
The hidden cost with full UI kits isn't just bundle size though — it's the cascade of JavaScript that comes with interactive components you probably don't need. A datepicker here, a modal there, and suddenly you're shipping 200KB of JS for what's essentially a static content site.
Would love to see someone do a Lighthouse comparison: same layout built with Tailwind vs MUI vs Chakra. My bet is the Tailwind version wins on CLS and LCP by a noticeable margin on mobile.
Cool article, but this is only the tip of the iceberg - the native browser/web APIs have become so extensive, most devs know only a tiny bit of what's available (to a large extent because they use frameworks like React to program the frontend) ...
What do you think of the idea (and feasibility) to not use React or other frameworks to build a frontend, but only "custom elements" (the preferred contemporary name for "web components", I've learned) and native browser APIs - is it a realistic alternative?
That’s a great question!
If I had to answer quickly, I’d say: probably not as a full replacement in most cases. Frameworks solve a lot of problems for us, they come with mature ecosystems, component libraries, state management patterns, routing, etc. So they’re not bad at all. The real issue is more that developers tend to overdo it with additional libraries on top of them.
That said… I’ve actually been thinking about this more recently, and I’m not so sure anymore, especially for simpler apps. With custom elements and modern browser APIs, you can go surprisingly far without a framework. So maybe it’s not about replacing frameworks entirely, but being more intentional about when we actually need them.
Great take, excellent - this:
"Maybe it’s not about replacing frameworks entirely, but being more intentional about when we actually need them"
That's exactly the gist of this article which I just came across:
blog.logrocket.com/anti-frameworki...
So yeah, native web APIs and 'custom elements' are not the holy grail, neither are frameworks - each has its place ...
And this one:
"The real issue is more that developers tend to overdo it with additional libraries on top of them"
Yes, we're way too 'easy'/lazy pulling in tons of dependencies even when we don't really need them, also for trivial things - which has drawbacks, and risks:
a16z.news/p/et-tu-agent-did-you-in...
But, if you rely on AI coding tools/agents - they tend to favor ... React:
dev.to/krunal_groovy/vue-vs-react-...
So you need to make a conscious choice, and maybe you need to put in a little bit more effort ...
Wow, that’s a lot of great content, saved! 🙌
As for preferring React, that doesn’t surprise me at all. It’s simply the most popular, so AI was probably trained on it the most. And of course, it’s often a good choice — I like React too, but not always.
At work, for my large enterprise project, we use Angular — and I really appreciate it. It’s stable, a lot of things work out of the box, and I’ve been blissfully avoiding vulnerability dramas for years 😄
That said, I do worry a bit that with AI we’ll see less actual thinking and more defaulting to whatever is suggested. I’m a bit afraid we’ll end up with very “cemented” tech choices. I’ve actually been meaning to write a post about this for a month now… but haven’t found the time yet 😅
Thanks! Yes that's my fear as well, that everything will a bit more "canned" and run-of-the-mill !
I am seriously of the opinion, among all the AI "hype", that it wouldn't be a bad thing if some development is still done "the old-fashioned way", if only as an antidote, or no, let me make that more specific:
These are really great ideas 🙌 I especially like the angle of keeping the “craft” alive — not everything has to be automated, some things are just genuinely fun to build.
And your last point actually reminded me of something a friend of mine does. She noticed that AI can sometimes go in completely the wrong direction, so now she always asks it to provide not just one solution, but also 2–3 alternatives. It’s surprisingly effective.
I’ve had similar situations myself — the LLM would suggest adding 10 files and building some complex structure, and when I asked “can this be simpler?”, it suddenly turned out that… yes, it can, and it’s just one extra line 😄
The
requestIdleCallbackexample is a good opener — it's one of those APIs that solves a real problem (deferring non-critical work without blocking the main thread) that most developers reach for a setTimeout hack to approximate.A few others worth adding to the "browser already solved it" list: the Intersection Observer API (replaces hand-rolled scroll listeners for lazy loading and animation triggers), the View Transitions API for page transition animations that most people build with JavaScript frameworks, ResizeObserver for element-level resize detection (no more polling or window resize hacks), and
dialogelement withshowModal()for accessible modals without a single line of focus-trap JavaScript.The pattern across all of these is the same: they exist because the browser vendors watched what developers were hacking together repeatedly and standardized the good version. The bottleneck is usually awareness — most developers don't audit their dependencies against the platform periodically. Worth doing annually.
Exactly this 🙌 I’ve actually written about some of these in my previous articles — things like Intersection Observer or ResizeObserver are such good examples of “the browser already solved it.”
I also really like the idea of doing a yearly audit. That’s honestly something more teams should consider. The problem is, we’re often tied to a specific UI library, and then it’s up to them whether they keep up with modern browser capabilities or not.
And I’ve definitely seen some “genius” cases where datepickers still use Moment.js… even though the Moment docs themselves say not to use it anymore 😄
The
requestIdleCallbackpoint really resonated. I run a static site with 100K+ pages built on Astro, and one of the biggest performance wins was deferring analytics and non-critical JS to idle time instead of loading it eagerly. Shaved nearly 200ms off LCP on mobile.The
:focus-withinone is also underrated — I used to write custom JS for that exact pattern on form containers. Replacing it with a single CSS pseudo-class was one of those "why didn't I know this earlier" moments.Curious if you've looked into the
Speculation Rules APIfor prerendering? That's another browser-native feature that replaces a lot of custom prefetching logic and has massive implications for perceived navigation speed.That’s a really nice win — shaving ~200ms off LCP just by deferring non-critical work is exactly the kind of improvement that actually matters in real apps 🙌
And yes, :focus-within is one of those “why did I ever write JS for this” moments 😄 I had the same reaction.
As for the Speculation Rules API — I’ve looked into it a bit, but haven’t used it in a real project yet. It definitely feels like another one of those features that can replace a lot of custom logic once it matures. The whole idea of letting the browser handle prerendering heuristics is super interesting. Have you used it in production already?
Haven't deployed it in production yet either, but it's high on my list. For a static site with predictable navigation patterns (stock page → sector page → related stocks), the prerender hints would map really cleanly to user intent. The part I'm most interested in is replacing the prefetch-on-hover JS I currently use — letting the browser handle that natively with better resource management feels like the right direction. Definitely one to watch as browser support expands.
requestAnimationFrameis great. You probably can skip theDate.now()part. The callback receives a timestamp as the first argument: developer.mozilla.org/en-US/docs/W...Good catch, you’re right! Thanks for the clarification 🙂
I like
requestIdleCallback. I read about a pattern you can implement with it: idle-until-urgent:There are some expensive calculations required for some function the user is likely to invoke. Instead of doing it once it is required, you can do it once you have time for it. Basically pre-caching.
But: when the result is required before the work was done, you cancel the callback and do it just-in-time.
Exactly this! It’s such a beautiful pattern. Idle-until-urgent really changes how you think about work scheduling in the browser. Instead of “do everything immediately”, it becomes “do it when it makes sense… unless the user needs it now”.
Feels like a small thing, but it actually shifts your whole mental model of what the browser can handle for you today.
Honestly, I'm still wrapping my head around the idea of container queries - it sounds like a total game changer for layout management. Saving this!
Exactly! 😄 It really is a game changer. Such a shame I barely write CSS anymore these days 😅
The
crypto.getRandomValuesone really resonates. I've seen so many projects useMath.random()for session tokens or even cart IDs - then wonder why they're getting collisions in production at scale. The browser's crypto API isn't just "better entropy" - it's the difference between "works in testing" and "works with real traffic."Also worth mentioning
crypto.randomUUID()if you just need a standard UUID v4 - one-liner and doesn't need the byte array dance. Been using it for a while now and it's surprisingly well-supported.Curious what made you pick these 9 specifically? Did they all come from real audits or was it more "things that annoyed you enough to write about"? 😄
Thanks a lot for the crypto clarification — great addition! 🙌 And yes, crypto.randomUUID() is such a nice one-liner, definitely worth mentioning too.
As for the 9… probably the second option 😄 I basically started thinking about lesser-known features and just kept listing them. Honestly, I could keep going for quite a while, but figured I can always do a part two 😏
Great article :)
The number of things people reinvent in 202x is too damn high!
Thanks! 😊 And yeah, it’s probably just a habit at this point. Back in the day nothing was built-in, so you had to do everything yourself 😄
Wow learned many nuances here! Also good lesson at the end. Always assume our knowledge is outdated thus always check whether a feature is already supported before installing another library. Great read!
This was a fun read because it hits a problem that quietly infects a lot of frontend work: people love building machinery for things the platform already handles perfectly well.
What I liked most is that this was not just another list of APIs for novelty points. The deeper point is discipline. A lot of overengineering starts with the assumption that custom automatically means better, when half the time it just means more code, more surface area, more bugs, and another dependency nobody needed in the first place.
That is why posts like this matter. They remind people that modern browsers are not some primitive canvas waiting to be rescued by JavaScript. They are already packed with capabilities that a lot of developers either forgot, never learned, or bypassed out of habit.
Also appreciated that this did not turn into anti library absolutism. That part matters. Libraries have their place, but too many teams reach for them before they have even asked the basic question: has the platform already solved this well enough?
Strong piece. The browser has grown up a lot, and a lot of developers are still coding like it has not.
Exactly this. Custom doesn’t automatically mean better — and in many cases the browser has already handled edge cases we might not even think about in our own implementations. That’s often where custom solutions start to fall apart 😄
Exactly. That is usually where the illusion breaks.
A custom solution often looks clean when it is first demoed because it only reflects the cases the developer remembered to design for. The browser implementation has usually already been dragged through the ugly reality of focus behavior, accessibility, input methods, device quirks, resizing, timing, and all the other little failure paths people do not think about until users hit them in production.
That is why platform discipline matters so much. Not because custom work is always wrong, but because a lot of teams are quietly volunteering themselves to re-solve problems the browser has already spent years hardening.
That is also what I liked about your post. It was really a case for restraint. Knowing when not to build is just as important as knowing how to build.
Wow, lots of useful info that I barely knew about. Time to start exploring more browser capabilities. And I am an avid reader of Sci-fi, I would love to read your story if you care to share.
With the project I am working, Dennis the Forge, I am also writing a story parallel to the development, to vent my artistic side (I am both an artist and a programmer). Now I am feeling the itch to go write some code and test all these cool features you mentioned. Great article! Saludos.
Thank you so much! 😊
I actually have a feeling that writing sci-fi and programming aren’t that separate after all,especially for someone with an artistic side. Both are about imagining systems, worlds, and “what if” scenarios, just expressed in different ways.
There’s just one tiny catch though: my story is in Polish 😄 When it comes to blog posts, my English + a bit of GPT polishing works just fine, but unfortunately it doesn’t quite translate the same way for prose 😅
That is unfortunate, even though years ago I had a Polish girlfriend, only a few words still stay in my memory. And I know what you mean with translations: I prefer reading the story in the original language it was written, I really dislike translations.
Exactly! The original is always the best. And when it comes to really good translations, those feel like a work of art on their own, almost as if a co-author was involved, not just a translator. There are books like that, but I feel like they’re becoming rarer.
And I’m not surprised you only picked up a few Polish words 😄 It’s a really difficult language. I honestly don’t know how people from abroad manage to learn it!
Point 8 hit home. I built a voice-powered task manager and went straight for the native SpeechRecognition API instead of pulling in a cloud STT SDK. Works offline, zero latency, no API key needed. The browser (and device) already solved it. I only fall back to a cloud provider for edge cases where native recognition struggles. Saved me from a whole dependency layer I didn't need.
That’s awesome, thanks for sharing! 🙌 Great to hear it’s already working so nicely in production, really good to know 🙂
Guilty as charged on a few of these. 🙈
The native form validation one hit closest to home. I've definitely built custom validation from scratch complete with error states, custom styling, the whole thing only to realize later that the browser already does 80% of it, and more reliably. The time we waste rebuilding what's already there is honestly embarrassing to think about.
The popover API is another one I discovered embarrassingly late. Spent a weekend building a custom tooltip system once. Never again.
I think part of the problem is how we learn most tutorials start with here's how to build it yourself and never mention or you could just use the browser's built-in thing. So we grow up as developers assuming everything needs to be hand-rolled.
That said, there's a fine line. Sometimes custom makes sense for complex edge cases. But the default should always be: does the browser already do this?
Thanks for the reminder bookmarking this as a read before reaching for a new npm package reference. 🙌
There also is the problem with outdated teaching/learning material.
Any material from before 2015 can safely be ignored.
If I see code examples that use the
varkeyword I skip the article. If it's a recent article the author is incompetent. If not, it is just outdated.I bet there are only a few high quality resources, from before 2015 that are worth reading today.
Exactly this. The knowledge gets outdated really fast. And the pace at which browsers evolve right now is honestly a bit insane. Even if someone works as a frontend dev daily, but doesn’t follow things very closely, there are just whole areas they simply don’t know about.
I was at a JS conference this year where a speaker showed the native — and people were literally sitting there with their jaws dropped. And these weren’t beginners. These were people from the industry, engaged enough to attend a conference!
I think that’s also where the popularity of these list-style posts comes from. Some of them go into tens of thousands of views, and it’s not because the ideas are groundbreaking — it’s just that it’s really hard to keep up with everything that the browser can already do now.
brilliant compilation! the popover API one hits hard - i've definitely been that person with the custom tooltip weekend. these browser evolutions happen so fast it's genuinely hard to keep up. daily.dev has saved me here more than once, surfacing these "wait, browsers can do that now?" moments before i dive into building yet another wheel. the Speech API support caveat is spot on though - chromium-only features always feel like they're teasing us with the future.
Haha, on the other hand I used to be the first person to install a library for literally anything… and then came version mismatches and security audits 😅
the agent overengineering problem is worse - it'll implement a custom state machine for something the browser handles natively because it's pattern-matching on "complex problems need complex solutions." knowing what not to build is harder to encode than what to build.
I’ve noticed exactly the same thing. It’s a bit of a trap, if you don’t have enough context or experience, it looks like that’s just how things are supposed to be done. Complex problem → complex solution.
And that’s the tricky part: knowing what not to build is much harder than just building something.
The
<dialog>element is the one that changed my workflow the most. I used to reach for a modal library every single time — managing focus traps, backdrop clicks, escape key handling, scroll locking. Then I discovered<dialog>handles all of that natively withshowModal(). The accessibility wins alone make it worth the switch.navigator.onLineis a great mention too, though worth noting it only tells you if there's a network connection, not if the internet actually works. I've paired it with a lightweight fetch to a known endpoint for more reliable offline detection on sites that serve critical data.Container queries are the sleeper hit on this list. The shift from "how wide is the viewport" to "how wide is my container" fundamentally changes how you think about component design. Once you start using them, media queries for layout feel like a workaround.
Thanks a lot for this comment, and especially for the clarification about navigator.onLine. You’re absolutely right, it can be a bit misleading sometimes!
And yes, is such a game changer. The amount of time we all spent reimplementing modals from scratch… 😅
These are really helpful, thanks for sharing!
This is a great reminder that the best code is often the code we don't have to write. It’s easy to default to npm, but leaning on the platform usually leads to better performance and accessibility by default. Looking forward to the CSS-native follow-up.
Exactly 😄 And pulling things from npm is fun… right up until the first vulnerability report shows up 😅
This. Finally.
A clear, no-BS take on frontend. Straight forward, precise, and refreshingly practical. Too many people overengineer problems the browser already solved years ago. Really enjoyed this one.
Thanks a lot! 😊💖
Maybe use the other Crypto method:
crypto.randomUUID().replaceAll("-","")Good point, that’s a nice alternative too!
This is a great reminder how often we reach for libraries out of habit
I’ve caught myself doing this with things that the browser already handles perfectly fine
especially stuff like animations or simple UI behavior
feels like a lot of overengineering just comes from not revisiting what the platform can do now
Exactly 😄 And sometimes I just cry a little when the UI library I have to use decides to reinvent the wheel anyway 😂
Browsers quietly shipping solutions while we’re busy adding dependencies for the same thing 😄 good reminder to check native first.
Exactly, that’s exactly how it works!
Interesting point, I agree that we overengineer things, but sometimes browser support or edge cases push us toward custom solutions. Still, starting simple and using native features first makes a lot of sense.
Exactly, there’s nothing wrong with custom solutions, as long as we’re not building them for no reason 😄 Thanks for the comment!
This list is a great reminder of how often we build "scaffolding" for things that have already been integrated into the foundation. It’s almost like we have a collective architectural muscle memory where we reach for a library because, for the last five years, that was the only way to survive.
The "Native vs. Polyfill" Gravity
Seeing requestIdleCallback and :focus-within here highlights a beautiful trend: the browser is slowly absorbing the "UI logic" we used to have to micromanage in JavaScript.
When we use :focus-within, we aren't just saving 40 lines of code; we're removing the event-listener tax from the main thread.
It’s a shift from Imperative Management (manually watching for changes) to Declarative Intent (telling the browser what state we care about and letting its optimized C++ internals handle the "how").
The Security of Entropy
I’m really glad you called out crypto.getRandomValues. In a "Binary DNA" sense, Math.random() is essentially a predictable stream—it’s pseudo-randomness that can be reverse-engineered if you have enough samples. Moving to the Web Crypto API isn't just about avoiding collisions; it’s about using true system-level entropy. It’s the difference between a toy and a tool when you’re generating identifiers that actually matter.
The Dialogue Paradox
The element is such a fascinating case of "overengineering vs. accessibility." For years, we built modals that were visually perfect but semantically "deaf." Now that the browser provides the container, we get the focus-trapping and screen-reader support for free. It’s a reminder that "Standardization" is the ultimate performance optimization—it reduces the amount of data we have to ship to the client to achieve a baseline of human usability.
A Reflective Thought
I wonder if we’re entering an era of "Library Pruning." Maybe the most valuable thing a senior dev can do right now isn't adding new features, but looking at a 200MB node_modules folder and asking, "Which of these 12 logic-chains are now just native CSS or browser APIs?"
Congrats on the sci-fi story, too! Making it into the top 15 out of nearly 200 is a serious "signal-to-noise" win. It’s funny how building systems and writing stories both require that same ability to visualize how different components (or characters) will interact when the "code" finally runs.
Love this comment — especially the “library pruning” idea, that really resonates 🙌
I think you’re absolutely right, we’re slowly moving from manually managing everything in JS to just declaring intent and letting the browser handle it. And honestly, that shift feels… healthier 😄
Also great point about entropy — a lot of people treat Math.random() as “good enough”, without realizing what’s actually behind it.
And yes, is such a perfect example of how standardization quietly solves problems we’ve been struggling with for years.
Really appreciate this perspective — and thanks for the kind words about the story as well 😊
This hits a pattern a lot of teams don’t want to admit. Overengineering usually isn’t about lack of skill, it’s habit. We’re trained to build things ourselves, so we default to that even when the platform already solved it better and more reliably.
The real shift is learning to pause and ask whether we’re solving a real problem or just recreating something out of instinct. Most of the time, the browser has already handled the messy parts we haven’t even thought about yet.
Exactly. Back in the day we had to build everything ourselves, so a lot of people still operate with that mindset, even though the platform has moved on 😄
Nice list. Crazy how much we overengineer without even realizing the browser will handle it for us. Makes me think twice before adding yet another tiny library.
Exactly 😄 I actually make my team double-check with me before adding any new dependency — just to be sure the browser (or something we already have) doesn’t handle it for free.
My bundle size just dropped 20kb just reading this. Cheers!
Hahahaha I love this comment!!! 😅🥰
This was genuinely great stuff, and I'm saying this as someone who is Backend-heavy.
Awww thanks a lot! 😍
Thanks for the morning chuckle, as well as being really useful!
💖💖 (BTW here in Poland it's already afternoon 😅)
Hey, nice article again.
Could you please add links to the according MDN pages? This makes it easier if you want to learn more.
Great idea, thanks for suggesting it! 😊 It would definitely make it easier to dig deeper into each feature. I’ll add MDN links, just probably not this week 😄
Lowkey great reminder that we keep reinventing stuff the browser already does — half of frontend feels like fighting problems we created ourselves
Exactly 😄 And at the same time, things are evolving so fast that it’s honestly hard to keep up with what the browser can already do now.
great article
Thanks, Ben 🥰
🌊 thanks
😊💖
Good
Thanks :)
OH man, I actauly didn't know this was possible. Now I am going to dive deeper into browser APIs. Much appreciated!
Haha thanks, that was exactly the plan 😄
This is a great reminder that a lot of “frontend complexity” is actually self-inflicted abstraction.
We’ve spent years building layers on top of the browser, and sometimes forget the browser itself is already a pretty sophisticated runtime.
The interesting shift now is:
are we still solving real problems — or just compensating for outdated mental models?
Clean, sharp, and actually useful — love it. The
crypto.getRandomValuesbit especially… too many people still faking randomness 😄Also, 13th on your first sci-fi attempt? That’s seriously solid. Keep going.
The native
<dialog>element is the one that changed the most for me. I used to reach for a modal library on every project without thinking. Then I tried<dialog>withshowModal()on a static Astro site and realized it handles focus trapping, backdrop, escape-to-close, and screen reader announcements out of the box. All the things I was importing 15KB of JS to do.The Idle Detection API is one I hadn't considered before though. Do you know if there's a reliable way to use it for prefetching content during idle time? I'm working on a site with thousands of pages and pre-rendering even a small subset during idle periods could significantly improve perceived navigation speed.
This was incredibly helpful, thank you @sylwia-lask
no more re-inventing I guess, some of these shocked me hehe