DEV Community: Jakub Andrzejewski

Preserve Component State in Vue with KeepAlive

Jakub Andrzejewski — Mon, 10 Aug 2026 08:15:21 +0000

When building Vue applications, we often switch between different components like tabs, multi-step forms, dynamic components, or event different views inside the same page.

By default, when Vue removes a component from the DOM, its component instance is also unmounted. When you render it again, Vue creates a completely new instance.

This means that things like local state, form input, or component state can be lost.

This is where <KeepAlive> becomes incredibly useful. Vue's KeepAlive component allows you to cache inactive component instances instead of destroying them.

In this article, we'll explore:

What KeepAlive is
What problem it solves
How to use it with dynamic components
How to control which components are cached
How onActivated and onDeactivated work
Common mistakes and best practices

Let's dive in.

🤔 What Is Vue KeepAlive?

<KeepAlive> is a built-in Vue component that allows you to cache component instances when they are switched out.

Consider a simple dynamic component:

<script setup lang="ts">
import { ref } from 'vue'

import Profile from './Profile.vue'
import Settings from './Settings.vue'

const currentComponent = ref(Profile)
</script>

<template>
  <button @click="currentComponent = Profile">
    Profile
  </button>

  <button @click="currentComponent = Settings">
    Settings
  </button>

  <component :is="currentComponent" />
</template>

When you switch from Profile to Settings, the Profile component is unmounted.

When you switch back, Vue creates a new Profile instance.

Now let's add KeepAlive:

<KeepAlive>
  <component :is="currentComponent" />
</KeepAlive>

Now Vue keeps the inactive component instance alive.

Instead of:

Profile
  ↓
Unmount
  ↓
Destroy state

you get:

Profile
  ↓
Deactivated
  ↓
Cached
  ↓
Activated again

The component state is preserved.

🟢 What Problem Does KeepAlive Solve?

Imagine you have a tabbed interface.

Profile | Settings | Billing

Inside the Profile tab, the user fills out a form:

Name: John
Email: john@example.com

Then they switch to Settings.

Without KeepAlive, the Profile component can be unmounted.

When they return:

Name:
Email:

The form has been reset.

That's a terrible user experience.

With KeepAlive:

Profile
  ↓
User enters data
  ↓
Switch to Settings
  ↓
Profile is cached
  ↓
Return to Profile
  ↓
Form state is preserved

This is one of the most common use cases for KeepAlive.

🟢 Using KeepAlive with Dynamic Components

The most common pattern is wrapping a dynamic component.

<KeepAlive>
  <component :is="currentComponent" />
</KeepAlive>

For example:

<script setup lang="ts">
import { ref } from 'vue'

import Dashboard from './Dashboard.vue'
import Analytics from './Analytics.vue'

const currentComponent = ref(Dashboard)
</script>

<template>
  <nav>
    <button @click="currentComponent = Dashboard">
      Dashboard
    </button>

    <button @click="currentComponent = Analytics">
      Analytics
    </button>
  </nav>

  <KeepAlive>
    <component :is="currentComponent" />
  </KeepAlive>
</template>

Now both components can preserve their internal state when switching between them.

This works especially well for:

tabs
dashboards
editors
multi-step forms
complex filters

🟢 KeepAlive and Lifecycle Hooks

When using KeepAlive, the normal lifecycle changes slightly.

A cached component is not unmounted when it becomes inactive.

Instead, Vue provides two special lifecycle hooks:

onActivated()

and:

onDeactivated()

For example:

<script setup lang="ts">
import {
  onActivated,
  onDeactivated
} from 'vue'

onActivated(() => {
  console.log('Component is active')
})

onDeactivated(() => {
  console.log('Component is inactive')
})
</script>

This can be useful when you need to perform actions whenever the component becomes visible or hidden.

For example:

refresh data
restart an animation
pause a timer
reconnect to a resource
update UI state

🟢 KeepAlive vs `onMounted`

One important thing to understand is that onMounted() doesn't run every time a cached component becomes visible.

Consider:

onMounted(() => {
  console.log('mounted')
})

onActivated(() => {
  console.log('activated')
})

The lifecycle looks roughly like this:

First visit
↓
onMounted()
↓
onActivated()

Switch away
↓
onDeactivated()

Return
↓
onActivated()

The component remains mounted while it is cached.

This distinction is important when working with data fetching or subscriptions.

🟢 Controlling Which Components Are Cached

You don't always want to cache everything.

Vue allows you to control the cache using include and exclude.

For example:

<KeepAlive include="Profile,Settings">
  <component :is="currentComponent" />
</KeepAlive>

Only components matching those names will be cached.

You can also exclude components:

<KeepAlive exclude="HeavyChart">
  <component :is="currentComponent" />
</KeepAlive>

This is useful when some components are expensive to keep in memory.

🟢 Limiting the Cache with `max`

KeepAlive also supports a max prop.

<KeepAlive :max="5">
  <component :is="currentComponent" />
</KeepAlive>

This limits the number of component instances kept in the cache.

When the limit is reached, Vue removes the least recently used cached component.

This is particularly useful for applications where users can navigate through many dynamic views.

🟢 KeepAlive Isn't Always the Right Choice

Caching components sounds great, but it comes with a cost.

A cached component still exists in memory.

If you cache many complex components, you can increase memory usage.

For example:

100 cached dashboards
+
large charts
+
large reactive state
=
potentially expensive memory usage

That's why KeepAlive should be used intentionally.

Ask yourself:

👉 "Does preserving this component's state provide enough value to justify keeping it in memory?"

If the answer is no, regular mounting and unmounting may be better.

🧪 Best Practices

Use KeepAlive when preserving component state improves UX
Prefer it for tabs, editors, forms, and complex dynamic views
Use include and exclude when only some components should be cached
Use max when users can create many cached component instances
Use onActivated for logic that should run whenever a cached component becomes active
Use onDeactivated to pause timers, subscriptions, or other ongoing work
Be careful when caching memory-heavy components
Don't use KeepAlive everywhere just because it is available

📖 Learn more

If you would like to learn more about Vue, Nuxt, JavaScript or other useful technologies, checkout VueSchool by clicking this link or by clicking the image below:

It covers most important concepts while building modern Vue or Nuxt applications that can help you in your daily work or side projects 😉

🧪 Advance skills

A certification boosts your skills, builds credibility, and opens doors to new opportunities. Whether you're advancing your career or switching paths, it's a smart step toward success.

Check out Certificates.dev by clicking this link or by clicking the image below:

Invest in yourself—get certified in Vue.js, JavaScript, Nuxt, Angular, React, and more!

✅ Summary

Vue's KeepAlive is a powerful built-in component for preserving state between dynamic component switches.

In this article, you learned:

What KeepAlive is
How it preserves component instances
How to use it with dynamic components
How onActivated and onDeactivated work
How to control caching with include, exclude, and max
When caching components can become a performance concern

KeepAlive is especially useful when users expect their state to remain intact while navigating between views.

Use it intentionally, cache the components that benefit from it, and avoid keeping large numbers of memory-heavy components alive unnecessarily.

Take care!
And happy coding as always 🖥️

How to set Content Security Policy with a Meta Tag?

Jakub Andrzejewski — Mon, 03 Aug 2026 08:41:49 +0000

When developers start implementing a Content Security Policy (CSP), they usually configure it through HTTP response headers.

But then a common question comes up:

👉 Can I define CSP using a <meta> tag instead?

The answer is:

Yes—but with some important limitations.

While using a meta tag can be convenient during development or on static websites, it doesn't provide the same level of protection as HTTP headers.

In this article, we'll explore:

What a CSP meta tag is
How it works
Its limitations
When you should (and shouldn't) use it
Best practices for securing your application

Let's dive in.

🤔 What Is a CSP Meta Tag?

Instead of sending the Content Security Policy as an HTTP response header, you can define it directly inside your HTML document using a <meta> element.

Example:

<meta
  http-equiv="Content-Security-Policy"
  content="
    default-src 'self';
    script-src 'self';
    style-src 'self';
  "
>

The browser reads this tag while parsing the document and applies the specified policy.

From that point onward, the CSP rules are enforced. Normally, CSP is configured by the server.

Example:

Content-Security-Policy:
default-src 'self';
script-src 'self';

However, sometimes you don't control the server configuration.

For example:

static websites
prototypes
documentation sites
GitHub Pages
simple demos

In these cases, a meta tag allows you to add a basic CSP without modifying server headers.

It's a convenient alternative when HTTP headers aren't available.

🟢 How to Use a CSP Meta Tag

A typical configuration looks like this:

<head>
  <meta
    http-equiv="Content-Security-Policy"
    content="
      default-src 'self';
      img-src 'self' https:;
      script-src 'self';
      style-src 'self';
    "
  />
</head>

The important part is:

👉 The meta tag should appear as early as possible inside the <head>.

Anything loaded before the browser encounters the CSP tag won't be protected by that policy.

🟢 What Are the Limitations?

This is where many developers get caught off guard.

Although the syntax is very similar, meta-based CSP is not equivalent to an HTTP CSP header.

❌ It Doesn't Protect Early Requests

The browser only applies the policy after parsing the meta tag.

That means resources loaded before it may bypass the policy.

This is one of the main reasons HTTP headers are preferred.

❌ Some Directives Are Not Supported

Certain CSP directives only work when delivered as HTTP headers.

For example, directives such as:

report-uri
report-to
frame-ancestors
sandbox

are ignored when specified in a meta tag.

This means you lose features like:

violation reporting
clickjacking protection
advanced security controls

❌ Cannot Replace Server Security

A meta tag is parsed as part of the HTML document.

An HTTP header is processed before the page content.

Because of this, response headers always provide stronger protection.

🟢 When Should You Use a Meta CSP?

Using a meta tag can still be useful in several scenarios.

✅ Static websites

When server configuration isn't available.

✅ Local development

Testing CSP rules before deploying them to production.

✅ Documentation sites

Platforms like GitHub Pages often don't allow custom response headers.

✅ Internal prototypes

For demos and internal tools where basic protection is sufficient.

🟢 Meta Tag vs HTTP Header

Let's compare both approaches.

Meta Tag	HTTP Header
Easy to add	Requires server configuration
Good for static sites	Recommended for production
Applied after HTML parsing	Applied before rendering
Limited directive support	Full CSP support
No reporting directives	Supports reporting and advanced policies

For most production applications, the HTTP header is the clear winner.

🧪 Best Practices

Prefer HTTP response headers for production
Use meta CSP only when server headers aren't available
Place the meta tag at the top of the <head>
Don't rely on meta CSP for advanced security features
Test your policy before deploying
Start with Report-Only mode when using HTTP headers
Keep your CSP as restrictive as your application allows

📖 Learn more

If you would like to learn more about Vue, Nuxt, JavaScript or other useful technologies, checkout VueSchool by clicking this link or by clicking the image below:

It covers most important concepts while building modern Vue or Nuxt applications that can help you in your daily work or side projects 😉

🧪 Advance skills

A certification boosts your skills, builds credibility, and opens doors to new opportunities. Whether you're advancing your career or switching paths, it's a smart step toward success.

Check out Certificates.dev by clicking this link or by clicking the image below:

Invest in yourself—get certified in Vue.js, JavaScript, Nuxt, Angular, React, and more!

✅ Summary

A Content Security Policy can be defined using either an HTTP response header or a <meta> tag—but they are not equivalent.

In this article, you learned:

What a CSP meta tag is
How to configure it
What limitations it has
When it's appropriate to use it
Why HTTP headers remain the recommended approach for production

A meta-based CSP is a useful option for static websites, prototypes, and environments where you can't configure server headers. However, for production applications that require strong security guarantees, always prefer delivering your Content Security Policy through HTTP response headers.

Take care!
And happy coding as always 🖥️

Improve Performance by Loading Videos Only When They're Needed

Jakub Andrzejewski — Mon, 13 Jul 2026 06:37:16 +0000

Videos are one of the heaviest assets you can add to a web page.

Loading videos too early can significantly impact your application's performance. The good news is that modern browsers are starting to support lazy loading for video elements, allowing you to defer loading until users are likely to watch them.

However, there's one important thing to know:

👉 This feature is not yet part of the Baseline web platform, so browser support is still limited.

At the time of writing, lazy loading for <video> elements is supported in Chromium-based browsers such as Google Chrome, Microsoft Edge, and Opera, while browsers like Firefox and Safari do not yet support it natively.

In this article, we'll explore:

What lazy loading videos is
Why it's important for web performance
How to implement it
Browser support considerations
Best practices for optimizing video loading

Let's dive in.

🤔 What Is Lazy Loading for Videos?

Lazy loading means delaying the loading of a resource until it's actually needed.

Instead of downloading every video immediately during page load, the browser waits until the video is close to entering the viewport.

This helps reduce:

initial network requests
bandwidth usage
page load time
memory consumption

Especially on pages with multiple videos, the difference can be significant.

🟢 What Problem Does It Solve?

Imagine an e-commerce page with several product videos.

Without lazy loading:

every video starts downloading immediately
bandwidth is consumed even for videos users never watch
page rendering may become slower

This negatively impacts; Largest Contentful Paint (LCP), Time to Interactive (TTI), and overall user experience.

Most visitors won't watch every video on the page. So why load them all? Lazy loading ensures videos are fetched only when they're actually needed.

🟢 How to Lazy Load a Video

The easiest approach is using the loading="lazy" attribute.

Example:

<video
  controls
  loading="lazy"
  poster="/preview.jpg"
>
  <source
    src="/video.mp4"
    type="video/mp4"
  />
</video>

Now the browser can defer loading the video until it's approaches the viewport.

Combined with a poster image, users still see a nice preview before playback begins.

🟢 Why Use a Poster Image?

A poster acts as a placeholder while the video hasn't loaded yet.

Example:

<video
  controls
  loading="lazy"
  poster="/thumbnail.jpg"
>
  <source
    src="/demo.mp4"
    type="video/mp4"
  />
</video>

Benefits:

faster visual rendering
improved perceived performance
lower initial network usage

Users immediately understand there's a video without downloading the entire file.

🟢 Loading Videos Only After User Interaction

For videos below the fold, you can optimize even further.

Instead of immediately defining the video source:

<video controls poster="/thumbnail.jpg">
</video>

You can dynamically add the <source> element after:

the user clicks Play
the video becomes visible
an Intersection Observer fires

This gives you complete control over when large video files start downloading.

It's a great fallback for browsers that don't yet support native lazy loading.

🟢 Browser Support

Since native video lazy loading isn't yet Baseline, it's important to understand browser compatibility.

Currently, native support is available in:

✅ Google Chrome
✅ Microsoft Edge
✅ Opera
✅ Other Chromium-based browsers

Support is currently unavailable in:

❌ Firefox
❌ Safari

For maximum compatibility, consider progressive enhancement.

Browsers that support the feature benefit automatically, while older browsers still function correctly.

🧪 Best Practices

Lazy load videos whenever they aren't immediately visible
Always provide a lightweight poster image
Compress videos before publishing
Use modern video formats when possible
Consider Intersection Observer for unsupported browsers
Test browser compatibility before relying on native lazy loading
Measure improvements using Lighthouse and Core Web Vitals

📖 Learn more

If you would like to learn more about Vue, Nuxt, JavaScript or other useful technologies, checkout VueSchool by clicking this link or by clicking the image below:

It covers most important concepts while building modern Vue or Nuxt applications that can help you in your daily work or side projects 😉

🧪 Advance skills

A certification boosts your skills, builds credibility, and opens doors to new opportunities. Whether you're advancing your career or switching paths, it's a smart step toward success.

Check out Certificates.dev by clicking this link or by clicking the image below:

Invest in yourself—get certified in Vue.js, JavaScript, Nuxt, Angular, React, and more!

✅ Summary

Lazy loading videos is an effective way to improve performance by reducing unnecessary network requests and delaying large downloads until they're actually needed.

Although native support isn't yet available across all browsers, it's already a valuable progressive enhancement for Chromium-based browsers. Combined with poster images and fallback techniques like Intersection Observer, it can significantly improve the loading experience of media-rich web applications.

Take care!
And happy coding as always 🖥️

Enforce Better Vue Architecture with ESLint

Jakub Andrzejewski — Mon, 06 Jul 2026 08:38:53 +0000

As Vue applications grow, keeping the codebase clean becomes increasingly challenging. At first, everyone follows the same conventions. But over time, you start noticing things like:

inconsistent component structure
multiple ways of solving the same problem
different Composition API patterns
imports scattered everywhere
code that's difficult to review and maintain

This is where ESLint becomes much more than a tool for formatting—it becomes a way to enforce your project's architecture and design patterns.

In this article, we'll explore:

Why ESLint is more than a linter
How it helps maintain a consistent architecture
Useful Vue-specific rules
Examples of enforcing project-wide patterns
Best practices for scaling Vue applications

Let's dive in.

🤔 ESLint Is More Than a Code Formatter

Many developers think ESLint is only used to catch things like; unused variables, missing semicolons, incorrect formatting. While that's true, ESLint can do much more.

With the right configuration, it can enforce:

coding conventions
project architecture
Vue best practices
Composition API patterns
import organization
component structure

Instead of relying on code reviews to catch inconsistencies, ESLint prevents them before the code is even merged.

🟢 What Problem Does It Solve?

Imagine a team of five developers.

One component looks like this:

<script setup>
...
</script>

<template>
...
</template>

<style>
...
</style>

Another one:

<template>
...
</template>

<script setup>
...
</script>

Someone uses:

watch()

Someone else always prefers:

watchEffect()

Some developers use relative imports:

../../../components/Button.vue

Others use aliases:

~/components/Button.vue

None of these are necessarily wrong... but together they create inconsistency across the project. ESLint helps eliminate these differences by enforcing one agreed-upon way of writing code.

🟢 Enforcing Vue Block Order

One of the simplest examples is keeping Vue Single File Components organized. Using the vue/block-order rule, you can define the exact order of blocks.

Example:

<template>
  ...
</template>

<script setup lang="ts">
  ...
</script>

<style scoped>
  ...
</style>

🟢 Enforcing Composition API Patterns

One of the biggest advantages of ESLint is enforcing how developers use Vue APIs.

For example, you might decide that your project should always use:

<script setup>
Composition API
defineProps
defineEmits

And avoid Options API or inconsistent component definitions. This ensures new components follow the same architecture from day one.

🟢 Restricting Specific APIs

Sometimes you want to discourage certain patterns altogether. For example, you may decide:

❌ Avoid watch() unless absolutely necessary.

Prefer:

computed()

watchEffect()

ESLint can restrict the use of specific APIs and encourage better alternatives. This keeps reactive logic predictable and easier to maintain.

🟢 Enforcing Import Conventions

Large Vue projects often suffer from inconsistent imports.

Example:

import Button from '../../../components/Button.vue'

vs.

import Button from '~/components/Button.vue'

ESLint can enforce:

path aliases
import ordering
grouped imports
no duplicate imports

The result is cleaner and more consistent code.

🟢 Preventing Architectural Violations

ESLint can also help enforce architectural boundaries. For example:

Components shouldn't access API clients directly.
Feature modules shouldn't import from other features.
UI components shouldn't depend on business logic.

Using rules such as no-restricted-imports, you can prevent these patterns entirely.

Example:

'no-restricted-imports': [
  'error',
  {
    patterns: [
      '@/api/*'
    ]
  }
]

Now components can't accidentally bypass your intended architecture.

🟢 Creating Custom Rules for Your Team

One of ESLint's greatest strengths is extensibility.

Beyond built-in rules, you can create custom rules—or use plugins—to enforce project-specific conventions.

For example:

composables must start with use
stores must live in a dedicated folder
feature modules cannot import each other
utility functions must remain pure
internal design system components must be used instead of native HTML elements

As your project grows, these automated checks become far more reliable than relying solely on code reviews.

🟢 Why This Matters in Large Vue Applications

Small projects can survive without strict rules. Large projects usually can't. Consistency helps:

onboard new developers faster
simplify code reviews
reduce technical debt
prevent architectural drift
improve long-term maintainability

Instead of debating coding style in every pull request ESLint enforces it automatically.

🧪 Best Practices

Treat ESLint as an architecture tool—not just a linter
Enable Vue-specific rules from eslint-plugin-vue
Agree on project conventions early
Enforce Composition API patterns consistently
Use no-restricted-imports to protect architectural boundaries
Automate linting in CI/CD pipelines
Keep rules practical—avoid overcomplicating your configuration

📖 Learn more

If you would like to learn more about Vue, Nuxt, JavaScript or other useful technologies, checkout VueSchool by clicking this link or by clicking the image below:

It covers most important concepts while building modern Vue or Nuxt applications that can help you in your daily work or side projects 😉

🧪 Advance skills

A certification boosts your skills, builds credibility, and opens doors to new opportunities. Whether you're advancing your career or switching paths, it's a smart step toward success.

Check out Certificates.dev by clicking this link or by clicking the image below:

Invest in yourself—get certified in Vue.js, JavaScript, Nuxt, Angular, React, and more!

✅ Summary

ESLint is much more than a tool for catching syntax errors or enforcing formatting.

As Vue applications grow, consistency becomes just as important as functionality.

By using ESLint to enforce architectural decisions, you ensure that every new piece of code follows the same standards—making your project easier to understand, review, and maintain for years to come.

Take care!
And happy coding as always 🖥️

Fix Web Performance Issues Faster with Modern Web Guidance and Chrome DevTools for AI Agents

Jakub Andrzejewski — Mon, 29 Jun 2026 05:22:27 +0000

Performance optimization has always been one of the hardest parts of web development. You run Lighthouse, record a Performance trace, identify a long task... And then comes the difficult part:

👉 How do you actually fix it?

Traditionally, developers had to spend hours searching documentation, comparing best practices, and figuring out which optimization applied to their situation.

Google is trying to simplify this workflow with two new resources:

Modern Web Guidance
Chrome DevTools for AI Agents

Together, they make it easier for both developers and AI coding assistants to identify and fix common performance issues.

In this article, we'll explore:

What Modern Web Guidance is
What Chrome DevTools for AI Agents does
How they work together
Real-world performance issues they help solve
Best practices for integrating them into your workflow

Let's dive in.

🤔 What Is Modern Web Guidance?

Modern Web Guidance is a collection of best practices published by the Chrome team.

Instead of generic advice like:

"Optimize your JavaScript."

It provides practical guidance for modern web applications covering topics such as:

rendering performance
Core Web Vitals
JavaScript optimization
CSS best practices
loading strategies
images and fonts
networking
accessibility

Think of it as a centralized knowledge base for building fast web applications. Instead of searching through dozens of blog posts, you can rely on guidance maintained by the team behind Chrome.

🟢 What Is Chrome DevTools for AI Agents?

Chrome DevTools for AI Agents exposes browser debugging information in a way that AI coding assistants can understand.

Instead of simply analyzing source code, an AI agent can inspect:

Performance traces
Network requests
Console messages
Rendering behavior
Layout shifts
Core Web Vitals

This allows AI assistants to reason about runtime behavior, not just static code.

🟢 How It Works Together

Imagine your application has poor Interaction to Next Paint (INP).

The workflow becomes:

Performance trace
↓
AI Agent analyzes DevTools data
↓
Identifies bottleneck
↓
Matches issue with Modern Web Guidance
↓
Suggests concrete improvements

🟢 Example: Finding a Long JavaScript Task

Suppose DevTools records a long task blocking the main thread. Instead of only showing:

Main thread blocked for 420ms

An AI agent can help explain why the task is expensive, which code caused it, and which optimization patterns apply.

For example; split large computations, lazy load modules, or reduce synchronous work. This dramatically shortens the debugging process.

🟢 Example: Fixing Layout Shifts

Another common issue is Cumulative Layout Shift (CLS). DevTools can identify layout shifts.

Modern Web Guidance recommends solutions such as:

reserving space for images
using skeleton loaders
avoiding unexpected DOM insertions
defining image dimensions
preventing late-loading UI elements

Instead of guessing, developers receive recommendations aligned with current web performance best practices.

🧪 Best Practices

Always profile before optimizing
Use Chrome DevTools to collect real performance data
Follow Modern Web Guidance instead of outdated optimization advice
Focus on Core Web Vitals that impact real users
Verify AI suggestions before applying them
Measure improvements after every optimization
Treat AI as a debugging assistant—not a replacement for understanding performance fundamentals

📖 Learn more

If you would like to learn more about Vue, Nuxt, JavaScript or other useful technologies, checkout VueSchool by clicking this link or by clicking the image below:

It covers most important concepts while building modern Vue or Nuxt applications that can help you in your daily work or side projects 😉

🧪 Advance skills

A certification boosts your skills, builds credibility, and opens doors to new opportunities. Whether you're advancing your career or switching paths, it's a smart step toward success.

Check out Certificates.dev by clicking this link or by clicking the image below:

Invest in yourself—get certified in Vue.js, JavaScript, Nuxt, Angular, React, and more!

✅ Summary

Modern Web Guidance and Chrome DevTools for AI Agents represent an exciting step forward in web performance optimization.

In this article, you learned:

What Modern Web Guidance is
How Chrome DevTools for AI Agents works
How they complement each other
How they help identify and fix common performance issues

Take care!
And happy coding as always 🖥️

10 Vue Performance Mistakes I Still See in Production Apps

Jakub Andrzejewski — Mon, 15 Jun 2026 07:08:48 +0000

Performance has become one of the most important aspects of modern frontend development. Users expect websites to be fast and Google rewards fast websites.

And yet... even experienced Vue developers still introduce performance issues that can significantly impact user experience.

The tricky part? Most applications work perfectly fine during development.

Problems usually appear later:

larger datasets
slower devices
poor network conditions
increased application complexity

In this article, we'll look at 10 common Vue performance mistakes I still see in production applications and how to fix them.

Let's dive in.

🤔 Why Vue Performance Matters

Vue is already a highly optimized framework.

However, even the best framework cannot compensate for inefficient application code.

Poor performance can lead to:

slow page loads
delayed interactions
poor Core Web Vitals scores
increased battery usage
frustrated users

The good news?

Most performance issues can be fixed with relatively small changes.

🟢 Mistake #1: Using Deep Watchers Everywhere

A common mistake is enabling deep watchers on large objects.

Example:

watch(
  userData,
  () => {
    saveDraft()
  },
  {
    deep: true
  }
)

Deep watchers force Vue to traverse the entire object tree.

For large datasets this can become very expensive.

Instead:

watch specific properties
split large objects
use computed values when possible

🟢 Mistake #2: Making Everything Reactive

Not every piece of data needs reactivity.

I often see code like this:

const hugeDataset = ref(largeArray)

When the data rarely changes, Vue still needs to create reactive proxies.

For large collections this introduces unnecessary overhead.

A better approach:

const hugeDataset = shallowRef(largeArray)

Or even:

const hugeDataset = markRaw(largeArray)

when reactivity isn't needed at all.

🟢 Mistake #3: Creating New Objects Inside Computed Properties

Consider this:

const userInfo = computed(() => ({
  name: user.value.name,
  role: user.value.role
}))

A brand-new object is created every time the computed runs.

This can trigger unnecessary component updates.

Instead, prefer returning primitives when possible or memoizing expensive transformations.

🟢 Mistake #4: Using v-if Instead of v-show for Frequently Toggled Elements

Many developers use:

<div v-if="isOpen">
  Content
</div>

But if the element is shown and hidden frequently, Vue must repeatedly:

mount
render
destroy

A better option:

<div v-show="isOpen">
  Content
</div>

This simply toggles CSS visibility.

For frequently toggled UI elements, it's usually much faster.

🟢 Mistake #5: Rendering Huge Lists Without Virtualization

Rendering thousands of DOM nodes is expensive.

Example:

<div
  v-for="user in users"
  :key="user.id"
>
  {{ user.name }}
</div>

This might work with 100 items.

It won't feel great with 10,000.

Instead consider:

virtual scrolling
pagination
infinite loading

Libraries like Vue Virtual Scroller can dramatically improve performance.

🟢 Mistake #6: Lazy Loading Nothing

Many applications ship their entire codebase on the first page load.

Example:

import UserSettings from './UserSettings.vue'

This increases:

bundle size
download time
parse time

Instead:

const UserSettings = defineAsyncComponent(
  () => import('./UserSettings.vue')
)

Users only download code when it's actually needed.

🟢 Mistake #7: Fetching Data Sequentially

A surprisingly common issue:

const users = await fetchUsers()
const posts = await fetchPosts()
const comments = await fetchComments()

Each request waits for the previous one.

A faster approach:

const [users, posts, comments] =
  await Promise.all([
    fetchUsers(),
    fetchPosts(),
    fetchComments()
  ])

This can reduce loading times significantly.

🟢 Mistake #8: Forgetting About Image Optimization

Images are often the largest assets on a page.

Yet many applications still serve:

oversized images
uncompressed formats
images outside the viewport

For Vue and Nuxt applications:

use WebP or AVIF
lazy load images
generate responsive sizes

Image optimization frequently provides the biggest performance wins.

🟢 Mistake #9: Ignoring Component Re-Renders

A component may render far more often than expected.

For example:

<ExpensiveChart
  :data="chartData"
/>

If chartData changes reference on every update, the chart keeps re-rendering.

Common solutions:

stabilize references
use shallowRef
avoid unnecessary reactive updates
profile components with Vue DevTools

Small changes here can have a huge impact.

🟢 Mistake #10: Never Measuring Performance

The biggest mistake?

Not measuring anything.

Many teams optimize blindly.

Instead, regularly check:

Lighthouse
Core Web Vitals
Vue DevTools
Chrome Performance Panel
Network waterfalls

Performance work should be data-driven.

You can't improve what you don't measure.

🟢 Performance Checklist

Before shipping a Vue application, ask yourself:

✅ Am I using deep watchers only when necessary?

✅ Do all objects really need reactivity?

✅ Are large lists virtualized?

✅ Are routes and components lazy loaded?

✅ Are API requests running in parallel?

✅ Are images optimized?

✅ Have I measured actual performance?

If any answer is "no", there may be easy performance wins available.

🧪 Best Practices

Use shallowRef for large datasets
Avoid deep watchers whenever possible
Lazy load routes and heavy components
Virtualize large lists
Optimize images aggressively
Profile real-world user flows
Monitor Core Web Vitals
Measure before and after every optimization

📖 Learn more

If you would like to learn more about Vue, Nuxt, JavaScript or other useful technologies, checkout VueSchool by clicking this link or by clicking the image below:

It covers most important concepts while building modern Vue or Nuxt applications that can help you in your daily work or side projects 😉

🧪 Advance skills

A certification boosts your skills, builds credibility, and opens doors to new opportunities. Whether you're advancing your career or switching paths, it's a smart step toward success.

Check out Certificates.dev by clicking this link or by clicking the image below:

Invest in yourself—get certified in Vue.js, JavaScript, Nuxt, Angular, React, and more!

✅ Summary

Vue is fast by default.

But performance problems often come from how we use the framework rather than the framework itself.

In this article, you learned:

10 common Vue performance mistakes
Why they impact real-world applications
How to identify them
Practical ways to fix them
Best practices for building faster Vue apps

Many of these issues are easy to overlook during development but become expensive at scale.

By avoiding these mistakes and measuring performance regularly, you can build applications that feel fast, responsive, and enjoyable to use.

Take care!
And happy coding as always 🖥️

Frontend Observability in Vue Apps with OpenTelemetry

Jakub Andrzejewski — Mon, 08 Jun 2026 08:59:35 +0000

As frontend applications become more complex, debugging production issues becomes increasingly difficult.

A user reports: "The page feels slow." or: "The dashboard sometimes freezes."

But when you check your logs... everything looks fine.

The problem is that traditional frontend monitoring often tells you what failed, but not why it happened.

This is where observability comes in. And one of the most popular tools for modern observability is OpenTelemetry.

In this article, we'll explore:

What frontend observability is
How it differs from traditional monitoring
Why OpenTelemetry is becoming the industry standard
How to add OpenTelemetry to a Vue application
Best practices for collecting useful telemetry

Let's dive in.

🤔 What Is Frontend Observability?

Observability is the ability to understand what's happening inside your application by collecting telemetry data.

Typically, this includes:

traces
metrics
logs

Unlike traditional monitoring, observability helps answer questions like:

Why is this page slow?
Which API request caused the delay?
What happened before the error occurred?
Which users are affected?

Instead of simply knowing that something failed...

👉 You can understand the entire chain of events that led to the problem.

🟢 Why Is Frontend Observability Important?

Most teams invest heavily in backend observability.

They track:

database queries
API latency
server errors
infrastructure metrics

But users interact with the frontend.

And many issues happen before the request even reaches the backend.

For example:

slow component rendering
blocked main thread
failed network requests
routing issues
third-party script delays

Without frontend observability these problems are often invisible.

🟢 What Is OpenTelemetry?

OpenTelemetry (often called OTel) is an open-source observability framework used to collect and export telemetry data.

It provides a standard way to collect:

traces
metrics
logs

And send them to tools such as:

Grafana
Jaeger
Datadog
New Relic
Honeycomb
Elastic

The biggest advantage? Vendor-neutral instrumentation.

You can change observability providers without rewriting your instrumentation.

🟢 How OpenTelemetry Helps Vue Applications

Imagine a user loads a dashboard.

Several things happen:

Route change
↓
Component mounts
↓
API request starts
↓
Data is fetched
↓
UI renders

Normally these events are disconnected.

With OpenTelemetry you can trace the entire flow.

This helps answer questions like:

Which API call slowed down the page?
How long did rendering take?
Which routes are causing performance issues?

🟢 Setting Up OpenTelemetry in Vue

Let's look at a simplified setup.

Install the required packages:

npm install \
  @opentelemetry/api \
  @opentelemetry/sdk-trace-web \
  @opentelemetry/instrumentation-fetch \
  @opentelemetry/instrumentation-xml-http-request

Basic initialization

import { WebTracerProvider } from '@opentelemetry/sdk-trace-web'

const provider = new WebTracerProvider()

provider.register()

This creates a tracer that can collect telemetry from the browser.

🟢 Creating Custom Traces

One of the most powerful features is custom tracing.

Example:

import { trace } from '@opentelemetry/api'

const tracer = trace.getTracer('vue-app')

Inside a component:

const span = tracer.startSpan('load-users')

try {
  await fetchUsers()
} finally {
  span.end()
}

Now you'll see exactly how long that operation took.

This becomes extremely useful when debugging production issues.

🟢 Tracking Route Performance

Vue Router is another excellent place to add tracing.

Example:

router.beforeEach((to, from, next) => {
  performance.mark('navigation-start')
  next()
})

router.afterEach(() => {
  performance.measure(
    'navigation',
    'navigation-start'
  )
})

Combined with OpenTelemetry exporters, this can help identify slow routes and navigation bottlenecks.

🟢 Monitoring API Requests

Many performance problems originate from network calls.

OpenTelemetry provides automatic instrumentation for:

Fetch API
XMLHttpRequest

Example:

registerInstrumentations({
  instrumentations: [
    new FetchInstrumentation()
  ]
})

Now requests can automatically generate traces.

You can see:

request duration
failures
dependencies between actions

without manually instrumenting every API call.

🧪 Best Practices

Instrument critical user flows first
Trace important API requests
Avoid collecting unnecessary telemetry
Sample traces in high-traffic applications
Correlate frontend traces with backend traces
Monitor route transitions and rendering bottlenecks
Focus on actionable insights rather than collecting everything

📖 Learn more

If you would like to learn more about Vue, Nuxt, JavaScript or other useful technologies, checkout VueSchool by clicking this link or by clicking the image below:

It covers most important concepts while building modern Vue or Nuxt applications that can help you in your daily work or side projects 😉

🧪 Advance skills

A certification boosts your skills, builds credibility, and opens doors to new opportunities. Whether you're advancing your career or switching paths, it's a smart step toward success.

Check out Certificates.dev by clicking this link or by clicking the image below:

Invest in yourself—get certified in Vue.js, JavaScript, Nuxt, Angular, React, and more!

✅ Summary

Frontend observability helps you understand not just what went wrong, but why it happened.

As applications grow in complexity, logs and error tracking alone are often no longer enough.

OpenTelemetry gives you deeper visibility into your Vue application, helping you identify bottlenecks, improve performance, and deliver a better user experience.

Take care!
And happy coding as always 🖥️

State-Driven Animations in Vue: Create Smooth UI Transitions with Reactive State

Jakub Andrzejewski — Mon, 01 Jun 2026 09:54:37 +0000

Animations can make an application feel faster, smoother, and more polished. However, many developers think animations are only useful for things like:

page transitions
modals
enter/leave effects

But Vue provides another powerful pattern - State-driven animations. Instead of animating when elements are added or removed from the DOM, you animate changes in reactive state. This allows you to create rich interactive experiences while keeping your code declarative and easy to maintain.

In this article, we'll explore:

What state-driven animations are
How they differ from regular Vue transitions
What problems they solve
How to implement them in Vue
Best practices for creating smooth UI interactions

Let's dive in.

🤔 What Are State-Driven Animations?

Most Vue developers are familiar with the <Transition> component.

Example:

<Transition>
  <Modal v-if="isOpen" />
</Transition>

This animates an element when it enters or leaves the DOM.

But what if the element already exists and only its state changes? For example:

a progress bar grows
a card expands
a chart updates
a panel changes size
a value changes position

This is where state-driven animations shine.

Instead of animating DOM insertion or removal, you animate changes caused by reactive state.

🟢 What Problem Do State-Driven Animations Solve?

Without animations, state changes can feel abrupt.

Example:

<div :style="{ width: progress + '%' }"></div>

When progress changes:

progress.value = 80

The width instantly jumps.

This works technically... but it doesn't feel great.

🟢 A Simple Example

Let's create an animated progress bar.

<script setup lang="ts">
const progress = ref(20)

function increase() {
  progress.value += 20
}
</script>

<template>
  <button @click="increase">
    Increase Progress
  </button>

  <div class="progress-container">
    <div
      class="progress-bar"
      :style="{ width: `${progress}%` }"
    />
  </div>
</template>

CSS:

.progress-container {
  width: 100%;
  height: 12px;
  background: #eee;
}

.progress-bar {
  height: 100%;
  background: #42b883;
  transition: width 0.3s ease;
}

Now whenever progress changes, the bar animates smoothly.

The animation is entirely driven by reactive state.

🟢 Animating Multiple Properties

State-driven animations are not limited to width.

Example:

<div
  class="card"
  :style="{
    transform: expanded
      ? 'scale(1.1)'
      : 'scale(1)',
    opacity: expanded
      ? 1
      : 0.7
  }"
