Let’s talk about making your JavaScript applications faster. I’ve spent a lot of time working on web applications that started out snappy but gradually became slow as features were added. The frustration of a janky interface, especially on a mobile device, is real. Over time, I’ve learned that performance isn’t just about raw speed; it’s about perception. A fast-feeling application keeps users happy and engaged.

The good news is you don’t need to be a browser engine expert to make big improvements. By applying a few consistent patterns, you can often turn a sluggish app into a smooth one. I want to share seven of the most effective patterns I use regularly. Think of them as tools in a toolbox. You don’t need to use every tool on every project, but knowing which one to reach for is the key.

The first pattern involves being smarter about how you send your code to the browser. In the old days, we might bundle our entire application—every page, every component, every library—into one massive JavaScript file. The browser has to download, parse, and compile all of it before the user can do anything. This creates a long wait.

A better way is to split your code into smaller pieces and only send what’s needed for the initial page. This is often called code splitting. The rest of your code can wait in the background and load only when a user is about to need it, like when they click a link to a different section of your app.

Modern tools like Webpack, Vite, or Parcel make this straightforward. You can define split points in your code using dynamic imports. It looks like telling the app, “Only fetch this chunk of code when we’re sure we need it.” Here’s a basic example of how you might set this up for different routes in a React-like application.

// Instead of a static import at the top of your file...
// import ExpensiveDashboard from './ExpensiveDashboard';

// You use a dynamic import function. This returns a Promise.
const loadDashboard = () => import('./ExpensiveDashboard');

// Later, when a button is clicked to view the dashboard:
button.addEventListener('click', async () => {
  const dashboardModule = await loadDashboard();
  const DashboardComponent = dashboardModule.default;
  // Now render the DashboardComponent
});

For your build tool, you might configure it to automatically group third-party libraries separately from your own code. This is useful because vendor libraries change less often. A configuration snippet might look like this, telling the bundler to create separate files for code from node_modules.

// webpack.config.js
module.exports = {
  // ... other config
  optimization: {
    splitChunks: {
      cacheGroups: {
        vendor: {
          test: /[\\/]node_modules[\\/]/,
          name: 'vendors',
          chunks: 'all',
        },
      },
    },
  },
};

The second pattern is a close relative of code splitting, but it focuses on assets and components. We call it lazy loading. Have you ever visited a news site with dozens of images? If all those images try to load the moment the page opens, it fights with the critical JavaScript and CSS for bandwidth, making everything feel slow.

Lazy loading means delaying the load of a resource until it’s actually needed. For an image, that’s when it’s about to scroll into the user’s viewport. For a complex component, it’s when a user interacts with a tab or button. The browser’s Intersection Observer API is perfect for this. It can watch elements and tell you when they become visible.

Here’s how you might implement lazy loading for images without a library. You store the real image URL in a data attribute like data-src and then swap it in when the image is near the viewport.

const imageObserver = new IntersectionObserver((entries, observer) => {
  entries.forEach(entry => {
    // Is the image visible (or within, say, 100 pixels of being visible)?
    if (entry.isIntersecting) {
      const img = entry.target;
      // Replace the placeholder 'src' with the real one
      img.src = img.dataset.src;
      // Stop observing this image once it's loaded
      observer.unobserve(img);
    }
  });
}, {
  rootMargin: '100px' // Start loading 100px before the image is visible
});

// Find all images you want to lazy-load and start observing them
document.querySelectorAll('img[data-src]').forEach(img => {
  imageObserver.observe(img);
});

In frameworks like React or Vue, lazy loading components is built-in. You wrap the import of a heavy component with React.lazy. The app will only fetch that component’s code when it’s rendered for the first time. You should always provide a fallback, like a loading spinner, to show while the code is being fetched.

import React, { Suspense } from 'react';

// This component's code will be split into a separate bundle
const HeavyChartComponent = React.lazy(() => import('./HeavyChartComponent'));

function AnalyticsPage() {
  return (
    <div>
      <h1>Analytics Dashboard</h1>
      <Suspense fallback={<div className="spinner">Loading chart...</div>}>
        <HeavyChartComponent />
      </Suspense>
    </div>
  );
}

The third pattern is about avoiding unnecessary work. If a function is called repeatedly with the same inputs and it performs a heavy calculation, why do the calculation more than once? This is where memoization comes in. It’s a fancy word for caching the results of a function call.

Memoization is ideal for pure functions—functions that always return the same output for the same input and have no side effects. Think of a function that calculates a factorial, filters a large list based on a filter string, or formats a date in a complex way.

You can write a simple helper function that creates a memoized version of any other function. It uses a JavaScript Map to store inputs and their corresponding outputs.

function memoize(fn) {
  const cache = new Map();
  return function(...args) {
    // Create a unique key for this set of arguments.
    // For simple arguments, JSON.stringify works. For complex ones, you might need a custom key generator.
    const key = JSON.stringify(args);

    if (cache.has(key)) {
      console.log('Fetching from cache for args:', args);
      return cache.get(key);
    }

    console.log('Calculating result for args:', args);
    const result = fn.apply(this, args);
    cache.set(key, result);
    return result;
  };
}

