Forem: Mikita Himpel

The Truth About Preloading in Modern Web

Mikita Himpel — Sun, 01 Jun 2025 14:56:36 +0000

One of the most common ways to optimize the size of an application's bundle is code splitting. With code splitting, we divide the application into smaller chunks that can be loaded on demand. This allows us to reduce the amount of JavaScript that needs to be downloaded and parsed when the user first opens the app.

A simple and widely used approach to code splitting is splitting by page. The logic is straightforward: when a user opens Page A, there’s no need to load the code for Page B at that moment. This approach provides a significant improvement in initial load time, which is especially important for large applications.

However, like any solution, this method comes with trade-offs. While first-time loading becomes faster, navigating between pages can feel slower. When the user switches to a new page, there may be a noticeable delay between clicking a link or button and actually seeing the new content. This delay can negatively impact user experience, especially if the transition feels unresponsive.

Preloading to Improve Page Transitions

To mitigate this issue, we can introduce preloading strategies. The idea is to load certain chunks of code before the user actually requests them, reducing or even eliminating the perceived delay during navigation.

However, implementing an effective preloading strategy is not trivial. The main challenges are choosing what to preload and when to preload it.

Timing Challenges

One option is to preload chunks after a fixed timeout once the page is idle. But this approach is unreliable, as every user has a different internet connection, device performance, and interaction pattern. In some cases, preloading at the wrong moment can harm user experience — for example, if preloading starts while the user is actively interacting with the page, it may slow down ongoing interactions.

Mouseover and Touchstart Preloading

Some frameworks apply mouseover-based preloading: preloading starts when the user hovers over a link. This approach helps preload content shortly before it's needed and works reasonably well on desktop.

However, it has limitations on mobile devices where no hover event exists. Some libraries therefore listen to touchstart on mobile as a fallback. But even touchstart happens very close to the actual navigation event — often too late to fully hide the loading delay, resulting in suboptimal UX.

Viewport-Based Strategies

Another group of strategies is based on Intersection Observer or simple viewport scanning. The idea is to preload links that are currently visible on screen or that are likely to be seen soon. Alternatively, one might preload all links on the page shortly after the initial load.

While these strategies help prioritize relevant links, they introduce new risks:

If preloading starts too early, it may compete for resources with critical page content and degrade UX.
If delayed too much, the preload may not complete before navigation.
On pages with many links, preloading too aggressively may result in unnecessary bandwidth usage and increased memory consumption.

Finding the right moment to start preloading remains difficult: we want to wait “a little bit” after the page has settled, but defining this "little bit" precisely is complicated.

Browser Limitations

One of the core challenges is that browsers give us very limited APIs to design truly smart preloading. There is no reliable way to query network conditions or system load in advance. APIs like requestIdleCallback help defer work during runtime idleness, but are not designed specifically for preloading, and don’t account for network bandwidth or user interactions.

In practice, most preloading strategies rely on heuristics, which may or may not work well across different user scenarios.

Declarative vs. Imperative Navigation

A key principle for enabling robust preloading is declarative navigation. When navigation is declared via <a href="..."> tags or dedicated Link components, the system has full knowledge of possible navigation targets ahead of time. This allows frameworks to implement automatic preloading strategies behind the scenes.

In contrast, when navigation is implemented imperatively (e.g. via custom JavaScript function calls like navigateTo(url)), it becomes much harder — or even impossible — to build generalized preloading logic without manually instrumenting every possible navigation trigger.

Declarative navigation should always be preferred not only for maintainability, but also because it opens the door for better UX optimizations like preloading.

If your framework supports declarative routing via Link components (or even plain <a>), and you stick to this declarative model, even if the framework doesn’t provide built-in preloading strategies — it's usually possible to implement your own preloading layer with reasonable effort.

Legacy Codebases & Imperative Navigation

However, if you already have a large codebase heavily relying on imperative navigation, adding preloading becomes much harder. In such cases, you typically have to:

Apply heuristics (e.g. manually preload certain key pages after a delay);
Manually instrument navigation calls to inject preloading;
Accept that fully automated preloading may not be feasible without architectural refactoring.

Preloading Support Across Frameworks