/>

CSS:

.card {
  transition:
    transform 0.3s ease,
    opacity 0.3s ease;
}

Now changing:

expanded.value = true

animates scale and opacity at the same time.

🟢 Using Vue Reactivity with Animations

One of the biggest advantages is that animations stay connected to Vue's reactivity system.

Example:

<script setup lang="ts">
const isActive = ref(false)
</script>

<template>
  <button @click="isActive = !isActive">
    Toggle
  </button>

  <div
    class="box"
    :class="{ active: isActive }"
  />
</template>

CSS:

.box {
  width: 100px;
  height: 100px;
  transition: all 0.4s ease;
}

.box.active {
  transform: rotate(180deg);
}

Vue handles state.

CSS handles animation.

The result is clean and maintainable.

🧪 Best Practices

Keep animations subtle and purposeful
Prefer CSS transitions for simple effects
Avoid animating expensive properties when possible
Use transforms instead of layout-changing properties when appropriate
Don't animate everything
Keep durations short (typically 200–400ms)
Use animations to communicate state changes, not distract users

📖 Learn more

If you would like to learn more about Vue, Nuxt, JavaScript or other useful technologies, checkout VueSchool by clicking this link or by clicking the image below:

It covers most important concepts while building modern Vue or Nuxt applications that can help you in your daily work or side projects 😉

