But they usually don't tell you the next info you need as a developer: What should I ask my coding agent to change?

AI coding agents can help you fix performance issues, but they need clear context. If you type "make this site faster", you'll often get broad advice. If you give the agent the metric, the affected resource, the likely cause, and the files to inspect first, you have a much better chance of getting a useful patch.

In this tutorial, you'll learn how to turn a browser performance finding into a structured AI fix prompt. You'll also see how to add a "Copy AI fix prompt" button to a Chrome DevTools extension.

I'll use PerfLens, a Chrome DevTools extension I built, as the example. But the same pattern works with any tool that can collect performance data.

What You Will Build

You'll build a small pipeline that looks like this:

Performance finding
  -> Structured issue object
  -> AI fix prompt
  -> Clipboard
  -> Coding agent
  -> Code change
  -> Re-run audit

By the end, you will have:

• A Finding type for storing audit results

• A prompt builder function

• A copy-to-clipboard function

• A DevTools panel button that copies the generated prompt

• A simple way to verify whether the fix worked

Prerequisites

To follow along, you should understand:

• Basic JavaScript or TypeScript

• Basic browser extension concepts

• How Chrome DevTools panels work at a high level

• How to use an AI coding agent such as Cursor, Claude Code, GitHub Copilot, or a similar tool

You don't need to build a full performance auditing engine for this tutorial. The focus is the handoff between a performance tool and a coding agent.

Table of Contents

• Why Performance Reports Are Hard to Turn into Code Changes

• What an AI Fix Prompt Should Include

• How to Store a Performance Finding as Structured Data

• How to Choose the Most Important Finding

• How to Build the AI Fix Prompt

• How to Copy the Prompt to the Clipboard

• How to Add the Button to a DevTools Panel

• How to Verify the Fix

• How This Fits Alongside Lighthouse

• Conclusion

Why Performance Reports Are Hard to Turn into Code Changes

A performance score is a symptom. For example, a report might say:

Largest Contentful Paint: 4.2 seconds

That number matters, but it doesn't tell you where the fix lives.

The cause might be:

• A large hero image

• A render-blocking script

• Too much JavaScript on the initial route

• A slow API request

• Missing image dimensions that cause layout shift

As a developer, you usually have to translate the report into a code-level task.

That translation step takes time. It's also the step where a coding agent can help most, if you give it enough context.

Instead of asking your agent to "make the site faster", you can give it a focused brief:

The homepage has a 258.1 KB image affecting load performance.
Inspect the hero section and image component first.
Resize or compress the image without changing the layout.
Then explain how to verify the improvement.

This is easier for the agent to act on because it points to one specific problem.

What an AI Fix Prompt Should Include

A good AI fix prompt should read like a short engineering brief.

It should include:

• The performance problem

• The measured evidence

• The affected page or resource

• The likely cause

• The files or patterns to inspect first

• A recommended fix

• Constraints for the change

• Verification steps

Here is an example prompt:

You are helping optimize a Next.js app in a production build.

Problem: Image is 258.1 KB and may be slowing down the page.
Evidence: Image size = 258.1 KB
Page: http://localhost:3000
Affected resource: http://localhost:3000/_next/image?url=%2Fhome%2Four_story.webp&w=3840&q=75

Likely cause:
The page is loading an image that is larger than needed for its rendered size.

Inspect first:
- app/page.tsx or pages/index.tsx
- components/**/*.{tsx,jsx}
- next.config.js
- the hero section or image component

Recommended fix:
Resize or compress the image, use an appropriate modern format, and keep explicit width and height values so the layout does not shift.

Constraints:
- Keep the change local to the route or component causing the issue.
- Do not add a new dependency unless there is no reasonable alternative.
- Explain the change before applying it.

After the change:
- Re-run the performance audit.
- Confirm the image transfer size is lower.
- Confirm the layout still looks correct.

This prompt is specific. It tells the agent what happened, where to look, what to change, and how to check the result.

That's the core idea behind an AI patch brief.

Here is what that looks like inside PerfLens. A single performance finding is rendered as an AI patch brief, with the measured value, the affected resource, and the generated prompt gathered in one place. The "Copy AI fix prompt" button then hands the whole brief off to your coding agent in one click.

How to Store a Performance Finding as Structured Data

Before you can build a prompt, you need to store the performance issue as data.

Here is a simple TypeScript type:

type Finding = {
  id: string;
  title: string;
  metric: string;
  measured: string;
  budget?: string;
  resource?: string;
  likelyCause: string;
  recommendedFix: string;
  inspectFirst: string[];
  severity: "low" | "medium" | "high";
};

Each field has a job:

• id identifies the type of issue.

• title gives the human-readable summary.

• metric names the measurement.

• measured stores the actual value.

• budget stores the target value, if you have one.

• resource stores the affected URL, file, or asset.

• likelyCause explains why the issue may be happening.

• recommendedFix gives the agent a direction.

• inspectFirst points the agent toward likely files.

• severity helps you decide what to show first.

Here is an example finding for an oversized image:

const finding: Finding = {
  id: "image-weight",
  title: "Image is 258.1 KB and may be slowing down the page",
  metric: "Image size",
  measured: "258.1 KB",
  resource: "http://localhost:3000/_next/image?url=%2Fhome%2Four_story.webp&w=3840&q=75",
  likelyCause:
    "The page is loading an image that is larger than needed for its rendered size.",
  recommendedFix:
    "Resize or compress the image, use an appropriate modern format, and keep explicit width and height values.",
  inspectFirst: [
    "app/page.tsx or pages/index.tsx",
    "components/**/*.{tsx,jsx}",
    "next.config.js",
    "the hero section or image component",
  ],
  severity: "high",
};

At this stage, you aren't doing anything with AI yet. You're only turning a performance result into a clean object.

That object gives you something reliable to transform into a prompt later.

How to Choose the Most Important Finding

You should avoid sending ten unrelated performance issues to an agent at once.

A large prompt with many issues can lead to a large patch. That makes the result harder to review.

A better approach is to generate one prompt per finding.

You can start with a simple severity score:

function scoreFinding(finding: Finding): number {
  const severityWeight = {
    low: 1,
    medium: 2,
    high: 3,
  };

  return severityWeight[finding.severity];
}

Then you can sort findings by score:

function sortFindings(findings: Finding[]): Finding[] {
  return [...findings].sort(
    (a, b) => scoreFinding(b) - scoreFinding(a)
  );
}

This is a simple version, but it's enough to get started.

Later, you can improve the score by considering:

• How far the metric is over budget

• Whether the issue affects Largest Contentful Paint

• Whether the issue affects layout shift or interaction delay

• Whether the affected resource is part of the first page load

• How confident you are in the recommended fix

The goal isn't to create a perfect scoring system. The goal is to help you focus on one high-impact issue at a time.

How to Build the AI Fix Prompt

Once you have a Finding, building the prompt becomes a string formatting task.

You also need a small amount of page context:

type PageContext = {
  framework: string;
  mode: string;
  pageUrl: string;
};

Page context is a few facts about the page the finding came from: the framework the app uses, whether it's a development or production build, and the URL being audited.

The finding tells the agent what is slow. The page context tells it where the fix will land and how the code is built. This matters because the same problem is fixed differently from one stack to the next. An oversized image is handled through next/image and next.config.js in Next.js, but through other files and conventions elsewhere. The mode field also hints whether production optimizations should already be in place.

Giving the agent this up front means it spends less effort guessing about your setup and more on the actual fix.

Then you can create a prompt builder:

function buildFixPrompt(finding: Finding, ctx: PageContext): string {
  const lines = [
    "You are helping optimize a " + ctx.framework + " app in a " + ctx.mode + " build.",
    "",
    "Problem: " + finding.title,
    "Evidence: " + finding.metric + " = " + finding.measured +
      (finding.budget ? " (budget: " + finding.budget + ")" : ""),
    "Page: " + ctx.pageUrl,
  ];

  if (finding.resource) {
    lines.push("Affected resource: " + finding.resource);
  }

  lines.push(
    "",
    "Likely cause:",
    finding.likelyCause,
    "",
    "Inspect first:",
    ...finding.inspectFirst.map((file) => "- " + file),
    "",
    "Recommended fix:",
    finding.recommendedFix,
    "",
    "Constraints:",
    "- Keep the change local to the route or component causing the measured cost.",
    "- Do not add new dependencies unless there is no reasonable alternative.",
    "- Explain the change before applying it.",
    "",
    "After the change:",
    "- Re-run the performance audit.",
    "- Confirm the measured issue improved.",
    "- Check that the UI still works correctly.",
  );

  return lines.join("\n");
}

You can call it like this:

const pageContext: PageContext = {
  framework: "Next.js",
  mode: "production",
  pageUrl: "http://localhost:3000",
};

const prompt = buildFixPrompt(finding, pageContext);

The output is a prompt you can paste into a coding agent.

The framework field is especially useful. If the agent knows the app uses Next.js, it can look for files such as app/page.tsx, pages/index.tsx, next.config.js, and image usage through next/image.

How to Copy the Prompt to the Clipboard

The safest integration is clipboard-first.

Many coding agents and editors support different launch methods. Some support deep links. Some run in the terminal. Some live inside an editor. But every agent can accept pasted text.

Here's a small copy function:

async function copyPrompt(prompt: string): Promise<void> {
  await navigator.clipboard.writeText(prompt);
}

In a browser extension UI, call this from a user action such as a button click:

copyButton.addEventListener("click", async () => {
  const prompt = buildFixPrompt(finding, pageContext);

  await copyPrompt(prompt);

  copyButton.textContent = "Prompt copied";
});

You can also try to open an editor after copying the prompt:

type AgentTarget = "cursor" | "vscode" | "copy-only";

async function sendToAgent(
  prompt: string,
  target: AgentTarget
): Promise<void> {
  await navigator.clipboard.writeText(prompt);

  if (target === "cursor") {
    window.location.href = "cursor://";
    return;
  }

  if (target === "vscode") {
    window.location.href = "vscode://";
    return;
  }
}

This doesn't paste the prompt into the agent automatically. It only copies the prompt and tries to open the selected tool.

That is a useful limitation. It keeps the workflow predictable and lets you review the prompt before sending it.

How to Add the Button to a DevTools Panel

If you build this into a Chrome extension, you can expose it inside a DevTools panel.

First, register a DevTools page in your manifest.json file:

{
  "manifest_version": 3,
  "name": "PerfLens",
  "version": "1.0.0",
  "devtools_page": "devtools.html",
  "permissions": ["clipboardWrite", "activeTab", "scripting"]
}

Then create the panel from your DevTools script:

chrome.devtools.panels.create(
  "PerfLens",
  "icons/icon-32.png",
  "panel.html"
);

Inside the panel, render each finding with a button:

function renderFinding(
  finding: Finding,
  ctx: PageContext
): HTMLElement {
  const item = document.createElement("article");
  const title = document.createElement("h3");
  const button = document.createElement("button");

  title.textContent = finding.title;
  button.textContent = "Copy AI fix prompt";

  button.addEventListener("click", async () => {
    const prompt = buildFixPrompt(finding, ctx);

    await sendToAgent(prompt, "copy-only");

    button.textContent = "Prompt copied";
  });

  item.append(title, button);

  return item;
}

The important part is the button handler.

When you click the button, your extension:

1. Builds a prompt from the performance finding.

2. Copies the prompt to the clipboard.

3. Shows feedback that the prompt was copied.

You can then paste the prompt into your coding agent and review the suggested patch.

How to Verify the Fix

An AI-generated patch is only useful if the metric improves.

After the agent suggests a change, you should:

1. Review the code diff.

2. Run the app locally.

3. Reload the page.

4. Re-run the performance audit.

5. Compare the new measurement with the original one.

For the image example, you would check:

• Did the image transfer size go down?

• Does the image still look sharp enough?

• Did the page layout stay stable?

• Did Largest Contentful Paint improve?

• Did the change affect any other route?

This creates a simple loop:

Measure -> Prompt -> Patch -> Measure again

You shouldn't treat the agent's answer as the final authority. The browser measurement is the final authority.

How This Fits Alongside Lighthouse

Lighthouse is still useful. It gives you a detailed lab audit and a consistent score. This workflow solves a different problem.

Lighthouse helps you answer:

How does this page perform under controlled conditions?

An AI patch brief helps you answer:

What should I ask my coding agent to fix right now?

You can use both.

Use Lighthouse for scoring, regression tracking, and deeper audits. Use an AI prompt workflow when you want to move from a specific finding to a code change faster.

A Note on Privacy

AI fix prompts can include URLs, resource names, routes, filenames, and implementation details.

Before you paste a prompt into a cloud-based coding agent, check that it doesn't include:

• Access tokens

• Private customer data

• Internal URLs you can't share

• Secrets from environment variables

• Sensitive logs

Keep the prompt focused on the performance issue. Give the agent enough context to help, but not more than it needs.

Conclusion

In this tutorial, you learned how to turn a performance audit finding into an AI fix prompt.

You created:

• A structured Finding type

• A way to rank findings

• A buildFixPrompt function

• A clipboard-first agent handoff

• A DevTools panel button

• A verification loop for checking the result

The main idea is simple: performance tools produce evidence, and coding agents need context. A good AI patch brief connects the two.

PerfLens is one example of this workflow. If you want to try the extension or inspect how it implements this flow, you can find it here:

• Chrome Web Store: PerfLens

• Source code: GitHub

Some preferred React. Others chose Vue, Angular, Svelte, or server-side frameworks such as Laravel and Django.

Entire conferences, blogs, and social media discussions have been dedicated to comparing frameworks and programming languages.

In 2026, those debates matter less than many developers think.

A modern website can be built with almost any mature framework and still perform well. The bigger challenge is making sure people can actually find, trust, and use that website.

Discoverability, performance, infrastructure, structured data, and AI search visibility now have a greater impact on success than the choice between competing frontend libraries.

The websites that win today aren't necessarily built with the most fashionable technologies. They're built with a strong foundation that helps users and search systems understand, access, and trust their content.

In this article, we'll look at what really matters when building a website these days. We'll explore why performance, hosting, domain management, structured data, and content quality often have a bigger impact than the technology stack itself.

We'll also examine how AI-powered search is changing the way people find information online and what developers can do to improve their website's visibility.

What We'll Cover:

• The Tech Stack Has Become a Commodity

• Performance Is Still a Competitive Advantage

• Domains and Infrastructure Still Matter

• Hosting Is No Longer Just About Servers

• Structured Data Has Become Essential

• The Rise of AI Search and Answer Engines

• Content Quality Is More Important Than Ever

• User Experience Is the New Differentiator

• The Future Is About Outcomes, Not Frameworks

The Tech Stack Has Become a Commodity

The web development ecosystem has matured significantly over the past decade. Most modern frameworks provide similar capabilities. They support component-based development, server-side rendering, API integrations, authentication systems, and performance optimization.

As a result, the gap between frameworks has narrowed.

A poorly optimized website built with the latest framework will often perform worse than a well-optimized website built with older technology. Users rarely care whether a page was built with React, Vue, or another framework. They care whether it loads quickly, works on mobile devices, and provides useful information.

Businesses care even more about outcomes. They want traffic, conversions, customer engagement, and revenue growth. None of those metrics improve simply because a team adopted a trendy technology stack.

This shift has forced development teams to focus on factors that have a direct impact on visibility and user experience.

Performance Is Still a Competitive Advantage

Despite advances in hosting and frontend tooling, website performance remains one of the strongest predictors of user satisfaction.

Research consistently shows that slower websites lead to higher bounce rates and lower conversion rates. Users expect pages to load almost instantly. Even a delay of a few seconds can cause visitors to abandon a website before interacting with its content.

Modern performance optimisation goes beyond minimising JavaScript bundles. Teams must consider image optimisation, edge caching, content delivery networks, lazy loading, and server response times.

For example, an e-commerce website might reduce page load times by serving product images in modern formats such as WebP, implementing lazy loading for below-the-fold content, and using a CDN to deliver assets from locations closer to shoppers. These improvements often produce a more noticeable impact than migrating to a new frontend framework.

Many websites spend months migrating between frameworks while ignoring performance bottlenecks that would have a much larger impact on user experience. In practice, improving page speed often delivers greater business value than rebuilding an application using a different frontend stack.

Performance has also become increasingly important for search visibility. Search engines reward websites that provide a fast and reliable user experience. A technically impressive website that loads slowly is unlikely to achieve its full potential.

Domains and Infrastructure Still Matter

Developers often focus on application code while overlooking the infrastructure that supports it.

A website's domain remains one of its most important digital assets. Domain management affects security, reliability, and long-term brand ownership. Choosing a reputable registrar and maintaining proper DNS configuration are critical responsibilities.

A simple example is setting up DNS failover and enabling registrar-level security features such as domain lock and two-factor authentication. These measures help prevent outages and unauthorised domain transfers that could take a website offline.

For many teams, services such as Namecheap and GoDaddy provide a straightforward way to manage domain registration, DNS records, SSL certificates, and related infrastructure. While these tasks may seem mundane compared to application development, they directly influence website availability and security.

DNS performance has become particularly important as websites adopt distributed architectures. Modern applications frequently rely on multiple services, APIs, content delivery networks, and edge platforms. A poorly configured DNS setup can introduce unnecessary latency and create reliability issues.

Infrastructure decisions also influence scalability. As traffic grows, websites must continue delivering fast and consistent experiences without requiring major architectural changes.

The most successful development teams treat infrastructure as a strategic asset rather than an afterthought.

Hosting Is No Longer Just About Servers

In the past, hosting primarily involved renting a server and deploying application code.

Today, hosting platforms offer far more than compute resources. They provide global content delivery networks, automatic scaling, integrated security features, observability tools, and deployment automation.

The rise of edge computing has changed how websites are delivered. Content can now be served from locations close to users, reducing latency and improving responsiveness.

A media website experiencing a sudden traffic spike after a story goes viral can benefit from automatic scaling and edge caching, maintaining fast load times without requiring engineers to provision additional infrastructure manually.

Modern hosting decisions affect everything from performance and reliability to search rankings and customer satisfaction.

This means developers should evaluate hosting providers based on outcomes rather than specifications. Raw server resources matter less than factors such as uptime, deployment speed, geographic distribution, and operational simplicity.

A website that remains available during traffic spikes creates a better user experience than one that struggles under load, regardless of the underlying technology stack.

Structured Data Has Become Essential

One of the most overlooked aspects of modern website development is structured data.

Search engines and AI systems increasingly rely on structured information to understand website content. Schema markup helps machines identify products, articles, organisations, events, reviews, and many other types of information.

For instance, an online store can use a Product schema to display pricing and availability information in search results. At the same time, a recipe website can implement a Recipe schema to surface cooking times, ratings, and ingredients directly within search experiences.

Without structured data, websites force search systems to infer meaning from unstructured text. This increases the likelihood of misinterpretation.

Structured data improves the chances that content will appear in rich search results, featured snippets, knowledge panels, and other enhanced search experiences.

More importantly, structured data provides context that helps emerging AI systems understand content accurately.

As search evolves beyond traditional blue links, machine-readable information becomes increasingly valuable.

Developers who ignore structured data risk making their websites less visible, even if the content itself is excellent.

The Rise of AI Search and Answer Engines

Perhaps the biggest shift in website visibility is the growth of AI-powered search experiences.

Users increasingly ask questions directly to AI assistants rather than typing keywords into traditional search engines. These systems generate answers by combining information from multiple sources and presenting results in a conversational format.

This change creates new challenges for website owners.

Ranking on Google is no longer the only goal. Websites must also be structured in ways that help AI systems understand, retrieve, and reference their content.

A software company publishing detailed comparison guides, implementation tutorials, and clearly structured FAQs is more likely to be cited in AI-generated responses than a competitor relying solely on promotional landing pages.

This is where Answer Engine Optimisation (AEO) is becoming important. Unlike traditional SEO, which focuses on improving rankings in search results, AEO focuses on increasing the likelihood that content will be selected, cited, or referenced within AI-generated responses.

AI-powered search systems evaluate content differently from traditional search engines. Rather than simply matching keywords, they attempt to identify sources that provide clear explanations, authoritative information, and direct answers to user questions. Content that is well structured, factually accurate, and easy to interpret tends to perform better in these environments.

Platforms such as DirJournal, an answer engine optimisation platform, help businesses understand how their content appears across AI-driven search environments. As teams adapt to changing search behaviour, they're increasingly monitoring not only search rankings but also the frequency with which AI systems reference their brands, products, and expertise.

The websites that succeed in this environment are often those that publish clear, authoritative content supported by strong technical foundations.

In many cases, the same practices that improve traditional SEO also support AI discoverability. Fast websites, structured data, authoritative content, and clear information architecture all contribute to better visibility.

Content Quality Is More Important Than Ever

Technology can improve delivery, but content remains the primary reason users visit a website.

AI systems are becoming increasingly effective at identifying expertise, authority, and relevance. Thin content designed solely for search rankings is becoming less effective.

Modern websites must provide genuine value. They need original insights, practical examples, clear explanations, and trustworthy information.

For example, a cybersecurity vendor might publish original research on emerging threats, while a healthcare provider could create evidence-based patient guides reviewed by medical professionals. Content grounded in expertise tends to earn greater trust and visibility.

Developers building content-driven websites should think beyond page views and rankings. The goal is to create resources that answer real questions and solve real problems.

Content that demonstrates expertise is more likely to earn links, generate engagement, and be referenced by both search engines and AI systems.

The websites that stand out now are those that prioritize usefulness over optimization tricks.

User Experience Is the New Differentiator

As technology becomes more accessible, user experience becomes a larger competitive advantage.

Visitors expect intuitive navigation, accessible interfaces, responsive layouts, and consistent performance across devices.

Simple improvements such as reducing the number of checkout steps, increasing button sizes on mobile devices, or ensuring keyboard navigation works correctly can significantly improve usability and conversion rates.

Poor user experiences create friction that drives users away regardless of how advanced the underlying technology may be.

Accessibility deserves particular attention. Websites should be usable by people with diverse abilities and assistive technologies. Accessibility improvements often enhance usability for all visitors while supporting compliance requirements.

The best websites combine technical excellence with thoughtful design. They remove obstacles and help users accomplish their goals quickly and efficiently.

The Future Is About Outcomes, Not Frameworks

The web development industry has reached a point where most modern frameworks are capable of delivering excellent results.

The real challenge is no longer choosing the perfect technology stack.