Framework	Preloading Triggers	Global Configuration	Notes
SvelteKit	`mouseover`, `touchstart`, `viewport (IntersectionObserver)`	✅ Yes	Multiple built-in strategies; globally configurable.
TanStack Router	`mouseover`, `touchstart`, `viewport (IntersectionObserver)`	✅ Yes	Rich set of built-in strategies; global configuration available.
Angular	After initial load (`PreloadAllModules`)	⚠️ Yes (only global strategy)	Has one built-in strategy that preloads all modules after initial load.
Vue Router	–	❌ No	No built-in preloading; requires custom solutions.
Nuxt.js	`viewport`, `interaction-based (hover, touchstart)`	✅ Yes	Built-in preloading based on links and user interaction; globally configurable.
Next.js	`viewport (prefetch in <Link>)`	⚠ Limited	No way to fully configure strategy globally; per-link `prefetch` attribute controls behavior.
React Router	`viewport`, `interaction-based (hover, touchstart)`	❌ No	Supports preloading per `<Link preload="...">`; no global configuration.

Summary

Code splitting helps optimize bundle size but introduces navigation delays.
Preloading helps hide navigation delays but is tricky to implement well.
Timing and link selection are two biggest challenges in preloading design.
Declarative navigation significantly simplifies adding preloading strategies.
Framework support varies widely — some offer global preloading, some offer none.

Integrating Angular with Storybook: Conquering React Version Complexities

Mikita Himpel — Fri, 19 Jan 2024 18:57:33 +0000

In the dynamic landscape of web development, integrating diverse frameworks and libraries is a common practice, yet it often brings compatibility challenges. This article presents a case study on an integration issue between Angular, Storybook, and React, shedding light on the specific problem arising from React's version flexibility and how it impacts Angular components when themes are switched in Storybook.

Certainly, let's revise the introduction to specifically mention the errors being addressed within the article. Here's how the updated introduction could read:

Introduction

In the multifaceted world of web development, integrating diverse frameworks and libraries is a common endeavor that often introduces compatibility challenges. This article presents a case study on a particularly intricate issue encountered when integrating Angular with Storybook in the context of varying React versions. Specifically, this study sheds light on the resolution of two prevalent errors encountered during theme switching in Storybook:

ERROR Error: NG05104: The selector "SELECTOR_NAME" did not match any elements.
StorybookWrapperComponent.js:1 NG0912: Component ID generation collision detected.

The article delves deep into the challenges posed by the flexibility of React version compatibility in Storybook, its implications for Angular components, and a strategic approach to resolving these specific errors, ensuring smoother integration and a more predictable development environment.

The Challenge: React Version Flexibility and Angular Component Behavior

While Storybook's configuration is designed to accommodate a range of React versions, this flexibility can inadvertently introduce issues:

"peerDependencies": {
  "react": "^16.8.0 || ^17.0.0 || ^18.0.0",
  "react-dom": "^16.8.0 || ^17.0.0 || ^18.0.0"
},

The problem becomes evident when switching themes in Storybook, an action that triggers a re-render of the Angular component's wrapper. React versions 17 and 18 demonstrate divergent behaviors in this context:

React 17: Remounts the wrapper, causing the Angular component to reinitialize and redeclare.
React 18: Does not remount the wrapper, avoiding the issue seen in React 17.

The remounting in React 17 leads to errors, specifically:

ERROR Error: NG05104: The selector "SELECTOR_NAME" did not match any elements.

StorybookWrapperComponent.js:1 NG0912: Component ID generation collision detected.

These errors indicate a selector mismatch and a component ID collision, issues stemming from the remounting and reinitialization process.

The Solution: Precise React Version Specification and Implementation

To address this issue, we implemented a more precise specification of the React version in our package.json. By introducing the following overrides, we ensured the consistent behavior of the components regardless of the broader peerDependencies range:

"overrides": {
  "react": "18.2.0",
  "react-dom": "18.2.0"
},

This strategy effectively aligns the React version used by Storybook with the one that best suits our application's needs, mitigating the re-rendering discrepancies and the ensuing errors.

Conclusion

This case study underscores the nuanced challenges that can emerge when integrating multiple technologies, particularly when version flexibility leads to inconsistent behavior across different environments. By pinpointing the root cause of such issues and enacting targeted solutions, developers can navigate these complexities, ensuring smoother, more predictable interactions between the integrated components. The approach detailed here exemplifies how a nuanced understanding of the technologies involved and a strategic implementation can effectively resolve compatibility challenges, paving the way for more robust and reliable application development.

Sentry Web Vitals: Unpacking and Resolving LCP Metric Detection Challenges

Mikita Himpel — Wed, 04 Oct 2023 14:58:39 +0000