🧪 Advance skills

A certification boosts your skills, builds credibility, and opens doors to new opportunities. Whether you're advancing your career or switching paths, it's a smart step toward success.

Check out Certificates.dev by clicking this link or by clicking the image below:

Invest in yourself—get certified in Vue.js, JavaScript, Nuxt, Angular, React, and more!

✅ Summary

State-driven animations are a powerful way to create smooth and engaging user experiences in Vue.

While <Transition> is perfect for entering and leaving elements, state-driven animations excel when existing elements need to react smoothly to changing data.

Used thoughtfully, they can make your applications feel significantly more responsive and professional.

Take care!
And happy coding as always 🖥️

Avoid Cross Module Dependencies with Dependency Cruiser

Jakub Andrzejewski — Mon, 25 May 2026 06:27:43 +0000

As applications grow, maintaining a clean architecture becomes increasingly difficult.

At first, everything feels manageable but after a few months (or years), projects often become full of:

circular dependencies
deeply coupled modules
messy import paths
forbidden cross-layer imports
architectural chaos

The worst part is that these problems usually grow silently over time.

This is where dependency-cruiser becomes incredibly useful. It helps you visualize and enforce rules for your project dependencies before things become unmaintainable.

In this article, we’ll explore:

What dependency-cruiser is
What problems it solves
How to set it up
Practical examples
How to enforce architectural boundaries