Success depends on building websites that are fast, discoverable, reliable, secure, and understandable to both humans and machines. Performance optimization, domain management, hosting strategy, structured data, content quality, and AI search visibility now play a larger role in determining outcomes.

These days, the websites that succeed aren't necessarily built with the newest technologies. They're built with the strongest foundations.

Developers who focus on those foundations will create websites that continue to perform well regardless of how search engines, AI systems, or frontend frameworks evolve in the years ahead.

Hope you enjoyed this article. You can connect with me on LinkedIn.

Then traffic climbs. A campaign over-performs. A marketplace onboards a popular seller. A SaaS product signs a couple of enterprise accounts.

Suddenly, /dashboard takes two seconds instead of 300 milliseconds. Queue jobs that used to clear in seconds sit waiting for minutes. You have database CPU spikes every afternoon.

So you add another app server, and response time barely moves because the real culprit was a slow query on a large table all along.

If you have run Laravel in production, you've probably lived some version of this. The good news is that scaling Laravel almost never means abandoning the framework. It means learning where pressure builds and making the application behave predictably under load.

In this guide, you'll learn how to find common bottlenecks, tune the database, use Redis effectively, move slow work onto queues, optimize APIs, and monitor a Laravel application in production.

None of this requires a single heroic rewrite. The biggest wins usually come from practical work: removing inefficient queries, pushing slow tasks onto queues, adding the right indexes, caching carefully chosen data, and measuring whether each change actually helped.

Prerequisites

You'll get the most out of this guide if you're already comfortable with:

• Building applications with Laravel and PHP

• Writing Eloquent queries and database migrations

• Using queues, jobs, and scheduled commands

• Reading a basic database query plan

• Deploying Laravel to a production server or platform

• Working with Redis and either MySQL or PostgreSQL in a production-like setup

Table of Contents

• What Happens When Laravel Apps Start Growing

• Common Laravel Bottlenecks

• How to Optimize the Database

• How to Scale with Redis

• How to Use Queue-Driven Architectures

• How to Optimize API Performance

• How to Monitor Laravel in Production

• An Example High-Traffic Laravel Architecture

• Lessons Learned the Hard Way

• A Pre-Launch Scaling Checklist

• Conclusion

• References

What Happens When Laravel Apps Start Growing

Traffic changes a system's behavior because it turns small inefficiencies into permanent costs. A query that takes 80 milliseconds is harmless when it runs a few hundred times an hour. Run it 30 times per page view on a page that gets thousands of hits a minute, and that same query becomes a capacity problem.

The pressure tends to show up in predictable places. More requests mean more PHP workers, more database connections, more queue volume, and more Redis operations.

The database, whether MySQL or PostgreSQL, is usually the first thing to buckle. Queues back up when work is created faster than workers can drain it. Caches only help when hit rates stay high and misses stay controlled. And scaling everything horizontally can turn sloppy code into an expensive cloud bill.

That's why scaling work has to start with measurement, not guesswork. Before you change anything, you want to know what is actually saturated: request CPU, database I/O, lock contention, Redis latency, queue depth, an external API, or oversized payloads.

A typical request in a growing Laravel app travels through several layers. The user sends a request, a load balancer routes it to an app server, and Laravel checks Redis for a cached result. On a miss, it queries the database, stores the computed result back in Redis, and hands any slow follow-up work to a queue. A worker picks up that job later while Laravel returns the response right away.

Here's the important part: adding more app servers does nothing for a slow query, a missing index, or an overloaded queue. Horizontal scaling only pays off once the shared dependencies behind those servers can keep up.

Common Laravel Bottlenecks

Laravel itself causes very few scaling problems. Most issues come from how application code talks to the database, the network, and background workers.

N+1 Queries

The classic offender is the N+1 query. You load a list of models, then lazily touch a relationship on each one:

use App\Models\Post;

$posts = Post::latest()->take(50)->get();

foreach (\(posts as \)post) {
    echo $post->author->name;
}

That's one query for the posts plus one query per author: 51 queries for a single page. Eager load the relationship instead:

use App\Models\Post;

$posts = Post::with('author')
    ->latest()
    ->take(50)
    ->get();

foreach (\(posts as \)post) {
    echo $post->author->name;
}

In production, these are sneaky. They often hide inside API Resources, Blade components, and authorization checks, where the relationship access isn't obvious from the controller.

Missing Indexes

Adding an index is one of the highest-return fixes you can make. Take a query like this:

\(orders = Order::where('account_id', \)accountId)
    ->where('status', 'paid')
    ->whereBetween('created_at', [\(start, \)end])
    ->latest()
    ->paginate(50);

If orders has millions of rows and no useful compound index, the database scans far more rows than it needs to. Add an index that matches how you actually query:

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

return new class extends Migration {
    public function up(): void
    {
        Schema::table('orders', function (Blueprint $table) {
            $table->index(['account_id', 'status', 'created_at']);
        });
    }

    public function down(): void
    {
        Schema::table('orders', function (Blueprint $table) {
            $table->dropIndex(['account_id', 'status', 'created_at']);
        });
    }
};

Indexes aren't free, though. They take up space and slow down writes. Add them for real, repeated query patterns, not for every column that ever appears in a where clause.

Inefficient Eager Loading

You can also swing too far the other way. Loading every relationship "just in case" burns memory and ships data the request never uses:

$users = User::with([
    'profile',
    'teams',
    'roles.permissions',
    'invoices.lineItems.product',
])->get();

That might be fine for an admin detail page showing one user. On a list page, it's a liability. Constrain the eager loads and select only the columns you need:

$users = User::query()
    ->select(['id', 'name', 'email'])
    ->with([
        'profile:id,user_id,avatar_url',
        'teams:id,name',
    ])
    ->latest()
    ->paginate(25);

One caveat: tightly scoped select lists can break later code that expects a column you didn't load. Keep this technique close to read-heavy endpoints where the payoff is obvious.

Synchronous Processing

High-traffic apps need short web requests. Sending email, generating PDFs, calling third-party APIs, resizing images, and building exports usually belong outside the request cycle. This version can hurt you:

public function store(Request $request)
{
    \(order = Order::create(\)request->validated());

    Mail::to(\(order->user)->send(new OrderReceipt(\)order));

    return response()->json($order, 201);
}

Push the work onto a queue instead:

public function store(StoreOrderRequest $request)
{
    \(order = Order::create(\)request->validated());

    SendOrderReceipt::dispatch($order->id);

    return response()->json([
        'id' => $order->id,
        'status' => 'accepted',
    ], 202);
}

Now your response time no longer depends on your mail provider. If the provider has a slow afternoon, the queue absorbs it and your users don't have to wait.

Large Payloads

Oversized JSON responses hurt everyone in the chain: the app server serializing them, the network carrying them, and the client parsing them. A frequent mistake is returning whole models when you meant to return a summary:

return User::with('orders', 'invoices', 'teams')->findOrFail($id);

Define an explicit API Resource instead:

use Illuminate\Http\Resources\Json\JsonResource;

class UserSummaryResource extends JsonResource
{
    public function toArray($request): array
    {
        return [
            'id' => $this->id,
            'name' => $this->name,
            'avatar_url' => $this->profile?->avatar_url,
            'plan' => $this->subscription_plan,
        ];
    }
}

A small, deliberate response contract keeps endpoint cost easy to reason about and prevents accidental coupling.

Expensive Joins

Joins are useful, but expensive joins across large tables can dominate your database time, especially when they sort or filter on columns that aren't indexed:

$rows = DB::table('orders')
    ->join('users', 'users.id', '=', 'orders.user_id')
    ->join('accounts', 'accounts.id', '=', 'users.account_id')
    ->where('accounts.region', 'us-east')
    ->where('orders.status', 'paid')
    ->orderByDesc('orders.created_at')
    ->limit(100)
    ->get();

At scale, you may need to denormalize a small field, precompute a reporting table, or move analytics off the primary transactional database entirely. Do not treat denormalization as an admission of defeat. Copying a stable field like account_id onto orders can remove a costly join from a hot path. The price you pay is keeping that duplicated data consistent, which can be a worthwhile trade-off.

How to Optimize the Database

When a Laravel app slows down, the database is usually the first place to look.

Add Indexes Around Real Query Patterns

Start with your slow query log, database metrics, and traces rather than intuition. If the app constantly looks up active subscriptions by account, build a compound index that matches that access pattern:

Schema::table('subscriptions', function (Blueprint $table) {
    $table->index(['account_id', 'status', 'renews_at']);
});

Then write the query so it can actually use the index:

\(subscription = Subscription::where('account_id', \)accountId)
    ->where('status', 'active')
    ->where('renews_at', '>=', now())
    ->orderBy('renews_at')
    ->first();

Get in the habit of running EXPLAIN after you add an index to confirm that the plan changed. An index the optimizer ignores is just write overhead.

Use Eager Loading Deliberately

Match eager loading to what the endpoint actually returns. For list endpoints, keep relationships shallow and constrained:

$projects = Project::query()
    ->select(['id', 'account_id', 'name', 'updated_at'])
    ->withCount('openTasks')
    ->with([
        'owner:id,name',
    ])
    ->where('account_id', $accountId)
    ->latest('updated_at')
    ->paginate(30);

When you only need a number, withCount beats loading a whole relationship to count it:

$teams = Team::query()
    ->withCount([
        'members',
        'invitations as pending_invitations_count' => fn (\(query) => \)query->whereNull('accepted_at'),
    ])
    ->paginate(25);

Your memory footprint stays flat, which matters much more on a list page than on a detail page.

Optimize Queries Before Adding Hardware

A bigger database instance buys you time. It also hides the inefficient queries that put you there until the next traffic jump exposes them again. Before you reach for a larger machine, find your highest-cost queries. In local or staging environments, logging slow ones is easy:

use Illuminate\Database\Events\QueryExecuted;
use Illuminate\Support\Facades\DB;
use Illuminate\Support\Facades\Log;

DB::listen(function (QueryExecuted $query) {
    if ($query->time > 100) {
        Log::warning('Slow query detected', [
            'sql' => $query->toRawSql(),
            'time_ms' => $query->time,
        ]);
    }
});

Be careful doing this in production. Bindings can contain sensitive data, and verbose logging at high volume can become its own performance problem.

Process Large Tables with Chunking

Never pull an entire large table into memory for a batch job:

User::where('is_active', true)
    ->chunkById(1000, function ($users) {
        foreach (\(users as \)user) {
            RefreshUserSearchIndex::dispatch($user->id);
        }
    });

chunkById is safer than offset-based chunking when rows can change while the job runs, because it tracks the last seen ID instead of a numeric offset. For very large exports, stream the records or write them out in batches.

Use Cursor Pagination for High-Volume Feeds

Offset pagination gets slower the deeper a user scrolls, because the database still has to skip every row it's not returning. For feeds, audit logs, messages, and timelines, cursor pagination is usually the better fit:

$events = AuditEvent::query()
    ->where('account_id', $accountId)
    ->orderByDesc('id')
    ->cursorPaginate(50);

return AuditEventResource::collection($events);

It relies on a stable, indexed ordering column and uses next/previous cursors rather than arbitrary page numbers, which is what an infinite-scroll feed usually needs.

Split Reads with Read Replicas

As read traffic grows, replicas can take load off the primary:

'mysql' => [
    'driver' => 'mysql',
    'read' => [
        'host' => [
            env('DB_READ_HOST', '127.0.0.1'),
        ],
    ],
    'write' => [
        'host' => [
            env('DB_WRITE_HOST', '127.0.0.1'),
        ],
    ],
    'sticky' => true,
    'database' => env('DB_DATABASE', 'laravel'),
    'username' => env('DB_USERNAME', 'root'),
    'password' => env('DB_PASSWORD', ''),
],

The sticky option keeps reads on the write connection after a write within the same request, which helps avoid some read-after-write surprises.

Replicas come with replication lag, and that lag matters. Don't route payment confirmations, password changes, permission checks, or anything else consistency-sensitive to a replica that might be a few seconds stale unless the business flow can genuinely tolerate seeing old data.

How to Scale with Redis

Redis often does a lot in a Laravel production stack: caching, sessions, rate limiting, queues, locks, and Horizon metrics. It's fast, but it still needs thought: sensible key design, expiration policies, memory monitoring, and a real plan for invalidation.

Caching

Cache expensive reads that get requested often and can tolerate being slightly out of date:

use Illuminate\Support\Facades\Cache;

$stats = Cache::remember(
    "accounts:{$account->id}:dashboard-stats",
    now()->addMinutes(5),
    fn () => DashboardStats::forAccount($account)->calculate()
);

Short time-to-live values go a surprisingly long way. A five-minute cache can wipe out thousands of duplicate queries while keeping the data fresh enough for most dashboards.

When the data changes after a known event, invalidate it explicitly:

Order::created(function (Order $order) {
    Cache::forget("accounts:{$order->account_id}:dashboard-stats");
});

Caching works best when your keys are predictable and your invalidation is tied to domain events rather than guesswork.

Sessions

For horizontally scaled app servers, file-based sessions are a trap: the next request can land on a different server that has never seen the session. Store sessions in Redis or a database so any server can handle any request:

SESSION_DRIVER=redis
CACHE_STORE=redis
QUEUE_CONNECTION=redis

Rate Limiting

Rate limits protect you from abusive clients, runaway loops, and endpoints that get hammered:

use Illuminate\Cache\RateLimiting\Limit;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\RateLimiter;

RateLimiter::for('api', function (Request $request) {
    return Limit::perMinute(120)->by(
        optional(\(request->user())->id ?: \)request->ip()
    );
});

Expensive endpoints deserve stricter limits:

RateLimiter::for('exports', function (Request $request) {
    return Limit::perHour(10)->by($request->user()->id);
});

Let business cost drive the numbers. Login, search, export, and webhook endpoints rarely need the same limit.

Queues

Redis is a common queue backend because it's quick and Horizon supports it well:

QUEUE_CONNECTION=redis

Dispatch work onto named queues from the request:

GenerateInvoicePdf::dispatch($invoice->id)
    ->onQueue('documents');

Split work by profile, such as default, emails, webhooks, documents, and imports, because each workload can need different worker counts and retry rules. Keep the names meaningful. During an incident, "the documents queue is 20 minutes behind" tells you far more than "default is slow."

How to Use Queue-Driven Architectures

Queues are one of Laravel's best scaling tools. They let the app accept work quickly and process it asynchronously with controlled concurrency. They also make the system more resilient: when a third-party API goes down, jobs retry on their own instead of tying up your PHP-FPM request workers.

Laravel Queues

A good job is small, idempotent, and safe to retry:

use App\Mail\OrderReceiptMail;
use App\Models\Order;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Foundation\Queue\Queueable;
use Illuminate\Support\Facades\Mail;

class SendOrderReceipt implements ShouldQueue
{
    use Queueable;

    public int $tries = 3;
    public int $backoff = 60;

    public function __construct(public int $orderId)
    {
    }

    public function handle(): void
    {
        \(order = Order::with('user')->findOrFail(\)this->orderId);

        Mail::to(\(order->user)->send(new OrderReceiptMail(\)order));
    }
}

Pass IDs into jobs rather than full Eloquent models. The model might change before the job runs, and serializing a whole model bloats the payload. For external APIs, add timeouts and guard against duplicate work:

use App\Models\Order;
use App\Services\CrmClient;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Foundation\Queue\Queueable;

class SyncOrderToCrm implements ShouldQueue
{
    use Queueable;

    public int $tries = 3;
    public int $backoff = 60;

    public function __construct(public int $orderId)
    {
    }

    public function handle(CrmClient $crm): void
    {
        \(order = Order::findOrFail(\)this->orderId);

        if ($order->crm_synced_at) {
            return;
        }

        \(crm->upsertOrder(\)order->external_reference, [
            'total' => $order->total,
            'status' => $order->status,
        ]);

        $order->forceFill(['crm_synced_at' => now()])->save();
    }
}

The crm_synced_at check is the whole point. Jobs run more than once in real life, and idempotency is what keeps a retry from double-charging or double-syncing.

Horizon

Horizon gives you visibility and control over Redis queues. A typical setup runs different supervisors for different workloads:

'production' => [
    'supervisor-default' => [
        'connection' => 'redis',
        'queue' => ['default', 'emails'],
        'balance' => 'auto',
        'maxProcesses' => 20,
        'tries' => 3,
    ],

    'supervisor-documents' => [
        'connection' => 'redis',
        'queue' => ['documents'],
        'balance' => 'simple',
        'maxProcesses' => 5,
        'tries' => 2,
        'timeout' => 300,
    ],
],

The separation matters: a long-running document job shouldn't starve a quick password-reset email.

Failed Jobs and Retries

Retries only help when failures are temporary. Retrying a job that's permanently broken just burns capacity. For jobs with a business deadline, use retryUntil:

use DateTime;
use Throwable;

public function retryUntil(): DateTime
{
    return now()->addMinutes(30);
}

public function failed(Throwable $exception): void
{
    ImportBatch::whereKey($this->batchId)->update([
        'status' => 'failed',
        'failed_reason' => $exception->getMessage(),
    ]);
}

Use failed to flag the problem somewhere a human will see it. Whatever you do, don't set unlimited retries on jobs that hit a third-party service.

Queue Monitoring

Track queue depth, wait time, failure rate, and processing time together. Depth alone can mislead you. When depth starts climbing, walk through it methodically: are workers keeping pace with incoming jobs? If the queue keeps growing, check how long individual jobs take. If the slow part is the database, fix the query or dial back worker concurrency. If it's an external API, add backoff or a circuit breaker. If the work is CPU-bound, scale workers or break the jobs into smaller pieces.

Be careful with the "scale workers" instinct, though. Adding more workers without checking the database first can make an incident worse. More workers mean more concurrent queries, more locks, and more pressure on the primary exactly when it's already struggling.

How to Optimize API Performance

APIs earn special attention because clients call them repeatedly and payloads tend to grow quietly over months.

API Resources

Resources keep your response shape intentional:

class OrderResource extends JsonResource
{
    public function toArray($request): array
    {
        return [
            'id' => $this->id,
            'status' => $this->status,
            'total' => $this->total,
            'placed_at' => $this->created_at->toIso8601String(),
            'customer' => new CustomerSummaryResource($this->whenLoaded('customer')),
        ];
    }
}

whenLoaded is doing real work here. It stops the resource from quietly triggering a lazy query when the relationship wasn't eager loaded:

$orders = Order::query()
    ->with('customer:id,name')
    ->where('account_id', $accountId)
    ->latest()
    ->paginate(50);

return OrderResource::collection($orders);

Pagination

Returning unbounded collections is an easy way to create an API performance problem you won't notice until a client has a lot of data:

$perPage = min((int) request('per_page', 50), 100);

\(orders = Order::where('account_id', \)accountId)
    ->latest()
    ->paginate($perPage);

Cap the page size. If a client genuinely needs every record for an export, make that an async job rather than a giant synchronous response.

Response Optimization

Stop returning fields nobody reads. On read-heavy endpoints, selecting only the columns you need cuts both database I/O and serialization cost:

$products = Product::query()
    ->select(['id', 'name', 'slug', 'price', 'thumbnail_url'])
    ->where('is_visible', true)
    ->orderBy('name')
    ->paginate(40);

It's also worth turning on compression at the web server or load balancer. JSON compresses extremely well, and that's often a small config change with a real bandwidth payoff.

Rate Limiting

Design API rate limits around identity and endpoint cost:

Route::middleware(['auth:sanctum', 'throttle:api'])
    ->group(function () {
        Route::get('/orders', [OrderController::class, 'index']);
        Route::post('/exports/orders', [OrderExportController::class, 'store'])
            ->middleware('throttle:exports');
    });

This keeps casual browsing and expensive exports under separate policies, so one heavy user can't squeeze out everyone else.

Caching API Responses

Cache responses that are expensive to compute and can tolerate being a little stale:

