DEV Community: Aamir Jamal

5 React JS Tricks to Improve Site Speed and Efficiency in 2026

Aamir Jamal — Wed, 10 Jun 2026 09:45:32 +0000

A practical guide for frontend developers who want faster, leaner React apps - without the fluff.

Performance is no longer a "nice to have." With Core Web Vitals directly influencing SEO rankings and user retention dropping sharply after a 2-second load time, a slow React app is a business problem. The good news? React's ecosystem in 2026 gives us sharper tools than ever.

Here are five tricks that actually move the needle.

1. Stop Over-Rendering with `useMemo`, `useCallback`, and `memo` - But Actually Use Them Right

React developers often reach for useMemo and useCallback as a reflex, which ironically hurts performance due to the overhead of memoization on cheap computations. The trick in 2026 is being surgical about it.

The rule of thumb: memoize when the computation is expensive or when referential equality matters for downstream components.

// ❌ Pointless - this is cheaper to just run
const fullName = useMemo(() => `${first} ${last}`, [first, last]);

// ✅ Worth it - heavy computation, or passed to a memoized child
const sortedList = useMemo(
  () => largeArray.sort((a, b) => a.score - b.score),
  [largeArray]
);

const handleSubmit = useCallback(() => {
  processOrder(cart, userId);
}, [cart, userId]);

Pair these with React.memo() on child components that receive stable props, so they bail out of re-renders entirely:

const ProductCard = React.memo(({ product, onAddToCart }) => {
  return (
    <div>
      <h3>{product.name}</h3>
      <button onClick={onAddToCart}>Add to Cart</button>
    </div>
  );
});

Pro tip for 2026: Use the React DevTools Profiler's "Why did this render?" feature to identify which components are actually causing performance issues before you reach for memoization. Don't guess - measure.

2. Code Split Aggressively with `React.lazy` and Route-Based Chunking

Shipping your entire app in one bundle is one of the biggest performance sins a React developer can commit. With React's built-in lazy and Suspense, route-based code splitting is now trivial - yet many codebases still don't do it properly.

import { lazy, Suspense } from 'react';
import { Routes, Route } from 'react-router-dom';

// Each page is its own chunk - loaded only when the route is visited
const Dashboard = lazy(() => import('./pages/Dashboard'));
const Analytics = lazy(() => import('./pages/Analytics'));
const Settings = lazy(() => import('./pages/Settings'));

function App() {
  return (
    <Suspense fallback={<PageSkeleton />}>
      <Routes>
        <Route path="/dashboard" element={<Dashboard />} />
        <Route path="/analytics" element={<Analytics />} />
        <Route path="/settings" element={<Settings />} />
      </Routes>
    </Suspense>
  );
}

Go further by lazy-loading heavy components within pages - rich text editors, chart libraries, map integrations, and modals that aren't immediately visible on load are all excellent candidates:

const RichEditor = lazy(() => import('./components/RichEditor'));
const ChartPanel = lazy(() => import('./components/ChartPanel'));

// Only loads the bundle when the user clicks "Edit"
{isEditing && (
  <Suspense fallback={<EditorSkeleton />}>
    <RichEditor content={post.body} />
  </Suspense>
)}

2026 tip: If you're on Next.js (which most serious React projects are), use next/dynamic with ssr: false for client-heavy widgets to eliminate their server-side overhead entirely.

3. Virtualize Long Lists with `@tanstack/react-virtual`

If your app renders lists - product catalogs, transaction histories, data tables, chat threads - and you're not virtualizing them, you're rendering potentially thousands of DOM nodes that the user will never see. This tanks both initial paint time and scroll performance.

@tanstack/react-virtual (the successor to react-window) is the 2026 standard for this:

npm install @tanstack/react-virtual

import { useVirtualizer } from '@tanstack/react-virtual';
import { useRef } from 'react';