// An expensive function we want to memoize
function calculateTax(amount, taxRate) {
  // Simulate a slow calculation with a loop
  let result = amount;
  for(let i = 0; i < 1000000; i++) {
    result = amount * (taxRate / 100);
  }
  return result;
}

const memoizedTaxCalc = memoize(calculateTax);

console.log(memoizedTaxCalc(100, 20)); // "Calculating result..." - slow
console.log(memoizedTaxCalc(100, 20)); // "Fetching from cache..." - instant!
console.log(memoizedTaxCalc(150, 20)); // "Calculating result..." - new input, slow again

Many utility libraries like Lodash have a _.memoize function, and React provides the useMemo and useCallback hooks for memoizing values and functions inside components.

The fourth pattern tackles a very specific but common problem: rendering long lists. If you have a list with 10,000 items and you render all of them as DOM elements, the browser will struggle. It has to create, style, and manage 10,000 nodes, which uses a huge amount of memory and makes scrolling incredibly slow.

The solution is virtualization. You only render a small window of items—the ones that are actually visible on the screen—plus a few extra above and below as a buffer for smooth scrolling. As the user scrolls, you recycle the DOM elements, updating their content to match the new items in the viewport.

While you’ll often use a library like react-window or vue-virtual-scroller for this, understanding the basic concept is valuable. Here’s a simplified version of how a virtual list works.

class SimpleVirtualList {
  constructor(container, itemHeight, totalItems, renderItemCallback) {
    this.container = container;
    this.itemHeight = itemHeight;
    this.totalItems = totalItems;
    this.renderItem = renderItemCallback;

    // How many items fit in the visible container?
    this.visibleItemCount = Math.ceil(container.clientHeight / itemHeight);
    // Render a few extra items above and below to prevent blanks during fast scroll
    this.buffer = 3;

    this.container.style.position = 'relative';
    this.container.style.overflow = 'auto';

    this.handleScroll = this.handleScroll.bind(this);
    this.container.addEventListener('scroll', this.handleScroll);

    this.renderWindow();
  }

  handleScroll() {
    this.renderWindow();
  }

  renderWindow() {
    const scrollTop = this.container.scrollTop;
    // Calculate the index of the first item we should render
    const startIndex = Math.max(0, Math.floor(scrollTop / this.itemHeight) - this.buffer);
    // Calculate the index of the last item we should render
    const endIndex = Math.min(
      this.totalItems,
      startIndex + this.visibleItemCount + (this.buffer * 2)
    );

    // Clear the container and create a document fragment for performance
    this.container.innerHTML = '';
    const fragment = document.createDocumentFragment();

    for (let i = startIndex; i < endIndex; i++) {
      const itemElement = this.renderItem(i); // Get a DOM element for this item
      itemElement.style.position = 'absolute';
      itemElement.style.top = `${i * this.itemHeight}px`;
      itemElement.style.width = '100%';
      fragment.appendChild(itemElement);
    }

    this.container.appendChild(fragment);
    // Set the total height of the container to enable scrolling
    this.container.style.height = `${this.totalItems * this.itemHeight}px`;
  }
}

// Usage
const listContainer = document.getElementById('myList');
const virtualList = new SimpleVirtualList(
  listContainer,
  50, // Each item is 50px tall
  10000, // We have 10,000 total items
  (index) => {
    const div = document.createElement('div');
    div.className = 'list-item';
    div.textContent = `Item #${index + 1}`;
    return div;
  }
);

The fifth pattern is crucial when you have tasks that take a lot of CPU time. JavaScript runs on the main thread, which is also responsible for painting the screen and responding to clicks. If a complex calculation takes 2 seconds, the entire interface freezes for 2 seconds. That’s a terrible user experience.

Web Workers give you a way to run scripts in background threads. They can perform heavy calculations without blocking the main thread. The worker and the main thread communicate by sending messages back and forth. You can’t directly manipulate the DOM from a worker, but you can send the results of a calculation back to the main thread, which can then update the UI.

Setting up a worker is simple. You create a new Worker object, point it to a separate JavaScript file, and set up message listeners.

// main.js - The main application thread
const calculationWorker = new Worker('./calculationWorker.js');

// Send data to the worker
const bigDataSet = /* ... some large array ... */;
calculationWorker.postMessage({
  type: 'PROCESS_DATA',
  payload: bigDataSet
});

// Listen for the result from the worker
calculationWorker.onmessage = (event) => {
  const processedData = event.data;
  // Now it's safe to update the UI with the result
  updateChart(processedData);
};

calculationWorker.onerror = (error) => {
  console.error('Worker error:', error);
};

// calculationWorker.js - The background worker file
self.onmessage = function(event) {
  const { type, payload } = event.data;

  if (type === 'PROCESS_DATA') {
    // This heavy processing won't block the main thread's UI
    const result = heavyDataProcessing(payload);
    // Send the result back to the main thread
    self.postMessage(result);
  }
};