public function index(Request $request)
{
    \(accountId = \)request->user()->account_id;
    \(page = \)request->integer('page', 1);

    \(cacheKey = "api:accounts:{\)accountId}:orders:v1:page:{$page}";

    return Cache::remember(\(cacheKey, now()->addSeconds(60), function () use (\)accountId) {
        return OrderResource::collection(
            Order::with('customer:id,name')
                ->where('account_id', $accountId)
                ->latest()
                ->paginate(50)
        )->response()->getData(true);
    });
}

Notice the v1 in the key. Bumping that version number lets you invalidate an entire response format at once when the shape changes. Always scope the key to the tenant or user for anything that's not truly global.

How to Monitor Laravel in Production

The teams that catch problems before customers do are the ones collecting signals from everywhere: Laravel, queues, the database, Redis, the infrastructure, and external services.

Laravel gives you several good starting points. Horizon shows queue throughput, failed jobs, wait times, and worker balancing. Telescope surfaces request details, queries, exceptions, jobs, mail, and cache events. Your logs capture slow operations, unexpected retries, and external failures. Your metrics track latency, error rate, queue depth, job runtime, database CPU, lock waits, cache hit ratio, and Redis memory. Your alerting ties all of it back to something a customer would actually feel.

That last part is where teams often make mistakes. The best alerts are about symptoms, not machines being busy: p95 API latency over 800ms for 10 minutes, checkout error rate above 1%, the emails queue waiting more than 5 minutes, database CPU over 85% with slow queries rising, Redis memory over 80%, or failed payment webhooks crossing a threshold.

A useful mental model is this: logs tell you what happened, metrics tell you whether the system is healthy, and traces tell you where the time went. In practice, wrapping your expensive business operations in a bit of instrumentation pays off quickly:

use Illuminate\Support\Facades\Log;

$startedAt = microtime(true);

\(report = \)builder->forAccount($account)->build();

Log::info('Billing report generated', [
    'account_id' => $account->id,
    'duration_ms' => (int) ((microtime(true) - $startedAt) * 1000),
    'invoice_count' => $report->invoiceCount(),
]);

When something is failing at 2am, a log line like that can tell you which account, import, or report is causing the pressure.

One more thing worth internalizing: monitor wait time, not just throughput. A queue can process thousands of jobs a minute and still be unhealthy if important jobs sit waiting too long before they start. Users feel the wait, not the throughput.

An Example High-Traffic Laravel Architecture

A high-traffic Laravel setup generally separates four things: stateless web requests, shared cache and session storage, asynchronous workers, and database roles.

Users hit a load balancer, which spreads traffic across a fleet of stateless Laravel app servers. Those servers use Redis for cache, sessions, rate limits, queues, and Horizon data. Queue workers handle slow or unreliable work off to the side. A MySQL primary takes all writes and any consistency-sensitive reads, while a read replica absorbs read-heavy endpoints that can tolerate some replication lag.

The flow looks like this:

Users
  -> Load balancer
  -> Stateless Laravel app servers
  -> Redis for cache, sessions, rate limits, queues, and Horizon data
  -> Primary database for writes and consistency-sensitive reads
  -> Read replica for safe read-heavy endpoints

Redis queue
  -> Queue workers
  -> Database, external APIs, mail providers, object storage, and other services

This isn't the only valid shape. PostgreSQL can stand in for MySQL, Amazon SQS can replace Redis queues, a CDN can serve static assets and cache public responses, and object storage should hold user uploads. The principle that matters is that each layer has one clear job and can be scaled or tuned on its own.

The flip side of stateless app servers is that anything a user needs after the request ends has to live in shared storage. Uploads, generated files, and session state shouldn't sit on a single server's local disk, or they may disappear from the user's point of view when the load balancer sends the next request somewhere else.

Lessons Learned the Hard Way

1. Premature Optimization

This usually shows up as elaborate infrastructure built before the app has any real visibility into itself.

The practical path works better: measure, rank the bottlenecks, fix the biggest one, repeat. For most Laravel apps, the first round of scaling is mostly indexes, N+1 fixes, queue separation, and trimming payloads.

2. Over-caching

Caching can make a system faster and harder to reason about at the same time. One team cached an account-settings response for 30 minutes, then later folded role changes into that same response. The result was that users who had just lost access could still see features until the cache expired.

The fix was splitting stable account metadata away from permission-sensitive state. The lesson is to avoid caching authorization data unless you have thought carefully about invalidation.

3. Missing Indexes

These hide until a table crosses a size threshold. A query that scanned 20,000 rows in development can scan 20 million in production. Bake index review into feature work, and plan big index migrations carefully so they don't lock a hot table at the worst possible time.

4. Queue Overload

Queues don't remove work, they move it. The classic failure is letting one noisy workload block everything else. A big CSV import floods the default queue, and password-reset emails get stuck behind it. Separate queues are cheap insurance against that entire class of incident.

5. Large Transactions

Long transactions hold locks longer and make failures more expensive. Dispatching a job inside a transaction is especially risky because a worker can grab it before the transaction commits:

DB::transaction(function () use ($request) {
    $order = Order::create([...]);
    \(order->items()->createMany(\)request->items);

    GenerateInvoicePdf::dispatch($order->id);
    SyncOrderToCrm::dispatch($order->id);
});

Use after-commit dispatching for any job that depends on committed data:

GenerateInvoicePdf::dispatch($order->id)->afterCommit();
SyncOrderToCrm::dispatch($order->id)->afterCommit();

Keep transactions scoped to the data that genuinely has to change atomically, and nothing more.

6. Treating Symptoms as Causes

This is the expensive one. If latency is high because an endpoint runs 300 queries, adding app servers adds database pressure. If jobs are slow because an external API is rate-limiting you, adding workers multiplies the failures.

Good scaling work keeps asking the same questions: What resource is saturated? Which endpoint, job, tenant, or query is causing it? Is this work necessary during the request? Can I reduce it, defer it, cache it, or isolate it? How will I know whether the change helped?

A Pre-Launch Scaling Checklist

Run through this before a big launch, a traffic campaign, or an enterprise rollout.

Application and runtime: Cache config, routes, and views during deploy. Set APP_DEBUG=false. Turn on OPcache. Keep web requests short and move slow work to queues. Store uploads in object storage, not on app-server disk. Keep servers stateless. Set timeouts on every external HTTP call.

Database: Review slow query logs first. Add indexes for your high-volume filters, joins, and ordering. Hunt for N+1 queries in controllers, resources, policies, and views. Paginate every list endpoint. Use chunkById or cursors for batch work. Avoid long transactions and external calls inside transactions. Confirm your backup and restore process works. Test stale-read behavior if you use replicas.

Redis and cache: Use Redis for cache, sessions, rate limiting, and queues where it fits. Set TTLs unless you have a clear reason not to. Include tenant, user, locale, and version in keys when relevant. Watch memory and the eviction policy. Avoid caching permission-sensitive responses without careful invalidation. Guard against cache stampedes on expensive recomputation.

Queues: Separate queues by workload. Configure Horizon supervisors per queue. Set timeouts, retries, and backoff on purpose. Make jobs idempotent where you can. Use afterCommit for jobs that depend on committed data. Monitor wait time, runtime, failures, and retries. Review failed jobs instead of ignoring them.

APIs: Use Resources to control response shape. Cap per_page. Use cursor pagination for big feeds and logs. Cache expensive reads with safe, versioned keys and short TTLs. Apply rate limits by endpoint cost. Don't return raw Eloquent models. Compress responses at the edge.

Observability: Track p50, p95, and p99 latency on the endpoints that matter. Track error rates by route and job class. Alert on queue wait time, not just size. Watch database CPU, connections, slow queries, and lock waits. Watch Redis memory, latency, and evictions. Log important business operations with durations and identifiers. Test your alerts before launch night because a silent alert is worse than no alert.

Conclusion

Laravel runs high-traffic production systems well when you design around the real costs of data, concurrency, and external dependencies. Just make sure you measure before you optimize, because guessing wastes time and tends to complicate the wrong layer.

Fix the database first: indexes, query shape, pagination, and eager loading usually deliver the biggest early wins. Lean on queues to keep requests fast and push slow work into controlled background workers. Cache deliberately, with clear keys, sane TTLs, and a plan for invalidation. Keep watching latency, errors, queue wait time, database health, Redis memory, and your external dependencies.

The best scaling work is practical and repeatable. You study the system you actually have, remove waste, isolate slow parts, and give yourself enough visibility to make the next change with confidence. Do that on a loop, and you rarely need the big rewrite.

References

• Laravel documentation: Eloquent relationships

• Laravel documentation: Database queries

• Laravel documentation: Cache

• Laravel documentation: Queues

• Laravel documentation: Redis

• Laravel documentation: Rate limiting

• Laravel documentation: Eloquent API resources

• Laravel Horizon documentation

• Laravel Telescope documentation

• MySQL documentation: Optimization

• Redis documentation

The internet depends on physical infrastructure: fiber-optic cables, satellites, and data centers often located thousands of kilometers away. Network requests travel at high speed, but they are still limited by the speed of light (around 300,000 km/s). For instance, a network request from Lagos, Nigeria to a server in San Francisco, USA travels more than 12,000 km, and takes about 150–200 milliseconds for a single round trip under ideal conditions. Multiply that by the 20–30 requests a typical web page makes (for HTML, CSS, images, APIs and more), and those milliseconds quickly add up to seconds of delay before a page fully loads.

In this article, we’ll explain in detail what Round Trip Time(RTT) is, why it is one of the most overlooked factors in web performance, and how you can use Next.js to minimize the number of RTTs to make your applications feel fast and responsive. You will learn how features like Server-Side Rendering (SSR), React Server Components (RSC), image optimization, and caching all work together to reduce Round Trip Time in a web page.

What You will Learn

• What You will Learn

• What is Round Trip Time (RTT)?

  • How Distance Increases Round Trip Time

• How Round Trip Time Affects Web Performance

  • Why Client-Side Rendering Feels Slower

• How to Reduce Round Trip Time with Next.js

  • Server-Side Rendering (SSR)

  • React Server Components (RSC)

  • Image Optimization

  • Caching and Static Rendering

• Trade-offs Across Next.js Rendering Methods

• When to Use Each Rendering Method

• Conclusion

What is Round Trip Time (RTT)?

When you visit a website, the browser makes a network request to a server. The server processes the request and then sends a response back. The Round Trip Time is the complete duration of this journey in milliseconds, which includes:

1. Travel Time: The amount of time it took the network request to get to the server.

2. Processing Time: The amount of time the server took to process the request.

3. Return Time: The amount of time it took the response get back to the browser.

How Distance Increases Round Trip Time

Round Trip Time depends heavily on the physical distance between the client and server. For example:

• A user in Lagos, Nigeria making a network request to a server in London that is about 5,000 km away might see a round trip time of 100–150 ms.

• A server in San Francisco that is about 12,000 km could push the roundtrip time to 200–300 ms. The farther the server, the higher the round trip time.

How Round Trip Time Affects Web Performance

Modern web pages make multiple network requests to load completely. Imagine loading an e-commerce product page that requires:

• 1 network request for HTML (about 200 ms)

• 5 network requests for CSS/JavaScript (about 1,000 ms)

• 10 network requests for images (about 2,000 ms)

• 4 network requests for product data via API (about 800 ms)

That shows that the product page will take 20 network requests to fully load, which is about 4 seconds of network delay.

The probability of bounce increases 32% as page load time goes from 1 second to 3 seconds (Google/SOASTA Research, 2017). That means about one-third of visitors leave before the page even loads.

Why Client-Side Rendering Feels Slower

In client side rendering applications, each request adds a round trip time, and traditional client-side rendering (CSR) in React apps increases this:

• The browser downloads a minimal HTML shell and a large JavaScript bundle.

• The JavaScript runs to fetch data and render the UI, requiring additional network requests.

• Each API call adds another RTT, delaying the First Contentful Paint (FCP).

First Contentful Paint (FCP) measures the time from when the user first navigated to the page to when any part of the page's content such as text, images,<svg> or <canvas> elements is rendered on the screen.

In CSR apps, FCP is delayed because the browser cannot display any meaningful content until JavaScript has finished loading, parsing, and executing the code needed to construct the UI. A regular CSR application may need 5 to 10 network round trips to get all the resources needed for the rendering of the UI, which can easily add several seconds of delay.

// pages/index.js (CSR)
import { useState, useEffect } from "react"

export default function Home() {
  const [products, setProducts] = useState([])

  useEffect(() => {
    // Fetch data after page loads
    fetch("https://api.example.com/products")
      .then((res) => res.json())
      .then((data) => setProducts(data))
  }, [])

  return (
    <div>
      <h1>Products</h1>
      {products.length ? (
        products.map((product) => <p key={product.id}>{product.name}</p>)
      ) : (
        <p>Loading...</p>
      )}
    </div>
  )
}

In the code above, when the Home component mounts, it initializes the state as an empty array. The useEffect hook then runs once to make an API request. While the request is in progress, the “Loading...” message is displayed on the screen. Once the request completes successfully, React updates the state with the fetched data and re-renders the UI to display the products. This process introduces an extra round trip, which further delays the FCP.

How to Reduce Round Trip Time with Next.js

You cannot eliminate round trip time completely. Data must still travel over the network. What Next.js does is to reduce how often those network requests happen and how much data each request carries. It does this through a number of techniques, such as Server-Side Rendering (SSR), React Server Components (RSC), image optimization, and caching or static rendering.

Server-Side Rendering (SSR)

Unlike traditional React.js applications, where the browser handles the majority of the work, such as fetching static files, JavaScript, and data required to render a page, the server generates the whole HTML, fetches the data, renders the page, and sends it to the browser in a single round trip time.

Advantages:

• Fewer Round Trips: Since data fetching and rendering take place on the server, the browser receives a ready-to-display page in one round trip time.

• Improved First Contentful Paint: Low round trip time means content displays on the page almost immediately.

// pages/index.js (SSR)
export async function getServerSideProps() {
  // Fetch data on the server
  const res = await fetch('https://api.example.com/products');
  const products = await res.json();

  return {
    props: { products }, // Pass data to the page
  };
}

export default function Home({ products }) {
  return (
    <div>
      <h1>Products</h1>
      {products.map((product) => (
        <p key={product.id}>{product.name}</p>
      ))}
    </div>
  );
}

In the code above, getServerSideProps runs entirely on the server. When a user visits or refreshes the page, getServerSideProps() is called to fetch product data from the external API. The fetched data is then pre-rendered on the server, meaning the list of products is included in the HTML before it is sent to the browser to display. This removes the additional round trip seen in CSR and improves the FCP, since users see meaningful content as soon as the page loads.

React Server Components (RSC)

Server-Side Rendering is a technique where the whole page gets generated on the server. But imagine if only some portions of a page are to be rendered on the server while others are to be rendered on the client?

React Server Components allow partition of rendering between the server and the client.

For example, a ProductList component can be rendered on the server, while a SearchInput component renders on the client to manage user interactions.

Advantages:
RSC reduces the overall round trip time (RTT) and also increases the page first contentful paint.

// app/ProductList.jsx (Server Component)
async function ProductList() {
  // Fetch data on the server
  const res = await fetch('https://api.example.com/products');
  const products = await res.json();

  return (
    <div>
      <h1>Products</h1>
      {products.map((product) => (
        <p key={product.id}>{product.name}</p>
      ))}
      <ClientSearch /> {/* Client Component */}
    </div>
  );
}

export default ProductList;

In the code above, ProductList is a server component with a ClientSeacrch component as a child component. The ClientSearch renders in the browser while the rest of the ProductList renders on the server. When the page loads, the server runs fetch() to retrieve product data and renders the complete HTML for the product list on the server while ClientSearch renders on the client side to handle user interactions.

// components/ClientSearch.jsx (Client Component)
'use client';

import { useState } from 'react';

export default function ClientSearch() {
  const [query, setQuery] = useState('');

  return (
    <input
      type="text"
      value={query}
      onChange={(e) => setQuery(e.target.value)}
      placeholder="Search products..."
    />
  );
}

The ClientSearch component above handles user interactions, such as updating the search input with useState. It’s marked with 'use client', so it runs entirely in the client side.

Image Optimization

Images negatively impact round-trip time RTT when they are unoptimized, as larger files take a longer time to transfer from the server to the browser.

Next.js Image component optimizes images automatically:

Resizing: It adjusts image size based on the user’s device.

Compression: It uses new formats like WebP to shrink the file size significantly.

Lazy Loading: Loads images only when they enter the user’s viewport, which reduces the number of initial requests.

// pages/index.js
import Image from 'next/image';

export default function Home() {
  return (
    <div>
      <h1>Welcome to Our Store</h1>
      <Image
        src="/product.jpg"
        alt="Product Image"
        width={500}
        height={300}
      />
    </div>
  );
}

In the code above, the page uses Next.js built-in Image component to render an optimized image. When the page loads, Next.js optimizes the image resizing, lazy loading, and so on. This means the browser will only download the right image size for the device.

Caching and Static Rendering

With SSR and Server Component, round trip time can still remain high if the server has to process data on every request. Next.js solves this problem with Static Site Generation (SSG) and Incremental Static Regeneration (ISR).

Here’s how it works:

Static Site Generation: Pages are pre-rendered during build time, cached and delivered as static HTML from a CDN.

Incremental Static Regeneration: Pages are pre-rendered but can be re-generated in the background after an interval, for example, every 60 seconds.

// app/page.jsx
export const revalidate = 60; // Regenerate the page every 60 seconds

export default async function Home() {
  // Fetch data on the server
  const res = await fetch("https://api.example.com/products", {
    next: { revalidate: 60 }, 
  });
  const products = await res.json();

  return (
    <div>
      <h1>Products</h1>
      {products.map((product) => (
        <p key={product.id}>{product.name}</p>
      ))}
    </div>
  );
}

In the code above, the page uses Incremental Static Regeneration (ISR). The revalidate = 60 option is to regenerate the page every 60 seconds. When a user visits the page, the server serves the pre-rendered HTML instantly. The next: { revalidate: 60 } inside the fetch() means that data is cached for 60 seconds. After 60 seconds, the next request will trigger the server to regenerate a fresh data.

Trade-offs Across Next.js Rendering Methods

With Server-Side Rendering (SSR), the browser gets the complete rendered page in only one round round trip. On the other hand, this can also lead to increased server load and a high TTFB. The TTFB (Time to First Byte) is the duration it takes for a user to see the content displayed on their browser.

With Incremental Static Regeneration (ISR), the page is pre-rendered and cached, thus getting an instantaneous response from the server. The page will be re-generated depending on a fixed period (such as every 60 seconds). The downside of this method is that users might see old content before it gets updated.

In Server Components, rendering takes place on the server, and only interactive parts are managed on the client. With this, server-side rendering are still maintained while still allowing client interactions. The only drawback is that developers need to be very particular while deciding what to run on the server and what to run on the client.

When to Use Each Rendering Method

Server-Side Rendering (SSR) should be applied to pages that updates frequently, such as dashboards, user profiles, and so on. SSR guarantee users to always see the latest data.

As for Incremental Static Regeneration (ISR), it should be applied to pages with infrequent changes, for instance, product listings, marketing pages, or blogs.

Use Server Components when you want part of the page to render on the server while some sections run on the client. For instance, pages that need user interaction like search inputs or filters, while data fetching and rendering takes place on the server.

Conclusion

Round Trip Time (RTT) is one of the hidden factors behind slow page loads. Each network request adds a round trip, and these network delays build up as the browser fetches several resources like scripts, images, and data files. Next.js deals with this issue by minimizing the number of network requests that need to be done before the first content paint.

• Server-Side Rendering (SSR) and React Server Components (RSC) shift data fetching and rendering to the server, which reduces client-side requests.

• Image optimization reduces image size and uses CDNs to deliver content faster from nearby servers.

• Caching and static rendering serve pre-generated pages instantly without further processing from the server.

With these techniques, you can build web applications that load faster and feel more responsive, even for users who are far from your origin server or are on slower networks.

At its core, every business thrives on delivering value to its users. When users are unable to access this value due to poor performance, it ultimately impacts the business's success. Slow load times, among other factors, frustrate users and drive them away before they even get a chance to engage.

Optimizing performance is more than just a technical detail – it’s also a critical part of creating a successful application. Without it, even the best features can go unnoticed if users don’t stick around long enough to see them.

In this article, we’ll explore key approaches to optimize your Next.js application, making it faster and more efficient.

Table of Contents

• Building a Performant Application

• How to Optimize Your Applications

• Key Techniques To Optimize Performance

  • Using The Next.js Image Component

  • Optimizing Third-Party Scripts with the Next.js Script Component

  • Remove Unused Packages/Dependencies

  • Caching and Incremental Static Regeneration (ISR)

  • Caching Frequently Used Content

  • Font Optimization With next/font

  • Lazy Loading And Code Splitting

  • Lazy Loading in Next.js

  • Code Splitting

• Conclusion

Building a Performant Application

Making your apps more performant means striking the right balance between speed, responsiveness, and efficient use of resources. You should strive to create an application that delivers value and keeps users satisfied.

Building a performant app is about making sure the app feels smooth and intuitive so that there are no frustrating lags when a user clicks buttons, scrolls, or navigates around. You’ll also want to make sure that data loads or updates without unnecessary delays.

How to Optimize Your Applications

The first step in optimizing your application is identifying problem areas. A number of tools and packages can help you analyze your application's performance effectively. Here's how you can use them:

Using npm run build

When you run npm run build, Next.js creates a production-ready version of your application and gives a detailed breakdown of your pages. This includes:

• Size: The size of the JavaScript files for each route. Highlighting any routes that are too large and could slow things down. Smaller page sizes generally result in faster load times while large pages might take longer to download, especially for users with slower network connections.

• First Load Js: This column provides information about the total amount of JavaScript the browser needs to download and execute to fully render the page for the first time. Large First Load JS values

  cause Slower Time-to-Interactive (TTI).

Running this command produces an analysis like below:

Using @next/bundle-analyzer

The bundle analyzer is a package provided by Next.js to analyze the size of JavaScript bundles by providing a visual representation of the application’s module and dependencies. Here’s how to use the package:

First, install the package by running this command:

npm install @next/bundle-analyzer

Or you can use yarn:

yarn add @next/bundle-analyzer

Then add the @next/bundle-analyzer configuration to your next.config.js file:

const withBundleAnalyzer = require('@next/bundle-analyzer')({
  enabled: process.env.ANALYZE === 'true',
});

module.exports = withBundleAnalyzer({
  // other Next.js config options here
});

To analyze your application bundles while generating a production build, run the following command:

ANALYZE=true npm run build

For a step-by-step guide on how to use the bundle analyzer effectively, check out this detailed video tutorial

Browser tools

Finally, modern browsers, including Google Chrome, Firefox, and Edge, offer powerful tools to analyze and improve your application's performance. Features like the Performance Tab help you record and visualize how your application runs, pinpointing issues like slow rendering or long tasks.

You can also use tools like Lighthouse (available in Chrome and Edge) to generate automated audits, highlighting problems such as large assets and unoptimized resources.

To access the Lighthouse and Performance tabs:

1. Open your browser's developer tools by right-clicking anywhere on the browser and selecting the Inspect option or pressing Command + Option + I (on Mac) or Ctrl + Shift + I (on Windows).

2. Look at the top menu in the developer tools.

3. If you don’t see the Lighthouse or Performance tabs right away, click the double right arrow (>>) to reveal hidden tabs.

4. Select the desired tab to start analyzing performance or generating a Lighthouse report.

Here is an example of a generated audit in the Performance tab on Chrome

Here’s another image showing the generated audit by lighthouse

Key Techniques to Optimize Performance

1.) Using The Next.js Image Component

Images often account for the largest portion of page weight, directly affecting load times and user experience. Large images slow down rendering and ultimately, increase bandwidth usage.

Next.js has a built-in Image component that automatically optimizes images, making it very useful for web performance. It takes care of resizing, lazy loading, and format optimization, so images are served in the most performant format (like .WebP) when the browser supports it.

import Image from 'next/image';

    <Image
      src="/house.jpg"
      alt="House Image"
      width={700}
      height={500}
      priority={false} // Lazy loads the image by default
    />

In the snippet above,

• src="/house.jpg": This points to the image file's location, which is in the public folder. Images in the /public directory are served statically, so you don’t need extra configuration.

• alt="House Image": The alt text (just like in the native HTML image element) provides a description of the image, which is great for accessibility (like screen readers) and also helps with SEO.

• width & height: By explicitly setting the width and height, Next.js can calculate the space the image will occupy on the page before it loads. This prevents the page layout from shifting as the image loads, which improves user experience and boosts performance metrics like Cumulative Layout Shift (as shown in the image above).

• priority={false}: This ensures the image will only load when it's near the user's viewport conserving the bandwidth and improving page load times for non-critical images. However, for important images that should load immediately (like those visible as soon as the page opens), you can set priority={true} to bypass lazy loading and ensure the image loads as quickly as possible.