function ProductList({ products }) {
  const parentRef = useRef(null);

  const virtualizer = useVirtualizer({
    count: products.length,
    getScrollElement: () => parentRef.current,
    estimateSize: () => 80, // estimated row height in px
    overscan: 5,            // render 5 items outside the viewport for smooth scroll
  });

  return (
    <div ref={parentRef} style={{ height: '600px', overflow: 'auto' }}>
      <div style={{ height: `${virtualizer.getTotalSize()}px`, position: 'relative' }}>
        {virtualizer.getVirtualItems().map((virtualItem) => (
          <div
            key={virtualItem.key}
            style={{
              position: 'absolute',
              top: 0,
              left: 0,
              width: '100%',
              transform: `translateY(${virtualItem.start}px)`,
            }}
          >
            <ProductCard product={products[virtualItem.index]} />
          </div>
        ))}
      </div>
    </div>
  );
}

Instead of rendering 10,000 rows, the virtualizer renders only what's in the viewport - typically 10 to 20 items. The performance difference on a large dataset is not subtle; it's transformative.

When to use it: Any list with more than 100 items is a candidate. Any list with more than 500 items is a requirement.

4. Optimize State Architecture - Collocate State and Avoid Context Overuse

One of the most overlooked performance killers in React is poor state architecture. Specifically: storing everything in a top-level context or a giant global state causes the entire tree to re-render whenever anything changes.

The fix is state collocation - move state as close to where it's used as possible.

// ❌ Global context re-renders the entire app on every keystroke
const AppContext = createContext();

function App() {
  const [searchQuery, setSearchQuery] = useState('');
  // searchQuery change re-renders everything subscribed to AppContext
  return (
    <AppContext.Provider value={{ searchQuery, setSearchQuery }}>
      <Header />
      <Sidebar />
      <MainContent />
      <Footer />
    </AppContext.Provider>
  );
}

// ✅ Collocated - only SearchBar re-renders on keystroke
function SearchBar() {
  const [query, setQuery] = useState('');
  return <input value={query} onChange={e => setQuery(e.target.value)} />;
}

When you do need global state, split your contexts by domain so updates in one slice don't re-render consumers of another:

// Instead of one big AppContext, use domain-specific contexts
<AuthContext.Provider value={authState}>
  <CartContext.Provider value={cartState}>
    <ThemeContext.Provider value={themeState}>
      <App />
    </ThemeContext.Provider>
  </CartContext.Provider>
</AuthContext.Provider>

For serious apps in 2026, consider Zustand or Jotai over React Context for shared state. They're lightweight, selector-based (components only re-render when their specific slice changes), and have no provider boilerplate.

5. Defer Non-Critical Work with `useTransition` and `useDeferredValue`

React 18's Concurrent Features are widely available and still underutilized. useTransition and useDeferredValue let you tell React: "this update isn't urgent - keep the UI responsive and get to it when you can."

This is a game changer for search inputs, filter UIs, and heavy data transformations.

useDeferredValue - for expensive renders triggered by fast-changing input:

import { useDeferredValue, useState } from 'react';

function SearchPage({ allProducts }) {
  const [query, setQuery] = useState('');
  const deferredQuery = useDeferredValue(query);

  // This filter runs on the deferred value - the input stays snappy
  const filteredProducts = allProducts.filter(p =>
    p.name.toLowerCase().includes(deferredQuery.toLowerCase())
  );

  return (
    <>
      <input
        value={query}
        onChange={e => setQuery(e.target.value)}
        placeholder="Search products..."
      />
      {/* filteredProducts uses deferredQuery, so the list update is non-blocking */}
      <ProductList products={filteredProducts} />
    </>
  );
}

useTransition - for marking state updates as non-urgent (e.g., tab switching, heavy page transitions):

import { useTransition, useState } from 'react';