function heavyDataProcessing(data) {
  // Simulate a CPU-intensive task
  return data.map(number => {
    let processed = number;
    for (let i = 0; i < 1000000; i++) {
      processed = Math.sqrt(processed) * Math.random();
    }
    return processed;
  });
}

The sixth pattern deals with high-frequency events. Events like scroll, resize, and input can fire dozens or hundreds of times per second. If you attach a costly function (like an API call or a complex DOM update) directly to these events, you’ll be trying to execute that function far more often than necessary, grinding your app to a halt.

Two related techniques solve this: debouncing and throttling. They are different, and choosing the right one matters.

Debouncing means, “Wait until this person has stopped doing this action for a bit, then respond.” It’s perfect for a search box. You don’t want to call the search API on every single keystroke. You want to wait until the user has paused typing for, say, 300 milliseconds.

Throttling means, “Only allow this function to run at most once every X milliseconds.” It’s perfect for a scroll handler that checks the user’s position. You might only need to check every 100ms, not for every pixel scrolled.

Here are implementations and examples of both.

// Debounce: Execute the function only after a pause in calls.
function debounce(func, waitMs) {
  let timeoutId;
  return function(...args) {
    // Clear the previous timer
    clearTimeout(timeoutId);
    // Set a new timer
    timeoutId = setTimeout(() => {
      func.apply(this, args);
    }, waitMs);
  };
}

// Throttle: Execute the function at most once per period.
function throttle(func, limitMs) {
  let lastCall = 0;
  return function(...args) {
    const now = Date.now();
    if (now - lastCall >= limitMs) {
      lastCall = now;
      func.apply(this, args);
    }
  };
}

// Usage examples:
const searchInput = document.getElementById('search');
const expensiveSearchAPI = (query) => { /* ... */ };

// Use debounce for search. Wait 350ms after the user stops typing.
const debouncedSearch = debounce(expensiveSearchAPI, 350);
searchInput.addEventListener('input', (e) => {
  debouncedSearch(e.target.value);
});

// Use throttle for a scroll-based button visibility check.
const checkScrollForButton = () => {
  if (window.scrollY > 500) {
    showBackToTopButton();
  }
};
const throttledScrollCheck = throttle(checkScrollForButton, 150);
window.addEventListener('scroll', throttledScrollCheck);

The seventh and final pattern is about not asking for the same thing twice. Caching is a fundamental concept in computing. In JavaScript applications, you can cache at different levels: in memory, in the browser’s localStorage or IndexedDB, or even at the network level using Service Workers.

A simple in-memory cache for API calls can prevent redundant network requests for data that doesn’t change often. You store the response keyed by the request URL (or parameters) and return the cached version if it exists and isn’t too old.

class SimpleAPICache {
  constructor(maxEntries = 50, timeToLiveMs = 5 * 60 * 1000) { // Default 5 minutes
    this.cache = new Map();
    this.maxEntries = maxEntries;
    this.ttl = timeToLiveMs;
  }

  set(key, data) {
    // Enforce a maximum cache size
    if (this.cache.size >= this.maxEntries) {
      const firstKey = this.cache.keys().next().value;
      this.cache.delete(firstKey);
    }
    this.cache.set(key, {
      data,
      timestamp: Date.now()
    });
  }

  get(key) {
    const entry = this.cache.get(key);
    if (!entry) {
      return null; // Cache miss
    }

    // Check if the entry has expired
    const isExpired = (Date.now() - entry.timestamp) > this.ttl;
    if (isExpired) {
      this.cache.delete(key);
      return null; // Treat as a miss if expired
    }

    return entry.data; // Cache hit!
  }

  clear() {
    this.cache.clear();
  }
}

// Using the cache with fetch
const apiCache = new SimpleAPICache();

async function fetchUserData(userId) {
  const url = `https://api.example.com/users/${userId}`;
  const cachedData = apiCache.get(url);

  if (cachedData) {
    console.log('Serving user data from cache');
    return cachedData;
  }

  console.log('Fetching user data from network');
  const response = await fetch(url);
  const data = await response.json();

  // Store it in the cache for next time
  apiCache.set(url, data);
  return data;
}

// First call will fetch from network
fetchUserData(123).then(data => console.log(data));

// A subsequent call for the same user within 5 minutes will use the cache
setTimeout(() => {
  fetchUserData(123).then(data => console.log(data)); // This will log "Serving from cache"
}, 2000);

For static assets like images, CSS, and JavaScript files, you can use a Service Worker to implement more advanced network caching strategies (like “Cache First” or “Network First”). This is the technology that enables Progressive Web Apps (PWAs) to work offline.

These seven patterns—code splitting, lazy loading, memoization, virtualization, web workers, debouncing/throttling, and caching—form a powerful foundation. Start by measuring your app’s performance using the browser’s DevTools, especially the Performance and Network panels. Find the biggest bottleneck, and apply the pattern that fits. Often, just one or two of these changes can make a world of difference. The goal is a smooth, responsive application that feels fast, no matter what your users are trying to do.