One of the key advantages of the Next.js Image component is its built-in lazy loading feature. This means that images won’t be loaded until they are actually needed (when they enter the viewport). By only loading images that are about to be viewed, performance is improved and pages can load faster, even with many high-quality images.

2.) Optimizing Third-Party Scripts with the Next.js Script Component

Third-party scripts, such as analytics tools or advertising networks, can heavily affect your application's performance if not properly managed. Next.js has a Script component that makes it easy to load scripts efficiently, giving you control over how and when they load.

The Script component allows you to define a loading strategy for scripts, determining when and how they are fetched and executed. By prioritizing or deferring scripts based on their importance, you can improve the overall performance and user experience of your application.

• beforeInteractive: Use this strategy for scripts that must load before the page becomes interactive, like essential analytics or monitoring tools.

• afterInteractive: When you use this strategy, the script loads after the page becomes interactive, which is the default behavior. This is ideal for scripts that add functionality but aren’t essential for initial rendering.

• lazyOnload: Defers loading the script until all other page resources have finished loading. This is perfect for non-essential scripts like ads or social media widgets.

<Script src="https://example.com/non-essential.js" strategy="lazyOnload" /> //Pass the strategy as a prop to the component

By leveraging the Next.js Script component, you can prevent scripts from blocking critical rendering, reducing load times and improve Time to Interactive (TTI).

3.) Remove Unused Packages/Dependencies

Over time, as you build and maintain your project, unused dependencies can pile up in your codebase. These unnecessary packages increase the size of your project, slow down installation times, and make the code harder to maintain. Cleaning up these unused dependencies is essential for optimizing your application's performance and keeping your codebase clean.

The depcheck tool is a great way to identify and remove unused dependencies from your project. It analyzes your package.json and the project files to find unused dependencies, unused devDependencies, and missing dependencies.

You can run a depcheck like this:

npx depcheck

After identifying the unused dependencies, you can remove them by running:

npm uninstall <package-name>

or with yarn:

yarn remove <package-name>

Regularly running depcheck is a simple yet effective way to keep your project clean and efficient.

4.) Caching and Incremental Static Regeneration (ISR)

When you find yourself running the same calculations or database queries repeatedly, you should consider caching. It’s a simple yet powerful way to boost your web application's performance, especially for content that doesn’t change often. By storing frequently accessed data in a cache, you can avoid unnecessary processing and speed up load times.

In Next.js, you can take this a step further with Incremental Static Regeneration (ISR), which lets you serve static content instantly while keeping it fresh behind the scenes.

Incremental Static Regeneration (ISR) in Next.js lets you update static pages without rebuilding the whole site. Here's how it works:

1. Build time generation: ISR generates pages when the site is built.

2. Caching: It stores the pages so they load quickly when users visit.

3. Background updates: When content changes, ISR updates the pages behind the scenes without affecting users.

4. Dynamic updates: It combines the fast loading of static pages with the ability to update content regularly.

export async function getStaticProps() {

  const data = await fetchData();

  return {
    props: { data },
    //regenerate the page every 20 seconds.
    revalidate: 20,
  };
}

//pre-render the page as static content
function MyPage({ data }) {
  return (
    <div>
      <h1>My Page</h1>
      <p>{data}</p>
    </div>
  );
}

export default MyPage;

Caching Frequently Used Content

For websites with pages that get a lot of visitors, like product listings or blog posts, it's important to keep the content fast and up-to-date.

Caching helps achieve this by saving a copy of the page so it doesn't need to be created from scratch each time someone visits. The browser or server will store this cached page for a set amount of time, which is controlled by caching headers. Meanwhile, ISR (Incremental Static Regeneration) ensures that the page can be updated in the background when necessary, without needing to rebuild the entire site.

In applications with lots of data, caching can also speed up the process by storing API responses. This way, when users request the same data again, they can get it quickly from the cache instead of waiting for it to be fetched anew. Tools like Vercel and Content Delivery Networks (CDNs) help by storing these cached pages in multiple locations around the world, so visitors can access them faster.

export async function getStaticProps() {
  const data = await fetchData();

  return {
    props: { data },
    // Regenerate page at most once every 30 seconds
    revalidate: 30,
    // Cache for 1 hour at the CDN level
    headers: {
      'Cache-Control': 'public, max-age=3600, must-revalidate',
    },
  };
}

Here, the page regenerates every 30 seconds and is cached at the CDN level for one hour. The Cache-Control header tells the CDN and browser to cache the page for 1 hour and revalidate it afterward.

For a deeper dive into caching and its role in web performance, check out this insightful freeCodeCamp article on Caching vs. Content Delivery Networks.

5.) Font Optimization With next/font

The next/font module in Next.js automatically handles font loading for improved performance, so you don’t need to manually configure or use extra libraries. It loads only the essential parts of the font, which results in faster page load times.

To further reduce the font file size, you can provide the subsets array which ensures fewer bytes are transferred and pages load quickly.

Here’s how it works:

• Automatic font loading: The module optimizes font loading automatically, making sure fonts are served in the most efficient way, improving performance without extra effort.

• Subsetting fonts: You can specify the exact font characters needed for your app.

• Font display strategy: The font-display strategy determines how text is shown to the user while fonts are loading. Next.js typically uses the swap strategy by default, but you can manually configure it if necessary. The most common strategies are swap fallback optional and block.

•   import { Inter } from 'next/font/google'
  
    const inter = Inter({
      subsets: ['latin', 'latin-ext'], // Load only the Latin and extended Latin subsets
      weight: '400', // Choose the specific weight you need
      style: 'normal', // Specify the style if needed
    })
  
    export default function Page() {
      return <div className={inter.className}>Hello World</div>
    }
  

The snippet above uses the Next.js built-in tool for Google Fonts. Instead of adding the font link in your HTML or using a third-party library, you can import it directly like this for ease and efficiency.s

• subsets: Tells the app to load only the characters needed. Skipping other character sets like Cyrillic (used in Russian) or Greek, avoids downloading extra, unnecessary data, which keeps your app lightweight and faster to load.

• weight: Instead of loading all font weights (e.g., Bold, Light), you only bring in Regular (400). This reduces the overall size.

• style: Stick with the standard style (no fancy italics). This also trims down what’s downloaded.

6.) Lazy Loading and Code Splitting

When building web apps, you want to make sure your users don’t wait too long for your pages to load. A big part of this involves reducing how much JavaScript is loaded when the page first opens. Two techniques that help with this are lazy loading and code splitting, both of which Next.js makes easy to use.

Lazy Loading in Next.js

Think of lazy loading like waiting to download a movie only when you decide to watch it. Imagine you have a large component like a chart or a map that users only see after interacting with a page. Instead of loading it upfront, you can tell Next.js to load it only when it’s needed using next/dynamic.

Code Splitting in Next.js

Code splitting breaks your JavaScript into smaller pieces (called bundles), so users only load what’s necessary. For example, if a user visits your homepage, there’s no need to load JavaScript for other pages like "About Us" or "Dashboard". It typically happens during the build process or dynamically at runtime.

import dynamic from 'next/dynamic'

// Load HeavyComponent only when it’s rendered
const HeavyComponent = dynamic(() => import('./HeavyComponent'), { ssr: false })

export default function Home() {
  return (
    <div>
      <h1>Welcome Home!</h1>
      <HeavyComponent /> {/* This loads only when rendered */}
    </div>
  )
}

In the above code, dynamic dynamically imports the component only when needed. ssr: false disables server-side rendering for the component, which can save resources if the component doesn’t need to be pre-rendered.

Next.js automatically splits code by page, meaning each page only loads the necessary JavaScript when accessed, improving load times. For more granular control, next/dynamic allows you to dynamically import specific components, ensuring they are loaded lazily only when needed. While Next.js handles page-level code splitting by default, using next/dynamic gives you the flexibility to apply component-level splitting, optimizing resource loading and enhancing performance.

Conclusion

Creating a high-performance application is a very important aspect of any business. A faster and more efficient application enhances user engagement, lowers bounce rates, and boosts SEO rankings, which all contribute to business growth and customer satisfaction.

By utilizing these techniques we discussed in this guide, you can provide a smooth user experience while maintaining optimal efficiency behind the scenes.

Remember, every second saved in load time translates to happier users and, ultimately, better business outcomes.

Thank you for reading!

Want to connect with me?

• Twitter / X: @timi471

• Linkedin: Ayantunji Timilehin

• Email: ayantunjitimilehin@gmail.com

References

• Next.Js Documentation

• Caching-vs-content-delivery-network

• Using next/bundle-analyzer

• Cumulative layout shift

This typically happens because the website is trying to fetch all the necessary data as soon as you land on the page. It could be that a API request is being processed, or multiple APIs are fetching data sequentially, causing delays in loading the page.

The result? A poor user experience. You might think, "How can such a large company not prioritize user experience? This is disappointing." Consequently, users often leave the site, affecting key metrics and potentially impacting revenue.

But what if you could fetch the data for these heavy pages ahead of time, so that by the time a user lands on the page, they can interact with it instantly?

This is where the concept of prefetching comes in, and that's exactly what we'll be diving into in this blog post. So without further ado, let's get started!

Table of Contents

• Prefetching as a Solution

• How Prefetching Improves User Experience

• Understanding The Problem

• Solution #1: Prefetching Data in the Parent Component

• Solution #2: Prefetch Data on Page load

• How to Implement Prefetching with React

• Too much prefetching can also cause slowness

• Summary

Prefetching as a Solution

Here’s the revised version with just the grammar and spelling corrected:

For the problem above, what we want is to fetch the data for a given page before it's loaded onto the website so that the user doesn’t need to fetch the data on page load. This is called prefetching. From a technical perspective, its definition is as follows:

It is a way to fetch the required data beforehand so that the main component doesn’t need to wait for the data, thus enhancing the experience.

This can improve the user experience, boosting the customer’s confidence in your website.

Prefetching is a simple yet elegant solution that is more user-centric than a standard process. To implement prefetching, we need to understand the user’s behavior on the website. That is, the most visited pages, or which components fetch data on small interactions (such as hover).

After analyzing such scenarios, it makes sense to apply prefetching to them. However, as developers, we should be mindful of using this concept. Too much prefetching can also slow down your website since you're trying to fetch a lot of data for future scenarios, which might block the fetching of data for the main page.

How Prefetching Improves User Experience

Let us look at couple of scenarios where prefetching is beneficial:

1. Loading data/page earlier for the most visited link from your landing page. For example, consider that you have a “contact us” link. Let’s assume that this is the link that users mostly check and it contains a lot of data when it loads. Rather than loading the data when the contact us page loads, you can simply fetch the data on the homepage so that you don’t have to wait at the Contact Us page for the data. You can read more about prefetching pages here.

2. Prefetching table data for later pages.

3. Fetching data from a parent component and loading it in the child component.

4. Prefetching data that needs to be displayed in a popover.

These are some of the ways to achieve prefetching in your application and how it helps improve the user experience.

In this blog post we will be discussing about the last scenario: “prefetching data that needs to be displayed in the popover”. This is a classic example where prefetching can be beneficial and provides a smoother experience to the user.

Understanding The Problem

Let me define the problem here. Imagine the following scenario:

1. You have a component that displays specific information.

2. There is an element inside this component that shows another popover/tooltip when you hover on it.

3. The popover fetches data when it loads.

Now imagine that the user hovers on the element and needs to wait for the data to be fetched and displayed in the popover. During this wait, they see the skeleton loader.

The scenario will look like this:

It’s just frustrating how long the user has to wait whenever they hover on the image:

To solve this problem, there are two solutions that can help you get started and optimize the solution according to your needs.

Solution #1: Prefetching Data in the Parent Component

This solution is inspired from Martin Fowler’s blogpost. It allows you to fetch the data before the popup appears, instead of fetching on component load.

The popup appears when you hover on it. We can fetch the data when the mouse enters the parent component. Before the actual component—the image—is hovered on, we’ll have the data for the popover and will pass it to the popover component.

This solution doesn’t remove the loading state all together but it helps to significantly lower the chances of seeing the loading state.

Solution #2: Prefetch Data on Page load

This solution is inspired by x.com where, for the popover component, they fetch the data partially on the main page load and fetch the rest of the data when the component mounts.

As you can see from the above video, the user’s profile details are viewed in the popover. If you look closely, the details related to followers are fetched later.

This technique is highly efficient when you have a lot of data to be displayed in the popover but fetching them can be costly on popover mount or on the main page load.

A better solution would be to partially load the required data on the main page and load the rest of the data when the component mounts.

In our example, we fetched the data for the popover when the cursor entered the image’s parent element. Now imagine that you need to fetch additional details once the popover data is loaded. So based on the above x.com’s method, we can fetch additional data on popover load. Here is the outcome of it:

Here, we do the following things:

• We fetch the main data which is just necessary to render the popover when mouse enters the parent component of the image.

• This gives us enough time to fetch the main data.

• On popover load, we fetch another data, which is the album count. While the user reads data like name and email, we’ll have the next data ready to be seen.

This way, we can make small and smart tweaks to minimize the blank staring of loaders on the screen 😊.

How to Implement Prefetching with React

In this section we’ll briefly go through the how to implement the above prefetching example app.

Project Setup

To get started with creating the prefetching app, follow the process below:

You can use vitejs (this is what I used) or create-react-app to create your app. Paste the command below in your terminal:

yarn create vite prefetch-example --template react-ts

Once the app has been created, you should have the following folder structure when you open the prefetch-example folder with VS Code.

Now let us dive into the components that we are going to be building for this app.

Components

In this example we are going to be using 3 components:

• PopoverExample

• UserProfile

• UserProfileWithFetching

PopoverExample Component

Let us start with the first component which is the PopoverExample. This component displays an image avatar and some text to the right side of it. It should look like this:

The purpose of this component is to serve as an example similar to the real life scenarios. The image in this component loads a popover component when it is hovered on.

Here’s the code for the component:

import { useState } from "react";
import { useFloating, useHover, useInteractions } from "@floating-ui/react";
import ContentLoader from "react-content-loader";
import UserProfile from "./UserProfile";
import UserProfileWithFetching from "./UserProfileWithFetching";

export const MyLoader = () => (
    <ContentLoader
        speed={2}
        width={340}
        height={84}
        viewBox="0 0 340 84"
        backgroundColor="#d1d1d1"
        foregroundColor="#fafafa"
    >
        <rect x="0" y="0" rx="3" ry="3" width="67" height="11" />
        <rect x="76" y="0" rx="3" ry="3" width="140" height="11" />
        <rect x="127" y="48" rx="3" ry="3" width="53" height="11" />
        <rect x="187" y="48" rx="3" ry="3" width="72" height="11" />
        <rect x="18" y="48" rx="3" ry="3" width="100" height="11" />
        <rect x="0" y="71" rx="3" ry="3" width="37" height="11" />
        <rect x="18" y="23" rx="3" ry="3" width="140" height="11" />
        <rect x="166" y="23" rx="3" ry="3" width="173" height="11" />
    </ContentLoader>
);
export default function PopoverExample() {
    const [isOpen, setIsOpen] = useState(false);
    const [isLoading, setIsLoading] = useState(false);
    const [data, setData] = useState({});

    const { refs, floatingStyles, context } = useFloating({
        open: isOpen,
        onOpenChange: setIsOpen,
        placement: "top",
    });

    const hover = useHover(context);

    const { getReferenceProps, getFloatingProps } = useInteractions([hover]);

    const handleMouseEnter = () => {
        if (Object.keys(data).length === 0) {
            setIsLoading(true);
            fetch("https://jsonplaceholder.typicode.com/users/1")
                .then((resp) => resp.json())
                .then((data) => {
                    setData(data);
                    setIsLoading(false);
                });
        }
    };

    return (
        <div
            id="hover-example"
            style={{
                display: "flex",
                flexDirection: "row",
                alignItems: "center",
                textAlign: "left",
            }}
            onMouseEnter={handleMouseEnter}
        >
            <span
                style={{
                    padding: "1rem",
                }}
            >
                <img
                    ref={refs.setReference}
                    {...getReferenceProps()}
                    style={{
                        borderRadius: "50%",
                    }}
                    src="https://cdn.jsdelivr.net/gh/alohe/avatars/png/vibrent_5.png"
                />
            </span>
            <p>
                Lorem Ipsum is simply dummy text of the printing and typesetting
                industry. Lorem Ipsum has been the industry's standard dummy text ever
                since the 1500s, when an unknown printer took a galley of type and
                scrambled it to make a type specimen book. It has survived not only five
                centuries, but also the leap into electronic typesetting, remaining
                essentially unchanged. It was popularised in the 1960s with the release
                of Letraset sheets containing Lorem Ipsum passages, and more recently
                with desktop publishing software like Aldus PageMaker including versions
                of Lorem Ipsum.
            </p>
            {isOpen && (
                <div
                    className="floating"
                    ref={refs.setFloating}
                    style={{
                        ...floatingStyles,
                        backgroundColor: "white",
                        color: "black",
                        padding: "1rem",
                        fontSize: "1rem",
                    }}
                    {...getFloatingProps()}
                >
                    {isLoading ? (
                        <MyLoader />
                    ) : (
                        <UserProfile hasAdditionalDetails {...data} />
                    )}
                    {/* <UserProfileWithFetching /> */}
                </div>
            )}
        </div>
    );
}

There are couple of things happening here, let me explain them step-by-step:

• We have a parent div named hover-example that contains an image and some text.

• Next, we conditionally rendered a div with class name of floating. This is the actual popover component that opens when you hover on the image.

  • We made use of the floating-ui library and its basic hover example to achieve the hover effect for the popover.

• Inside the popover we conditionally loaded the UserProfile and the skeleton loader. This loader appears when we are fetching the data for the user’s profile. More on this later.

• We made use of the react-content-loader library in the MyLoader component. This library also has a website that helps you to create loaders, you can check it out here.

UserProfile Component

Now that we have defined our Popover example, it is time for us to get into the details of the UserProfile component.

This component appears inside the popover component. The purpose of this component is to load the name email phone website details which are fetched from JSON placeholder API.

To demonstrate the prefetching example, we have to make sure that the UserProfile component only acts as a presentational component; that is, no explicit fetching logic is present inside of it.

The key thing to note about this component is that fetching the data happens from the parent component which is the PopoverExample component. In this component, we start fetching the data when the mouse enters this component (the mouseenter event). This is the solution #1 we discussed previously.

This gives you enough time for fetching the data until the user hovers on the image. Here’s the code:

import { useEffect, useState } from "react";
import ContentLoader from "react-content-loader";

const MyLoader = () => (
    <ContentLoader
        speed={2}
        viewBox="0 0 476 124"
        backgroundColor="#d1d1d1"
        foregroundColor="#fafafa"
    >
        <rect x="4" y="43" rx="0" ry="0" width="98" height="30" />
    </ContentLoader>
);

export default function UserProfile(props: Record<string, string | boolean>) {
    const { name, email, phone, website, hasAdditionalDetails } = props;
    const [isLoading, setIsLoading] = useState(false);
    const [additionalData, setAdditionalData] = useState(0);

    useEffect(() => {
        if (hasAdditionalDetails) {
            setIsLoading(true);
            fetch("https://jsonplaceholder.typicode.com/albums")
                .then((resp) => resp.json())
                .then((data: Array<unknown>) => {
                    const albumCount = data.reduce((acc, curr) => {
                        if (curr.userId === 1) acc += 1;

                        return acc;
                    }, 0);
                    setAdditionalData(albumCount);
                })
                .finally(() => {
                    setIsLoading(false);
                });
        }
    }, [hasAdditionalDetails]);

    return (
        <div id="user-profile">
            <div id="user-name">name: {name}</div>
            <div id="user-email">email: {email}</div>
            <div id="user-phone">phone: {phone}</div>
            <div id="user-website">website: {website}</div>
            {hasAdditionalDetails && (
                <>
                    {isLoading ? (
                        <MyLoader />
                    ) : (
                        <div id="user-albums">Album Count: {additionalData}</div>
                    )}
                </>
            )}
        </div>
    );
}

This component makes use of the hasAdditionalDetails prop. The purpose of this prop is to load additional data when the component mounts. It illustrates the solution #2 mentioned above.

UserProfileWithFetching Component

This component is pretty similar to that of the UserProfile component. It just contains the logic for fetching data when the component loads. The purpose of this component is to show what the general solution without the prefetching technique would look like.

So this component will always load the data when the component mounts, which displays the skeleton loader.

Here is the code:

import { useEffect, useState } from "react";
import { MyLoader } from "./PopoverExample";

export default function UserProfileWithFetching() {
    const [isLoading, setIsLoading] = useState(false);
    const [data, setData] = useState<Record<string, string>>({});

    useEffect(() => {
        setIsLoading(true);
        fetch("https://jsonplaceholder.typicode.com/users/1")
            .then((resp) => resp.json())
            .then((data) => {
                setData(data);
                setIsLoading(false);
            });
    }, []);

    if (isLoading) return <MyLoader />;

    return (
        <div id="user-profile">
            <div id="user-name">name: {data.name}</div>
            <div id="user-email">email: {data.email}</div>
            <div id="user-phone">phone: {data.phone}</div>
            <div id="user-website">website: {data.website}</div>
        </div>
    );
}

The entire code for this app can be found here.

Too much prefetching can also cause slowness

A word of advice, too much prefetching is not good because:

• It might slow your app down.

• It can degrade user experience if prefetching is not applied strategically.

Prefetching needs to be applied when you know the behavior of the user. That is, you are able to predict the user movement by metrics and be able to tell if they visit a page often. In that case, prefetching is a good idea.

So remember to always apply prefetching strategically.

Summary

That’s all folks! Hope you like my blog post. In this blogpost, you learned that implementing prefetching can significantly enhance your web application’s speed and responsiveness, improving user satisfaction.

For further reading, please refer to the below articles:

• Prefetching pages

• Preload, Prefetch And Priorities in Chrome

• What not to prefetch

For more content, you can follow me on Twitter, GitHub, and LinkedIn.

Developers rely on tools like compilers and bundlers to transform their code, optimize performance, and ensure compatibility across different environments.

These tools are essential for modern JavaScript applications, enabling developers to write clean, maintainable code while leveraging the latest language features.

This article will help you understand what Speedy Web Compiler (SWC) is and how it helps optimize the performance of your web apps.

Table of Contents

• Introduction to Speedy Web Compiler

• Background of SWC