function TabView({ tabs }) {
  const [activeTab, setActiveTab] = useState(tabs[0]);
  const [isPending, startTransition] = useTransition();

  function handleTabChange(tab) {
    startTransition(() => {
      setActiveTab(tab); // React can interrupt this if the user does something more urgent
    });
  }

  return (
    <div>
      <nav>
        {tabs.map(tab => (
          <button key={tab.id} onClick={() => handleTabChange(tab)}>
            {tab.label}
          </button>
        ))}
      </nav>
      {isPending ? <LoadingSpinner /> : <TabContent tab={activeTab} />}
    </div>
  );
}

The key insight: by marking the tab switch as a transition, React won't freeze the UI while the new tab renders. If the user clicks another tab immediately, React will abandon the previous render and start the new one. This is fundamentally different from anything you could do in React 17 or earlier.

Wrapping Up

These five tricks address the most common performance bottlenecks in real-world React apps in 2026:

Trick	What It Solves
Surgical memoization	Unnecessary re-renders
Code splitting	Bloated initial bundle
List virtualization	DOM overload on long lists
State collocation	Context-triggered cascading re-renders
Concurrent Features	UI blocking on expensive updates

Performance optimization is an iterative process. The best workflow is: measure with DevTools → identify the actual bottleneck → apply the right fix → measure again. Don't pre-optimize, but don't ignore the data either.

Ship fast. Iterate faster.

Found this helpful? Share it with your team. React performance is a team sport.

How I Automated Template based Mobile App Creation With a Single CLI Command

Aamir Jamal — Sat, 06 Jun 2026 15:26:28 +0000

As developers, we love building features.

What we don't enjoy is spending hours setting up the same project for the tenth time.

At my company, every new React Native project followed a familiar pattern:

Create the application
Configure TypeScript
Install dependencies
Set up Firebase
Configure environment variables
Add Fastlane
Configure CI/CD
Create the project structure
Add shared utilities and configurations

None of these tasks were difficult, but they were repetitive.

After creating multiple applications and following the same setup checklist over and over, I started asking myself a simple question:

Why are we manually doing work that can be automated?

That question led me to build CAM (Custom App Manager) — a CLI tool that can create and configure a production-ready mobile application with a single command.

cam create-app MyApp

In this article, I'll walk through how I built it and the tools that made it possible.

The Problem

Every team eventually develops its own preferred architecture and setup process.

The challenge is ensuring every developer follows it consistently.

For us, creating a new application meant:

npx react-native init MyApp

# Install dependencies
npm install @react-navigation/native
npm install axios
npm install react-query

# Configure Firebase

# Create environment files

# Setup Fastlane

# Configure CI/CD

# Create folder structure

Even with documentation, the process was:

Time-consuming
Error-prone
Difficult for new developers
Inconsistent across projects

I wanted a solution that would convert our setup documentation into executable code.

Introducing CAM (Custom App Manager)

CAM is an internal CLI tool that automates mobile app creation and configuration.

Instead of spending hours setting up a project, developers simply run:

cam create-app MyApp

CAM then:

Creates the project
Installs dependencies
Generates folder structures
Configures Firebase
Creates environment files
Adds Fastlane configuration
Applies company standards
Sets up CI/CD templates

The goal was simple:

Move developers from setup mode to feature development as quickly as possible.

Building The CLI

Command Parsing With Commander.js

The first requirement was creating custom commands.

I used Commander.js to build the command-line interface.

import { Command } from 'commander';

const program = new Command();

program
  .command('create-app <name>')
  .description('Create a new application')
  .action((name) => {
    console.log(`Creating ${name}`);
  });

program.parse();

This allowed CAM to support commands such as:

cam create-app MyApp
cam upgrade
cam configure-firebase
cam setup-fastlane

Commander handles argument parsing, validation, help menus, and command organization.

Interactive Setup With Inquirer

Not every application requires the same configuration.

To make CAM flexible, I used Inquirer.js for interactive prompts.

import inquirer from 'inquirer';

const answers = await inquirer.prompt([
  {
    type: 'confirm',
    name: 'firebase',
    message: 'Enable Firebase?'
  }
]);