Let’s dive in.

🤔 What Is dependency-cruiser?

dependency-cruiser is a powerful tool for analyzing and validating dependencies in JavaScript and TypeScript projects.

It scans your project imports and helps you:

detect circular dependencies
enforce architecture rules
visualize dependency graphs
identify unused modules
prevent bad import patterns

Think of it like:

👉 “ESLint for your project architecture.”

🟢 What Problem Does dependency-cruiser Solve?

In large applications, dependencies can quickly become messy.

Example problems:

❌ Circular dependencies

A → B → C → A

These can cause:

runtime issues
undefined values
difficult debugging
unpredictable behavior

❌ Layer violations

Example:

components → api → components

Or:

ui → backend → ui

This breaks separation of concerns.

❌ Shared modules becoming dumping grounds

You often end up with:

/utils
/shared
/helpers

containing everything.

Over time:

dependencies become tangled
architecture loses structure

✅ dependency-cruiser helps enforce boundaries

You can define rules like:

“UI cannot import backend”
“Feature modules cannot depend on each other”
“No circular dependencies allowed”

And automatically validate them in CI.

🟢 Installing dependency-cruiser

Setup is very simple.

Install it:

npm install --save-dev dependency-cruiser

🟢 Generating Your First Dependency Graph

One of the coolest features is visualization.