• How Speedy Web Compiler Works

• Benefits of Using Speedy Web Compiler

• How to Set Up Speedy Web Compiler in Your Project

• SWC Integration in Popular Frameworks

• Conclusion

What is Speedy Web Compiler?

First, let me break it down.

SWC stands for Speedy Web Compiler, and when broken down:

Speedy - This means it's fast! SWC processes and transforms JavaScript code, making it efficient to use in big projects.

Web - It’s all about web development. It focuses on improving how JavaScript (the language of the web) handles it.

Compiler - It takes code written in one form and transforms it into another form that can be better understood or used by computers.

Background of SWC

kdy1, a South Korean developer and maintainer of Next.js, created SWC as a faster tool for handling JavaScript code.

The motivation was the need for speed and efficiency, as web projects grow larger and more complex.

With numerous websites and apps depending on JavaScript, SWC helps developers save time and work more efficiently.

How Speedy Web Compiler Works

SWC uses Rust, a programming language known for its speed and safety.

SWC works by taking your JavaScript or TypeScript code and transforming it into a version that can run efficiently in various environments.

Understanding how SWC achieves this involves examining its core steps: parsing, transforming, and generating code.

How Does SWC Parse Code?

The first step in the compilation process is parsing.

Begins by reading and analyzing the code to understand its structure.

This is akin to taking a complex sentence and breaking it down into its grammatical components—subject, verb, object, etc.

In technical terms, SWC converts your code into an Abstract Syntax Tree (AST).

The AST is a tree-like representation of the source code, where each node in the tree corresponds to a construct occurring in the code, such as expressions, statements, and functions.

This tree structure allows SWC to process and understand the code’s logic in a way that is both efficient and scalable.

How Does SWC Transform Code?

After creating the AST, SWC moves on to the transformation phase.

This is where the magic happens—SWC applies various optimizations and changes to the code based on the target environment.

For instance, if you're targeting older browsers that don't support modern JavaScript features, SWC will transform your ES6+ code into a backward-compatible version.

During this phase, SWC also handles TypeScript transformations. It strips away TypeScript-specific syntax, such as types and interfaces, converting the code into pure JavaScript that gets executed by any JavaScript engine.

SWC can apply custom transformations based on plugins or specific configurations, making it highly versatile.

How Does SWC Generate Optimized Code?

After the transformations are complete, SWC proceeds to the final step: code generation.

In this step, SWC takes the transformed AST and converts it back into executable code.

In contrast, this process is not just a reversal of the parsing process.

SWC takes special care to generate code that is both functionally correct and optimized for performance.

For instance, SWC might remove dead code (code that will never be executed) or inline certain functions to reduce overhead.

The goal is to produce code that is as clean and efficient as possible, ensuring that it runs quickly and reliably in production environments.

Benefits of Using Speedy Web Compiler

Performance

One of the major benefits of using SWC is its outstanding speed. SWC achieves this exceptional speed by using Rust.

Developers can expect a significant performance improvement when compiling their code for large projects or codebases.

This speed greatly reduces build times, enhancing the efficiency and responsiveness of the development process. It is so fast, you might think it’s late for a meeting!

Optimized Output

SWC compiles your code and guarantees that the output is highly optimized for performance in production environment by removing dead code, in-lining functions, and reducing the size of the output.

This makes using SWC cost-effective, saving you from extra expenses during production.

The result is a leaner, faster, and more efficient code that can enhance loading times and performance in web applications.

Compatibility

SWC is fully compatible with modern JavaScript libraries and frameworks.

You do not have to worry about using ES6+ or TypeScript. This makes SWC a versatile choice for your projects.

How to Set Up Speedy Web Compiler

Installation

To install SWC in your JavaScript or TypeScript project, follow these steps:

1. Initialize your project: If you haven't already, start by initializing a new project. In your terminal, run:

npm init -y

2. Install SWC with npm: Run the following command to download the pre-built binaries:

npm install -D @swc/cli @swc/core

3. Create a JavaScript file: Create a src/index.js file with some code:

const greet = (name) => {
  return `Hello, ${name}!`;
};

console.log(greet("World"));

4. Compile with SWC: Run SWC from the command line to compile your JavaScript file:

npx swc src/index.js -o dist/index.js

5. Resulting Code: The resulting JavaScript code in dist/index.js will look like this:

"use strict";
var greet = function(name) {
    return "Hello, " + name + "!";
};
console.log(greet("World"));

This is the transpiled ES5 code produced by SWC, suitable for environments that require backward compatibility with older JavaScript versions.

SWC Integration in Popular Frameworks

If you are using Next.js, Deno, Vite, Remix, Parcel, or Turbopack, SWC is already integrated.

Notable improvements were made on Next.js, a popular React framework, since version 12 (Source: Next.js 12: The SDK for the Web)

Conclusion

In the constantly changing realm of JavaScript development, having the correct tools can make a significant difference.

SWC, the Speedy Web Compiler, distinguishes itself as a strong solution for converting and optimizing JavaScript and TypeScript code.

Its impressive speed, owing to its Rust-based implementation, along with its efficient management of code transformations and optimizations, positions it as a powerful tool for modern web development.

If you would like to stay in touch:

Connect with me on LinkedIn

Follow me on X

An application that takes more than 3 seconds to load is considered slow and may cause users to leave the application or website.

Next.js is a React-based framework you can use to build scalable, performant, and faster web applications and websites. With the inclusion of React Server Components in the Next.js app router release, developers have a new mental model for "thinking in a server components" way. It solves the problem with SEO, helps create zero bundle size React components, and the end result is faster loading of UI components.

But your application may not be always about the server components. You may need to use client components as well. Also, you may want to load them either as part of the application's initial load or on demand (say at the click of a button).

Loading a client component on the browser includes downloading the component code into the browser, downloading all the libraries and other components you had imported into that client component, and a few additional things that React takes care of for you to make sure your components are working.

Based on the user's internet connection and other network factors, the entire loading of the client component may take a while, which may keep your users from using the application more quickly.

This is where Lazy Loading techniques can come in handy. They can help save you from a monolithic loading of your client components on the browser.

In this article, we will discuss a couple of lazy loading techniques in Next.js for client component loading optimization. We will also talk about a few edge cases you should know to handle.

If you like to learn from video content as well, this article is also available as a video tutorial here: 🙂

Before we get started, a couple of things for you:

• We will write a bunch of code to build an app to demonstrate the lazy loading techniques. You can find all the source code from this GitHub repository: https://github.com/tapascript/nextjs-lazy-load. But I strongly suggest that you write the code yourself as we proceed and use the repository only as a reference.
• You can also access the app deployed publicly on Netlify here.

Let's start 🚀. Oh yes, if you are Tom & Jerry cartoon lover, you are going to enjoy this even more!

Table of Contents

• What is Lazy Loading?
• Lazy Loading Techniques in Next.js
• Lazy Loading with dynamic import and next/dynamic
• Lazy Loading with React.lazy() and Suspense
• How to Lazy Load the Named Exported Components
• Lazy Loading Your Server Components
• Should We Lazy Load All Client Components in Next.js?
• What's Next?

What is Lazy Loading?

In modern day web application development, we don't code all the logic in one JavaScript/TypeScript file, or all the styles into one mammoth CSS file. Rather, we split them at the source code level and create logical modules, business logic, presentational components, and style related files. This helps us organize our code better.

Then we use something called a bundler which kicks in at the build phase of the application development process. It creates bundles for our scripts and styles. Some of the famous bundlers are Webpack, Rollup, and Parcel, among others.

Bundler creating bundles from the source code

Now, as we have the bundles, if we try to load them on the browser all together, we will encounter some slowness. This is because the complete bundle needs to be loaded into the browser for the user interface to be functional.

Loading a huge bundle results in a poor loading experience

So, instead of waiting for the huge bundle to get loaded into the browser, modern web development libraries and tooling systems allow us to load the bundle in chunks.

We may want to load some of the chunks immediately, as users may need them sooner as the application loads. At the same time, we may want to wait to load certain parts of a web page until they're needed.

Breaking into chunks and loading what is needed

This mechanism of waiting to load part of the pages or application, and loading them only when they are absolutely necessary, is called Lazy Loading. The concept of lazy loading is not React or Next.js-specific. It is a performance optimization technique that you can implement with various libraries and frameworks.

Lazy Loading Techniques in Next.js

Lazy loading techniques in Next.js is used to reduce the amount of JavaScript needed by a route. This helps the initial load performance of the application be faster. We can defer the load of the client components and imported libraries until they are needed.

There are two ways we can implement lazy loading techniques in Next.js:

• Using dynamic imports with the help of the next/dynamic package.
• Using a combination of React.lazy() and Suspense.

Let's understand each of these techniques with code examples.

Lazy Loading With dynamic import and next/dynamic

next/dynamic is a combination of React.lazy() and Suspense from ReactJS. Using a dynamic import with the next/dynamic package is a preferred approach to achieve lazy loading in Next.js.

To demonstrate it, let's first create a Next.js app using the following command:

npx create-next-app@latest

You can start the app locally using the following command:

## Using npm
npm run dev

## Using yarn
yarn dev

## Or use pnpm, bun, whatever you wish!

Now create a folder called components under the app/ directory. We will create all our components under the component folder. Now, create a folder called tom under the app/components/. Finally, create a React component called tom.jsx under the app/components/tom/ directory with the following code:

// tom.jsx

const LazyTom = () => {
  return (
    <div className="flex flex-col">
      <h1 className="text-3xl my-2">The Lazy Tom</h1>
      <p className="text-xl my-1">
        Tom, named &quot;Jasper&quot; in his debut appearance, is a gray and white
        domestic shorthair cat 🐈. &quot;Tom&quot; is a generic name for a male cat. He is
        usually but not always, portrayed as living a comfortable, or even
        pampered life. Tom is no match for Jerry&apos;s wits.
      </p>
      <p className="text-xl my-1">
        Although cats typically chase mice to eat them, it is quite rare for Tom
        to actually try to eat Jerry. He tries to hurt or compete with him just
        to taunt Jerry, even as revenge, or to obtain a reward from a human,
        including his owner(s)/master(s), for catching Jerry, or for generally
        doing his job well as a house cat. By the final &quot;fade-out&quot; of each
        cartoon, Jerry usually gets the best of Tom.
      </p>
    </div>
  );
};

export default LazyTom;

To explain the above code:

• We have created a ReactJS component called LazyTom.
• It is a simple presentational component which has a heading and a couple of paragraphs talking about the cat, Tom, from the famous Tom & Jerry cartoon.
• At the end, we have default exported the component to import it elsewhere.

Now, create another file called tom-story.jsx under the app/components/tom/ directory with the following code:

// tom-story.jsx

"use client";

import { useState } from "react";
import dynamic from "next/dynamic";

const LazyTom = dynamic(() => import("./tom"), {
    loading: () => <h1>Loading Tom&apos;s Story...</h1>,
});

function TomStory() {
    const [shown, setShown] = useState(false);

    return (
        <div className="flex flex-col m-8 w-[300px]">
            <h2 className="text-xl my-1">Demonstrating <strong>dynamic</strong></h2>
            <button
                className="bg-blue-600 text-white rounded p-1"
                onClick={() => setShown(!shown)}
            >
                Load 🐈 Tom&apos;s Story
            </button>

            {shown && <LazyTom />}
        </div>
    );
}

export default TomStory;

The main magic of lazy loading with dynamic is happening in the above code:

• We have created a client component called TomStory using the "use client" directive.
• First, we have imported the useState hook for managing a toggle state, and the dynamic function from the next/dynamic for the lazy loading of the component we created before.
• The dynamic function takes a function as an argument that returns the imported component. You can also configure a custom loading message by providing an optional configuration object as argument to the dynamic function.
• The dynamic() function returns the lazily loaded component instance – that is, LazyTom (could be any name). But this component is not loaded yet.
• In the JSX, we have a toggle button that shows and hides the LazyTom component. Note that the component will be lazy loaded into the user browser at the first instance of a button click. After that, if you hide and show it again, the LazyTom component will not be reloaded until we hard refresh the browser or clear the browser cache.
• Finally, we have default exported the TomStory component.

Now we need to test it out. To do that, open the page.js file in the app/ directory and replace the content with the following code:

import TomStory from "./components/tom/tom-story";

export default function Home() {
  return (
    <div className="flex flex-wrap justify-center ">
      <TomStory />
    </div>
  );
}

This is a simple ReactJS component that imports the TomStory component and uses it in its JSX. Now open your browser window. Open the browser's DevTools and open the Network tab. Make sure that the All filter is selected.

Now access the app on your browser using http://localhost:3000. You should see the button to load Tom's story. Also a bunch of resources will be listed on the Network tab. These are resources required in the initial load of the application and have been downloaded on your browser.

The LazyTom component from the tom.jsx has not been downloaded yet. This is because we haven't yet clicked on the Load Tom's Story button.

The button to lazy load Tom's story

Now, click on the button. You should see a loading message for a moment and then the component will be loaded with Tom's story. You can now see the tom.jsx component listed in the Network tab and also the component rendered on the page with the Tom's story.

Now Tom's story is lazily loaded

Now that you have experienced how the dynamic function from next/dynamic helps us load a component lazily, let's get started with the other technique using React.lazy() and Suspense.

Lazy Loading with React.lazy() and Suspense

To demonstrate this technique, let's start with Jerry's story, my favourite character from the Tom & Jerry cartoon.

First, we'll create a folder called jerry under the app/components/ directory. Now, create a file called jerry.jsx under the app/components/jerry/ with the following code:

// jerry.jsx

const LazyJerry = () => {
  return (
    <div className="flex flex-col justify-center">
      <h1 className="text-3xl my-2">The Lazy Jerry</h1>
      <p className="text-xl my-1">
        Jerry 🐀, whose name is not explicitly mentioned in his debut appearance,
        is a small, brown house mouse who always lives in close proximity to
        Tom. Despite being very energetic, determined and much larger, Tom is no
        match for Jerry&apos;s wits. Jerry possesses surprising strength for his
        size, approximately the equivalent of Tom&apos;s, lifting items such as
        anvils with relative ease and withstanding considerable impacts.
      </p>
      <p className="text-xl my-1">
        Although cats typically chase mice to eat them, it is quite rare for Tom
        to actually try to eat Jerry. He tries to hurt or compete with him just
        to taunt Jerry, even as revenge, or to obtain a reward from a human,
        including his owner(s)/master(s), for catching Jerry, or for generally
        doing his job well as a house cat. By the final &quot;fade-out&quot; of each
        cartoon, Jerry usually gets the best of Tom.
      </p>
    </div>
  );
};

export default LazyJerry;

The content of jerry.jsx is structurally similar to tom.jsx. Here we have posted Jerry's story, instead of Tom's, and default exported the component.

Like the last time, let's create a jerry-story.jsx file to showcase the lazy loading of Jerry's story. Create the file under the app/components/jerry/ directory with the following code:

// jerry-story.jsx

"use client";

import React, { useState, Suspense } from "react";

const LazyJerry = React.lazy(() => import('./jerry'));

function JerryStory() {
    const [shown, setShown] = useState(false);

    return (
        <div className="flex flex-col m-8 w-[300px]">
            <h2 className="text-xl my-1"> Demonstrating <strong>React.lazy()</strong></h2>
            <button
                className="bg-pink-600 text-white rounded p-1"
                onClick={() => setShown(!shown)}
            >
                Load 🐀 Jerry&apos;s Story
            </button>

            {shown && <Suspense fallback={<h1>Loading Jerry&apos;s Story</h1>}>
                <LazyJerry />
            </Suspense>}
        </div>
    );
}

export default JerryStory;

Here also we have a client component, and we will be using the lazy() method and Suspense from React, so we have imported them. Like the dynamic() function in the last technique, the lazy() function also takes a function as an argument that retrurns the lazily imported component. We have also provided the relative path to the component that we are trying to load.

Note that with dynamic() we had an opportunity to customize the loading message as part of the function itself. With lazy(), we will be doing that as part of the Suspense fallback.

Suspense uses a fallback when you wait for the data to load. If you would like to understand the Suspense and Error Boundary from ReactJS in-depth, you can check out this video tutorial.

Here, as our LazyJerry component is loading lazily, we have provided a fallback to show a loading message until the component code is download into the browser successfully and rendered.

{shown && 
    <Suspense fallback={<h1>Loading Jerry&apos;s Story</h1>}>
                <LazyJerry />
    </Suspense>
}

Also, as you can see, we are loading the component on the first button click. Here also, the component will not be reloaded every time we click on the button unless we refresh the browser or clear the browser cache.

Let's now test it by importing it into the page.js file and adding the component in its JSX.

// page.js

import TomStory from "./components/tom/tom-story";
import JerryStory from "./components/jerry/jerry-story"; 

export default function Home() {
  return (
    <div className="flex flex-wrap justify-center ">
      <TomStory />
      <JerryStory />
    </div>
  );
}

Now, you'll see another component appear on the user interface with a button to load Jerry's story. At this stage, you will not see the jerry.jsx component loaded into the browser.

The button to lazy load Jerry's story

Now, click on the button. You will see that the component is loaded, and you can see it on the Network tab list. You should be able to read Jerry's story rendered as part of the lazily loaded component.

Jerry's story is lazily loaded

How to Lazy Load the Named Exported Components

So far, with both the techniques we have imported a component that was exported with the default export and then lazy loaded it. In JavaScript (and so in React), you can export and import modules in two different ways:

• With the default keyword. In this case, the exported module can be imported with any name. You would use this if you wanted to export only one functionality from a module.
• Without the default keyword, this is called a named export. In this case, you have to maintain the same module name for the export and import. You also need to enclose the module name in the curly brackets ({...}) while importing. You would use this if you wanted to export multiple functionalities from a module.

If you want to get into JavaScript modules and how they work in greater detail, I would suggest going through this crash course published on freeCodeCamp's YouTube channel.

To demonstrate the lazy loading of a named export component, let's create another simple presentational React component. This time we will use the angry but cute dog named Spike from the Tom & Jerry cartoon.

Create a folder called spike under the app/components/ directory. Now, create a file called spike.jsx under the app/components/spike/ directory with the following code:

// spike.jsx

export const LazySpike = () => {
  return (
    <div className="flex flex-col">
      <h1 className="text-3xl my-2">The Lazy Spike</h1>
      <p className="text-xl my-1">
        In his attempts to catch Jerry, Tom often has to deal with Spike 🦮, known
        as &quot;Killer&quot; and &quot;Butch&quot; in some shorts, an angry, vicious but easily
        duped bulldog who tries to attack Tom for bothering him or his son Tyke
        while trying to get Jerry. Originally, Spike was unnamed and mute, aside
        from howls and biting noises as well as attacking indiscriminately, not
        caring whether it was Tom or Jerry though usually attacking Tom.
      </p>
      <p className="text-xl my-1">
      In
        later cartoons, Spike spoke often, using a voice and expressions,
        performed by Billy Bletcher and later Daws Butler, modeled after
        comedian Jimmy Durante. Spike&apos;s coat has altered throughout the years
        between gray and creamy tan. The addition of Spike&apos;s son Tyke in the
        late 1940s led to both a slight softening of Spike&apos;s character and a
        short-lived spin-off theatrical series called Spike and Tyke.
      </p>
    </div>
  );
};

Again, this component is structurally exactly same as the tom.jsx and jerry.jsx components we have seen before, but with two major differences:

1. Here, we have exported the component without the default keyword, hence it is a named export.
2. We are talking about the dog, Spike.

Now, we need to handle the lazy loading of a named exported component and it's going to be a bit different from the default exported component.

Create a file called spike-story.jsx under the app/components/spike/ directory with the following code:

// spike-story.jsx

"use client";

import { useState } from "react";
import dynamic from "next/dynamic";

const LazySpike = dynamic(() => import("./spike").then((mod) => mod.LazySpike), {
    loading: () => <h1>Loading Spike&apos;s Story...</h1>,
});

function SpikeStory() {
    const [shown, setShown] = useState(false);

    return (
        <div className="flex flex-col m-8 w-[300px]">
            <h2 className="text-xl my-1">Demonstrating <strong>Named Export</strong></h2>
            <button
                className="bg-slate-600 text-white rounded p-1"
                onClick={() => setShown(!shown)}
            >
                Load 🦮 Spike&apos;s Story
            </button>

            {shown && <LazySpike />}
        </div>
    );
}

export default SpikeStory;

Like tom-story, we are using the dynamic import with the next/dynamic. But let's zoom into the following block from the above code:

const LazySpike = dynamic(() => import("./spike").then((mod) => mod.LazySpike), {
    loading: () => <h1>Loading Spike&apos;s Story...</h1>,
});

The changes you will notice here are that we are resolving the promise explicitly from the import("./spike") function using the the .then() handler function. We get the module first, and then pick the exported component by its actual name – that is LazySpike in this case. The rest of the things remain the same as before as in the tom-story.

Now to test it out, again import the component into the page.js file, and use it in the JSX like the last two times.

// page.js

import TomStory from "./components/tom/tom-story";
import JerryStory from "./components/jerry/jerry-story";
import SpikeStory from "./components/spike/spike-story"; 

export default function Home() {
  return (
    <div className="flex flex-wrap justify-center ">
      <TomStory />
      <JerryStory />
      <SpikeStory />
    </div>
  );
}

There you go – you should see the new component rendered on the browser with a button to load Spike's story from the spike.jsx file which is not loaded yet.

The button to lazy load Spike's story

Clicking on the button will load the file into the browser and render the component to show you Spike's story.

Spike's story is lazily loaded

Below you can see all three components demonstrating three different techniques and uses cases side-by-side. You can test them together. The image below is showcasing lazy loading of two components in parallel where another component was already lazily loaded.

Lazily loading multiple components in parallel

Here is another case where all three components were lazy loaded, on demand with the respective button clicks.

All the stories lazy loaded

Lazy Loading Your Server Components

We spoke about the lazy loading techniques of client components. Can we use the same on server components as well? Well, you can but you don't have to, as server components are already code split and the loading aspect is already been taken care of by Next.js. You are not going to get any kind of error if you are trying to do so, but it would be unnecessary.

In case, you are dynamically importing a server component that has one or more client components as children, those client components will be lazy loaded. But there won't be any impact on the (parent) server component itself.

Here is an example of a server component that has two client components as children:

// server-comp.jsx

import ComponentA from "./a-client-comp";
import ComponentB from "./b-client-comp";