This allows developers to customize their projects during creation.

Examples:

Enable Firebase?
Configure Analytics?
Include Push Notifications?
Setup Fastlane?

Based on the answers, CAM adjusts the generated project.

File Management With fs-extra

A large portion of CAM's functionality involves generating files and copying templates.

For this, I used fs-extra.

import fs from 'fs-extra';

await fs.copy(
  './templates/react-native-base',
  './MyApp'
);

This library simplifies:

Copying directories
Creating folders
Updating configuration files
Managing templates

Running Shell Commands With child_process

Project setup often requires executing external commands.

Examples:

npm install
pod install
fastlane init

Node's child_process module allows CAM to execute these commands programmatically.

import { execSync } from 'child_process';

execSync(
  'npm install',
  { stdio: 'inherit' }
);

This became the orchestration layer that ties everything together.

Template-Based Project Generation

One of the best decisions I made was using templates instead of generating files from scratch.

The CLI maintains a collection of project templates:

templates/
├── react-native-base/
├── firebase-enabled/
├── analytics-enabled/
├── fastlane-config/
└── enterprise-template/

When a developer runs:

cam create-app MyApp

CAM selects the appropriate templates and customizes them with project-specific values.

This approach makes maintenance significantly easier because templates can evolve independently.

Automating Firebase Configuration

Firebase setup was one of the most repetitive parts of every project.

CAM automates:

Package installation
Environment setup
Firebase initialization
Boilerplate service creation
Configuration file placement

Instead of following lengthy setup documentation, developers answer a few prompts and continue building features.

Environment Management

Almost every project needs multiple environments.

Typically:

.env.dev
.env.qa
.env.stage
.env.prod

CAM generates these automatically and injects the required configuration values.

This reduces setup mistakes and keeps environments consistent across applications.

Fastlane Integration

Another recurring task was configuring deployment pipelines.

CAM can generate Fastlane configurations for:

Android builds
iOS builds
Beta deployments
Store releases

Instead of manually creating lanes for every new project, developers start with a standardized configuration.

CI/CD Automation

Since our projects use automated pipelines, CAM also generates CI/CD templates.

This includes:

Build workflows
Environment configuration
Test execution steps
Deployment templates

A newly created project is immediately ready for automation.

Standardizing Architecture

The original goal was saving time.

The biggest benefit turned out to be consistency.

Every generated project follows the same structure:

src/
├── components/
├── screens/
├── hooks/
├── services/
├── navigation/
├── utils/
├── assets/
└── constants/

Benefits include:

Easier onboarding
Faster code reviews
Predictable project organization
Reduced technical debt

Developers no longer debate where code should live because every project starts from the same foundation.

Lessons Learned

1. Repetition Is A Signal

If you find yourself following the same setup checklist repeatedly, it's probably a candidate for automation.

2. Templates Scale Better Than Generators

Copying and customizing templates is often easier to maintain than generating every file programmatically.

3. Consistency Is More Valuable Than Speed

The time savings were great.

The real value came from ensuring every project followed the same standards from day one.

4. Start Small

The first version of CAM automated only a handful of tasks.

Over time it evolved to include:

Project creation
Firebase setup
Environment management
Fastlane integration
CI/CD templates
Dependency installation

Automation compounds over time.

What's Next?

Future improvements include:

Automatic Firebase project provisioning
Store configuration automation
Dependency upgrade management
Automated test setup
Playwright and E2E testing configuration

The long-term goal is to make project creation nearly effortless.

Final Thoughts

CAM started as a side project to eliminate repetitive setup work.

It eventually became a way to standardize how mobile applications are built across the organization.

What once required dozens of commands, configuration steps, and setup guides can now be accomplished with:

cam create-app MyApp

The result is faster onboarding, fewer setup mistakes, and a more consistent development experience for everyone involved.

If your team keeps rebuilding the same foundation for every project, consider investing time in a custom CLI. It might be one of the highest-leverage tools you build.