Example:

npx depcruise src --include-only "^src" --output-type dot | dot -T svg > dependency-graph.svg

This generates a visual graph of your project dependencies.

You can quickly spot:

circular dependencies
overly connected modules
problematic architecture

In large projects, this is incredibly eye-opening.

🟢 Creating Rules

The real power comes from architecture validation.

Example config:

module.exports = {
  forbidden: [
    {
      name: 'no-circular',
      severity: 'error',
      from: {},
      to: {
        circular: true
      }
    }
  ]
}

Now dependency-cruiser will fail whenever circular dependencies appear.

🟢 Real-World Example: Enforcing Layered Architecture

Imagine this structure:

src/
├── components/
├── features/
├── api/
├── utils/

You may want:

👉 components should never import from api

Rule example:

module.exports = {
  forbidden: [
    {
      name: 'no-components-to-api',
      from: {
        path: '^src/components'
      },
      to: {
        path: '^src/api'
      }
    }
  ]
}

Now architecture rules become automated.

This is extremely valuable for:

large teams
enterprise projects
monorepos
long-term maintainability

🟢 Using dependency-cruiser with Vue Projects

dependency-cruiser works great with:

Vue
Nuxt
React
Angular
Node.js
TypeScript monorepos

For Vue apps, it’s especially useful when managing:

composables
feature modules
shared UI components
store architecture
layered frontend structure

Example issue it can prevent:

components → composables → components

Which can become very difficult to maintain later.

🟢 CI Integration

One of the best things about dependency-cruiser:

👉 It can run automatically in CI/CD pipelines.

Example:

npx depcruise src --validate .dependency-cruiser.js

Now pull requests fail when architecture rules are violated.

This prevents technical debt from growing silently.

🟢 Common Mistakes

❌ Creating overly strict rules too early

Start simple.

Too many restrictions can frustrate teams.

❌ Ignoring the reports

The tool is only useful if rules are actually enforced.

❌ Not visualizing dependencies

Graphs often reveal architecture problems immediately.

❌ Allowing shared folders to grow uncontrollably

dependency-cruiser helps expose this early.

🧪 Best Practices

Start with circular dependency detection
Gradually add architectural rules
Integrate validation into CI
Use dependency graphs regularly
Keep rules aligned with real architecture decisions
Avoid massive shared utility folders
Use the tool proactively — not only after problems appear

📖 Learn more

If you would like to learn more about Vue, Nuxt, JavaScript or other useful technologies, checkout VueSchool by clicking this link or by clicking the image below:

It covers most important concepts while building modern Vue or Nuxt applications that can help you in your daily work or side projects 😉

🧪 Advance skills

A certification boosts your skills, builds credibility, and opens doors to new opportunities. Whether you're advancing your career or switching paths, it's a smart step toward success.

Check out Certificates.dev by clicking this link or by clicking the image below:

Invest in yourself—get certified in Vue.js, JavaScript, Nuxt, Angular, React, and more!

✅ Summary

dependency-cruiser is an incredibly valuable tool for keeping project architecture healthy as applications grow.

Good architecture rarely happens accidentally.

Tools like dependency-cruiser help teams maintain structure, reduce technical debt, and prevent dependency chaos before it becomes a serious problem.

Take care!
And happy coding as always 🖥️

Avoid Unnecessary Re-renders in Vue with `v-memo`

Jakub Andrzejewski — Mon, 18 May 2026 09:21:34 +0000

When building Vue applications, performance usually feels great by default - Vue’s reactivity system is incredibly efficient.

But as applications grow larger, you may eventually run into situations where:

components re-render too often
large lists become expensive
UI updates feel sluggish
unnecessary computations happen repeatedly

This is where memoization becomes useful. And in Vue, one of the easiest ways to optimize rendering is with v-memo.

In this article, we’ll explore:

What memoization is
What problem it solves
How v-memo works in Vue
Real-world examples
Best practices and common mistakes

Let’s dive in.

🤔 What Is Memoization?

Memoization is an optimization technique where results are cached and reused instead of recalculating them again.

Instead of:

recomputing
re-rendering
recalculating

You simply use the cached version.

🟢 What Problem Does Memoization Solve?

In reactive applications, updates can trigger many re-renders even when most data has not changed for example:

Parent component updates
Entire list re-renders
Hundreds of child components update unnecessarily

This can hurt performance, responsiveness, and even battery usage on mobile devices.

Without memoization every update causes new rendering work - even for unchanged content.

With memoization Vue can skip rendering when dependencies stay the same which reduces DOM operations, Virtual DOM diffing, and in general component work.

🟢 What Is `v-memo` in Vue?

v-memo is a Vue directive that memoizes part of a template.

Basic example:

<div v-memo="[value]">
  {{ expensiveContent }}
</div>

Vue will only re-render this block when value changes. Otherwise Vue reuses the previous rendered result.

Let’s imagine a large user list.

Without v-memo

<script setup lang="ts">
const users = ref([
  { id: 1, name: 'John' },
  { id: 2, name: 'Alice' }
])

const counter = ref(0)
</script>

<template>
  <button @click="counter++">
    {{ counter }}
  </button>

  <div
    v-for="user in users"
    :key="user.id"
  >
    {{ user.name }}
  </div>
</template>

Every counter update re-renders the whole list even though users never changed.

With v-memo we can:

<script setup lang="ts">
const users = ref([
  { id: 1, name: 'John' },
  { id: 2, name: 'Alice' }
])

const counter = ref(0)
</script>

<template>
  <button @click="counter++">
    {{ counter }}
  </button>

  <div
    v-for="user in users"
    :key="user.id"
    v-memo="[user.id]"
  >
    {{ user.name }}
  </div>
</template>

And now counter updates still happen but unchanged list items are skipped. This becomes extremely valuable for large lists, dashboards, or tables.

🟢 When NOT to Use It

v-memo is not needed everywhere as Vue is already highly optimized.

Avoid using it for tiny components, static content, or premature optimization as overusing memoization can:

reduce readability
make debugging harder
introduce stale UI bugs

🧪 Best Practices

Use v-memo only for measurable bottlenecks
Great for large dynamic lists
Keep dependency arrays minimal
Avoid premature optimization
Profile performance before optimizing
Combine with virtual scrolling for huge datasets
Prefer stable keys and predictable state updates

📖 Learn more

If you would like to learn more about Vue, Nuxt, JavaScript or other useful technologies, checkout VueSchool by clicking this link or by clicking the image below:

It covers most important concepts while building modern Vue or Nuxt applications that can help you in your daily work or side projects 😉

🧪 Advance skills

A certification boosts your skills, builds credibility, and opens doors to new opportunities. Whether you're advancing your career or switching paths, it's a smart step toward success.

Check out Certificates.dev by clicking this link or by clicking the image below:

Invest in yourself—get certified in Vue.js, JavaScript, Nuxt, Angular, React, and more!

✅ Summary

Memoization is a powerful optimization technique that helps avoid unnecessary work.

In this article, you learned:

What memoization is
What problem it solves
How Vue’s v-memo works
Practical examples for lists and components
When to use it — and when not to

Take care!
And happy coding as always 🖥️

Why Loaders Matter for Performance

Jakub Andrzejewski — Mon, 11 May 2026 09:29:43 +0000

When developers think about performance optimization, they usually focus on things like:

lazy loading
caching
image optimization
bundle size

And while those things absolutely matter there’s another area that heavily impacts user experience -> Loading states and layout stability.

A badly implemented loading experience can make an app feel slow, jumpy, or frustrating to use. This is strongly connected to an important Core Web Vital metric Cumulative Layout Shift (CLS).

In this article, we’ll explore:

What CLS is
Why loaders are critical for perceived performance
How poor loading states hurt UX
Practical examples in Vue
Best practices for stable layouts

Let’s dive in.

🤔 What Is Cumulative Layout Shift (CLS)?

CLS measures how much elements unexpectedly move during page loading.

Example of bad CLS:

Text suddenly jumps down
Buttons move while you try to click
Images appear late and push content around

We’ve all experienced websites like this:

👉 You try to click something… and suddenly the layout shifts. Extremely annoying.

Why does this happen? Usually because:

content loads asynchronously
elements have no reserved space
loaders are missing
images don’t define dimensions
components suddenly appear

Why does CLS matter? Because it affects user experience, accessibility, or mobile usability (and obviously Google Core Web Vitals). Even if your app is technically fast poor layout stability can make it feel slow.

👉 Users care more about perceived performance than actual milliseconds.

A good loader communicates progress, prevents layout jumping, and makes apps feel responsive

A bad or missing loader creates uncertainty. Users start thinking:

“Did the app freeze?”
“Is something broken?”
“Why is everything moving?”

🟢 Implementing proper loaders in Vue

Let's take a look at the following example:

<script setup lang="ts">
const users = ref([])
const loading = ref(true)

onMounted(async () => {
  users.value = await fetchUsers()
  loading.value = false
})
</script>

<template>
  <div v-if="loading" class="skeleton-list">
    <div
      v-for="n in 5"
      :key="n"
      class="skeleton-card"
    />
  </div>

  <UserCard
    v-else
    v-for="user in users"
    :key="user.id"
    :user="user"
  />
</template>

<style scoped>
.skeleton-card {
  height: 120px;
  border-radius: 12px;
  margin-bottom: 16px;
}
</style>

We fetch users, but when the fetch is in progress we display the same hard coded number of loaders/skeletons. When the users are loaded there is no layout shift as it occupies the same space improving perceived performance and User Experience.

If we don't know how many results there will be, we have to assume some number but it is still better than not having skeletons at all :)

Many apps still use simple spinners or text/icon loaders like:

<div>Loading...</div>

But modern UX usually prefers Skeleton loaders because they mimic final layout, reduce layout shift, and improve perceived speed.

🧪 Best Practices

Prefer skeleton loaders over tiny spinners
Reserve space before content loads
Keep loading and final layouts similar
Always define image dimensions
Avoid injecting large content suddenly
Test CLS using Lighthouse or Core Web Vitals tools
Think about perceived performance — not just raw speed

📖 Learn more

If you would like to learn more about Vue, Nuxt, JavaScript or other useful technologies, checkout VueSchool by clicking this link or by clicking the image below:

It covers most important concepts while building modern Vue or Nuxt applications that can help you in your daily work or side projects 😉

🧪 Advance skills

A certification boosts your skills, builds credibility, and opens doors to new opportunities. Whether you're advancing your career or switching paths, it's a smart step toward success.

Check out Certificates.dev by clicking this link or by clicking the image below:

Invest in yourself—get certified in Vue.js, JavaScript, Nuxt, Angular, React, and more!

✅ Summary

Loaders are much more important than most developers realize.

In this article, you learned:

What Cumulative Layout Shift (CLS) is
Why poor loading states hurt UX
How skeleton loaders improve perceived performance
How to avoid layout jumping in Vue and other frameworks
Best practices for stable, responsive interfaces

Fast apps are great.

But apps that feel smooth and stable are what users truly remember.

Take care!
And happy coding as always 🖥️

How to Safely Allow Inline Scripts Without Breaking Security with CSP Nonce

Jakub Andrzejewski — Mon, 27 Apr 2026 06:46:57 +0000

When building modern web applications, security is not optional. One of the most important protections you can add is a Content Security Policy (CSP).

But here’s the catch:

👉 CSP often blocks inline scripts and styles — which can break your app.

So how do you keep your app secure without disabling useful features?

That’s where CSP nonce comes in - it allows you to safely execute inline code without opening security holes.

In this article, we’ll explore:

What CSP nonce is
What problem it solves
How to implement it
How it works automatically in Nuxt with nuxt-security
Best practices and common pitfalls

Let’s dive in.

🤔 What Is CSP Nonce?

A nonce (short for number used once) is a unique, random value generated for each request.

It is used in CSP to explicitly allow trusted inline scripts or styles.

Example:

<script nonce="abc123">
  console.log('Secure inline script')
</script>

And in your HTTP headers:

Content-Security-Policy: script-src 'nonce-abc123'

The browser will only execute scripts that have a matching nonce.

CSP nonce is a whitelist mechanism:

Only scripts with the correct nonce are allowed
Everything else is blocked
The nonce changes on every request

This makes it extremely effective against XSS (Cross-Site Scripting) attacks.

CSP nonce is commonly used for:

SSR frameworks - Injecting initial state, Hydration scripts
Analytics / tracking snippets - Inline scripts required by providers
Critical inline scripts - Small scripts needed before app bootstraps

🟢 What Problem Does CSP Nonce Solve?

Without nonce, you usually face a trade-off:

❌ Allow inline scripts (unsafe)

Content-Security-Policy: script-src 'unsafe-inline'

Problem:

Opens the door to XSS attacks
Any injected script can run

❌ Block inline scripts completely

Content-Security-Policy: script-src 'self'

Problem:

breaks inline event handlers
breaks injected scripts (SSR hydration, state)
breaks some frameworks

🟢 How to Implement CSP Nonce

The process is relatively simple but let's break it down and explain each step individually.

Step 1: Generate a nonce per request

Example (Node.js):

import crypto from 'crypto'

function generateNonce() {
  return crypto.randomBytes(16).toString('base64')
}

Step 2: Add it to response headers

const nonce = generateNonce()

res.setHeader(
  'Content-Security-Policy',
  `script-src 'nonce-${nonce}'`
)

Step 3: Inject it into your HTML

<script nonce="{{nonce}}">
  window.__INITIAL_STATE__ = {}
</script>

⚠️ Critical rule

The nonce in the header and HTML must match exactly. Otherwise, script will be blocked and app may break silently.

🟢 CSP Nonce in Nuxt (with nuxt-security)

If you’re using Nuxt, things get much easier thanks to nuxt-security module that can:

Automatically generate nonce per request
Inject it into CSP headers
Attach it to scripts/styles

It makes it much easier to work with CSP nonces in Nuxt. Let's take a look at the following configuration:

export default defineNuxtConfig({
  modules: ['nuxt-security'],
  security: {
    headers: {
      contentSecurityPolicy: {
        'script-src': [
          "'self'",
          "'nonce-{{nonce}}'"
        ]
      }
    }
  }
})

What happens automatically:

Nuxt generates a nonce per request
Replaces {{nonce}} in headers
Applies nonce to inline scripts

You don’t need to manually wire everything

You can read more here:
https://nuxt-security.vercel.app/

🟢 Common Mistakes

Let's take a look at the list of common mistakes to understand what to look for:

❌ Reusing the same nonce - Nonce must be unique per request and cryptographically random
❌ Forgetting to apply nonce in HTML - if you only set CSP header the scripts will still be blocked
❌ Mixing nonce with unsafe-inline - script-src 'unsafe-inline' 'nonce-abc'
❌ Caching issues - if HTML is cached nonce may not match header

🧪 Best Practices

Generate nonce per request
Use secure randomness (crypto)
Never reuse nonce
Avoid unsafe-inline
Use frameworks/tools (like nuxt-security)
Test CSP in report-only mode first
Monitor browser console for CSP violations

📖 Learn more

If you would like to learn more about Vue, Nuxt, JavaScript or other useful technologies, checkout VueSchool by clicking this link or by clicking the image below:

It covers most important concepts while building modern Vue or Nuxt applications that can help you in your daily work or side projects 😉

🧪 Advance skills

A certification boosts your skills, builds credibility, and opens doors to new opportunities. Whether you're advancing your career or switching paths, it's a smart step toward success.

Check out Certificates.dev by clicking this link or by clicking the image below:

Invest in yourself—get certified in Vue.js, JavaScript, Nuxt, Angular, React, and more!

✅ Summary

CSP nonce is a powerful mechanism that allows you to safely use inline scripts while maintaining strong security.

In this article, you learned:

What CSP nonce is and how it works
What problem it solves (security vs flexibility)
How to implement it step by step
How Nuxt + nuxt-security handle it automatically
Common mistakes and best practices

Take care!
And happy coding as always 🖥️

DEV Community: Jakub Andrzejewski

Preserve Component State in Vue with KeepAlive

🤔 What Is Vue KeepAlive?

🟢 What Problem Does KeepAlive Solve?

🟢 Using KeepAlive with Dynamic Components

🟢 KeepAlive and Lifecycle Hooks

🟢 KeepAlive vs onMounted

🟢 Controlling Which Components Are Cached

🟢 Limiting the Cache with max

🟢 KeepAlive Isn't Always the Right Choice

🧪 Best Practices

📖 Learn more

🧪 Advance skills

✅ Summary

How to set Content Security Policy with a Meta Tag?

🤔 What Is a CSP Meta Tag?

🟢 How to Use a CSP Meta Tag

🟢 What Are the Limitations?

❌ It Doesn't Protect Early Requests

❌ Some Directives Are Not Supported

❌ Cannot Replace Server Security

🟢 When Should You Use a Meta CSP?

✅ Static websites

✅ Local development

✅ Documentation sites

✅ Internal prototypes

🟢 Meta Tag vs HTTP Header

🧪 Best Practices

📖 Learn more

🧪 Advance skills

✅ Summary

Improve Performance by Loading Videos Only When They're Needed

🤔 What Is Lazy Loading for Videos?

🟢 What Problem Does It Solve?

🟢 How to Lazy Load a Video

🟢 Why Use a Poster Image?

🟢 Loading Videos Only After User Interaction

🟢 Browser Support

🧪 Best Practices

📖 Learn more

🧪 Advance skills

✅ Summary

Enforce Better Vue Architecture with ESLint

🤔 ESLint Is More Than a Code Formatter

🟢 What Problem Does It Solve?

🟢 Enforcing Vue Block Order

🟢 Enforcing Composition API Patterns

🟢 Restricting Specific APIs

🟢 Enforcing Import Conventions

🟢 Preventing Architectural Violations

🟢 Creating Custom Rules for Your Team

🟢 Why This Matters in Large Vue Applications

🧪 Best Practices

📖 Learn more

🧪 Advance skills

✅ Summary

Fix Web Performance Issues Faster with Modern Web Guidance and Chrome DevTools for AI Agents

🤔 What Is Modern Web Guidance?

🟢 What Is Chrome DevTools for AI Agents?

🟢 How It Works Together

🟢 Example: Finding a Long JavaScript Task

🟢 Example: Fixing Layout Shifts

🧪 Best Practices

📖 Learn more

🧪 Advance skills

✅ Summary

10 Vue Performance Mistakes I Still See in Production Apps

🤔 Why Vue Performance Matters

🟢 Mistake #1: Using Deep Watchers Everywhere

🟢 Mistake #2: Making Everything Reactive

🟢 Mistake #3: Creating New Objects Inside Computed Properties

🟢 Mistake #4: Using v-if Instead of v-show for Frequently Toggled Elements

🟢 Mistake #5: Rendering Huge Lists Without Virtualization

🟢 Mistake #6: Lazy Loading Nothing

🟢 Mistake #7: Fetching Data Sequentially

🟢 Mistake #8: Forgetting About Image Optimization

🟢 Mistake #9: Ignoring Component Re-Renders

🟢 Mistake #10: Never Measuring Performance

🟢 Performance Checklist

🧪 Best Practices

🟢 KeepAlive vs `onMounted`

🟢 Limiting the Cache with `max`

🟢 What Is `v-memo` in Vue?