import React from 'react'

const AServerComp = () => {
  return (
    <div className="flex flex-col m-8 w-[300px]">
      <ComponentA />
      <ComponentB />
    </div>
  )
}

export default AServerComp

Now, we are dynamically importing the server component into the page.js file and using it in its JSX. The child client components of the dynamically imported server component will be lazy loaded, but not the server component itself.

// page.js

import dynamic from "next/dynamic";

import TomStory from "./components/tom/tom-story";
import JerryStory from "./components/jerry/jerry-story";
import SpikeStory from "./components/spike/spike-story";

const AServerComp = dynamic(() => import('./components/server-comps/server-comp'), {
  loading: () => <h1>Loading Through Server Component...</h1>,
})


export default function Home() {
  return (
    <div className="flex flex-wrap justify-center ">
      <TomStory />
      <JerryStory />
      <SpikeStory />

      <AServerComp />
    </div>
  );
}

Should We Lazy Load All Client Components in Next.js?

I had this question when I first started learning about lazy loading. Now that I have gained more experience with this technique, here is my perspective:

You don't have to lazy load all client components. Optimzation is great, but over optimization can have adverse effects. You need to identify where these optimizations are required.

• Do you have client components that are really bulky?
• Are you unnecessarily putting so many things into one component that you should break it down and refactor?
• Do you import heavy libraries into your client components?
• Have you opted for tree-shaking?
• Can you mark bulky client components per route and is it fine not to load some or all of them at the initial load of the page for that route?

As you see, these are a bunch of meaningful questions to ask before you step into optimizing things. Once you have answers, and decide you need lazy loading, then you can implement the techniques you learned from this article.

What's Next?

That's all for now. Did you enjoy reading this article and have you learned something new? If so, I would love to know if the content was helpful. I have my social handles provided below.

Up next, if you are willing to learn Next.js and its ecosystem like Next-Auth(V5) with both fundamental concepts and projects, I have a great news for you: you can check out this playlist on my YouTube channel with 20+ video tutorials and 11+ hours of engaging content so far, for free. I hope you like them as well.

Let's connect.

• Subscribe to my YouTube Channel.
• Follow me on X (Twitter) or LinkedIn if you don't want to miss the daily dose of up-skilling tips.
• Check out and follow my Open Source work on GitHub.
• I regularly publish meaningful posts on my GreenRoots Blog, you may find them helpful, too.

See you soon with my next article. Until then, please take care of yourself, and keep learning.

In the world of network optimization, Content Delivery Networks (CDNs) and caching play a vital role in improving website performance and user experience.

And while both aim to speed up website loading times, they have distinct purposes and mechanisms.

In this tutorial, we'll dive deep into the details of CDNs and caching to understand their similarities, differences, and how they contribute to enhancing online experiences.

Here's what we'll cover:

1. What is Caching?
2. What is a Content Delivery Network (CDN)?
3. Caching vs CDNs – What's the Difference?
4. When to Use Caching
5. When to use CDNs
6. Combining Caching and CDNs
7. Wrapping Up

What is Caching?

Imagine you’re a librarian managing a popular library. Every day, readers come in asking for the same set of books like “Think and Grow Rich” or “The Intelligent Investor.”

Initially, you fetch these books from the main shelves, which takes time and effort. But soon, you notice a pattern: the same set of books are requested repeatedly by different readers. So, what do you do?

You decide to create a special section near the entrance where you keep copies of these frequently requested books. Now, when readers come asking for them, you don’t have to run to the main shelves each time. Instead, you simply hand them the copies from the special section, saving time and making the process more efficient.

This special section represents the cache, storing frequently accessed books for quick retrieval.

Caching is a technique used to store copies of frequently accessed data temporarily. The cached data can be anything from web pages and images to database query results. When a user requests cached content, the server retrieves it from the cache instead of generating it anew, significantly reducing response times.

When a web server receives a request, it can follow different caching strategies to handle it efficiently. One prevalent strategy is known as read-through caching:

1. Request Received: The web server gets a request from a client.
2. Check Cache: It first looks into the cache to see if the response to the request is already there.
3. Cache Hit: If the response is in the cache (hit), it sends the data back to the client right away.
4. Cache Miss: If the response isn’t in the cache (miss), the server queries the database to fetch the required data.
5. Store in Cache: Once it gets the data from the database, it stores the response in the cache for future requests.
6. Send Response: Finally, the server sends the data back to the client.

What to Consider When Implementing a Cache System

Decide When to Use a Cache:

• A cache is best for frequently read but infrequently modified data.
• Cache servers are not suitable for storing critical data as they use volatile memory.
• Important data should be stored in persistent data stores to prevent loss in case of cache server restarts.

Set an Expiration Policy:

• Implement an expiration policy to remove expired data from the cache.
• Avoid setting expiration dates too short (to prevent frequent database reloads), and too long (to prevent stale data).

Maintain Synchronization Between Data Stores and Cache

• Inconsistencies can arise due to separate operations on data storage and cache, especially in distributed environments.

Mitigate Failures:

• Use multiple cache servers across different data centers to avoid single points of failure.
• Over-provision memory to accommodate increased usage and prevent performance issues.

Implement an Eviction Policy:

• When the cache is full, new items may cause existing ones to be removed (cache eviction).
• A popular eviction policy is Least Recently Used (LRU), but other policies like Least Frequently Used (LFU) or First In, First Out (FIFO) can be chosen based on specific use cases.

Real-World Applications of Caching

Social Media Platforms: Imagine scrolling through your Facebook feed. Thanks to caching, you see profile pictures, trending posts, and recently liked content instantly, even if millions of users are accessing the platform simultaneously.

Caching these frequently accessed elements on servers or your device minimizes delays and makes the experience smoother and more engaging.

E-commerce Websites: When browsing Amazon for a new gadget, you expect a seamless shopping experience. Caching plays a crucial role here. Product images, descriptions, and pricing information are cached, enabling the website to display search results and product pages rapidly.

This is especially crucial during peak seasons like Black Friday or Cyber Monday, where caching helps handle surges in traffic and ensures customers can complete their purchases without encountering delays.

Content Management Systems (CMS): Millions of websites rely on CMS platforms like WordPress. To ensure smooth performance for all these users, many CMS platforms integrate caching plugins. These plugins cache frequently accessed pages, reducing the load on the server and database.

This translates to faster page loading times, improved SEO ranking due to faster indexing by search engines, and a more responsive website overall, providing a better experience for visitors.

What is a Content Delivery Network (CDN)?

Now, think of a CDN as a global network of book delivery trucks. Instead of storing all the books in one central library, you have local branches worldwide, each with copies of the most popular books.

When readers request a book, you don’t have to ship it from the main library. Instead, you direct them to the nearest branch, where they can quickly pick up a copy. This cuts down on travel time (data transfer time) and keeps everyone happy with fast access to their favorite books.

In technical terms, a CDN is a network of servers distributed across various locations globally. Its primary purpose is to deliver web content, such as images, videos, scripts, and stylesheets to users more efficiently by reducing the physical distance between the server and the user.

How CDNs Work:

First, imagine that User A wants to see an image on a website. They click on a link provided by the CDN, like “https://mywebsite.cloudfront.net/image.jpg". This requests the image.

Then, if the image isn’t in the CDN’s storage (cache), the CDN fetches the image from the original source, like a web server or Amazon S3.

In response to that, the original source sends the image back to the CDN. It might include a Time-to-Live (TTL) header, indicating how long the image should stay cached.

Next, the the CDN stores the image and serves it to User A. It stays cached until the TTL expires.

Then let's say that user B requests the same image. At that point, the CDN checks if it’s still in the cache. If the image is still cached (TTL hasn’t expired), the CDN serves it from there (a hit). Otherwise (a miss), it fetches a fresh copy from the origin.

What to Consider When Implementing a CDN

• Cost Management: CDNs charge for data transfers. It’s wise to cache frequently accessed content, but not everything.
• Cache Expiry: Set appropriate cache expiry times. Too long, and content might be stale. Too short, and it strains origin servers.
• CDN Fallback: Plan for CDN failures. Ensure your website can switch to fetching resources directly from the origin if needed.
• Invalidating Files: You can remove files from the CDN before they expire using various methods provided by CDN vendors.

Real-World Applications of a CDN

Video Streaming Services: Imagine you're in Sydney, Australia, craving to watch the latest season of your favorite show on Netflix. Without a CDN, the data would have to travel all the way from a server in, say, California, leading to buffering and frustrating delays.

But thanks to CDNs, Netflix caches popular content on edge servers closer to you, in Sydney or its surrounding region. This significantly reduces the distance the data needs to travel, ensuring smooth playback and an uninterrupted viewing experience, regardless of your location.

In fact, studies show that CDNs can reduce video startup time by up to 50%, making a significant difference in user satisfaction.

Gaming Content Distribution: Gamers know the pain of waiting for massive game updates or DLC downloads. But companies like Steam and Epic Games leverage CDNs to make things faster.

These platforms cache game files, updates, and multiplayer assets on edge servers close to gaming communities. This means whether you're downloading a new game in New York or patching your favorite title in Tokyo, the data doesn't have to travel across continents.

Using CDNs can decrease download times quite a bit, leading to quicker access to the games you love and smoother multiplayer experiences with minimal lag.

Global News Websites: Staying informed about global events shouldn't be hindered by slow loading times. Major news organizations like BBC News and The New York Times use CDNs to ensure their breaking news updates and multimedia content reach audiences worldwide instantly.

By caching critical information like articles, videos, and images on servers across different continents, CDNs enable news websites to deliver real-time updates quickly, keeping readers informed regardless of their location.

During major events or emergencies, this can be especially crucial, as evidenced by a case study where a news organization using a CDN reported a 20% increase in website traffic without any performance issues during a breaking news event.

Caching vs CDNs – What's the Difference?

Similarities between caching and CDNs:

Improved Performance: Both CDNs and caching aim to enhance website performance by reducing latency and speeding up content delivery.

Efficient Resource Utilization: By serving cached or replicated content, both approaches help optimize resource utilization and reduce server load.

Enhanced User Experience: Faster load times lead to a better user experience, whether achieved through CDNs or caching.

Differences between Caching and CDNs

Scope:

• CDNs: CDNs are a network of servers located in different geographic locations around the world.
• Caching: Caching is a method of storing web content on a user’s local device or server.

Implementation:

• CDNs: CDNs require a separate infrastructure and configuration.
• Caching: Caching can be implemented within a web application or server using caching rules and directives.

Geographic Coverage:

• CDNs: Designed to deliver web content to users across the world.
• Caching: Typically used to improve performance for individual users or within a local network.

Network Architecture:

• CDNs: Use a distributed network of servers to cache and deliver content.
• Caching: This can be implemented using various types of storage such as local disk, memory, or a server-side cache.

Performance Benefits:

• CDNs: Provide faster and more reliable content delivery by caching content in multiple locations.
• Caching: Improves performance by reducing the number of requests to the origin server and delivering content faster from a local cache.

Cost:

• CDNs: Can be more expensive to implement and maintain due to the need for a separate infrastructure and ongoing costs for network maintenance.
• Caching: Can be implemented using existing infrastructure and server resources, potentially reducing costs.

When to use Caching

Caching is ideal for frequently accessed content that doesn't change frequently. This includes static assets like images, CSS files, and JavaScript libraries.

It's particularly effective for websites with a substantial user base accessing similar content, such as news websites, blogs, and e-commerce platforms.

Caching can also significantly reduce server load and improve response times for users, especially in scenarios where content delivery latency is a concern.

When to use CDNs

CDNs are invaluable for delivering content to a global audience, especially when geographical distance between users and origin servers leads to latency issues.

They are well-suited for serving dynamic content, streaming media, and handling sudden spikes in traffic.

CDNs also excel in scenarios where content needs to be delivered reliably and consistently across diverse geographic regions, ensuring optimal user experience regardless of location.

Combining Caching and CDNs

In many scenarios, employing both caching and CDNs together yields optimal results, particularly for dynamic websites and applications where a mix of static and dynamic content delivery is essential. Let's consider a popular news website as an example.

Imagine a bustling news website that regularly publishes breaking news articles, accompanied by images and videos. While the core news content is dynamic and frequently updated, the images and videos associated with older articles remain relatively static and are accessed repeatedly by users.

To address this, the website can implement a combined strategy:

1. Caching on the Origin Server: Frequently accessed elements like website templates, navigation menus, and static content are cached directly on the origin server. This caching reduces server load and enhances performance for initial page loads.
2. CDN Caching: The website leverages a CDN to cache frequently accessed images and videos associated with news articles on edge servers located worldwide. This ensures that users, regardless of their geographic location, can swiftly access these elements with minimal latency.

There are many benefits of the combined approach, such as:

• Faster Loading Times: By serving cached content from both the origin server and CDN edge servers, users experience significantly faster loading times, leading to a more engaging browsing experience.
• Reduced Server Load: Caching alleviates pressure on the origin server, enabling it to efficiently process dynamic content updates while serving static elements from cache.
• Improved Global Reach: The CDN ensures that users worldwide can access the website and its content with minimal delays, irrespective of their proximity to the origin server.

But there are also some factors to consider:

• Cache Invalidation: Regularly updating cached content ensures users access the latest information. Most CDNs offer efficient cache invalidation mechanisms to facilitate this process.
• Cost Optimization: While combining caching and CDNs enhances performance, it's crucial to evaluate the cost-effectiveness of caching specific content. Analyzing user access patterns helps determine the optimal caching strategy.

By strategically combining caching and CDNs, you and your team can create a robust content delivery infrastructure that delivers a superior user experience worldwide.

Wrapping Up

Both CDNs and caching play crucial roles in optimizing website performance and user experience by speeding up content delivery.

While caching stores frequently accessed data locally for quick retrieval, CDNs provide a geographically distributed network of servers to deliver content efficiently to users worldwide.

Understanding their similarities in performance improvement and resource utilization, as well as their key differences in scope, implementation, and cost is crucial for choosing the right approach for your specific needs.

Performance testing is a routine software practice which is carried out to determine the stability of a system in terms of scalability, reliability, and data management, among other parameters.

In this tutorial, I'll walk you through what performance testing entails, and the common tools used for backend testing. We'll also walk through a demo performance testing project together.

The tutorial is simplified and suitable for beginners, mid-level developers, and professional developers. Being proficient in performance testing is fundamental to growing as a backend developer, and this guide will serve as a good review even if you're more advanced in your career. With that said, let's dive in.

Prerequisites:

• Intermediate knowledge of Node.js
• Basic knowledge of JavaScript operations
• Knowledge of API development\

Table of Contents:

1. What is Performance Testing?
2. Examples of Performance Testing Tools
3. Demo Project
4. Conclusion

What is Performance Testing?

Performance testing serves quite a lot of purposes – one of the most important of which is to test system efficiency in performing and sustaining tasks. It also serves as a standard you can use to compare systems of varying efficiency and builds and enables you to choose the most effective one.

Performance testing also helps reveal vulnerabilities. State-of-the-art testing tools are well optimized to efficiently analyze the code to detect any errors. They're quick to highlight the areas where these errors occur.

The end goal of performance testing is dependent how you're using the application. It might be concurrency-oriented or transaction rate-oriented, depending on whether the app involves end users or not.

Performance testing could also involve load testing, which is usually carried out to evaluate the behavior of a web service under a specific expected load. Other types of testing you can do include integration testing, spike testing, soak testing, and stress testing.

Examples of Performance Testing Tools

There are many tools commonly used to test the efficacy and latency of web applications. In this section, I'll discuss some of the popular tools used, and highlight their strengths and use cases.

Jest

Jest is a multi-platform testing tool used to assess the correctness of JavaScript-based applications. It's the one we'll be using in this demo.

Jest was initially created to test the efficiency of React applications, but has since been extended to test the efficiency of Node.js apps as well. It also offers a code coverage feature.

Mocha

Mocha is a concise asynchronous JavaScript-based testing tool for Node.js applications. It is also used with assertion libraries such as [Chai]( https://www.npmjs.com/package/chai) and [should]( https://www.npmjs.com/package/should).

Pythagora

Pythagora offers a unique integrating testing feature to help test how different part of the application works together. It also has a code coverage feature.

Artillery

Artillery is a stack agnostic testing tool. This means it can be used for multiple web applications based on different programming languages and still produce an optimal test outcome.

This tool provides efficient load testing features which help to determine the optimal status of the application when exposed to a large load of traffic. It also checks the speed at which an app responds to a user request without crashing.

Ava

Ava is a JavaScript-based performance unit testing tool used to test the efficacy of Node.js applications. It works asynchronously, running multiple concurrent tests to determine the suitability of multiple code units.

Loadtest

Loadtest is a special Node package which is used to load test Node.js applications. It evaluates their ability to cope with requests of varying volumes and it evaluates for efficiency and concurrency.

Apache J-meter

Apache J-meter offers load-testing features for web applications. It has an in-built IDE to enable interaction with the user. It is multithreaded, increasing its ability to mimic several users.

There are other testing tools which are also useful. But in this tutorial, we will be utilizing Jest to test our back-end application.

Demo Project

Install Jest

We'll now perform a unit test on our code using the Jest testing tool. To do this, you'll need to install the Jest package in your code folder. Type npm install jest in the command prompt. A success message will be displayed when the installation is completed.

Configure package.json

In this tutorial, we'll test the efficiency of some selected routes in our Node.js application. This will necessitate writing different unit tests for each route and evaluating its correctness.

Now let’s optimize our file structure to successfully unit test our application. Navigate to the package.json file and edit it to include the following code:

"scripts": {
    "test": " jest",
    "start": "nodemon index.js"
  },

Modifying the package.json file to include this code ensures that the Node.js server recognizes Jest as our default unit testing tool for the project. By so doing, any time we enter npm test in the command prompt, Jest gets activated.

Set up the test environment

Create a folder in the root directory named “tests”. This helps the Jest operator locate the specific files housing the routes to be tested.

Within the test folder, create a test file. The file can be named whatever you prefer, but the suffix .test.js should be added to enable Jest to recognize it and execute it.

After completing these steps, let’s get into the core details of unit testing in our project.

Run the unit tests

The demo project we'll test in this tutorial is an eBook library application which contains some functions such as a get all books route, Get a single book route, upload a book route, and delete a book route. We'll create unit tests for the GetAllBooks route in the example below, and then you can try to create your own for the other routes.

So firstly, we'll import the book database into the test.js file like this:

const Book = require('../models/Book')

The code above imports and initializes our default book MongoDB database model.

Then we'll import the functions that we'll test in each route:

const Book =  require("../models/Book")

async function GetAllBooks (req, res)  {
    try {
const allBooks =  await Book.find();
res.status(200)
res.send(allBooks)
    }
    catch (err) {
res.status(500)
res.send(err) 
    }
}
module.exports = {GetAllBooks};

const {GetAllBooks} = require("../controllers/Books");

The code above imports the getAllBooks function from a controller folder.

Having imported the function, let's now go ahead to setup our Jest unit test function.

jest.mock("../models/Book");

const req = {};
const res = {
  status: jest.fn((x) => x),
  send: jest.fn((x) => x),
};

it("it should return all the books in the database", async () => {

Book.find.mockImplementationOnce(() => ({
    Title: "black is king",
    Author: "black",
    price: "$23",
    Summary: "Hello",
  }));

  await GetAllBooks(req, res);


expect(res.status).toHaveBeenCalledWith(200);

expect(res.send).toHaveBeenCalledTimes(1);
});

First of all, Jest offers you the ability to create a fake database by copying the structure of the default database. This is known as mocking. This enables the unit test to operate faster and eliminate the lag that comes with getting responses from large databases.

Testing which involves the real database is referred to as end-to-end testing as opposed to unit testing.

Here's how you can do that in Jest:

jest.mock("../models/Book");

The code above illustrates database mocking. In order to get a faster unit test, we have to mock the existing Book database model we're using in our application.

const req = {};
const res = {
  status: jest.fn((x) => x),
  send: jest.fn((x) => x),
};

The above code contains the default sample requests and response objects. The sample response object contains both the status and send functions, which return a defined output if executed successfully or not.

it("it should return all the books in the database", async () => {
Book.find.mockImplementationOnce(() => ({
    Title: "black is king",
    Author: "black",
    price: "$23",
    Summary: "Hello",
  }));
  await GetAllBooks(req, res); 
expect(res.status).toHaveBeenCalledWith(200);
expect(res.send).toHaveBeenCalledTimes(1);
});

Now the It function contains a short description of what the test should be about. This is then coupled to an anonymous asynchronous function which contains a mock implementation of the database model with some dummy data.

After that, the getAllBooks request is triggered and executed with a null request passed to it and the format of the response object is included.

The expect statement returns passed if the function satisfies the requirements expected. For this code, the requirements are that the response object should return a status code of 200 and the response.send object should be called at least once with the response object included. If it fails, a failed status will be returned.

Tests passing

You now know the basics of how to unit test functions. You can also try to test the delete book route, upload a book route and find a specific book route.

Conclusion

In this tutorial, you've been able to harness the usefulness of testing tools in optimizing your web applications.

You've learned about various testing tools available and their use cases, and you also implemented a unit test in a web application.

Following the steps highlighted in this tutorial, you will be able to perform unit tests on your coding projects.

I sincerely hope you learned something new and enjoyed this tutorial. Until next time, keep on coding.

In today's digital landscape, the performance of a website is a key factor in its success. Writing efficient CSS code can greatly influence how quickly your web pages load, impacting everything from user experience to search engine rankings.

This guide delves into effective strategies to help you refine your CSS, ensuring that your website not only looks great but also loads swiftly and runs smoothly.

How CSS affects Web Performance

When a user visits a webpage, the browser retrieves the site's structural HTML and its stylistic CSS. This is a set of detailed instructions on how each part of the webpage should look.

If the CSS is packed with too much information or is too complex, it's like giving the browser a puzzle that takes longer to solve. This can lead to longer waiting times for users, which can be annoying.

That's where the art of streamlining CSS comes into play. It's not just about tidying up the code, but also making sure the browser can get the webpage ready faster.

When CSS is made leaner and simpler, it's like giving the browser a clear, easy-to-follow map. This makes webpages load faster, making everything feel more responsive.

1. Write Shorter CSS

When writing CSS, use the popular software development principle Don’t Repeat Yourself (DRY). This advocates for conciseness and clarity in your code.

This is important here, because in practice, CSS involves repeating properties across various selectors. The goal should be to identify and consolidate these repetitive properties. By doing so you eliminate redundancies, leading to cleaner and more manageable CSS.

For instance, in the code below, multiple elements (h1and h2) share the same font-size and color.

h1 {
    font-size: 20px;
    color: #fff;
}
h2 {
    font-size: 20px;
    color: #fff;
}

So instead of declaring these properties separately for each selector, you can group them under a common class. This not only streamlines your stylesheet but also makes future updates easier and less error-prone.

You can rewrite the above code to look like this:

h1, h2 {
    font-size: 20px;
    color: #fff;
}

Using shorthand properties is another effective strategy for minimizing the size of your CSS, making your code more efficient. It also allows you to set multiple related CSS properties with a single declaration. Here's how you can write effective shorthand CSS:

When all sides of an element have the same value, use that one value.

/* Before shorthand */
.same-sides {
    padding-top: 15px;
    padding-right: 15px;
    padding-bottom: 15px;
    padding-left: 15px;
}

/* After shorthand */
.same-sides {
    padding: 15px;
}

When all sides of an element have different values, use all four.

/* Before shorthand */
.different-sides {
    padding-top: 10px;
    padding-right: 20px;
    padding-bottom: 15px;
    padding-left: 25px;
}

/* After shorthand */
.different-sides {
    padding: 10px 20px 15px 25px;
}

When top/bottom and right/left have the same value, use two values.

/* Before shorthand */
.two-sides {
    padding-top: 10px;
    padding-right: 20px;
    padding-bottom: 10px;
    padding-left: 20px;
}

/* After shorthand */
.two-sides {
    padding: 10px 20px;
}

When only the right/left values are the same but the top and bottom aren't, use three values.

/* Before shorthand */
.three-sides {
    padding-top: 10px;
    padding-right: 20px;
    padding-bottom: 15px;
    padding-left: 20px;
}

/* After shorthand */
.three-sides {
    padding: 10px 20px 15px;
}

2. Use Shallow CSS Selectors

Shallow CSS selectors are direct and concise selectors with fewer levels of nested elements that don't dig too deep into the HTML structure.

Simplifying your selectors can significantly speed up your webpage rendering because deeply nested selectors take longer for browsers to evaluate, which results in a slower page render.

Consider the example in the code below: to assign property values to a deeply nested selector like header nav ul li a is cumbersome and will cause rendering delays because the browser needs time to check each level (header, then nav, then ul, and so on) to find the right <a> tag to style).