For those unacquainted, Sentry isn't just a tool for error monitoring. It's a robust platform that also allows for the measurement and analysis of web vitals metrics. These metrics provide tangible insights into the performance of web applications from the end-user's perspective. As we move deeper into the digital age, understanding and optimizing for user-centric metrics becomes paramount to delivering a top-notch user experience. However, while these metrics are designed to reflect real-world user interactions, they employ heuristics in their measurements. And inherently, heuristic approaches, though efficient, aren't always flawless. This brings us to the challenges and nuances of the Largest Contentful Paint (LCP) metric detection in Sentry, as we detail below.

The Background:
Recently, we encountered an issue with the LCP metric detection in Sentry. If you're not familiar with the LCP, it's a core web vital metric that represents the point in the page load timeline when the largest content element of a page is likely visible to users. Having this metric is crucial in understanding how well our application is performing from a user's perspective.

The Problem:
The LCP metric in Sentry wasn't behaving as expected. After diving deep into the operational aspects of this metric within Sentry, we identified the root cause. In our application, we remove the loading splash screen only after all resources have loaded and we receive the server response with some data. The Sentry transaction, however, is dispatched after the "load" event on the page, combined with specific Sentry processes and an idleTimeout set to the default 1000ms.

The Solution:
To give the content enough time to render on the page, we opted to adjust the idleTimeout parameter. This modification ensures that the "pageload" transaction in Sentry is dispatched later, allowing the primary content enough time to become visible.

Additionally, through experimentation, we discovered that older versions of Sentry only collect the LCP metric after a user interaction, particularly a click on an interactive element. This means, after our changes, the LCP metric will be captured only if a user interacts with an element within the idleTimeout duration post page load.

What’s Next?:
The good news is that the latest version of Sentry rectifies this limitation. Upon updating Sentry, the LCP metric will be automatically recorded at the end of the “pageload” transaction. Following this, the metric will be noted even if the user hasn't interacted with the page.

In conclusion, while web vitals metrics offer invaluable insights, understanding their nuances and ensuring accurate setups can greatly improve the user experience. If you've been grappling with Sentry's LCP metric, consider revisiting your idleTimeout settings and updating to the latest version.

With the new version of Sentry, the LCP metric is recorded automatically at the end of the "pageload" transaction. However, in our specific scenario, adjusting the idleTimeout remains imperative. Without it, the transaction would conclude prematurely. This is primarily because, in our application design, we remove the loading splash screen only after receiving pertinent data from the backend. This makes the idleTimeout adjustment a necessary step to ensure the LCP metric is captured accurately and reflects the true user experience.

For a deeper dive into the technical specifics of this issue, consult the related Sentry GitHub issue.

Managing @Input Typing in Angular: A Perspective for Newcomers

Mikita Himpel — Mon, 02 Oct 2023 21:19:28 +0000

Hello everyone,

Being relatively new to Angular, I've found myself pondering over how to work with @Input typisation, especially in applications where strict null checks are enabled. Let me present the variants I've observed and then offer an approach I've been considering.

The Variants:

Undefined Type:
```
@Input()
field: Type | undefined;
```
This method does the job, but it also requires incorporating numerous 'if' conditions in the code, compromising its readability.
Asserting Input:
```
@Input()
field!: Type;
```
A decent approach for Angular 15, where the input is mandatory. However, I've heard that Angular 16 won't present the same issues. There's also the risk that someone might initiate the input in the constructor, which might bypass any type or linting checks.
Default Value Initialization:
```
@Input()
fields: Type[] = [];
```
This is feasible but isn't universally applicable.

From the official documentation, I've seen all three methods employed, leaving me sometimes perplexed as to why one was chosen over the others.

My Proposed Approach:

I'm thinking of a structure where:

If the input is mandatory: field!: Type
If it's optional: field?: Type

This method distinctly demarcates mandatory from optional inputs at the type level. Essentially, inputs should carry either a ! or ? sign.

Now, there could be situations where the input is essential, but at the component's initialization phase, the value isn't available. For such scenarios, I suggest: field!: Type | null. Analogously, for optional fields where data isn't ready during the component's initialization phase, we'd use: field?: Type | null.

A Look Back at React:

Having previously coded in React, I didn't encounter such dilemmas in functional components. It was quite puzzling for me not to find a standardized solution for such a ubiquitous problem in Angular. It seems the issue stems from Angular's reliance on classes, which means inputs can't be initialized during the constructor phase. Interestingly, from my understanding, Vue 3 seems to have navigated away from this problem, albeit with a different strategy.

I'd love to get your feedback on this. If you've found alternative solutions or have insights into why one approach might be better than the others, please share. Let's make this journey into Angular smoother for everyone who's new!