Alternatively, giving it a direct class .nav-link is straightforward and quicker for browsers to interpret. Class selectors are generally more efficient than nested tags because the browser simply looks for elements with a class and applies the styles, without worrying about their position in the DOM tree.

/* Less efficient: Deeply nested selector */
header nav ul li a { 
   color: #000;
   font-size: 10px;
 }

/* More efficient: Class selector */
.nav-link {
   color: #000;
   font-size: 10px;
}

3. Segment CSS Code

Segmenting your CSS code into smaller, more focused segments like separate files for different website components and creating page-specific styles can greatly improve your website's performance. This approach not only makes it easier to find and edit specific styles but also ensures that webpages load only the CSS they need, avoiding unnecessary bulk.

Enhanced maintainability and faster page loading are the most obvious key benefits. Smaller CSS files are easier to manage, much like a well-organized toolbox where everything is easy to find. But also, by loading only the essential CSS for each page, the browser has less work to do hence improving the user experience.

Original CSS

Suppose you have a CSS file that contains styles for various parts of your website:

/* Styles for the home page */
.homepage {
    background-color: #f0f0f0;
    padding: 10px;
}

/* Styles for the services page */
.services {
    background-color: #333;
    color: white;
}

/* Styles for the contact page */
.contact {
    background-color: #222;
    color: white;
    padding: 20px;
}

Segmented CSS

Now, let's segment this CSS into different files based on their purpose:

1. Home page Styles (homepage.css):

.homepage {
    background-color: #f0f0f0;
    padding: 10px;
}

2. Services page Styles (services.css):

.services {
    background-color: #333;
    color: white;
}

3. Contact page Styles (contact.css):

.contact {
    background-color: #222;
    color: white;
    padding: 20px;
}

Each CSS file is focused on a specific part of the website. Now, when a user visits your website, each page loads only the CSS it requires hence enhancing the website's performance.

4. Optimize CSS Delivery

You can make your CSS files lighter and faster to load by shrinking your CSS – that is, you can remove extra spaces and lines (this is called minifying). Then you can compress these files so they're smaller and quicker for users to download.

Also, make sure the most important styles of your website load first, so people see your page faster. The other styles can load in the background without slowing things down.

You can also make your website faster for people who visit more than once, by saving some of your CSS in their browser (this is known as caching). This means it doesn’t have to load again every time they visit.

Also, if you use a CDN or a network of servers, your CSS files can be stored in many places around the world to load faster no matter where your users are.

Graphic comparing file size between an unminified CSS file at 167KB and a minified CSS file at 92KB

Original CSS

/* Main Stylesheet */
/* Header Style */
header {
  background-color: #333;
  color: white;
  padding: 10px;
}

/* Navigation Style */
nav {
  background-color: #444;
  margin-top: 10px;
}

The above CSS code is readable and well-commented, but it contains extra spaces and comments that increase the file size.

Minified CSS

header{background-color:#333;color:white;padding:10px}nav{background-color:#444;margin-top:10px;}

The minified version combines all the rules into a single line, removing unnecessary spaces and comments, which reduces the file size for quicker loading.

Conclusion

Optimizing your CSS speeds up your website and consequently improves the overall user experience.

By implementing the practices outlined in this article, you can achieve more performant, efficient and maintainable CSS. The performance savings may not be significant from tweaking a few lines but over hundreds more across different stylesheets, the impact will begin to show.

Remember, web performance is an ongoing process. Regularly review and refine your CSS to keep up with best practices and emerging trends.

Additional Resources

• MDN Web Docs on CSS
• Google Web Fundamentals
• Web Performance In Action

Among the plethora of strategies you can use to enhance web performance, lazy loading stands out for its efficiency and impact.

But what exactly is lazy loading, and how does it revolutionize the way we handle web resources? That's what we'll cover in this article.

What is Lazy Loading?

Lazy loading is a web performance optimization strategy that plays a critical role in how resources are loaded on a webpage.

Traditionally, when you go to access a webpage, the browser attempts to load all resources (images, scripts, stylesheets) immediately. This can lead to longer load times, especially if the page contains many large files.

Lazy loading addresses this by marking certain resources as non-blocking or non-critical, loading them only when they are needed. This method is especially effective for elements that aren't immediately visible on the initial page load, such as images and videos that appear further down the page.

Key benefits of lazy loading:

• Improved Performance: By loading only the necessary resources, the initial page load is faster, leading to a better user experience.
• Reduced Bandwidth Usage: Lazy loading minimizes the amount of data that needs to be transferred initially, saving bandwidth for both the user and the server.
• Enhanced User Engagement: Faster load times generally lead to lower bounce rates and higher engagement, as users are less likely to leave a slow-loading site.

Lazy loading can be implemented in various ways, with the most common method being JavaScript-based. But modern web development practices have introduced native HTML ways to implement lazy loading, such as the loading attribute for images.

The Role of the Image Loading Attribute in Lazy Loading

As we delve deeper into the practicalities of lazy loading, you'll see that the loading attribute in the <img> element is a game-changer.

This attribute, a relatively recent addition to the HTML specification, offers a simple yet powerful way to implement lazy loading natively, without the need for additional JavaScript. By leveraging the loading attribute, you can significantly enhance web performance and user experience, especially in content-heavy websites.

Browser-Level Lazy Loading

Primarily, browsers like Chrome and Firefox support the loading attribute for and

This method is efficient and enhances performance by loading images only when they are likely to be viewed by the user. But it's important to note that the lazy value for

Let's look at some examples to see how this works.

Basic lazy loading of a single image

<img src="image-1.jpg" alt="A scenic landscape" loading="lazy">

In this example, the loading="lazy" attribute in the <img> tag tells the browser to defer loading this image until it's about to enter the viewport. This means the image won't load when the page initially loads, but only when the user scrolls near it.

Lazy loading with high-priority images

<img src="logo.jpg" alt="Company Logo" loading="eager"> 
<img src="featured.jpg" alt="Featured Product" loading="lazy">

Here, the first image (logo) uses loading="eager", which is the default behavior to load the image immediately. It's useful for important images that need to be seen right away. The second image (featured product) uses loading="lazy", ideal for images that are not critical to see immediately.

Lazy loading in a gallery

<img src="gallery-image-1.jpg" alt="Gallery Image 1" loading="lazy"> 
<img src="gallery-image-2.jpg" alt="Gallery Image 2" loading="lazy">
<img src="gallery-image-3.jpg" alt="Gallery Image 3" loading="lazy">

For image galleries, using loading="lazy" for each image ensures that images load as the user scrolls through the gallery, improving page load time and reducing bandwidth usage.

Combining Lazy Loading with Art Direction

Art direction in web design refers to the practice of adapting the presentation of content to suit different contexts, devices, or demographics. It often involves using different images or visual styles to convey a specific message or feeling that resonates with various audience segments or fits different screen sizes.

For instance, a website might display a detailed, large image on a desktop but a simpler, smaller image on a mobile device – both delivering the same message but optimized for their respective viewing contexts.

Here’s how you can implement this alongside lazy loading:

<picture>
  <source media="(min-width: 800px)" srcset="large.jpg" loading="lazy">
  <source media="(min-width: 400px)" srcset="medium.jpg" loading="lazy">
  <img src="small.jpg" alt="Responsive Image" loading="lazy">
</picture>

In this code, the <picture> element contains multiple <source> elements, each with a different srcset attribute for different screen sizes, and a default <img> element. The loading="lazy" attribute is added to each source to enable lazy loading.

Intersection Observer for Polyfilling

The Intersection Observer API is a modern web API that provides a way to asynchronously observe changes in the intersection of a target element with an ancestor element or the viewport. Essentially, it allows you to execute code when an element enters or leaves the viewport, which is perfect for lazy loading images.

Polyfilling is a technique in web development where modern functionality is replicated in older browsers that do not support that functionality natively. A polyfill is a piece of code (usually JavaScript) that provides the technology that developers expect the browser to provide natively.

When it comes to lazy loading, if a browser does not support the loading attribute, we can use the Intersection Observer as a polyfill to achieve lazy loading behavior.

This JavaScript-based method involves observing <img> elements to determine their visibility within the viewport. When an image becomes visible, its src and srcset attributes are updated to load the actual image.

This method requires additional markup, including a class attribute for selection, a src attribute for a placeholder image, and data-src and data-srcset attributes for the actual image URLs

First, the HTML setup:

<img class="lazy" src="placeholder.jpg" data-src="actual-image.jpg" alt="Description">

• class="lazy": A class identifier for JavaScript selection.
• src: A placeholder image URL.
• data-src: The actual image URL to be loaded.

Then, the JavaScript:

document.addEventListener("DOMContentLoaded", function() {
  var lazyImages = [].slice.call(document.querySelectorAll("img.lazy"));

  if ("IntersectionObserver" in window) {
    let lazyImageObserver = new IntersectionObserver(function(entries, observer) {
      entries.forEach(function(entry) {
        if (entry.isIntersecting) {
          let lazyImage = entry.target;
          lazyImage.src = lazyImage.dataset.src;
          lazyImage.classList.remove("lazy");
          lazyImageObserver.unobserve(lazyImage);
        }
      });
    });

    lazyImages.forEach(function(lazyImage) {
      lazyImageObserver.observe(lazyImage);
    });
  } else {
    // Fallback for browsers without Intersection Observer support
  }
});

This section of code demonstrates how you can use the Intersection Observer API to implement lazy loading. It checks if the Intersection Observer is supported in the browser and, if so, uses it to load images only when they enter the viewport.

Wrapping Up

Using lazy loading, particularly through the loading attribute in HTML, can significantly help you improve web performance. By selectively deferring the loading of images and iframes until they are needed, this technique not only enhances the speed and efficiency of web pages but also contributes to a more seamless and responsive user experience.

Whether you apply lazy loading to individual images, galleries, or complex responsive layouts, the versatility of the loading attribute allows you to cater to various web development scenarios, ensuring that resources are utilized effectively and efficiently.

As web technologies continue to evolve, adopting such performance-centric strategies will become increasingly vital in delivering content that meets the expectations of modern web users.

So you might wonder – how do you make sure your application runs without breaking? To handle this, you can send tasks to a queue outside your application's flow.

What is a Message Queue?

A message queue is a tool that facilitates the communication and transfer of data between services within a single application (or externally). It stores these data or messages using the First-In-First-Out (FIFO) principle. This means that older data that's passed into these queues gets processed before newer data.

Different components make up a message queue, such as:

• Messages: These are the data that are sent to the queue. They are often referred to as jobs.
• Queues: These are the data structures used for storing messages.
• Producers: These are a service that sends messages or data into the queue system.
• Consumers: These are a service that listens to the queue and executes messages passed in it.

Message Queuing Tools

Now, there are various message queuing tools you can use in asynchronous systems, like the following:

• RabbitMQ: a reliable and flexible option for implementing message queues in applications.
• Apache Kafka: an efficient message queuing tool, also very good at event stream processing.
• Redis: an in-memory store used for message queuing, caching, and data processing.

Note that some of these tools are not limited to message queuing but can be used for other purposes as well, like stream processing.

In this article, you will create a simple Nest.js project which will use RabbitMQ as the Message Queue Service Provider.

The tutorial will be divided into 3 parts:

• How to Set Up a Nest.js Project for Basic User Registration Flow
• How to Set Up an Email Service for User Registration
• How to Integrate a Queue Service using RabbitMQ

Prerequisites

• You'll need to have Node installed on your system. If you don't have it, here is its official site: https://nodejs.org/en.
• You'll need to have Node Package Manager (NPM) installed, which you can download here if you don't have it: https://docs.npmjs.com/downloading-and-installing-node-js-and-npm.
• You'll need to have installed RabbitMQ. Here is where you can get it in case you haven't yet: https://www.rabbitmq.com/download.html
• You'll need to have a text editor. For this article, I'll use VSCode. You can download it here: https://code.visualstudio.com/download or use the code editor of your choice.

How to Set Up a Nest.js Project

Spinning up a Nest.js application is fast and simple if you use the Nest CLI. Open up your terminal and enter this command below to install the CLI:

 $ npm install -g @nestjs/cli

This installs the Nest.js CLI globally on your system, meaning you can call the CLI commands regardless of the directory you are currently in.

Moving forward, to create a simple REST API project, you will enter the command below:

nest new simple-queue

Simple-queue here is the directory name that will be created. Inputting this command gives you a prompt to select a package manager.

When that's done, navigate to the created directory and open it in your text editor by entering this command:

cd simple-queue && code .

This opens up your text editor. We want to work on a project that will best show how a message queue can be used in a real-world scenario – so let's set up a basic user registration form. On successful data entry it sends an email to the user, but you'll handle the email service separately by passing it into a queue to improve performance.

For this, we'll be using an SQLite database, TypeOrm, class-validators, and the dotenv package so you can secure your config variables. Go ahead to install them by typing this command in your terminal:

npm install --save @nestjs/typeorm typeorm sqlite3 class-validator dotenv

When the installation is complete, go to your root app module, and then include the TypeOrm configuration for your database.

SQLite is a lightweight SQL database which allows us to quickly spin up and test data. It's optimal for this use case – and now we'll configure it.

Configuring the SQLite Database

import { Module } from "@nestjs/common";
import { TypeOrmModule } from "@nestjs/typeorm";
import { AppController } from "./app.controller";
import { AppService } from "./app.service";

@Module({
  imports: [
    TypeOrmModule.forRoot({
      type:'sqlite',
      database: 'mini-db.sqlite',
      entities: [__dirname + '/**/*.entity{.ts,.js}'],
      synchronize: true,  
  })],
  controllers: [AppController],
  providers: [AppService],
})
export class AppModule {}

Congrats! You have successfully connected a DB to your project. Now it's time to create the services that will handle the user registration.

In order to do this, you will have to go back to your dear friend the Nest CLI. There, you'll be inputting a different command to help generate a resource folder for the User, which will contain the entity, service, dto, and the controller.

To do this, open your terminal and enter in this command:

nest generate resource users

A prompt to select your transport layer will be shown. Select the first one which is the REST API. Then, another prompt will ask if you would like to generate CRUD endpoints – you can type Yes. Then you can make modifications according to your requirements.

To proceed, you first have to define what information each user should have. First, create a User entity. You can do this by navigating to the user entity file in the created entity subfolder in the user folder. Then define the user data like this:

import { Entity, PrimaryGeneratedColumn, Column } from "typeorm";

@Entity('users')
export class User {
  @PrimaryGeneratedColumn('uuid')
  id: string;

  @Column({ length: 100, unique: true })
  username: string;

  @Column({ length: 100, unique: true })
  email: string;
}

For this mini-project, you'll use basic user data to make the process faster. The username and email field have been set to be unique, meaning that there won't be a duplicate of the data instance passed in for this user table.

Now having done this, modify the create user dto file that was generated like this:

import { IsNotEmpty, IsString, IsEmail } from "class-validator";

export class CreateUserDto {
    @IsNotEmpty()
    @IsString()
    username: string;

    @IsNotEmpty()
    @IsString()
    @IsEmail()
    email: string;
  }

This was created to validate the payload that will be sent in your request by using the class-validator package.

Now, modify the create method in the user service file.

import { Injectable } from "@nestjs/common";
import { InjectRepository } from "@nestjs/typeorm";
import { Repository } from "typeorm";
import { CreateUserDto } from "./dto/create-user.dto";
import { User } from "./entities/user.entity";

@Injectable()
export class UsersService {
  constructor(
    @InjectRepository(User)
    private readonly userRepository: Repository<User>
  ) {}
  async create(createUserDto: CreateUserDto): Promise<User> {
    const newUser = this.userRepository.create(createUserDto);
    return await this.userRepository.save(newUser);
  }
}

Next you'll modify the controller file. You've already defined the create endpoint, so you'll just have to clean up the other endpoints that are not needed.

import { Controller, Post, Body } from "@nestjs/common";
import { CreateUserDto } from "./dto/create-user.dto";
import { UsersService } from "./users.service";

@Controller('users')
export class UsersController {
 constructor(private readonly usersService: UsersService) {}
  @Post()
  create(@Body() createUserDto: CreateUserDto) {
    return this.usersService.create(createUserDto);
  }
}

Open up the user module file and make some adjustments by adding the import field to the Module decorator and using the TypeOrmModule property.

import { Module } from '@nestjs/common';
import { UsersService } from './users.service';
import { UsersController } from './users.controller';
import { TypeOrmModule } from '@nestjs/typeorm';
import { User } from './entities/user.entity';

@Module({
  imports: [TypeOrmModule.forFeature([User])],
  controllers: [UsersController],
  providers: [UsersService],
})
export class UsersModule {}

Next, start up your server by entering this command on your terminal: npm run start:dev. Once the server is up and running, open up your API client of choice. For this article, we'll use Postman. Then make a POST request to the endpoint, which will be localhost:3000/users, providing the payload data required.

A request was made and a user instance was created.

Next up is adding an email service to your project which will help notify new users who are registering.

How to Set Up an Email Service for User Registration

For this, you'll use some packages which are required to create an email service. Open up your terminal and input the command below to install these packages:

npm install --save @nestjs-modules/mailer nodemailer

When these packages are installed, you can now implement the mail service. Using the Nest CLI, create a mailer module and service by entering this command in your terminal:

nest generate module email && nest generate service email

When it's done, open up the newly created module file in the mail folder. You'll use the MailerModule property of the @nestjs-modules/mailer package to configure your mail service here. It requires an SMTP client whose keys you'll need to configure this MailerModule.

For that you can use https://app.elasticemail.com to get these SMTP keys. Sign up and connect to the SMTP API. You'll then be given keys for your private use.

Note that this free mode of the SMTP client has limitations and it cannot send to all emails – so you should use a test email service.

How to Configure the Mailer Module

Once you have gotten that set up, go back to your application and create a .env file. Set your secrets for the SMTP keys. Then configure your MailerModule like this:

import { Global, Module } from "@nestjs/common";
import { EmailService } from "./email.service";
import { MailerModule } from "@nestjs-modules/mailer";

require('dotenv').config();
@Global()
@Module({
  imports: [
    MailerModule.forRoot({
      transport: {
        service: 'QueueTest',
        host: process.env.SMTP_HOST,
        port: process.env.SMTP_PORT,
        auth: {
          user: process.env.SMTP_USER,
          pass: process.env.SMTP_PASSWORD,
        },
      },
      defaults: {
        from: process.env.FROM_EMAIL,
      },
    }),
  ],
  providers: [EmailService]
})
export class EmailModule {}

The global decorator was set in order to make sure the MailModule can be called anywhere in your application. Make sure your secrets are properly loaded and thaqt you have a valid Email set in the from: process.env.FROM_EMAIL.

Check to make sure that the EmailModule is also imported in the root App Module the same way your UsersModule was imported in the Imports Array of the App Module.

Next, open your email service file – you'll need to make some modifications to the EmailService class. Add a constructor and call the MailService property from the @nestjs-modules/mailer package. Then go ahead and create a function that will handle sending the emails.

Below is a class and method that does this:

import { MailerService } from '@nestjs-modules/mailer';
import { HttpException, HttpStatus, Injectable } from '@nestjs/common';

@Injectable()
export class EmailService {
  constructor(private mailerService: MailerService) {}
  async sendEmail(options: { email: string; subject: string; html: string;
  }) {
    try {
      const message = {
        to: options.email,
        subject: options.subject,
        html: options.html
      };
      const emailSend = await this.mailerService.sendMail({
        ...message,
      });
      return emailSend;
    } catch (error) {
      throw new HttpException('Error', HttpStatus.INTERNAL_SERVER_ERROR);
    }
  }
}

Now you've defined the method to send an email. You've also put an exception handler in place for better error handling.

Now it's time to add this newly created service to your user registration flow.

Navigate to your user service file, and add the mail service to your constructor as a provider. Then call the service in your create user method like this:

@Injectable()
export class UsersService {
  constructor(
    @InjectRepository(User)
    private readonly userRepository: Repository<User>,
    private emailService: EmailService
  ) {}
  async create(createUserDto: CreateUserDto): Promise<User> {
    const newUser = this.userRepository.create(createUserDto);
    const user =  await this.userRepository.save(newUser);
      const emailData = {
        email: user.email,
        subject: 'Welcome to Our Community',
        html: `<p>Hello ${user.username},</p>
        <p>Welcome to our community! Your account is now active.</p>
        <p>Enjoy your time with us!</p>`,
      };
      await this.emailService.sendEmail(emailData)
    return user
  }
}

Make sure to modify your modules in order to correct any dependency injection errors. In your email module file, add the EmailService to the exports array:

 providers: [EmailService],
 exports: [EmailService]

Add it below your providers to export the Email Service so it can be accessed in other modules. Then import the EmailModule to your User module file and add it to your import array like this:

@Module({
  imports: [TypeOrmModule.forFeature([User]), EmailModule],
  controllers: [UsersController],
  providers: [UsersService],
})
export class UsersModule {}

Now it's time to test it. Get a free account from any online email testing platform and open Postman. Make a request to the create user endpoint with your valid email. You should get an email response like this:

Email response you should get

How to Integrate a Queue Service using RabbitMQ

To get started with this, you'll have to install some packages that let you implement queues using RabbitMQ. Enter the command below to install these packages:

npm install --save amqplib @types/amqplib amqp-connection-manager

Configure the Producer Service

Once installation is complete, it's time to configure RabbitMQ. You'll create a new folder in your src directory and name it queues. Then create the queue producer file. Import these packages and set them up like this:

import { HttpException, HttpStatus, Injectable, Logger } from '@nestjs/common';
import amqp, { ChannelWrapper } from 'amqp-connection-manager';
import { Channel } from 'amqplib';

@Injectable()
export class ProducerService {
  private channelWrapper: ChannelWrapper;
  constructor() {
    const connection = amqp.connect(['amqp://localhost']);
    this.channelWrapper = connection.createChannel({
      setup: (channel: Channel) => {
        return channel.assertQueue('emailQueue', { durable: true });
      },
    });
  }

  async addToEmailQueue(mail: any) {
    try {
      await this.channelWrapper.sendToQueue(
        'emailQueue',
        Buffer.from(JSON.stringify(mail)),
        {
          persistent: true,
        },
      );
      Logger.log('Sent To Queue');
    } catch (error) {
      throw new HttpException(
        'Error adding mail to queue',
        HttpStatus.INTERNAL_SERVER_ERROR,
      );
    }
  }
}

The AMQP connection was set and is running on localhost with the default RabittMQ port which is 5432. You also established a channel on that connection with an option input which is executed anytime a new channel is created. This helps if you have any configuration for that channel.

You also created an emailQueue with the assertQueue property which checks that a queue with that name does not already exist. If it does exist, it has no effect so it's idempotent.

Then you created an option durable: true to make sure that the queue will survive a server restart.

Next, you defined the method to add the email data to a queue. This calls the sendToQueue property of the channelWrapper, passing in the queue name you want to send the data to. Ideally, it should be the same name as the one you defined with the assertQueue property.

The second argument is the mail data, but firstly you converted it to a JSON string then to a Buffer. You do this because messages in RabbitMQ are mostly transmitted as binary data.

You can then set an option persistent: true to ensure that the data being sent to the queue won't be lost if the server crashes. Then with some error handling and the method to send messages to the queue, it's good to go.

Set Up the Consumer Service

Now that you've configured the producer service, it's time to set up the consumer service.

Create another file in the queue sub-folder. It's quite similar, but in this case, you will be consuming the data from the queue. Below is the configuration for the consumer service:

import { Injectable, OnModuleInit, Logger } from '@nestjs/common';
import amqp, { ChannelWrapper } from 'amqp-connection-manager';
import { ConfirmChannel } from 'amqplib';
import { EmailService } from 'src/email/email.service';

@Injectable()
export class ConsumerService implements OnModuleInit {
  private channelWrapper: ChannelWrapper;
  private readonly logger = new Logger(ConsumerService.name);
  constructor(private emailService: EmailService) {
    const connection = amqp.connect(['amqp://localhost']);
    this.channelWrapper = connection.createChannel();
  }

  public async onModuleInit() {
    try {
      await this.channelWrapper.addSetup(async (channel: ConfirmChannel) => {
        await channel.assertQueue('emailQueue', { durable: true });
        await channel.consume('emailQueue', async (message) => {
          if (message) {
            const content = JSON.parse(message.content.toString());
            this.logger.log('Received message:', content);
            await this.emailService.sendEmail(content);
            channel.ack(message);
          }
        });
      });
      this.logger.log('Consumer service started and listening for messages.');
    } catch (err) {
      this.logger.error('Error starting the consumer:', err);
    }
  }
}

First, you defined your consumer class. For this, it implements the onModuleInit interface which is provided by @nestJs/common. This specifies that the defined class should have a method named onModuleInit().

Like the name says, the method will be called automatically during the module initialization which is when the module containing this class is loaded.

In the class constructor, you added the emailService because you'll be using the sendEmail method of that class.

In the onModuleInit() method, you defined a channel. This is necessary because you need a channel to consume messages from a queue.

From this, the channel is then used to assert a queue which should be similar in name and options to what you have on your producer service. If it's not, you won't be able to listen to the queue created on the producer service.

Then you used the consume method of channel to listen and execute the message coming from the queue you have registered.

Recall that before, you had to convert the message to Buffer in order to send it into a queue. Now, you have to convert it to a JavaScript object. Then call the emailService method to send an email and pass in the converted JavaScript object as the argument of that method.

Finally, you called the ack method which is used to inform the queue that the message has been received and processed successfully in order for it to be removed from the queue.

Now that you've defined these services, create a module file and set them in the providers array. Then export the producer service because you will be calling it in another module.

import { Module } from '@nestjs/common';
import { ConsumerService } from './consumer.file';
import { ProducerService } from './producer.file';

@Module({
  providers: [ProducerService, ConsumerService],
  exports: [ProducerService],
})
export class QueueModule {}

Next up is to add the emails being sent on user registration to the queue service that you just created.

Navigate back to your user service file and make some modifications: replace the email service with the producer service as a provider in the constructor, and then call the service and the method to add to the email queue as shown below:

import { Injectable } from "@nestjs/common";
import { InjectRepository } from "@nestjs/typeorm";
import { Repository } from "typeorm";
import { CreateUserDto } from "./dto/create-user.dto";
import { User } from "./entities/user.entity";
import { ProducerService } from "src/queues/producer.file";

@Injectable()
export class UsersService {
  constructor(
    @InjectRepository(User)
    private readonly userRepository: Repository<User>,
    private producerService: ProducerService,
  ) {}
  async create(createUserDto: CreateUserDto): Promise<User> {
    const newUser = this.userRepository.create(createUserDto);
    const user = await this.userRepository.save(newUser);
    const emailData = {
      email: user.email,
      subject: 'Welcome to Our Community',
      html: `<p>Hello ${user.username},</p>
        <p>Welcome to our community! Your account is now active.</p>
        <p>Enjoy your time with us!</p>`,
    };
    await this.producerService.addToEmailQueue(emailData);
    return user;
  }
}

Also in the user module file, replace the EmailModule with that of the QueueModule to avoid dependency injection errors when you start up your server.

import { Module } from '@nestjs/common';
import { UsersService } from './users.service';
import { UsersController } from './users.controller';
import { TypeOrmModule } from '@nestjs/typeorm';
import { User } from './entities/user.entity';
import { QueueModule } from 'src/queues/queue.module';

@Module({
  imports: [TypeOrmModule.forFeature([User]), QueueModule],
  controllers: [UsersController],
  providers: [UsersService],
})
export class UsersModule {}

Now finally, it's time to test the user registration flow again. So navigate back to Postman and then type in a valid email and username and hit enter. On the terminal of your server running, you will see logs that were set in order to track the way the message got sent and how it was received and executed.

Logs that help you track the message

You can also open up the RabbitMQ dashboard to view queue activity on http://localhost:15672, By default the user is "guest", so enter in guest for the username and password.

RabbitMQ Queues and Streams

Here's the link to the GitHub repository. Feel free to check it out whenever you're stuck.

Conclusion

In this article you learned what a message queue is along with some major components of how they work. You also built a mini Nest.js project and implemented an email service in it. Finally, you integrated the queue service into your project, showing how it works in a real-life scenario.

Understanding message queue behaviors and patterns is an essential skill when developing scalable applications. This helps reduce lag and improves the speed and efficiency of your applications.

I hope you enjoyed reading this article. You can follow me on Twitter.

esbuild is a lightweight and efficient bundler for React apps. Here's an overview of how to use esbuild to bundle a basic React application.

How to Install esbuild Globally

We'll start by installing esbuild globally in your system by running npm install -g esbuild in the command line. This will install the latest version of esbuild globally on your system.

After installation, you can access esbuild from the command line by typing esbuild.

How to Create a New Directory for Your React Application

To create a new directory for your React application, open the terminal and navigate to the directory where you want to create the new directory. Then run the following command:

mkdir my-react-app

This will create a new directory named my-react-app. You can replace it with whatever name you want to give your React application directory.

After creating the directory, navigate into it by running:

cd my-react-app

Initialize a new npm project by running the following command and following the prompts:

npm init -y

Install React and React DOM by running npm install react react-dom in the terminal. This will install the latest versions of React and React DOM in your project, along with any required dependencies.

How to Create the Necessary Files and Folders

Let's create the necessary files and folders. Here's a basic structure:

my-react-app
├── src
|   |
│   |── index.js
├── |--- index.html
│  
└── package.json

Add the code shown below in your app, following the above structure:

index.html:

<!DOCTYPE html>
<html>

<head>
  <meta charset="UTF-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
  <title>Hello, esbuild!</title>
</head>

<body>
  <div id="root"></div>
  <script src="Bundle.js"></script>
</body>

</html

The above code outlines the fundamental structure of an HTML5 web page. It starts with a declaration indicating the use of HTML5. The main structure consists of an <html> root element containing a <head> section for metadata, including character encoding and viewport settings for responsiveness.

The <title> element defines the browser tab's title, while the actual content resides in the <body> element. Within the <body>, a <div> element with the id "root" serves as a placeholder for potential dynamic content.

Additionally, there's a <script> tag pointing to an external JavaScript file named "Bundle.js," generated by esbuild, to be executed by the browser.

This structure sets the foundation for building a web page with HTML5, CSS, and JavaScript functionality.

index.js

import React from "react";
import ReactDOM from "react-dom";

function App() {
  return (
    <div>Hello, esbuild! </div>
  );
}

ReactDOM.render(<App />, document.getElementById("root"));

Our React code sets up a simple React application with a single component App. It renders a <div> element with the text Hello, esbuild! and mounts it into the DOM, specifically into the element with the id of root.

How to Create the Build Function

Let's add the following build script using the esbuild bundler in our package.json file:

"scripts": {
        "build": "esbuild src/index.js --bundle --outfile=Bundle.js --loader:.js=jsx --format=cjs"
},

This build script starts with the entry point src/index.js and proceeds to bundle all the dependencies. The resulting bundled code is saved as Bundle.js.

The script also specifies that files with the .js extension should be treated as jsx files, indicating the usage of JSX syntax.

Finally, the output format is set to CommonJS (cjs) which is the module system utilized by Node.js.

By executing this build script, the esbuild bundler will process the files, apply the necessary transformations, and generate a single bundled JavaScript file ready for deployment or further usage.

Overview of the Build Function and its Purpose

The build script using esbuild is JavaScript code that bundles your JavaScript code into a single file. This is useful for optimizing your code for production environments, reducing the number of HTTP requests needed to load your application, and improving load times.

The build method takes an options object as its argument, which allows you to configure how your code is bundled. The options object specifies properties such as entryPoints, outfile, format, bundle, and loader.

Once the build method is configured with the desired options, the build function is called, which triggers the build process. This will output a single bundled file containing all of your JavaScript code.

Finally, the build script is run by executing the script using Node.js. You can do this by updating the package.json file to include a script that runs the build script, as shown above.

Build the React app using the following command:

npm run build

Then run the app using this command:

npx http-server

Conclusion

By following these steps, you can bundle your basic React application using esbuild and have it ready for deployment or further usage. Here is the demo.

Happy coding!

The N+1 query problem is a performance issue you might face while building APIs, regardless of whether they're GraphQL or REST APIs.

In fact, this problem occurs when your application needs to return a set of data that includes related nested data – for example, a post that includes comments.

But how can you fix this problem? To avoid this issue, you should understand what is it and how it occurs.

So in this tutorial, you'll learn what the N+1 query problem is, why it is easy to fall into it, and how you can avoid it.

Before starting, it is good to know:

• The examples in this article are just for the sake of simplicity.
• SELECT * is very bad, and you should avoid it.
• You should care about pagination if you’re working with large data sets.

You can find the examples in this article in this repo. Let's dive in.

Understanding the N+1 Query Problem

The N+1 problem occurs when your application needs to return a set of data that includes related data that exists in:

• Another table.
• Another database (in the case of microservices, for example)
• Or even another third-party service.

In other words, you need to execute extra database queries or external requests to return the nested data.

If you are wondering about what the name means (N+1), follow the below example, which uses a single database:

Illustration of N+1 problem

As you can see, the relationship between Post and Comment is one-to-many, respectively.

So, if your application needs to return a list of posts and their related comments, you might end up with this code:

const posts = await rawSql('SELECT * FROM "Post"'); // Get all posts (1 database query)
for (const post in posts) {
    // For sure, you can replace the following query with an external request if you need to retrieve the post's comments from another service
    const comments = await rawSql(`SELECT * FROM "Comment" WHERE "post_id" = ${post.id}`); // Get all comments for every post (n database query for n posts)
    post.comments = comments;
}

So, you have executed N queries to retrieve every post’s comments and 1 query to retrieve all posts (N comments queries + 1 posts query).

But, why you should be aware of this problem?

Why Is the N+1 Query Problem a Serious Issue?

Here are some reasons why the N+1 query problem can cause serious performance issues in your application:

1. Your application makes a lot of database queries or external requests to retrieve a list of data like posts.
2. The more data your application retrieves, the slower your request is going to be and the more resources your application is going to consume.
3. A large data set might end up with notable network latency.
4. It is going to be challenging to scale the application to handle larger data sets.

On top of that, you are going to see the performance impact in numbers in the benchmarks section later in this article.

Now that you understand the N+1 query problem and its impact on your application, let’s introduce some effective ways you can avoid this problem.

Strategies to Avoid the N+1 Query Problem

Fortunately, there are a few simple strategies you can follow to avoid the N+1 query problem.

Let’s apply them to our previous example.

1) Eager Loading (Using SQL Joins, for example)

In this strategy, instead of returning the post’s comments separately for every post, you can use SQL Joins.

const postsAndComments = await rawSql(`
    SELECT * 
    FROM "Post"
    JOIN "Comment"
    ON "Comment"."post_id" = "Post"."post_id"
`);

When you're using this strategy, it's good to know that:

• It is only one database query to return all posts and their nested comments.
• You can't apply this strategy if you are consuming your data sets from a different database or service.

2) Batch Loading

In this strategy, your code should follow the below steps:

• Execute one request to retrieve all posts.
• Execute another request to load a batch of posts’ comments instead of loading every post’s comments separately.
• Map every comment to its corresponding parent post.

Let’s jump into an example:

const posts = await rawSql('SELECT * FROM "Post"'), // 1- Retrieve all posts in one request
    postsIds = posts.map(post => post.id),
    postsComments = await rawSql(`SELECT * FROM "Comment" WHERE "post_id" IN (${postsIds})`); // 2- retrieve all posts’ comments in another request

for (const post in posts) { // 3- Map every comment to its parent post
    const comments = postsComments.filter(comment => comment.post_id === post.id);
    post.comments = comments;
}

As you see, in this strategy, there are just two requests: one to retrieve all posts and another one to retrieve their comments.

3) Caching

You may be familiar with caching and its impact on any application's performance.

You can implement caching on your client side or server side using Redis, Memcached, or any other similar tool. Wherever you can properly use caching, it significantly pushes your application's performance.

Let’s get back to our example and cache the posts’ comments in a Redis store.

    const posts = await rawSql('SELECT * FROM "Post"'),
        postsIds = posts.map(post => post.id),
        cachedPostsComments = getPostsCommentsFromRedis(postsIds);

for (const post in posts) {
    const comments = cachedPostsComments.filter(comment => comment.post_id === post.id);
    post.comments = comments;
}

As you might guess, you can cache the posts’ comments or even the posts themselves which significantly minimizes the load on databases.

4) Lazy Loading

In this strategy, you are distributing the responsibility between the server side and the client side.

You shouldn’t return all data at once from the server side. Instead, you prepare two endpoints for the client side like this:

• GET /api/posts: Retrieves all posts.
• GET /api/comments/:postId: Retrieves a post’s comments on demand.

And now, the data retrieval is up to the client side.

This strategy is very useful because:

• It enables the client side to load the parent post first and display its content, and then load its related comments lazily. So users don't have to wait for the entire data set to be returned from the server side.
• You have full control over sorting, filtering, pagination and so on over every endpoint.

The key point of this strategy is that it gets rid of nested data like comments and flattens all data sets in their own endpoint.

5) GraphQL Dataloader

As you might guess, this strategy works with GraphQL APIs.

Dataloader is a GraphQL utility that works by batching multiple database queries into one request. So, it uses the Batch Loading strategy under the hood.

Let’s jump into our example:

const DataLoader = require('dataloader');

// 1- GraphQL Schema Definition
const typeDefs = gql`
  type Post {
    post_id: ID!
        comments: [Comment]
  }

    type Comment {
        comment_id: ID!
    post_id: ID!
  }

  type Query {
    posts: [Post]
  }
`;

// 2- Resolve the GraphQL Schema
const resolvers = {
  Query: {
    posts: async () => {
      const posts = await rawSql('SELECT * FROM "Post"');
            return posts;
    }
  },

  Post: {
    comments: (post, args, { dataLoaders }) => {
      return dataLoaders.commentsLoader.load(post.id);
    }
  }
};

// 3- Define Dataloaders
const commentsBatchFunction = async postsIds => {
      const comments = await rawSql(`SELECT * FROM "Comment" WHERE "post_id" IN (${postsIds})`);
        const groupedComments = comments.reduce((tot, cur) => {
      if (!tot[cur.post_id]) {
        tot[cur.post_id] = [cur];
      } else {
        tot[cur.post_id].push(cur);
      }
      return tot;
    }, {});
        return postsIds.map((postId) => groupedComments[postId]);
    },
    createCommentsLoader = new DataLoader(commentsBatchFunction),
    createDataloaders = () => ({
        commentsLoader: createCommentsLoader()
    });

// 4- Inject Dataloaders in the GraphQL Context
const server = new ApolloServer({
    typeDefs,
    resolvers,
    context: () => {
    return {
      dataLoaders: createDataloaders(),
    }
  }
});

So how does it work? To get more detailed information, you can check out the documentation. But we'll go through the basics here.

The key point of the Dataloader is the Batch Function. Here, the batch function commentsBatchFunction takes an array of keys postsIds and returns a Promise which resolves to an array of values comments, [ [post1comment1, post1comment2], [post2comment1], ... ].

On top of that, the batch function has two constraints:

• The size of the keys array postsIds must equal the values array comments. In other words, this expression must be true: postsIds.length === comments.length.
• Each index in the keys array postsIds must correspond to the values array comments. So you might note that I looped over the postsIds to map each corresponding comment.

As a result, you can see that GraphQL Dataloader uses the second strategy (Batch Loading) under the hood.

Let’s get back to our example to walk through its implementation:

1. First, we defined the GraphQL schema.
2. Then we resolved the GraphQL schema. Keep in mind, if you resolved the comments in the Post type using this query await rawSql('SELECT * FROM "Comment" WHERE "post_id" = ' + post.id);, you’re going to fall into the N+1 query problem.
3. Next, we defined the comments batch function and then created the comments dataloader.
4. Finally, we injected dataloaders in the GraphQL Context to be able to use them in resolvers.

So, by using GraphQL Dataloader, if you have 10 posts and every post has 5 comments, you would end up with two queries – one to retrieve the 10 posts and another one to retrieve their comments.

Take a look at the following screenshot:

Illustration of process with and without Dataloader

Benchmarks About N+1 Query Problem

In this section, let’s compare each strategy in terms of performance.

Note that the results of the Cache strategy are coming just after caching the data set. The first query is ignored as caching is missed.

These results were generated from the following environment:

• Seeded data: 1000 posts and 50 comments for every post.
• CPU: AMD Ryzen 5 3600 6-Core Processor 3.60 GHz.
• RAM: 32.0 GB.
• OS: Windows 10 Pro.

To be able to retest these strategies in your environment, follow these steps:

• Clone this repo.
• Then run docker-compose up.
• For GraphQL, open http://localhost:3000/graphql.
• A query suffers from the N+1 problem: query only commentsWithNPlusOne in the Post type.
• Dataloader strategy: query only commentsWithDataloader in the Post type.
• For REST, follow these endpoints:
• A query suffers from the N+1 problem: http://localhost:3000/api/postsWithNPlusOne.
• Eager Loading strategy: http://localhost:3000/api/postsWithEagerLoading.
• Batch Loading strategy: http://localhost:3000/api/postsWithBatchLoading.
• Caching strategy: http://localhost:3000/api/postsWithCache.

My notes about these benchmarks:

• These strategies are way too efficient.
• You may notice that the slower strategy in REST, the Eager Loading strategy, is about 34 times faster than the N+1 query in the REST API.
• The Dataloader strategy is about 6.4 times faster than the N+1 query in the GraphQL API.
• If you compared the results of REST and GraphQL APIs, you may notice that REST is faster than GraphQL. I think this is because of the internal implementations of GraphQL, which makes sense.

Conclusion

In this article, you learned that the N+1 query problem is a performance issue you might encounter when working with APIs.

You then learned about some strategies you can follow to avoid this problem like:

• Eager Loading using SQL Joins
• Batch Loading by executing fewer requests and then mapping each corresponding item to its parent.
• Caching using Redis
• Dataloader in the GraphQL world.

Finally, we created some benchmarks about the N+1 query problem so we could see how efficiently these strategies improve our API performance.

Before you leave

If you found this article useful, you can check out some of my other articles on my personal blog as well.

Thanks a lot for staying with me up till this point. I hope you enjoy reading this article.