I've audited EKS clusters at more than 10 companies. The same waste patterns appear every time: over-provisioned nodes, cross-AZ data transfer, idle EBS volumes, and so on. And the most expensive mistake of all: buying compute commitments before rightsizing.

This handbook is the fix. I've used this 7-step playbook to reduce EKS costs by 50–60% at every company where I've implemented it. There are no product code changes, and no downtime. Just infrastructure optimization executed in the right order.

By the end of this guide, you'll know how to right-size pod resource requests, implement Karpenter for intelligent bin-packing and Spot diversification, migrate compatible workloads to Graviton for 20% cheaper compute, and eliminate NAT Gateway charges entirely with VPC endpoints.

All Terraform modules, NodePool templates, and automation scripts referenced in this guide are available in the companion repository at github.com/aayostem/eks-cost-optimization. The repo includes ready-to-deploy configurations for every step so you can move from reading to implementing in the same afternoon.

Table of Contents

• What You'll Learn

• Prerequisites

• Part 1: The Baseline — Where Your EKS Money Is Going

• Part 2: Right-Sizing Pod Resource Requests

• Part 3: Karpenter for Bin-Packing and Spot Diversification

• Part 4: Graviton Migration

• Part 5: VPC Endpoints for Data Transfer

• Part 6: EBS Volume Optimisation

• Part 7: Load Balancer Consolidation

• The Complete 7-Step Sequence

• Best Practices Summary

• Resources

What You'll Learn

• How to right-size pod resource requests using VPA recommendations

• The complete Karpenter setup with Spot diversification and automatic consolidation

• Graviton3 migration for all non-GPU workloads

• VPC endpoints to eliminate NAT Gateway data transfer charges

• EBS gp2 to gp3 migration — 20% cheaper with zero performance loss

• Load balancer consolidation with shared Ingress

• The 7-step sequence that maximises ROI — and why the order isn't optional

Let's dive in.

Prerequisites

Before following along, you should have:

Knowledge:

• Working familiarity with Kubernetes — you can deploy an application and inspect pods

• Basic AWS knowledge — you understand EC2 instance types, VPCs, and EBS volumes

• Comfort reading Terraform HCL and Kubernetes YAML

Tools and access:

• An existing EKS cluster running Kubernetes 1.27 or later

• kubectl configured and pointing at your cluster

• AWS CLI v2 installed and authenticated with appropriate permissions

• Helm 3 installed (for Karpenter and Kubecost)

• Metrics Server installed in your cluster

Companion repository: Clone the repo before starting. It contains all YAML, Terraform, and shell scripts referenced in this guide:

git clone https://github.com/aayostem/eks-cost-optimization
cd eks-cost-optimization

Estimated savings: For a cluster running at \(85,000/month with typical over-provisioning, expect \)40,000–55,000/month in savings after completing all 7 steps. Smaller clusters under $10,000/month typically see 40–50% reduction.

Part 1: The Baseline — Where Your EKS Money Is Going

1.1 The Typical EKS Cost Breakdown

Before touching anything, you need to know exactly where the money is going. Optimising the wrong category first is how teams waste weeks of engineering time and see no meaningful reduction.

Here's what a typical $85,000/month EKS cluster looks like when you break it down:

Compute and Data Transfer together represent 79% of the bill and account for 90% of the correctable waste. Those are the targets.

Run this command to see your own breakdown before starting anything:

# Pull last month's cost breakdown by service
# Save this output — it becomes your before number
aws ce get-cost-and-usage \
  --time-period Start=\((date -d 'last month' +%Y-%m-01),End=\)(date +%Y-%m-01) \
  --granularity MONTHLY \
  --group-by Type=DIMENSION,Key=SERVICE \
  --metrics UnblendedCost \
  --query 'ResultsByTime[0].Groups[*].{Service:Keys[0],Cost:Metrics.UnblendedCost.Amount}' \
  --output table | sort -k3 -rn

Screenshot the output and save it. You'll compare against it after each step to verify actual savings before moving to the next one.

1.2 The Most Expensive Mistake: Wrong Optimisation Order

Here's what most teams do when they get a large AWS bill:

1. Buy Savings Plans immediately, locking in waste at a 30% discount

2. Then implement Karpenter, discovering they've over-committed the wrong instance family

3. Then migrate to Graviton, discovering their Savings Plan doesn't cover ARM instances

The result: a 12–36 month commitment paying for waste they could have eliminated in three weeks.

The correct sequence is:

Step 1: Right-size pod requests        ← Always first
Step 2: Implement Karpenter            ← Dynamic provisioning on rightsized requests
Step 3: Enable Spot for non-prod       ← Karpenter handles fallback automatically
Step 4: Migrate to Graviton            ← Karpenter makes this seamless
Step 5: Add VPC endpoints              ← Eliminate data transfer charges
Step 6: Optimise EBS volumes           ← Quick win, run alongside other steps
Step 7: Consolidate load balancers     ← Final structural cleanup

Then, and only then, buy Savings Plans — against the optimised baseline you've just established.

The one rule: optimise first, then commit. Every step before the Savings Plan purchase reduces what you're locking in for 1–3 years.

Part 2: Right-Sizing Pod Resource Requests

2.1 Why Over-Provisioned Requests Are So Expensive

Kubernetes schedules pods based on resource requests — not actual usage. A pod that requests 2 vCPUs and 4GB of memory requires a node with that capacity available, regardless of whether the pod is actually using it.

Here's the incorrect approach with the requests set to worst-case peak estimates:

# Bad: Resource requests set during initial deployment, never revisited
# This pod actually uses 250m CPU and 512Mi memory on average
resources:
  requests:
    cpu: "2"        # 8x more than actual usage
    memory: "4Gi"   # 8x more than actual usage
  limits:
    cpu: "4"
    memory: "8Gi"

When every pod is over-requested by 8x, your cluster needs 8x more nodes than your workloads actually require. That's where the 61% compute line in your bill comes from.

First, verify actual usage before changing anything:

# Install Metrics Server if not already running
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

# Check actual CPU and memory usage per pod
# Compare these numbers against your current resource requests
kubectl top pods --all-namespaces --sort-by=cpu

Expected output showing the typical gap:

NAMESPACE     NAME                    CPU(cores)   MEMORY(bytes)
production    payment-api-xxx         25m          128Mi
production    user-api-xxx            15m          96Mi
production    notification-svc-xxx    5m           64Mi
staging       worker-xxx              10m          256Mi

If your pods are requesting 2 CPU cores each but using 25m–15m cores in practice, you have a 50–80x over-request ratio. Every node in your cluster is mostly empty space you're paying for.

2.2 Using the Vertical Pod Autoscaler for Recommendations

The Vertical Pod Autoscaler (VPA) is a Kubernetes component that analyses historical CPU and memory usage for each deployment and recommends optimal resource requests. You use it in recommendation-only mode first — it tells you what to set without changing anything automatically, so you can review and apply the changes yourself with full control.

Here's the correct implementation:

# Good: VPA in recommendation-only mode
# Watches your pod's actual usage for 24+ hours, then recommends right-sized requests
# updateMode: "Off" means it only recommends — it never restarts your pods
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: payment-api-vpa
  namespace: production
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: payment-api
  updatePolicy:
    updateMode: "Off"   # Recommendation only — you apply manually after review
  resourcePolicy:
    containerPolicies:
    - containerName: "*"
      minAllowed:
        cpu: "100m"     # VPA will never recommend below this floor
        memory: "256Mi"
      maxAllowed:
        cpu: "2"        # VPA will never recommend above this ceiling
        memory: "4Gi"

Install VPA and retrieve recommendations:

# Install VPA components
kubectl apply -f https://github.com/kubernetes/autoscaler/releases/download/vertical-pod-autoscaler-1.0.0/vpa-v1.0.0.yaml

# Apply the VPA manifest for each deployment you want to right-size
kubectl apply -f vpa/payment-api-vpa.yaml

# Wait 24 hours for VPA to collect usage data, then check recommendations
kubectl describe vpa payment-api-vpa -n production

What a VPA recommendation looks like:

Recommendation:
  Container Recommendations:
    Container Name: payment-api
    Lower Bound:
      cpu:     50m
      memory:  128Mi
    Target:
      cpu:     250m      ← Set your requests to this value
      memory:  512Mi     ← Set your requests to this value
    Upper Bound:
      cpu:     500m
      memory:  1Gi

Apply the recommendation to your deployment:

# Good: Right-sized requests based on VPA Target recommendation
resources:
  requests:
    cpu: "250m"     # Down from 2000m — an 8x reduction
    memory: "512Mi" # Down from 4096Mi — an 8x reduction
  limits:
    cpu: "500m"     # 2x the request — headroom for genuine spikes
    memory: "1Gi"   # 2x the request

All VPA manifests for common deployment types are in vpa/ in the companion repo.

2.3 The ROI of Right-Sizing

Verify the improvement after applying recommendations:

# Check cluster-level utilisation after right-sizing
# Target: 60–75% CPU and memory utilisation across nodes
kubectl top nodes

Part 3: Karpenter for Bin-Packing and Spot Diversification

Karpenter is an open-source Kubernetes node provisioner built by AWS and donated to the CNCF.

Where the default Kubernetes Cluster Autoscaler scales pre-configured node groups up and down, Karpenter watches the actual resource requests of pending pods and provisions exactly the right EC2 instance type to satisfy them — selecting dynamically from thousands of available instance families rather than the two or three you pre-configured. It also continuously monitors running nodes for underutilisation and consolidates workloads onto fewer nodes, terminating the empty ones automatically.

The result is a cluster that is always sized to what your workloads actually need right now, not what you anticipated at setup time.

3.1 The Ceiling with Cluster Autoscaler

Cluster Autoscaler works with pre-defined node groups. You configure which instance types are available and it scales those groups up and down.

The limitation is that it can only provision instances from the types you pre-configured. It can't dynamically select the right instance type based on what the workload actually needs right now.

Here's the incorrect approach using static node groups:

# Bad: Two static node groups, each over-provisioning against worst-case scenarios
# CPU-optimised group runs even when workloads are memory-bound
# Memory-optimised group runs even when workloads are CPU-bound
eksctl create nodegroup \
  --cluster my-cluster \
  --name cpu-optimized \
  --instance-types c5.2xlarge \
  --nodes-min 5 --nodes-max 20

eksctl create nodegroup \
  --cluster my-cluster \
  --name memory-optimized \
  --instance-types r5.2xlarge \
  --nodes-min 3 --nodes-max 10

You're provisioning for the worst case in each family simultaneously. At any given moment, one group is underutilised while the other is scaling. Neither is right.

3.2 How Karpenter Solves This

Karpenter watches the actual resource requests of pending pods and provisions exactly the right instance type to fit them. It selects from thousands of available instance types, not just the two you pre-configured. It also consolidates running workloads onto fewer nodes when utilisation drops, automatically terminating underutilised nodes.

Here's the correct implementation:

# Good: Karpenter NodePool
# Karpenter selects the optimal instance type based on pending pod requirements
# Tries Spot first, falls back to On-Demand automatically when Spot isn't available
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      requirements:
        # Allow both x86 and ARM (Graviton) — Karpenter picks the cheaper option
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64", "arm64"]
        # Try Spot first, fall back to On-Demand if unavailable
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
        # Exclude families with poor price-to-performance ratio
        - key: karpenter.k8s.aws/instance-family
          operator: NotIn
          values: ["t2", "t3a"]
  limits:
    cpu: "1000"
    memory: "4000Gi"
  disruption:
    # Remove underutilised nodes and reschedule their pods automatically
    consolidationPolicy: WhenUnderutilized
    # Recycle nodes after 30 days to ensure fresh, patched AMIs
    expireAfter: 720h

What each setting does:

• consolidationPolicy: WhenUnderutilized: Karpenter continuously monitors node utilisation and removes underused nodes, moving their pods elsewhere. Your node count decreases automatically as load drops without any manual intervention.

• expireAfter: 720h: Nodes older than 30 days are gracefully replaced, ensuring your infrastructure always runs the latest EKS-optimised AMI with current security patches.

• values: ["spot", "on-demand"]: Karpenter attempts Spot capacity first. If Spot is unavailable for the requested instance type, it falls back to On-Demand with no alerts and no manual action required.

Migrating from Cluster Autoscaler safely:

# Step 1: Install Karpenter alongside Cluster Autoscaler — do not remove CAS yet
helm repo add karpenter https://charts.karpenter.sh
helm install karpenter karpenter/karpenter \
  --namespace karpenter \
  --create-namespace \
  --set settings.clusterName=your-cluster-name

# Step 2: Apply NodePool and NodeClass configuration
kubectl apply -f karpenter/nodepool.yaml
kubectl apply -f karpenter/nodeclass.yaml

# Step 3: Taint existing legacy nodes so new pods schedule on Karpenter nodes
# This migrates workloads gradually — zero downtime
kubectl taint nodes -l eks.amazonaws.com/nodegroup=cpu-optimized \
  group=legacy:NoSchedule

# Step 4: Watch pods reschedule to Karpenter-managed nodes over the next hour
kubectl get pods -o wide --all-namespaces | grep -v legacy

# Step 5: After 30 days of stable operation, remove the old node groups
eksctl delete nodegroup --cluster my-cluster --name cpu-optimized
eksctl delete nodegroup --cluster my-cluster --name memory-optimized

Ready-to-deploy NodePool and NodeClass templates are in karpenter/ in the companion repo.

3.3 Spot Instances for Non-Production Workloads

Staging and development workloads don't need the reliability guarantees of On-Demand instances. Moving them to Spot saves 60–90% on those node costs. Karpenter handles Spot interruptions by rescheduling pods automatically. For stateless workloads, interruptions are invisible to users.

# Good: Spot-only NodePool for staging environments
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: staging-spot
spec:
  template:
    metadata:
      labels:
        billing/environment: staging
    spec:
      taints:
        - key: environment
          value: staging
          effect: NoSchedule  # Only pods that tolerate this taint schedule here
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot"]   # Spot only for non-production
  disruption:
    consolidationPolicy: WhenUnderutilized

3.4 The ROI of Karpenter and Spot

Part 4: Graviton Migration

AWS Graviton is Amazon's own ARM-based processor family, available across EC2 instance types with names ending in g — m7g, c7g, r7g, and so on.

Graviton instances are priced approximately 20% lower than equivalent Intel or AMD x86 instances. For most server-side workloads — Node.js, Python, Go, Java — they also deliver 20–40% better performance per dollar because the processor architecture is optimised specifically for these workload types.

You don't change your application code to use Graviton. You change the architecture flag in your container image build and the node selector in your Kubernetes deployment.

4.1 Why Graviton Reduces Cost Without Reducing Performance

The first question to answer before migrating is whether your container images support ARM64. Most official images from Docker Hub ship as multi-architecture images. Your own application images need to be built for both architectures explicitly.

Check whether your images support ARM64:

# Check if an image has an ARM64 manifest
docker manifest inspect your-registry/your-app:latest | jq '.manifests[].platform'

Expected output for a multi-arch image:

{"architecture": "amd64", "os": "linux"},
{"architecture": "arm64", "os": "linux", "variant": "v8"}

If arm64 appears, the image is ready. If not, you need to build and push a multi-arch image first.

Build and push a multi-architecture image:

# Build for both x86 and ARM in a single command using Docker Buildx
docker buildx create --use --name multi-arch-builder

docker buildx build \
  --platform linux/amd64,linux/arm64 \
  --tag your-registry/your-app:latest \
  --push \
  .

4.2 Migrating Workloads to Graviton

With Karpenter already installed, Graviton migration is a single label change on your deployment. Karpenter provisions the appropriate ARM64 node automatically.

Here's the correct implementation:

# Good: nodeSelector directs the pod to Graviton nodes
# Karpenter provisions an arm64 node if one isn't already available
apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-api
spec:
  template:
    spec:
      nodeSelector:
        kubernetes.io/arch: arm64   # Schedule exclusively on Graviton nodes
      containers:
        - name: api
          image: your-registry/payment-api:latest  # Must be multi-arch

Migrate gradually, starting with stateless services:

# Step 1: Migrate one stateless service and monitor for 48 hours
kubectl patch deployment payment-api \
  -p '{"spec":{"template":{"spec":{"nodeSelector":{"kubernetes.io/arch":"arm64"}}}}}'

# Step 2: Watch for errors in the first 30 minutes
kubectl logs -l app=payment-api --tail=100 -f

# Step 3: Verify the pod is running on a Graviton node
# The NODE column should show a Graviton instance type (m7g, c7g, r7g)
kubectl get pods -l app=payment-api -o wide

# Step 4: After 48 hours of stable operation, migrate the next service

There are some situations where you shouldn't migrate to Graviton: GPU workloads, applications with native x86 binary dependencies, or any workload where you haven't yet built multi-arch images.

4.3 The ROI of Graviton

Part 5: VPC Endpoints for Data Transfer

5.1 The NAT Gateway Tax

Every byte that travels from your EKS pods to an AWS service — S3, DynamoDB, ECR, SQS — goes through a NAT Gateway if you haven't configured VPC endpoints. NAT Gateway charges $0.045 per GB of data processed.

A busy EKS cluster pulling container images from ECR, writing to S3, and polling SQS queues can process hundreds of terabytes per month through NAT Gateway — generating thousands of dollars in charges for traffic that never actually left the AWS network.

Measure your current NAT Gateway cost before adding endpoints:

# Get last month's NAT Gateway data processing charges
aws ce get-cost-and-usage \
  --time-period Start=\((date -d 'last month' +%Y-%m-01),End=\)(date +%Y-%m-01) \
  --granularity DAILY \
  --filter '{
    "Dimensions": {
      "Key": "USAGE_TYPE",
      "Values": ["NATGateway-Bytes"]
    }
  }' \
  --metrics UnblendedCost \
  --query 'ResultsByTime[*].{Date:TimePeriod.Start,Cost:Total.UnblendedCost.Amount}' \
  --output table

5.2 VPC Endpoints — The Fix That Takes 30 Minutes

A VPC endpoint creates a private connection between your VPC and an AWS service, routing traffic through the AWS backbone without touching the NAT Gateway. The data transfer becomes free. Each endpoint costs approximately \(0.01/hour — roughly \)7.20/month — far less than the NAT Gateway processing charges it replaces.

Here's the complete implementation for the four most common EKS traffic destinations:

# Get your VPC ID and primary route table ID first
VPC_ID=$(aws eks describe-cluster --name your-cluster \
  --query 'cluster.resourcesVpcConfig.vpcId' --output text)

ROUTE_TABLE_ID=$(aws ec2 describe-route-tables \
  --filters Name=vpc-id,Values=$VPC_ID Name=association.main,Values=true \
  --query 'RouteTables[0].RouteTableId' --output text)

echo "VPC: \(VPC_ID | Route Table: \)ROUTE_TABLE_ID"

# S3 gateway endpoint — free to create, eliminates all S3 traffic through NAT
aws ec2 create-vpc-endpoint \
  --vpc-id $VPC_ID \
  --service-name com.amazonaws.us-east-1.s3 \
  --route-table-ids $ROUTE_TABLE_ID

# DynamoDB gateway endpoint — also free, same mechanism as S3
aws ec2 create-vpc-endpoint \
  --vpc-id $VPC_ID \
  --service-name com.amazonaws.us-east-1.dynamodb \
  --route-table-ids $ROUTE_TABLE_ID

# ECR API interface endpoint — eliminates NAT charges on image pulls
aws ec2 create-vpc-endpoint \
  --vpc-id $VPC_ID \
  --vpc-endpoint-type Interface \
  --service-name com.amazonaws.us-east-1.ecr.api \
  --subnet-ids $(aws ec2 describe-subnets \
    --filters Name=vpc-id,Values=$VPC_ID Name=tag:Tier,Values=private \
    --query 'Subnets[*].SubnetId' --output text)

# ECR Docker endpoint — required alongside ECR API for complete image pull coverage
aws ec2 create-vpc-endpoint \
  --vpc-id $VPC_ID \
  --vpc-endpoint-type Interface \
  --service-name com.amazonaws.us-east-1.ecr.dkr \
  --subnet-ids $(aws ec2 describe-subnets \
    --filters Name=vpc-id,Values=$VPC_ID Name=tag:Tier,Values=private \
    --query 'Subnets[*].SubnetId' --output text)

The Terraform module that creates all four endpoints in a single apply is in terraform/vpc-endpoints/ in the companion repo.

Verify that the endpoints are routing traffic correctly:

aws ec2 describe-vpc-endpoints \
  --filters Name=vpc-id,Values=$VPC_ID \
  --query 'VpcEndpoints[*].{Service:ServiceName,State:State,Type:VpcEndpointType}' \
  --output table
# Expected: all endpoints showing State=available

5.3 The ROI of VPC Endpoints

Part 6: EBS Volume Optimisation

6.1 The gp2 to gp3 Migration

EBS gp2 volumes price their IOPS based on storage size — 3 IOPS per GB, with a 100 IOPS minimum. EBS gp3 volumes provide 3,000 IOPS baseline regardless of size, and cost 20% less per GB. The migration runs online with no downtime.

Find and migrate all gp2 volumes:

# Step 1: List all gp2 volumes and their sizes
aws ec2 describe-volumes \
  --filters Name=volume-type,Values=gp2 \
  --query 'Volumes[*].{ID:VolumeId,Size:Size,State:State}' \
  --output table

# Step 2: Migrate each gp2 volume to gp3 — no instance stop required
# The modify operation runs online while the volume stays attached and in use
aws ec2 describe-volumes \
  --filters Name=volume-type,Values=gp2 \
  --query 'Volumes[*].VolumeId' \
  --output text | tr '\t' '\n' | while read vol; do
    echo "Migrating $vol from gp2 to gp3..."
    aws ec2 modify-volume \
      --volume-id $vol \
      --volume-type gp3
done

# Step 3: Verify all volumes are now gp3
aws ec2 describe-volumes \
  --filters Name=volume-type,Values=gp2 \
  --query 'Volumes[*].VolumeId' \
  --output text
# Expected: empty output — zero gp2 volumes remaining

6.2 Finding and Removing Orphaned Volumes and Snapshots

When Kubernetes PersistentVolumeClaims are deleted, the underlying EBS volumes sometimes aren't cleaned up. They keep running — and billing — indefinitely.

# Find unattached EBS volumes — status=available means not attached to any instance
aws ec2 describe-volumes \
  --filters Name=status,Values=available \
  --query 'Volumes[*].{ID:VolumeId,Size:Size,Created:CreateTime}' \
  --output table

# Find EBS snapshots older than 90 days
aws ec2 describe-snapshots \
  --owner-ids self \
  --query "Snapshots[?StartTime<='$(date -d '90 days ago' --iso-8601=seconds)'].[SnapshotId,StartTime,VolumeSize]" \
  --output table

Before deleting any snapshot, cross-reference with your RDS automated backup schedule to confirm it's not the only backup for a production database.

6.3 The ROI of EBS Optimisation

Part 7: Load Balancer Consolidation

7.1 The Problem — One Load Balancer Per Service

Many teams create a separate LoadBalancer Service for every microservice. On AWS, each Application Load Balancer costs approximately \(16.20/month base charge plus \)0.008/LCU-hour for traffic processed. At 20 microservices, that's $324/month before a single request is processed.

Here's the incorrect approach:

# Bad: This creates a dedicated AWS ALB every time it's applied
# 20 microservices = 20 ALBs = $324+/month before any traffic charges
apiVersion: v1
kind: Service
metadata:
  name: payment-api
spec:
  type: LoadBalancer   # Creates a dedicated ALB
  ports:
  - port: 80
    targetPort: 8080

7.2 The Fix — Shared Ingress Controller

An Ingress controller is a Kubernetes component that runs as a pod inside your cluster and programs a single external load balancer to route traffic to multiple services based on hostname and URL path. Instead of one AWS Application Load Balancer per microservice, you get one ALB total — with path-based routing directing each request to the right backend service. The result is the same routing behaviour at a fraction of the cost.

Here's the correct implementation:

# Good: One Ingress resource routes all external traffic
# The AWS Load Balancer Controller creates one ALB for all services listed here
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shared-ingress
  namespace: production
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS": 443}]'
    alb.ingress.kubernetes.io/ssl-redirect: "443"
spec:
  rules:
  - host: api.company.com
    http:
      paths:
      - path: /payments
        pathType: Prefix
        backend:
          service:
            name: payment-service
            port:
              number: 8080
      - path: /users
        pathType: Prefix
        backend:
          service:
            name: user-service
            port:
              number: 8080
  - host: dashboard.company.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: dashboard-service
            port:
              number: 3000
  tls:
  - hosts:
    - api.company.com
    - dashboard.company.com
    secretName: tls-wildcard-cert

Verify the Ingress is provisioned and the ALB DNS name is assigned:

# Watch until the ADDRESS column shows the ALB DNS name (typically 2–3 minutes)
kubectl get ingress shared-ingress -n production -w

The cost difference:

The shared Ingress manifest is in k8s/ingress/ in the companion repo.

The Complete 7-Step Sequence

Annual saving at this rate: $597,588. Engineering time required: one engineer, one sprint per step.

Best Practices for EKS Cost Optimisation

✅ Do: Right-size pod resource requests before any other optimisation. Every subsequent step depends on accurate requests.

✅ Do: Implement Karpenter with consolidationPolicy: WhenUnderutilized. Let it continuously optimise your node count automatically.

✅ Do: Move staging and development workloads to Spot. 60–90% savings for workloads that tolerate interruption.

✅ Do: Migrate compatible workloads to Graviton. Most web services and APIs run without code changes.

✅ Do: Add VPC endpoints for S3, DynamoDB, and ECR before reviewing data transfer costs.

✅ Do: Migrate gp2 volumes to gp3. It's online, zero downtime, and immediately 20% cheaper.

✅ Do: Use a single shared Ingress controller for all external traffic instead of per-service load balancers.

❌ Don't: Buy Savings Plans before completing steps 1–6. You'll lock in waste for 1–3 years.

❌ Don't: Use static node groups with Cluster Autoscaler when your workload mix changes. Karpenter handles this dynamically.

❌ Don't: Run staging and development environments on On-Demand instances. Spot interruptions are manageable, but the cost difference is not.

Resources

• Karpenter Documentation — Official NodePool configuration reference and installation guide

• AWS Graviton Getting Started Guide — Language-specific compatibility notes and migration guidance from AWS

• Vertical Pod Autoscaler GitHub — VPA installation and configuration documentation

• AWS VPC Endpoints Documentation — Complete list of available VPC endpoints and configuration options

• EBS Volume Modification Documentation — AWS guide for online volume type migration with zero downtime

• AWS Load Balancer Controller — Official documentation for the Ingress controller that provisions AWS ALBs

• AWS Cost Explorer API Reference — Full reference for the cost breakdown commands used throughout this guide

• EKS Best Practices Guide — Cost Optimisation — AWS's official EKS cost optimisation framework

• Companion Repository — All Terraform modules, NodePool templates, VPA manifests, and automation scripts from this guide

I spent a good chunk of last year debugging slow Docker builds across multiple teams. The pattern was always the same: builds that should take two minutes were eating up fifteen, and nobody knew why. The fix turned out to be surprisingly systematic once I understood what was actually happening under the hood.

This guide walks you through exactly how to fix slow Docker builds, step by step. We'll start with how the cache actually works, then tear apart the most common mistakes, and finish with production-ready patterns you can copy into your projects today.

Table of Contents

• Prerequisites

• How Docker Build Cache Actually Works

  • How Cache Keys Are Computed

  • The Cache Chain Rule

• How to Identify Common Cache-Busting Mistakes

  • Mistake 1: Copying Everything Too Early

  • Mistake 2: Not Separating Dependency Files

  • Mistake 3: Using ADD Instead of COPY

  • Mistake 4: Splitting apt-get update and install

  • Mistake 5: Embedding Timestamps or Git Hashes Too Early

• How to Structure Your Dockerfile for Maximum Cache Reuse

  • Step 1: Apply the Dependency-First Pattern

  • Step 2: Add an Aggressive .dockerignore

  • Step 3: Use Multi-Stage Builds

  • Step 4: Order Layers by Change Frequency

  • Step 5: Use BuildKit Mount Caches

• How to Set Up CI/CD Cache Backends

  • Option A: Registry-Based Cache

  • Option B: GitHub Actions Cache

  • Option C: S3 or Cloud Storage

  • Option D: Local Cache with Persistent Runners

• How to Implement Advanced Cache Patterns

  • Parallel Build Stages

  • Cache Warming for Feature Branches

  • Selective Cache Invalidation with Build Args

• How to Measure Your Improvements

  • The Four Scenarios to Benchmark

  • Real-World Before and After Numbers

  • How to Check Cache Hit Rates

• Complete Optimized Dockerfile Examples

  • Node.js Full-Stack App

  • Python FastAPI App

  • Go Microservice

• Troubleshooting Guide

• Quick-Reference Checklist

• Conclusion

Prerequisites

To follow along, you'll need:

• A working Docker installation (Docker Desktop or Docker Engine 20.10+)

• Basic comfort with writing Dockerfiles

• Access to a CI/CD system like GitHub Actions, GitLab CI, or Jenkins

How Docker Build Cache Actually Works

Every instruction in a Dockerfile produces a layer. Docker stores these layers and reuses them when it detects nothing has changed. That's the cache. Simple enough in theory, but the details matter a lot.

How Cache Keys Are Computed

Different instructions compute their cache keys differently:

The Cache Chain Rule

Here's the thing most people miss: Docker cache is sequential. If any layer's cache gets invalidated, every layer after it rebuilds from scratch, even if those later layers haven't changed at all.

Picture a row of dominoes. Knock one over in the middle and everything after it goes down too. This is why the order of instructions in your Dockerfile is so important.

Key insight: The single most impactful optimization you can make is reordering your Dockerfile so that the stuff that changes most often comes last.

How to Identify Common Cache-Busting Mistakes

Before we fix anything, let's look at what's probably breaking your cache right now. I've seen these patterns in almost every unoptimized Dockerfile I've reviewed.

Mistake 1: Copying Everything Too Early

This is the big one. Putting COPY . . near the top of the Dockerfile, before installing dependencies, means that any file change in your project invalidates the cache from that point forward. Changed a README? Cool, now your dependencies reinstall.

# BAD: Any file change invalidates the dependency install
FROM node:20-alpine
WORKDIR /app
COPY . .                    # Cache busted on every commit
RUN npm ci                  # Reinstalls every single time
RUN npm run build

Mistake 2: Not Separating Dependency Files

Your dependency manifests (package.json, requirements.txt, go.mod, Gemfile) change way less often than your source code. If you don't copy them separately, you're reinstalling all dependencies every time you touch a source file.

Mistake 3: Using ADD Instead of COPY

ADD has special behaviors like auto-extracting archives and fetching remote URLs. Those features make its cache behavior unpredictable. Stick with COPY unless you specifically need archive extraction.

Mistake 4: Splitting apt-get update and install

When you put apt-get update and apt-get install in separate RUN commands, the update step gets cached with stale package indexes. Then the install step fails or grabs outdated packages.

# BAD: Stale package index
RUN apt-get update
RUN apt-get install -y curl    # May fail with stale index

# GOOD: Always combine them
RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/*

Mistake 5: Embedding Timestamps or Git Hashes Too Early

Injecting build-time variables like timestamps or git commit hashes via ARG or ENV early in the Dockerfile invalidates the cache on every single build. Move these to the very last layer.

⚠️ Watch out for this: CI/CD systems often inject variables like BUILD_NUMBER or GIT_SHA as build args automatically. If those ARG declarations sit near the top, your cache is toast on every run.

How to Structure Your Dockerfile for Maximum Cache Reuse

Now let's fix those mistakes. These five steps, applied in order, will get you most of the way to an optimized build.

Step 1: Apply the Dependency-First Pattern

Copy only the dependency manifests first, install, and then copy the rest of the source code. This one change alone can cut your build times in half.

# GOOD: Dependency-first pattern for Node.js
FROM node:20-alpine
WORKDIR /app

# Copy ONLY dependency files
COPY package.json package-lock.json ./

# Install dependencies (cached unless package files change)
RUN npm ci --production

# Copy source code (only this layer rebuilds on code changes)
COPY . .

# Build
RUN npm run build

The same idea works across every language:

Step 2: Add an Aggressive .dockerignore

A .dockerignore file keeps irrelevant files out of the build context. Fewer files in the context means fewer things that can break your cache.

# .dockerignore
.git
node_modules
dist
*.md
*.log
.env*
docker-compose*.yml
Dockerfile*
.github
tests
coverage
__pycache__

Step 3: Use Multi-Stage Builds

Multi-stage builds let you use a full development image for compiling, then copy only the finished artifacts into a slim runtime image. You get smaller images, better security, and improved cache performance because build tools and intermediate files don't carry over.

# Stage 1: Build
FROM node:20-alpine AS builder
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build

# Stage 2: Production
FROM node:20-alpine AS production
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
COPY package.json ./
EXPOSE 3000
CMD ["node", "dist/index.js"]

Step 4: Order Layers by Change Frequency

Think of your Dockerfile as a stack. Put the boring, stable stuff at the top and the volatile stuff at the bottom:

1. Base image and system dependencies (rarely change)

2. Language runtime configuration (occasionally change)

3. Application dependencies (change when you add or remove packages)

4. Source code (changes on every commit)

5. Build-time metadata like git hash or version labels (changes every build)

Step 5: Use BuildKit Mount Caches

Docker BuildKit supports RUN --mount=type=cache, which mounts a persistent cache directory that survives across builds. This is a game-changer for package managers that maintain their own download caches.

# syntax=docker/dockerfile:1

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .

# Mount pip cache so downloads persist across builds
RUN --mount=type=cache,target=/root/.cache/pip \
    pip install -r requirements.txt

COPY . .

The best part: mount caches persist even when the layer itself gets invalidated. So if you add one new package, pip only downloads that one package instead of re-fetching everything.

Here are the common cache targets for popular package managers:

How to Set Up CI/CD Cache Backends

Here's where things get tricky. Your local Docker cache works great on your laptop because the layers persist between builds. But CI/CD runners are usually ephemeral: each job starts with a totally empty cache. Without explicit cache configuration, every CI build is a cold build.

Option A: Registry-Based Cache

BuildKit can push and pull cache layers from a container registry. This is the most portable approach and works with any CI system.

docker buildx build \
  --cache-from type=registry,ref=myregistry.io/myapp:buildcache \
  --cache-to type=registry,ref=myregistry.io/myapp:buildcache,mode=max \
  --tag myregistry.io/myapp:latest \
  --push .

💡 Use mode=max to cache all layers including intermediate build stages. The default mode=min only caches layers in the final stage, which means your build stage layers get thrown away.

Option B: GitHub Actions Cache

If you're on GitHub Actions, there's native integration with BuildKit through the GitHub Actions cache API. It's fast and requires minimal setup.

# .github/workflows/build.yml
- name: Set up Docker Buildx
  uses: docker/setup-buildx-action@v3

- name: Build and push
  uses: docker/build-push-action@v5
  with:
    context: .
    push: true
    tags: myregistry.io/myapp:latest
    cache-from: type=gha
    cache-to: type=gha,mode=max

Option C: S3 or Cloud Storage

For teams on AWS, GCP, or Azure, cloud object storage makes a solid cache backend. It's fast, persistent, and works across any CI system.

docker buildx build \
  --cache-from type=s3,region=us-east-1,bucket=my-docker-cache,name=myapp \
  --cache-to type=s3,region=us-east-1,bucket=my-docker-cache,name=myapp,mode=max \
  --tag myapp:latest .

Option D: Local Cache with Persistent Runners

If your CI runners have persistent storage (self-hosted runners, GitLab runners with shared volumes), you can export cache to a local directory.

docker buildx build \
  --cache-from type=local,src=/ci-cache/myapp \
  --cache-to type=local,dest=/ci-cache/myapp,mode=max \
  --tag myapp:latest .

How to Implement Advanced Cache Patterns

Once you've nailed the basics, these patterns can squeeze out even more performance.

Parallel Build Stages

BuildKit builds independent stages in parallel. If your app has a frontend and a backend that don't depend on each other during build, split them into separate stages and let BuildKit run them simultaneously.

# These stages build in parallel
FROM node:20-alpine AS frontend
WORKDIR /frontend
COPY frontend/package.json frontend/package-lock.json ./
RUN npm ci
COPY frontend/ .
RUN npm run build

FROM python:3.12-slim AS backend
WORKDIR /backend
COPY backend/requirements.txt .
RUN pip install -r requirements.txt
COPY backend/ .

# Final stage combines both
FROM python:3.12-slim
COPY --from=backend /backend /app
COPY --from=frontend /frontend/dist /app/static
CMD ["python", "/app/main.py"]

Cache Warming for Feature Branches

Feature branches often start with a cold cache because they diverge from main. You can warm the cache by specifying multiple --cache-from sources. Docker checks them in order.

docker buildx build \
  --cache-from type=registry,ref=registry.io/app:cache-${BRANCH} \
  --cache-from type=registry,ref=registry.io/app:cache-main \
  --cache-to type=registry,ref=registry.io/app:cache-${BRANCH},mode=max \
  --tag registry.io/app:${BRANCH} .

If the branch cache hits, Docker uses it. If not, it falls back to main's cache, which usually shares most layers. This makes a massive difference for short-lived branches.

Selective Cache Invalidation with Build Args

You can use ARG instructions as cache boundaries. Anything above the ARG stays cached, while anything below it rebuilds when the arg value changes.

FROM node:20-alpine
WORKDIR /app

COPY package.json package-lock.json ./
RUN npm ci

# This ARG only invalidates layers below it
ARG CACHE_BUST_CODE=1
COPY . .
RUN npm run build

# This ARG only invalidates the label
ARG GIT_SHA=unknown
LABEL git.sha=$GIT_SHA

How to Measure Your Improvements

Optimization without measurement is just guessing. Here's how to actually prove your changes are working.

The Four Scenarios to Benchmark

Run each scenario at least three times and take the median:

1. Cold build: No cache at all (first build or after docker builder prune)

2. Warm build: No changes, full cache hit

3. Code change: Only source code modified

4. Dependency change: Package manifest modified

Real-World Before and After Numbers

Here's what I saw on a mid-sized Node.js project after applying the techniques from this guide:

The "before" column is the same for all rows because without cache optimization, every build was essentially a cold build. That 85% improvement on code-only changes is the number that matters most, since that's what happens on the vast majority of commits.

How to Check Cache Hit Rates

Set BUILDKIT_PROGRESS=plain to get detailed output showing which layers hit cache:

BUILDKIT_PROGRESS=plain docker buildx build . 2>&1 | grep -E 'CACHED|DONE'

Look for the CACHED prefix on layers. Your goal is to see CACHED on everything except the layers that actually needed to change.

Complete Optimized Dockerfile Examples

Here are production-ready Dockerfiles you can adapt for your own projects.

Node.js Full-Stack App

# syntax=docker/dockerfile:1
FROM node:20-alpine AS deps
WORKDIR /app
COPY package.json package-lock.json ./
RUN --mount=type=cache,target=/root/.npm npm ci

FROM node:20-alpine AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN npm run build

FROM node:20-alpine AS runner
WORKDIR /app
ENV NODE_ENV=production
RUN addgroup --system --gid 1001 appgroup \
    && adduser --system --uid 1001 appuser
COPY --from=builder --chown=appuser:appgroup /app/dist ./dist
COPY --from=deps /app/node_modules ./node_modules
COPY package.json ./
USER appuser
EXPOSE 3000
CMD ["node", "dist/index.js"]

Python FastAPI App

# syntax=docker/dockerfile:1
FROM python:3.12-slim AS builder
WORKDIR /app
COPY requirements.txt .
RUN --mount=type=cache,target=/root/.cache/pip \
    pip install --user -r requirements.txt

FROM python:3.12-slim
WORKDIR /app
COPY --from=builder /root/.local /root/.local
ENV PATH=/root/.local/bin:$PATH
COPY . .
EXPOSE 8000
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

Go Microservice

# syntax=docker/dockerfile:1
FROM golang:1.22-alpine AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN --mount=type=cache,target=/go/pkg/mod go mod download
COPY . .
RUN --mount=type=cache,target=/root/.cache/go-build \
    CGO_ENABLED=0 go build -ldflags='-s -w' -o /app/server ./cmd/server

FROM gcr.io/distroless/static-debian12
COPY --from=builder /app/server /server
EXPOSE 8080
ENTRYPOINT ["/server"]

Troubleshooting Guide

When things go wrong, check this table first:

Quick-Reference Checklist

Print this out and tape it next to your monitor:

• [ ] Enable BuildKit: set DOCKER_BUILDKIT=1 or use docker buildx

• [ ] Add a comprehensive .dockerignore file

• [ ] Use the dependency-first pattern: copy manifests, install, then copy source

• [ ] Order layers from least-changed to most-changed

• [ ] Combine RUN commands that belong together (apt-get update && install)

• [ ] Use multi-stage builds to separate build and runtime

• [ ] Add RUN --mount=type=cache for package manager caches

• [ ] Move volatile ARGs (git hash, build number) to the very last layers

• [ ] Configure a CI/CD cache backend (registry, gha, or s3)

• [ ] Set up cache warming for feature branches from the main branch

• [ ] Use COPY instead of ADD unless you need archive extraction

• [ ] Benchmark all four scenarios: cold, warm, code change, dependency change

Conclusion

I used to think slow Docker builds were just something you had to live with. After going through this process on a few projects, I realized the fix is pretty mechanical once you understand that one core principle: cache is sequential, and order matters.

Start with the dependency-first pattern and a .dockerignore. Those two changes alone will probably cut your build times in half. Then add multi-stage builds, mount caches, and CI/CD cache backends as you need them.

The teams I've worked with typically see 70-85% reductions in CI/CD pipeline times after spending a few hours on these changes. That's time you get back on every single commit, every single day.

If you found this helpful, consider sharing it with your team. There's a good chance whoever wrote your Dockerfile last didn't know about half of these tricks. No shade to them, I didn't either until I went looking.

Happy building.

Go follows the same model, but you usually don’t decide between the stack and the heap directly. Instead, the Go compiler decides where values live. If the compiler can prove a value is only needed within the current function call, it can keep it on the stack. If it cannot prove that, the value “escapes” and is placed on the heap. This technique is called escape analysis.

This matters because heap allocations increase garbage collector work. In code that runs often, that extra work can show up as more CPU spent in GC, more allocations, and less predictable performance.

In this article, I’ll explain what escape analysis is, the common patterns that trigger heap allocation, and how to confirm and reduce avoidable allocations.

Table of Contents

• Prerequisites

• Do You Really Need to Care About Escape Analysis?

• Memory Layout and Lifecycle

• Sharing Down and Sharing Up

• Escape Analysis in Practice

• How to Use Escape Analysis to Guide Performance

• Conclusion

• Further Reading

Prerequisites

• Familiarity with Go fundamentals (functions, variables, structs, slices, maps)

• Basic understanding of pointers in Go (& and *)

• A general idea of how goroutines work

Do You Really Need to Care About Escape Analysis?

Before we go deeper, I want to call this out clearly. For the correctness of your program, it doesn’t matter whether a variable lives on the stack or on the heap, or whether you know that detail. The Go compiler is smart enough to place values where they need to be so that your program behaves correctly.

Most of the time, you don’t need to think about this at all. It only starts to matter when performance becomes a problem. If your program is already fast enough, you’re done, and there’s no point trying to squeeze out extra speed.

You should only start caring about stack vs heap when you have benchmarks that show your program is too slow, and those same benchmarks point to heavy heap allocation and garbage collection as part of the problem.

Memory Layout and Lifecycle

To get a better understanding of what escape analysis is, you first need a simple picture of how Go lays out memory while your program runs. At this level, it comes down to the stack each goroutine uses, how stack frames are carved out of that stack, and when values move to the heap where the garbage collector can see them.

Goroutine Stacks and Stack Frames

When a Go program starts, the runtime creates the main goroutine, and every go statement creates a new goroutine, each with its own stack.

There’s not a single global stack for the whole process. As of writing this article, with Go v1.25.7, each goroutine gets an initial contiguous block of 2,048 bytes of memory, which acts as its stack. The stack is where Go stores data that belongs to function calls. When a goroutine calls a function, Go reserves a chunk of that goroutine’s stack for the function’s local data. That chunk is called a stack frame.

It holds the function’s local variables and the call state needed to return and continue execution. If that function calls another function, a new frame is added on top. When the inner function returns, its frame becomes invalid, and the goroutine continues in the caller’s frame.

A stack frame only lives for as long as the function is active. Once the function returns, anything stored in its frame is considered invalid, even if the raw bytes are still in memory and will be reused later. Code must not rely on those values after the return

Go stacks can grow. A goroutine starts with a small stack and the runtime grows it when needed, but the lifetime rule stays the same. A value is safe in a stack frame only if nothing can still reference it after the function returns. If it might be referenced later, it can’t stay in that frame and must be placed somewhere safer.

Pointers and Lifetime

In Go, taking an address like p := &x means you now have a pointer in one stack frame that refers to a value which may have been created in another frame. When you pass that pointer into a function, Go still passes by value. The callee gets its own pointer variable on its own stack frame, but the address inside still points to the same underlying value. So pointers are how you share access to one value across several frames without copying the value itself.

Lifetime becomes important when a pointer can outlive the frame where the pointed value was created. As long as both the pointer and the value live inside frames that are still active in the current call stack, everything is safe.

Once a pointer might still exist after the original frame has returned, the value can no longer stay in that frame, because that frame will become invalid. At that point, the value has to be placed in a safer location so that no pointer ever points into dead stack memory.

Sharing Down and Sharing Up

Now that you have a picture of stacks, frames, and pointers, we can look at two common ways pointers move through your code. I’ll call them sharing down and sharing up. The names aren’t special Go terms. They’re just a simple way to describe how a pointer moves along the call stack.

Sharing Down

Sharing down means a function passes a pointer or reference to functions it calls. The pointer moves deeper into the call stack, but the value it points to still belongs to a frame that is active.

Example code:

package main

import "fmt"

func main() {
    n := 10
    multiply(&n) 
}

func multiply(v *int) {
   *v = *v * 2
}

In main, you take the address of n and pass it into multiply. While multiply runs, both the main frame and the multiply frames are active. The pointer in multiply points to a value that still lives in an active frame, so this situation is safe from a lifetime point of view.

In the diagram below, after the multiply function runs and returns, the multiply frame becomes invalid, and we don’t need to do anything because the stack pointer is simply popped back to the previous frame's address. This action automatically reclaims all the memory used by that function in one step, so the garbage collector is not involved in cleaning up stack memory

Sharing Up

Sharing up means a function returns a pointer, or stores it somewhere that will still be around after the function returns. The pointer moves back up the call stack or into some longer-lived state while the frame that created the value is about to end, so that value can no longer be tied to that one frame.

The same idea shows up when you share a value with another goroutine, because Go doesn’t let one goroutine hold pointers into another goroutine’s stack, so shared data needs a lifetime that is not tied to a single stack.

Heap, garbage collection, and lifetime

Values that might outlive a single stack frame can’t stay in that frame. The compiler places them on the heap instead. The heap is a separate region of memory that isn’t tied to one function call. Any goroutine can hold pointers to heap values, and those values stay valid as long as something in the program can still reach them. You can think of the heap as storage for “might live longer than this call”.

The garbage collector is what keeps this safe. Periodically, the runtime starts from a set of roots (global variables, active stack frames, some internal state) and follows all the pointers it can see. Any heap value that is still reachable is kept. Any heap value that is no longer reachable is treated as garbage and its memory is reclaimed.

This means a pointer in main will never legally point into dead stack memory. Either the value stayed in an active frame, or it was placed on the heap where the GC can track its lifetime. The tradeoff is that more heap allocations and longer-lived objects require the GC to do more work.

Here’s an example:

package main

import "fmt"

type Car struct {
    Brand string
    Model string
}

func main() {
    // main receives a pointer from a function it called and this is sharing up
    carPtr := makeCar("Volkswagen", "Golf") 

    fmt.Printf("I received a car: %s %s\n", carPtr.Brand, carPtr.Model)
}

func makeCar(b, m string) *Car {
    myCar := Car{
        Brand: b,
        Model: m,
    }
    return &myCar
}

In the above code:

1. In makeCar (the callee frame), Go creates a local variable myCar. Because you return &myCar, the compiler allocates the Car value on the heap, and let’s myCar hold the heap address 0xc00029fa0.

2. When makeCar returns, that address is copied into carPtr in main (the top frame). carPtr is just another stack variable, but its value is still 0xc00029fa0, so now main also points to the same heap Car.

3. On the right, the heap bubble shows the actual Car value at 0xc00029fa0. Both car (while makeCar is running) and carPtr (after it returns) reach that same value through their pointers.

4. Once makeCar is done, its frame drops into the “invalid memory” region, but the Car stays alive on the heap because main still holds carPtr. That’s the escape: the value stops being tied to the callee frame and gets heap lifetime instead.

Escape Analysis in Practice

Escape analysis is how the Go compiler decides whether a value lives on the stack or on the heap. It’s not only about returning pointers – it follows how addresses move through your code. If a value might outlive the current function, the compiler can’t keep it in that stack frame and moves it to the heap. Since only the compiler sees the full picture, the useful thing is to ask it to show these decisions and then link them back to your code.

To do that, we can pass compiler flags using -gcflags when running go build or go run. If you want to see the available options, you can check go tool compile -h. In that list, -m prints the compiler’s optimisation decisions, including escape analysis output. If you want more details, you can use -m=2 or -m=3 for a more verbose output. The -l flag disables inlining, so the report is easier to read because the compiler is not merging small functions into their callers.

So, the command will look like this:

go run -gcflags='all=-m -l' .

Or for a build:

go build -gcflags='all=-m -l' .

How to Use Escape Analysis to Guide Performance

You can think of escape analysis as the thing that turns your code choices into GC work. When a value escapes, it gets heap lifetime, and the garbage collector has to visit it. In hot paths, lots of small escaping values show up as extra GC time and jitter in latency. When a value stays in a stack frame, it becomes invalid and dies with the frame and the GC does not care about it.

Here are five simple practices that help performance without making

1. Prefer values for small data: If the function doesn’t need to mutate the caller’s data, use value types for small structs and basic types when passing arguments and returning results. It’s cheap to copy an int or a small struct, and it often keeps lifetimes local to a single call.

2. Use pointers when sharing or mutation is part of the design: opt for pointers when you genuinely need shared mutable state or want to avoid copying large structs.

3. Avoid creating long-lived references by accident: Be careful when returning pointers to locals, capturing variables in closures, or storing addresses in long-lived structs, maps, or interfaces. These patterns are the ones most likely to push values out of a stack frame.

4. Pass in reusable buffers on hot paths: On code paths that run very often, the problem is usually not one big allocation, but many small ones happening in a loop. A common cause is functions that always create a new buffer inside, even when the caller could have passed one in.

   A simple way to cut those extra allocations is to let the caller own the buffer. The caller allocates a []byte once, then passes it into the function each time. The function only fills the buffer instead of creating a new one.

   Here’s an example of how a bad function allocates a new buffer every call:

    package main
   
    // Bad: helper allocates every call.
    func fillBad() []byte {
        buf := make([]byte, 4096)
        // pretend we read into it
        buf[0] = 1
        return buf
    }
   
    func hotPathBad() {
        for i := 0; i < 1_000_000; i++ {
            b := fillBad() // allocates 1,000,000 times
            _ = b
        }
    }
   
    func main() {
        hotPathBad()
    }
   

   When we run escape analysis with this:

    go run -gcflags='-m -l' .
   

   We see the following:

    ./main.go:5:13: make([]byte, 4096) escapes to heap
   

   If we were only allocating a few times, we could choose not to worry – but the real problem is how this looks inside the loop. hotPathBad calls fillBad on every iteration, so each call allocates a new 4 KB slice on the heap. If this loop runs many times, you end up creating a lot of short-lived heap objects. The garbage collector then has to find and clean up all those buffers, which adds extra work that you could have avoided by reusing a single buffer.

   Here’s an example of a better version where the caller allocates once and reuses:

    package main
   
    func fill(buf []byte) int {
        // pretend we read into it
        buf[0] = 1
        return 1
    }
   
    func hotPath() {
        buf := make([]byte, 4096) 
   
        for i := 0; i < 1_000_000; i++ {
            n := fill(buf) 
            _ = buf[:n]
        }
    }
   
    func main() {
        hotPath()
    }
   

   In this version, hotPath controls the buffer. It allocates buf once, then passes it into fill on every loop. You still read the same data, but you avoid creating a new slice on each call. That reduces avoidable allocations in the hot path.

Conclusion

In Go, where a value ends up is not decided by how you create it. It’s decided by how long that value must remain valid and how it is referenced as your code runs.

The practical takeaway is not to avoid pointers. It’s to be deliberate about lifetime. Value semantics can keep lifetimes tight and reduce GC work, while pointers can be the right choice when you need shared state or in-place updates. The balance is to write the clear version first, then look at your benchmarks and profiles to see if anything actually really needs to change.

Further Reading

Language Mechanics On Stacks And Pointers - William Kennedy

Go Compiler: Escape Analysis Flaws

In this article, you’ll learn why traditional testing methods fall short for AI systems and how an evaluation flywheel can be used as a practical approach to testing and improving AI applications. The sections below break the evaluation flywheel down step by step, from identifying the problem to implementing a repeatable evaluation loop.

Table of Contents

• Why Does Traditional Testing Fail for AI applications?

• What is the Evaluation Flywheel?

• Drawing Parallels to Familiar Practices

• Why Silent Failures Matter: A Real-World Example

• How to Create an Evaluation Flywheel

• Tools and Frameworks you can use for evaluation

• What a Complete Evaluation Loop Looks Like in Practice

• Key Takeaways

• Conclusion

Why Does Traditional Testing Fail for AI applications?

In standard programming, tests assume deterministic behavior. This means the same input is expected to always produce the same output. For example:

def authenticate_user_age(age: int) -> str:
    limit = 18

    if age >= limit:
        return "Access granted"
    else:
        return "User doesn't meet the age limit"

# Test 
assert authenticate_user_age(20) == "Access granted"
assert authenticate_user_age(16) == "User doesn't meet the age limit"

The response from this function is always predictable. You can write tests once and trust they'll catch errors forever.

However, AI models don’t behave the same way every time, they generate output based on probabilities. A query like “best programming practices” may produce strong guidance one day, and outdated or incomplete advice the next. This shift can happen because of changes in the underlying model, updates to retrieval components, or gradual data drift. Without a structured evaluation process in place, these inconsistencies slip into production unnoticed and can quietly weaken the system’s performance.

What is the Evaluation Flywheel?

The evaluation flywheel is a continuous improvement system where test cases representing real user behavior are passed through multiple evaluation steps to assess the output of AI models. The results don't just tell you whether the system passed or failed, they feed directly into the next cycle of improvement.

┌─────────────┐
│   Collect   │
│ Test Cases  │
└──────┬──────┘
       │
       ▼
┌─────────────┐
│     Run     │
│ Evaluations │
└──────┬──────┘
       │
       ▼
┌─────────────┐      ┌─────────────┐
│  Identify   │─────▶│   Improve   │
│  Failures   │      │   System    │
└─────────────┘      └──────┬──────┘
                            │
                            ▼
                       ┌─────────────┐
                       │   Repeat    │
                       └─────────────┘

Here's how it works in practice:

• Collect test cases — Gather examples from real user interactions or create synthetic scenarios. These should reflect the kind of tasks and input your system needs to handle.

• Run evaluations — Pass each test case through a series of checks. The check can either be programmatic (automated metrics like relevance scores or hallucination detectors) or require manual review (like verifying legal advice accuracy or brand voice consistency).

• Identify failures — Detect where the model goes wrong, this can include hallucinations, irrelevant responses, or mistakes on corner-cases.

• Improve the system — Based on those failures, refine prompts, improve training or retrieval data, or adjust architectural components.

• Repeat the cycle — Re-run the updated system on the existing and newly collected cases. Over time, this grows and strengthens your evaluation suite and boosts system reliability.

Drawing Parallels to Familiar Practices

If you've written software before, the evaluation flywheel will feel familiar. It mirrors patterns that are already used in engineering. For instance,

Unit tests → Evaluation datasets
Unit tests confirm a function returns the right output. Evaluation datasets play the same role for AI: they're ground-truth queries and answers that guard against regressions.

Test-driven development (TDD) → Evaluation-driven development (EDD)
In TDD, you write tests before code. In EDD, you write evaluation cases before shipping prompts or updating models. This replaces assumptions with verifiable results.

CI/CD pipelines → Continuous evaluation pipelines
CI/CD runs checks automatically on every code change. Continuous evaluation does the same for models: it runs automated quality checks every time you tweak a prompt, retrain, or swap out a component.

The key difference is subtle but important. Traditional software tests check whether a function returns the right value or type. AI evaluation tests check whether the system produces the right meaning. That's harder to measure, but the principle is the same: build a safety net that grows stronger with every cycle.

Why Silent Failures Matter: A Real-World Example

AI systems often behave differently in production than they do in development. A model that seems solid in testing can drift, hallucinate, or silently fail when facing real-world input.

Case in point: A fraud detection model passed all monitoring metrics yet missed a spike in fraud. An ML engineer shared how their production monitoring dashboards tracked latency, throughput, and error rates, everything showed green. But fraudulent transactions were slipping through at twice the normal rate. Nobody noticed because existing observability tools focused on pipeline health, not prediction quality.

This silent failure cost the company significant losses. The system seemed fine by traditional metrics. It measured system performance—latency, throughput, uptime—but ignored what mattered most: prediction accuracy. As fraudsters adapted their tactics, the model drifted, and without proper evaluation loops, the degradation went undetected for weeks.

Source: InsightFinder.

Why This Example Matters

• Silent failures aren't always bugs — They often stem from models failing to adapt to shifting patterns in the real world.

• Static evaluation isn't enough — You need continuous, real-world feedback loops to detect when assumptions no longer hold.

• Data drift has business impact — Model degradation isn't just technical, it translates directly into revenue loss, security breaches, or damaged user trust.

How to Create an Evaluation Flywheel

To show how to build a flywheel and how it works, let's create one for a customer support chatbot that answers questions about a SaaS product.

Step 1: Build Your AI System

Create your initial product: prompts, retrieval logic, and integrations. For our chatbot:

def answer_support_question(question: str) -> str:
    # Retrieve relevant docs from knowledge base
    context = retrieve_docs(question, top_k=5)

    # Generate answer using LLM
    prompt = f"""You are a helpful customer support agent.

Context: {context}

Question: {question}

Provide a clear, accurate answer based on the context."""

    response = llm.generate(prompt)
    return response

How this works: This function defines the core chat logic, it takes a customer’s question and returns an AI-generated answer. First, it searches your knowledge base to find the five most relevant documents using retrieve_docs(). These documents provide context about your product or policies. Next, it constructs a prompt that includes this context and the user's question, then sends it to a language model. The LLM reads the context and generates a relevant answer, which the function returns.

Step 2: Identify Test Cases

Build an evaluation set that reflects real user behavior. The more representative your test cases are, including common cases, edge cases, and ambiguous inputs, the better your model can catch failures before they reach production.

Sources for test cases:

• Previous customer support tickets

• Common FAQ topics

• Edge cases discovered in beta testing

• Synthetic scenarios (hypothetical but realistic queries)

Example test cases:

test_cases = [
    {
        "question": "How do I reset my password?",
        "expected_elements": ["settings page", "reset link", "email"],
        "category": "account_management"
    },
    {
        "question": "What's your refund policy?",
        "expected_elements": ["30 days", "full refund", "contact support"],
        "category": "billing"
    },
    {
        "question": "Can I export my data to CSV?",
        "expected_elements": ["yes", "export button", "dashboard"],
        "category": "features"
    },
    {
        "question": "Does your API support webhooks?",
        "expected_elements": ["yes", "webhook endpoints", "documentation"],
        "category": "technical"
    }
]

How this works: Here, we define a set of representative test cases to evaluate the AI system. Each test case includes the user’s question, a list of key elements expected in the answer, and a category for organization. These cases help ensure the chatbot is tested against real-world scenarios, edge cases, and important information that should appear in responses.

Step 3: Evaluate Outputs

Define evaluation criteria based on what matters for your use case: accuracy, faithfulness, safety, relevance, tone. Then measure the output against these criteria.

Evaluation happens in two main ways:

Automated Evaluation

Use programmatic metrics and LLM-as-judge patterns:

def evaluate_response(question: str, response: str, expected_elements: list) -> dict:
    scores = {}

    # 1. Faithfulness: Does response contain expected elements?
    scores['contains_key_info'] = all(
        elem.lower() in response.lower() 
        for elem in expected_elements
    )

    # 2. Relevance: Semantic similarity to question
    scores['relevance'] = calculate_semantic_similarity(question, response)

    # 3. Safety: Check for problematic content
    scores['is_safe'] = not contains_harmful_content(response)

    # 4. Tone: Use LLM-as-judge
    judge_prompt = f"""Rate the helpfulness of this support response on a scale of 1-5.

Question: {question}
Response: {response}

Score (1-5):"""

    scores['helpfulness'] = int(llm.generate(judge_prompt))

    return scores

# Run evaluation
for test_case in test_cases:
    response = answer_support_question(test_case['question'])
    scores = evaluate_response(
        test_case['question'],
        response,
        test_case['expected_elements']
    )
    test_case['scores'] = scores
    test_case['response'] = response

How this works: The evaluate_response() function applies four different checks to each AI response:

• First, it verifies faithfulness by checking if all expected elements appear in the response using simple string matching.

• Second, it calculates semantic similarity, a measure of how closely the responses meaning match the intent of the questions, using embeddings.

• Third, it runs a safety check to flag any problematic content.

• Fourth, it uses an LLM as a judge by asking a more powerful model (like GPT-4) to rate the helpfulness of the response on a 1-5 scale.

The loop then runs the evaluation for every test case. It generates a response for each question, evaluates it using the evaluate_response function, and then stores both the scores and the response back in the test case. This creates a complete dataset of test results for analysis and further improvements.

Common Automated Metrics:

• Semantic similarity (0.0–1.0): This is measured by converting the question and response into vector embeddings and calculating cosine similarity. The score shows how closely the response matches the intent of the question, even if the wording differs.

• ROUGE / BLEU scores: The model’s output is compared to reference answers by checking n-gram overlap. These metrics help spot regressions, though scores can be modest for open-ended answers.

• LLM-as-judge: A stronger model (like GPT-4 or Claude) can rate the response on a fixed scale, such as 1–5. These ratings give a sense of quality and are useful for tracking improvements or drops over time.

• Retrieval metrics (Precision@k, Recall@k): For retrieval-based systems, these metrics calculate how many relevant documents appear in the top-k results. Precision shows accuracy of the retrieved set, and recall indicates completeness.

• Custom validators: Simple rule-based checks, like regex patterns, keywords, or length limits, ensure responses meet hard requirements. These help catch issues automated metrics might miss.

Manual Evaluation

Automated metrics can't capture everything. Subjective qualities like tone, empathy, and brand voice require human judgment, as do small factual errors that slip past keyword checks and similarity scores.

# Flag cases for human review
needs_review = [
    case for case in test_cases 
    if case['scores']['helpfulness'] < 3 
    or not case['scores']['contains_key_info']
]

# SMEs review and annotate
for case in needs_review:
    annotation = get_sme_feedback(case)
    case['human_rating'] = annotation['rating']
    case['improvement_notes'] = annotation['notes']

This code filters test cases to find responses that need human attention, those scoring below 3 for helpfulness or missing important information. Subject matter experts review these flagged cases and provide ratings with helpful feedback. Their input helps you spot patterns that automated metrics miss and shows you where to improve your prompts, retrieval setup, or system settings.

When to use manual evaluation:

• Assessing tone, empathy, or brand voice

• Detecting subtle hallucinations automated checks miss

• Validating edge cases with domain-specific nuance

• Creating ground truth labels for training evaluation models

Step 4: Learn and Improve

Once you've identified failures, adjust the controllable parts of your AI system (the "configs"):

Common configuration levers:

• Prompts — Add instructions, examples, constraints

• Retrieval — Change chunk size, top-k, reranking strategy

• Model — Switch models, adjust temperature, max tokens

• Context — Modify system instructions, add memory

• Post-processing — Add validation, formatting, safety filters

Example improvement cycle:

# Problem discovered: Chatbot missing key details
failing_case = {
    "question": "What's your refund policy?",
    "response": "We offer refunds in certain cases.",
    "issue": "Too vague, missing 30-day window and process"
}

# Root cause: Retrieval returning wrong docs
retrieved_docs = retrieve_docs(failing_case['question'], top_k=5)
# Docs about "payment processing" ranked higher than "refund policy"

# Solution 1: Improve retrieval with reranking
def retrieve_docs_v2(question: str, top_k: int) -> str:
    # Initial retrieval
    candidates = vector_search(question, top_k=20)

    # Rerank by relevance
    reranked = rerank_by_relevance(question, candidates)

    return reranked[:top_k]

# Solution 2: Update prompt to require specificity
prompt_v2 = f"""You are a helpful customer support agent.

Context: {context}

Question: {question}

Provide a clear, accurate answer based on the context. Include specific details like:
- Time windows (e.g., "within 30 days")
- Step-by-step processes
- Relevant links or contact methods

Answer:"""

# Re-evaluate
new_response = answer_support_question_v2(failing_case['question'])
new_scores = evaluate_response(
    failing_case['question'],
    new_response,
    ["30 days", "full refund", "contact support"]
)

# Verify improvement
assert new_scores['contains_key_info'] == True
assert new_scores['helpfulness'] >= 4

How this works: In this example, the chatbot's refund answer was too vague. After checking what went wrong, the problem was that the system retrieved docs about payment processing instead of the refund policy.

To resolve this, two changes can be made. First, retrieval is improved by grabbing twenty documents, then picking the best five. Second, the prompt is updated to ask for specific details like dates and steps.

After making these changes, the test runs again to confirm it works: the response now has all the key info and scores at least 4 out of 5. This process turns problems into fixes you can measure.

Step 5: Automate and Repeat

Integrate evaluation into your development workflow using CI/CD:

# .github/workflows/eval.yml
name: Continuous Evaluation

on:
  pull_request:
  push:
    branches: [main]

jobs:
  evaluate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2

      - name: Run evaluation suite
        run: python run_evals.py

      - name: Check pass rate
        run: |
          PASS_RATE=$(python calculate_pass_rate.py)
          if (( $(echo "$PASS_RATE < 0.85" | bc -l) )); then
            echo "Pass rate $PASS_RATE below threshold"
            exit 1
          fi

      - name: Upload results
        uses: actions/upload-artifact@v2
        with:
          name: eval-results
          path: results/

Explanation: This GitHub Actions workflow automates your evaluation process so it runs automatically on every code change. The workflow triggers whenever someone opens a pull request or pushes code to the main branch. It checks out your code, runs your full evaluation suite using run_evals.py, then calculates what percentage of test cases passed. If the pass rate drops below 85%, the workflow fails and blocks the code from being merged, preventing quality regressions from reaching production.

Key practices for automation:

• Version your test cases — Track them in Git alongside code

• Set quality gates — Block deployments if pass rate drops below threshold

• Monitor trends — Track metrics over time to catch gradual drift

• Alert on regressions — Notify team when specific test cases start failing

• Sample production traffic — Continuously add real queries to eval dataset

Tools and Frameworks you can use for evaluation

Several platforms can help implement continuous evaluation. The one you choose depends on your stack and needs:

If you're building with LLMs: Try LangSmith or Braintrust first. Both handle prompt versioning, evaluation datasets, and tracing out of the box.

If you're doing traditional ML: Weights & Biases is the industry standard. If you're in the Microsoft ecosystem, PromptFlow integrates well with Azure.

If you want full control: Build custom with pytest for test execution and MLflow for tracking results. More setup, but you own the entire pipeline

What a Complete Evaluation Loop Looks Like in Practice

This walkthrough shows how a support chatbot improves after running a single cycle of evaluations. Each stage shows how evaluation signals guide improvements and lock in quality for the next release.

Next cycle:

• Add this test case to permanent suite

• Look for similar issues (other plan-related questions)

• Monitor if this pattern appears in production queries

Key Takeaways

• AI systems need continuous evaluation, not one-time testing — Models drift, data changes, and silent failures accumulate without ongoing checks.

• Build evaluation into your workflow from day one — Don't wait until production failures force you to retrofit evaluation.

• Start simple, then scale — Begin with 10-20 test cases and basic metrics. Grow your suite as you encounter edge cases.

• Automate what you can, involve humans for what you can't — Use programmatic checks for speed, SME review for nuance.

• Treat evaluation datasets as first-class artifacts — Version control them, review changes, and grow them over time.

• Make evaluation a team sport — Product, engineering, and domain experts should all contribute test cases and evaluation criteria.

Conclusion

Every developer has felt the relief of seeing "all tests passing." In AI systems, that reassurance is often misleading. A model can deploy successfully, meet performance benchmarks, and still produce incorrect, incomplete, or misleading outputs in ways traditional tests miss.

The evaluation flywheel addresses this gap by making model behavior testable in practice. Instead of assuming correctness, it forces the system to answer real questions, measures the quality of those answers, and highlights where performance degrades over time. This shifts evaluation from a one-off validation step into an ongoing part of development.

Evaluation won't eliminate uncertainty completely, but it makes failures visible before they reach users. With failures clearly exposed, teams stop guessing and start fixing based on results. This might mean adjusting prompts, improving retrieval logic, or refining evaluation criteria. Over time, this leads to AI systems that evolve in controlled ways rather than breaking silently.

Resources for further reading

• Anthropic's eval guide: https://docs.anthropic.com/en/docs/build-with-claude/develop-tests

• OpenAI's evals framework: https://github.com/openai/evals

• LangChain evaluation: https://python.langchain.com/docs/guides/evaluation

• Arize AI blog: Comprehensive resources on ML observability

Today, we’ve moved beyond simple container deployments and into building Global AI Architectures. This setup leverages Google’s infrastructure to deliver context-aware, instant Gen AI responses anywhere in the world. If you're ready to get your hands dirty, let's build the future of global, intelligent features.

In this article, you’re not just going to deploy a container, you’ll be building a global AI architecture.

A global AI architecture is a design pattern that leverages a worldwide network to deploy and manage AI services, ensuring the fastest possible response time (low latency) for users, no matter where they are located. Instead of deploying a feature to a single region, this architecture distributes the service across multiple continents.

Most people may deploy a service to a single region. That’s fine for a local user, but physical distance, and the speed of light, creates terrible latency for everyone else. We are going to eliminate this problem by leveraging Google’s global network to deploy the service in a "triangle" of locations.

The generative AI service you’ll be building is a "Local Guide." This application will be designed to be deeply hyper-personalized, changing its personality and providing recommendations based on the user's detected geographical context. For example, if a user is in Paris, the guide will greet them warmly, mentioning their city and suggesting a local activity.

You’re going to build this service to achieve three critical goals:

• Lives Almost Everywhere: Deployed to three continents simultaneously (USA, Europe, and Asia).

• Feels Instant: Uses Google's global fiber network and Anycast IP to route users to the nearest server, ensuring the lowest possible latency.

• Knows Where You Are: Automatically detects the user's location (without relying on client-side GPS permissions) to provide deeply personalized, location-aware suggestions.

Table of Contents

• Prerequisites

• Phase 1: The "Location-Aware" Code

• Phase 2: Build & Push

• Phase 3: The "Triangle" Deployment

• Phase 4: The Global Network (The Glue)

• Phase 5: Testing (Teleportation Time)

• Conclusion: The Global AI Edge

Prerequisites

To follow along, you need:

1. A Google Cloud Project (with billing enabled).

2. Google Cloud Shell (Recommended! No local setup required). Click the icon in the top right of the GCP Console that looks like a terminal prompt >_.

Note: The project utilizes various Google Cloud services (Cloud Run, Artifact Registry, Load Balancer, Vertex AI), all of which require a Google Cloud Project with billing enabled to function. While many of these services offer a free tier, you must link a billing account to your project. Although a billing account is required, new Google Cloud users may be eligible for a free trial credit that should cover the cost of this lab. See credit program eligibility and coverage

Phase 1: The "Location-Aware" Code

We don’t want to build a generic chatbot, so we’ll be building a "Local Guide" that changes its personality based on where the request comes from.

Enable the APIs

To wake up the services, run this in your terminal:

gcloud services enable \
  run.googleapis.com \
  artifactregistry.googleapis.com \
  compute.googleapis.com \
  aiplatform.googleapis.com \
  cloudbuild.googleapis.com

This command enables the necessary Google Cloud APIs for the project:

• Cloud Run (run.googleapis.com)

• Artifact Registry (artifactregistry.googleapis.com)

• Compute Engine (compute.googleapis.com)

• Vertex AI (aiplatform.googleapis.com)

• Cloud Build (cloudbuild.googleapis.com).

Enabling them ensures that the services we need are ready to be used.

Create and Populate main.py

This is the brain of our service. In your Cloud Shell terminal, create a file named main.py and paste the following code into it:

import os
import logging
from flask import Flask, request, jsonify
import vertexai
from vertexai.generative_models import GenerativeModel

app = Flask(__name__)

# Initialize Vertex AI
PROJECT_ID = os.environ.get("GOOGLE_CLOUD_PROJECT")
vertexai.init(project=PROJECT_ID)

@app.route("/", methods=["GET", "POST"])
def generate():
    # 1. Identify where the code is physically running (We set this ENV var later)
    service_region = os.environ.get("SERVICE_REGION", "unknown-region")

    # 2. Identify where the user is (Header comes from Global Load Balancer)
    # Format typically: "City,State,Country"
    user_location = request.headers.get("X-Client-Geo-Location", "Unknown Location")

    model = GenerativeModel("gemini-2.5-flash")

    # 3. Construct a location-aware prompt
    prompt = (
        f"You are a helpful local guide. The user is currently in {user_location}. "
        "Greet them warmly mentioning their city, and suggest one "
        "hidden gem activity to do nearby right now. Keep it under 50 words."
    )

    try:
        response = model.generate_content(prompt)
        return jsonify({
            "ai_response": response.text,
            "meta": {
                "served_from_region": service_region,
                "user_detected_location": user_location
            }
        })
    except Exception as e:
        return jsonify({"error": str(e)}), 500

if __name__ == "__main__":
    app.run(debug=True, host="0.0.0.0", port=int(os.environ.get("PORT", 8080)))

It’s a simple Flask web application that relies entirely on a specific HTTP header (X-Client-Geo-Location) that the global load balancer will inject later in the process. This design choice keeps the Python code clean, fast, and focused on using the context that the powerful Google Cloud infrastructure provides. The script uses Vertex AI and the high-performance Gemini 2.5 Flash generative model.

This core logic of the application is a simple Flask web service. It does the following:

• Initialization: Sets up the Flask app, logging, and initializes the Vertex AI client using the project ID.

• Context: It extracts two critical pieces of information: the SERVICE_REGION (where the code is physically running) from the environment variable, and the X-Client-Geo-Location (the user's detected location) from the request header, which will be injected by the global load balancer.

• AI Generation: It uses the high-performance gemini-2.5-flash model.

• Prompt Construction: A dynamic, location-aware prompt is built using the detected city to instruct Gemini to act as a helpful local guide and provide a personalized suggestion.

• Response: The response includes the AI's generated text and a meta section containing both the serving region and the user's detected location, which helps in verification.

Create the Dockerfile

This Dockerfile tells Cloud Run how to build the Python application into a container image. Create a file named Dockerfile in the same directory as main.py and paste the following content into it:

FROM python:3.9-slim

WORKDIR /app
COPY main.py .

# Install Flask and Vertex AI SDK
RUN pip install flask google-cloud-aiplatform

CMD ["python", "main.py"]

Here’s what the code does:

• Starts with a lightweight Python base image python:3.9-slim.

• Sets the working directory inside the container WORKDIR /app.

• Copies your application code into the container.

• RUN pip install... installs the required Python packages: Flask for the web server and google-cloud-aiplatform for accessing the Gemini model.

• CMD specifies the command to run when the container starts.

Phase 2: Build & Push

Let's package this up. For efficiency and consistency, we’ll follow the best practice of Build Once, Deploy Many. We’ll build the container image once using Cloud Build and store it in Google's Artifact Registry. This guarantees that the same tested application code runs in New York, Belgium, and Tokyo.

First, sets an environment variable for your Google Cloud Project ID to simplify later commands.

# 1. Set your Project ID variable
export PROJECT_ID=$(gcloud config get-value project)

Then create a new Docker repository named gemini-global-repo in the us-central1 region to store the application container image:

# 2. Create the repository
gcloud artifacts repositories create gemini-global-repo \
    --repository-format=docker \
    --location=us-central1 \
    --description="Repo for Global Gemini App"

Using the mkdir gemini-app command, create and navigate into a directory where you should place your main.py and Dockerfile:

# 3. Prepare the Build Environment (Crucial Step! 💡). To ensure the build process only includes our necessary code and avoids including temporary files from Cloud Shell's home directory 
mkdir gemini-app
cd gemini-app

Next, use gcloud builds submit --tag to build the container image from the files in the current directory and push the resulting image to the newly created Artifact Registry repository:

# 4. Build the image (This takes about 2 minutes)
gcloud builds submit --tag us-central1-docker.pkg.dev/$PROJECT_ID/gemini-global-repo/region-ai:v

NOTE: You might notice that we created the Artifact Registry repository (gemini-global-repo) in the us-central1 region. This choice is purely for management and storage of the container image. When you create an image and push it to a regional Artifact Registry, the resulting image is still accessible globally. For this lab, us-central1 serves as a reliable, central location for our single, canonical container image, the single source of truth, which is then pulled by Cloud Run in the three separate global regions.

Phase 3: The "Triangle" Deployment

We’ll deploy the same image to three corners of the world, forming our "Triangle". This ensures that whether a user is in Lagos, London, or Tokyo, they’ll be geographically close to a server. This is the low-latency core of our architecture.

We’ll use Cloud Run to deploy our services. Cloud Run is a fully managed serverless platform on Google Cloud that enables you to run stateless containers via web requests or events. Crucially, it is serverless, meaning you don't manage any virtual machines, operating system updates, or scaling infrastructure. You provide a container image, and Cloud Run automatically scales it up (and down to zero) in the region you specify.

For this project, we’ll use its regional deployment capability to easily and consistently deploy the exact same container image to New York, Belgium, and Tokyo.

Note: Setting it up primarily involves enabling the API (done in Phase 1) and using the gcloud run deploy command, which handles provisioning and managing the service in the specified region.

Now, we’ll proceed to deploy the single, canonical container image to three separate Cloud Run regions, forming the "Triangle Deployment".

First, set a variable for the image path, pointing to the image stored in Artifact Registry.

# Define our image URL
export IMAGE_URL=us-central1-docker.pkg.dev/$PROJECT_ID/gemini-global-repo/region-ai:v1

# 1. Deploy to USA (New York)
gcloud run deploy gemini-service \
    --image $IMAGE_URL \
    --region us-east4 \
    --set-env-vars SERVICE_REGION=us-east4 \
    --allow-unauthenticated

# 2. Deploy to Europe (Belgium)
gcloud run deploy gemini-service \
    --image $IMAGE_URL \
    --region europe-west1 \
    --set-env-vars SERVICE_REGION=europe-west1 \
    --allow-unauthenticated

# 3. Deploy to Asia (Tokyo)
gcloud run deploy gemini-service \
    --image $IMAGE_URL \
    --region asia-northeast1 \
    --set-env-vars SERVICE_REGION=asia-northeast1 \
    --allow-unauthenticated

gcloud run deploy gemini-service... deploys the service. Key flags:

• --image \$IMAGE_URL specifies the container image to use.

• --region specifies the deployment region (for example, us-east4 for New York).

• --set-env-vars SERVICE_REGION=... injects an environment variable into the running container to let the main.py code know its own physical region.

• --allow-unauthenticated makes the service publicly accessible, as required for the Load Balancer to connect.

Note: The commands are repeated for Europe (europe-west1) and Asia (asia-northeast1) regions.

user_detected_location is always "Unknown Location". This is expected. You are accessing the Cloud Run URLs directly, not via the global load balancer, so the X-Client-Geo-Location header is not yet being injected.

Phase 4: The Global Network (The Glue)

You are now ready to execute the steps to create the Global External HTTP Load Balancer infrastructure. This is the "magic" that stitches the three regional services together behind a single Anycast IP Address. The load balancer performs two critical functions:

1. Global Routing: It uses Google’s high-speed network to automatically route the user to the closest available region (for example, Tokyo user → Asia service).

2. Context Injection: It dynamically adds the X-Client-Geo-Location header to the request, telling your code exactly where the user is^.

The Global IP

gcloud compute addresses create... creates a single, global, static Anycast IP address (gemini-global-ip) that will serve as the single public entry point for users worldwide. That is

gcloud compute addresses create gemini-global-ip \
    --global \
    --ip-version IPV4

The Network Endpoint Groups (NEGs)

gcloud compute network-endpoint-groups create... creates a Serverless Network Endpoint Group (NEG) for each regional Cloud Run deployment. For example, neg-us is created in us-east4 and points to the gemini-service in that region. These map your Cloud Run services to the Load Balancer's backend service:

# USA NEG
gcloud compute network-endpoint-groups create neg-us \
    --region=us-east4 \
    --network-endpoint-type=serverless  \
    --cloud-run-service=gemini-service

# Europe NEG
gcloud compute network-endpoint-groups create neg-eu \
    --region=europe-west1 \
    --network-endpoint-type=serverless \
    --cloud-run-service=gemini-service

# Asia NEG
gcloud compute network-endpoint-groups create neg-asia \
    --region=asia-northeast1 \
    --network-endpoint-type=serverless \
    --cloud-run-service=gemini-service

The Backend Service & Routing

This is the load balancer's core, distributing traffic across your regions. Connect the NEGs to a global backend.

gcloud compute backend-services create... creates the global backend service (gemini-backend-global), which is the core component that manages traffic distribution:

# Create the backend service
gcloud compute backend-services create gemini-backend-global \
    --global \
    --protocol=HTTP

gcloud compute backend-services add-backend... adds all three regional NEGs (neg-us, neg-eu, neg-asia) as backends to the global service. This tells the load balancer where all the services are located:

# Add the 3 regions to the backend
gcloud compute backend-services add-backend gemini-backend-global \
    --global --network-endpoint-group=neg-us --network-endpoint-group-region=us-east4
gcloud compute backend-services add-backend gemini-backend-global \
    --global --network-endpoint-group=neg-eu --network-endpoint-group-region=europe-west1
gcloud compute backend-services add-backend gemini-backend-global \
    --global --network-endpoint-group=neg-asia --network-endpoint-group-region=asia-northeast1

The URL Map & Frontend

Now we can finalize the connection.

gcloud compute url-maps create... creates a URL Map (gemini-url-map) to direct all incoming traffic to the Backend Service:

# Create URL Map (Maps incoming requests to the backend service)
gcloud compute url-maps create gemini-url-map \
    --default-service gemini-backend-global

gcloud compute target-http-proxies create... creates an HTTP Proxy (gemini-http-proxy) that inspects the request and directs it based on the URL map.

# Create HTTP Proxy (The component that inspects the request headers)
gcloud compute target-http-proxies create gemini-http-proxy \
    --url-map gemini-url-map

export VIP=... retrieves the final, public IP address of the newly created Global IP and stores it in the VIP environment variable.

# Get your IP Address variable
export VIP=$(gcloud compute addresses describe gemini-global-ip --global --format="value(address)")

gcloud compute forwarding-rules create... creates the final global Forwarding Rule (gemini-forwarding-rule). This links the Global IP ($VIP) to the HTTP Proxy and opens port 80 for public traffic.

# Create Forwarding Rule (Open port 80)
gcloud compute forwarding-rules create gemini-forwarding-rule \
    --address=$VIP \
    --global \
    --target-http-proxy=gemini-http-proxy \
    --ports=80

Phase 5: Testing (Teleportation Time)

Global load balancers take about 5-7 minutes to propagate worldwide. This is how you verify that the global load balancer is working correctly:

• Using the single VIP (Virtual IP) address.

• Routing traffic to the nearest server.

• Injecting the X-Client-Geo-Location header to tell your code where the user is.

1. Get your Global IP

First, ensure your VIP variable is set and retrieve the final address:

echo "http://$VIP/"

The output will be your single point of entry for the entire global architecture.

2. Test "Teleportation"

These curl commands simulate a user requesting the service from different geographical locations by manually injecting the X-Client-Geo-Location header. This bypasses the need to be physically in those locations for testing.

Simulate Europe (Paris)

We expect this to be served by the europe-west1 region because it's the closest server.

curl -H "X-Client-Geo-Location: Paris,France" http://$VIP/

Expected Output: Gemini should say "Bonjour" and mention Paris. The served_from_region should be europe-west1.

Simulate Asia (Tokyo)

We expect this to be served by the asia-northeast1 region.

curl -H "X-Client-Geo-Location: Tokyo,Japan" http://$VIP/

Expected Output: Gemini should mention Tokyo. The served_from_region should be asia-northeast1.

Simulate USA (New York)

We expect this to be served by the us-east4 region.

curl -s -H "X-Client-Geo-Location: New York,USA" http://$VIP/ | jq .

Expected Output: Gemini should mention USA. The served_from_region should be us-east4.

Note: The | jq . part is optional, but highly recommended as it formats the JSON output, making it much easier to read the served_from_region and ai_response details. If jq isn't available, you can just run curl ... without it.

Conclusion: The Global AI Edge

Congratulations! You have successfully built a sophisticated, global AI architecture that solves the challenges of latency and personalization for generative AI features. By combining the following technologies, you achieved two critical outcomes:

• Guaranteed Low Latency: By deploying the Cloud Run service to a "Triangle" of global regions (USA, Europe, Asia) and using the Global External HTTP Load Balancer's Anycast IP, your users are automatically routed across Google’s private fiber network to the closest available server.

• Hyper-Personalization: The global load balancer was configured to dynamically inject the user's geographical location via the X-Client-Geo-Location header. This context was passed directly to the Gemini 2.5 Flash model, allowing it to act as a truly location-aware "Local Guide".

This pattern allows you to scale intelligent features globally and is immediately applicable to any application where speed and context are essential, from real-time translations to hyper-local recommendations.

Cleanup

Don't leave the meter running! Remember to execute the cleanup commands to ensure you don't incur unnecessary charges

gcloud run services delete gemini-service --region us-east4 --quiet
gcloud run services delete gemini-service --region europe-west1 --quiet
gcloud run services delete gemini-service --region asia-northeast1 --quiet
gcloud compute forwarding-rules delete gemini-forwarding-rule --global --quiet
gcloud compute addresses delete gemini-global-ip --global --quiet
gcloud compute backend-services delete gemini-backend-global --global --quiet
gcloud compute url-maps delete gemini-url-map --global --quiet
gcloud compute target-http-proxies delete gemini-http-proxy --global --quiet

Resources

• Google Cloud Shell Documentation

• Vertex AI Generative AI SDK

• Artifact Registry Documentation

• Cloud Run Documentation

• Global External HTTP(S) Load Balancer Overview

• Serverless Network Endpoint Groups (NEGs)

• Serve traffic from multiple regions

Whether you are building a pixel-art indie game or a high-fidelity 3D world, understanding how resolution works is essential.

It affects how your art assets scale, how your UI appears, and how your game feels on different screens. Yet, many developers still treat resolution as a simple number instead of a design decision.

Let’s learn what resolutions are and why it matters for game developers.

What we will Cover

• What Resolution Really Means

• The Evolution of Resolution in Gaming

• DPI, Scaling, and Texture Clarity

• Resolution vs. Performance

• Aspect Ratio and Display Diversity

• The Art of Testing in 4K and HDR

• Preparing for Next-Gen Displays

• Conclusion

What Resolution Really Means

Resolution defines how many pixels a screen can display horizontally and vertically.

A monitor labelled 1920x1080 has 1920 pixels across and 1080 down, which equals over two million pixels in total. More pixels mean more visual detail but also more rendering work for the GPU.

In game development, that tradeoff is constant. Rendering at higher resolutions improves clarity but reduces frame rates unless your code and assets are optimized.

Many developers solve this by offering resolution scaling options in their games, letting players balance visual quality and performance.

It’s also important to distinguish between screen size and resolution. A 27-inch monitor and a 15-inch laptop can both run at 1080p, but the larger display will have bigger, less dense pixels.

This is where pixel density comes in. High-density displays pack more pixels per inch, creating smoother edges and sharper textures even at the same resolution.

The Evolution of Resolution in Gaming

Games have evolved alongside display technology.

Early consoles ran at 240p, then 480p during the SD era. The jump to HD with 720p and 1080p transformed game visuals. Suddenly, developers had to think about anti-aliasing, texture resolution, and UI scaling in new ways.

Today, 4K and HDR have become the standard for modern consoles and PCs. Developers now design with higher fidelity in mind, baking in lighting systems, shaders, and art pipelines that scale up to Ultra HD.

That’s why testing on different display resolutions isn’t just good practice, it’s critical for consistent player experience.

If you want to see how your game performs on large high-resolution displays, try testing it on a modern TV for PS5. These screens are optimized for 4K and 120Hz refresh rates, giving you a realistic look at how your game will appear in a living-room setup.

They also help you spot UI scaling issues, frame pacing problems, and HDR color mismatches that might go unnoticed on a typical monitor.

DPI, Scaling, and Texture Clarity

For web developers, DPI mostly affects how images scale. But for game developers, DPI connects directly to texture resolution and how art assets are perceived at different screen sizes.

A sprite that looks crisp on a 1080p monitor might appear tiny or blurry on a 4K display if not properly scaled. Engines like Unity and Unreal handle this with dynamic scaling options, but understanding the underlying math helps.

When your display density doubles, each asset needs four times as many pixels to appear at the same size and sharpness. If you do not plan for this, your carefully crafted textures might look soft or misaligned on higher-resolution displays.

This is why UI systems in modern engines rely on resolution-independent units. In Unity, Canvas Scaler helps ensure your interface looks the same on every device. In Unreal, DPI scaling rules allow developers to maintain consistent HUD layouts. Getting this right means your game remains legible on everything from handhelds to 8K TVs.

Resolution vs Performance

The biggest cost of higher resolution is GPU load. Rendering in 4K means pushing four times as many pixels as 1080p. Without proper optimization, frame rates can drop sharply.

That’s why many AAA games use resolution scaling techniques like temporal upsampling or DLSS. These methods render frames at a lower resolution and then use AI or interpolation to upscale them without losing clarity.

As a developer, you should test your game across multiple resolutions and aspect ratios. This helps ensure your render pipeline, shaders, and assets adapt smoothly. Tools like NVIDIA Nsight or Unreal’s built-in profiler show how resolution affects frame time and GPU usage.

If your game includes video content or cinematic sequences, also remember that video compression behaves differently at higher resolutions. Encoding 4K video requires significantly more bandwidth and storage, which can affect your build size and performance during playback.

Aspect Ratio and Display Diversity

Aspect ratio determines the shape of the display.

Most modern games target 16:9, but 21:9 ultrawide and 32:9 super-ultrawide displays are becoming more popular. Developers must ensure their camera framing and UI layouts adapt accordingly.

When a game is locked to one ratio, black bars or stretching can occur. To fix this, adjust your camera’s field of view dynamically or provide safe viewport settings.

Engines like Unreal let you script these adjustments easily, while Unity’s Cinemachine system handles FOV scaling automatically.

Even TVs now vary in aspect ratio capabilities, especially with new mini LED and OLED technologies. Testing across multiple ratios ensures your game looks balanced and cinematic on every screen.

The Art of Testing in 4K and HDR

4K and HDR introduce new layers of visual complexity. HDR displays show a wider range of brightness and color depth, which means lighting and textures can look completely different compared to SDR monitors. To handle this, calibrate your color grading pipeline and use tone mapping tools within your engine.

When working with HDR assets, always test your output on real hardware. Emulators and monitors often fail to reproduce true HDR contrast. A proper HDR-certified TV helps you identify overexposure, color clipping, and banding issues before release.

Preparing for Next-Gen Displays

The display industry continues to evolve fast. 8K and high refresh rate panels are already entering mainstream markets.

For developers, this means thinking ahead. Designing scalable rendering systems, supporting dynamic resolution, and maintaining flexible UI layouts are now essential parts of modern game design.

As displays get sharper, player expectations rise too. Textures, shaders, and post-processing all need to support higher levels of detail without compromising performance. By understanding how resolution interacts with your pipeline, you can future-proof your games for years to come.

Conclusion

Resolution is more than a number on a settings menu. It is a design constraint, a performance factor, and a creative opportunity. As a game developer, mastering resolution helps you build experiences that look sharp, play smoothly, and scale across every device.

The next time you polish your textures or fine-tune your rendering settings, remember that every pixel counts. Understanding how resolution, scaling, and density interact will not only make your games more beautiful but also more accessible to every player, whether they’re gaming on a laptop, a monitor, or the living-room tv that brings your visuals to life in stunning detail.

Hope you enjoyed this article. Find me on Linkedin or visit my website.

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.

Consider the code bellow:

console.log('My age is', age)
console.log('My name is', name)
console.log('My country is', country)

var age = 24
let name = 'Shejan'
const country = 'Bangladesh'
sayHi()
function sayHi() {
  console.log('Hi!')
}

What do you think the output of this code will be?

The first line will probably print undefined, right? But what about the second line with name? This will throw a “ReferenceError: Cannot access name before initialization.” Why? Because let variables are hoisted but remain uninitialized in the temporal dead zone (TDZ) until their declaration line is reached.

The third line with country will never execute because the code stops at line 2 due to the ReferenceError. But if line 2 wasn’t there, line 3 would throw the same error for the same reason – const also stays in the TDZ.

And what about the sayHi() function call? If we could reach it, it would work perfectly and print "Hi!" because function declarations are fully hoisted with their complete body.

The main question: why and how is all this happening? Let's dive in and find answers to these questions.

Here’s What We’ll Cover:

• How Does the Global Execution Context Work?

• Memory Creation Phase

• Understanding the Flowchart

• What Exactly is Hoisting?

• Does Only var Get Hoisted?

• Temporal Dead Zone (TDZ) – What is it Really?

• Function Hoisting – The Most Interesting Part!

• What Happens in the Memory Phase:

How Does the Global Execution Context Work?

When we run any JavaScript code, the very first thing that happens is the creation of a Global Execution Context (GEC). This is the fundamental concept behind JavaScript execution! This global execution context has two important phases:

1. Memory creation phase (memory phase)

2. Code execution phase (thread phase)

Let's look at what happens in each phase, one by one.

Memory Creation Phase

This is the preparation time. During this phase, the JavaScript engine scans through the entire code once (without executing it) and allocates memory for all variables and functions.

But here's where it gets interesting:

• Variables (var, let, const) are given space in memory.

  • var is assigned the value undefined.

  • let and const are placed in memory but remain uninitialized.

  • Functions (function declarations) are stored in memory with their complete code body.

So what happens in the memory phase for our example code?

age: undefined
name: <uninitialized>
country: <uninitialized>
sayHi: function() { console.log("Hi!"); }

As you can see, even before a single line of code is executed, everything is already in memory! This entire process of lifting variables and functions into memory during the memory creation phase is called Hoisting – and this is what makes JavaScript execution seem "magical."

Code Execution Phase

Now the real action begins! The JavaScript engine starts executing the code line by line.

Line 1: console.log("My age is", age);

• Looks for age in memory

• Finds undefined

• Output: My age is undefined

Line 2: console.log("My name is", name);

• Looks for name in memory Finds that it exists in memory but hasn't been initialized yet (it's in the temporal dead zone, or TDZ – we'll explore this concept in detail later).

• Output: ReferenceError: Cannot access name before initialization.

The code execution stops right here! The remaining lines won't be executed.

But what would happen if Lines 2 and 3 weren't there?

Line 4: var age = 24;

• The value of age in memory gets updated from undefined to 24

Line 5: let name = "Shejan";

• name is now initialized with the value "Shejan"

• From this point forward, name can be accessed

Line 6: const country = "Bangladesh";

• country is initialized with the value "Bangladesh"

Lines 7-9: Function call

• The sayHi() function was already loaded with its complete body during the memory phase.

• When sayHi() is called, the JavaScript engine creates a new execution context specifically for this function.

• This new context is known as a Function Execution Context (FEC) – it works as a child of the global execution context.

This function execution context also has two phases, just like the global execution context:

1. Memory Creation Phase:

   • All variables, parameters, and nested functions inside the function are allocated in memory.

   • Function arguments are assigned.

   • A function scope is created and a reference link is established with the outer lexical environment (where the function was defined) – this link is called the scope chain. The scope chain is JavaScript's way of resolving variable names. It's like a chain of connected scopes. When JavaScript looks for a variable inside a function, it first checks the function's own scope. If it doesn't find the variable there, it moves up the chain to check the parent scope (where the function was defined), then the grandparent scope, and so on, until it reaches the global scope. This chain ensures that functions can access variables from their outer environments.

2. Code Execution (Thread) Phase:

   • Now the function body is executed line by line.

   • console.log("Hi!"); executes and prints "Hi!"

Once the function execution is complete:

• That function execution context is popped off the call stack.

• And control returns to the global execution context.

Note: When all code execution is complete, the global execution context is also popped off the call stack.

The flowchart diagram above illustrates the JavaScript global execution context workflow, showing the two phases. In the memory creation phase, variables and functions are allocated, and in the code execution phase, the code runs line by line. It also shows how the function execution context is created when functions are called.

Understanding the Flowchart

The diagram above visualizes the complete journey of JavaScript code execution from start to finish.

The flow begins when JavaScript execution starts and immediately creates a global execution context (GEC). This context then splits into two distinct phases, shown as a diamond in the diagram.

On the left side - Memory Creation Phase: You can see three parallel branches showing how different types of declarations are handled:

• var variables are allocated with the value undefined

• let and const variables are allocated but remain uninitialized (in the temporal dead zone)

• Function declarations are fully hoisted with their complete body

On the right side - Code Execution Phase: JavaScript now executes the code line by line. During execution:

• It accesses variable values from memory

• If you try to access let or const before initialization, you get a ReferenceError (temporal dead zone)

• If you access var before assignment, you get undefined

• When a function is called, a new Function Execution Context (FEC) is created

The Function Execution Context (FEC) (shown in the right branch) works as a child of the GEC and has its own Memory and Execution phases. After the function executes completely, the FEC is popped off the call stack and control returns to the GEC.

Finally, when all code execution is complete, the GEC itself is popped from the call stack, and the program ends.

This visual representation helps you understand that JavaScript doesn't just read and run your code - it prepares everything first (Memory Phase) and then executes it systematically (Execution Phase).

What Exactly is Hoisting?

Hoisting is JavaScript's default behavior of moving variable and function declarations to memory before code execution begins.

Think of it this way – it appears as if all declarations automatically move to the very top of the code. Although the code doesn't physically move, the memory allocation happens first.

Does Only var Get Hoisted?

This surprises many people, but the answer is no. It's not just var that gets hoisted! This is a huge misconception among many developers.

The truth is that—let, const, and functions—everything gets hoisted! But their behavior is completely different. Let's dive into the details.

What Happens with var?

console.log(name) // undefined
var name = 'Rahim'
console.log(name) // "Rahim"

Variables declared with var:

• Get hoisted

• Are initialized with undefined

• Exist in global scope or function scope

• Can be accessed before declaration (doesn't throw an error)

What Happens with let?

console.log(name) // ReferenceError: Cannot access 'name' before initialization
let name = 'Rahim'
console.log(name) // "Rahim"

Is this magic? No! Actually, let does get hoisted, but it's stuck in a special state called the temporal dead zone!

Space is allocated in memory, but it's not initialized. So if you try to access it before declaration, JavaScript says – "Hey, the variable exists, but you can't use it yet!"

What Happens with const?

console.log(age) // ReferenceError: Cannot access 'age' before initialization
const age = 24
console.log(age) // 24

The behavior of const is exactly the same as let:

• Gets hoisted

• Stays in the TDZ until declaration

• Exists in block scope

• Plus, once assigned, it cannot be reassigned

Temporal Dead Zone (TDZ) – What is it Really?

The Temporal Dead Zone is the time period or zone when a variable exists in memory (due to hoisting) but hasn't been initialized yet. During this time, the variable is essentially "dead" – meaning that you cannot access it.

// ← TDZ starts for x and y
console.log(x) // ReferenceError - still in TDZ
console.log(y) // ReferenceError - still in TDZ

// TDZ continues...
let x = 10 // ← x's TDZ ends at this line
const y = 20 // ← y's TDZ ends at this line

console.log(x) // 10 - can access now
console.log(y) // 20 - can access now

The entire concept of TDZ is to force us to write better code. Using variables before declaring them is a bad practice, and TDZ prevents us from doing that.

Function Hoisting – The Most Interesting Part!

Hoisting with functions is even more interesting and powerful:

greet() // "Hello World!" - Perfect! It works!

function greet() {
  console.log('Hello World!')
}

How is this possible? Because function declarations are completely hoisted! This means not just the name, but the entire function body is lifted into memory. That's why it can be called even before the declaration.

But wait! Not all functions work this way.

With Function Expressions:

greet() // TypeError: greet is not a function

var greet = function () {
  console.log('Hello World!')
}

What happened here? greet was hoisted as a variable and received the value undefined. It wasn't hoisted as a function! So when you try to call it, you get an error. In other words, it's hoisted as a variable (assigned undefined), but the function body isn't loaded into memory.

With Arrow Functions:

sayHello() // ReferenceError (if let/const is used)

const sayHello = () => {
  console.log('Hello!')
}

Arrow functions behave just like function expressions. They follow variable rules.

Let's clear everything up with a complete example:

console.log(a) // undefined (var hoisting)
console.log(b) // ReferenceError (TDZ)
console.log(c) // ReferenceError (TDZ)
multiply(2, 3) // 6 (function hoisting)
add(2, 3) // TypeError (function expression)

var a = 10
let b = 20
const c = 30

function multiply(x, y) {
  return x * y
}

var add = function (x, y) {
  return x + y
}

What Happens in the Memory Phase:

a: undefined
b: <uninitialized>
c: <uninitialized>
multiply: function(x, y) { return x * y; }
add: undefined

This snapshot represents the state of memory before any code is executed. Here's what each line means:

a: undefined - Since a is declared with var, it gets hoisted and immediately assigned the value undefined. This is why you get undefined instead of an error when you try to access a before its declaration line.

b: <uninitialized> - The variable b is declared with let, so it's hoisted and memory is allocated for it, but it remains uninitialized. It's in the Temporal Dead Zone (TDZ). Attempting to access it before the declaration line will throw a ReferenceError.

c: <uninitialized> - Similarly, c is declared with const and follows the same behavior as let. It's hoisted but stays uninitialized in the TDZ until the declaration line is reached.

multiply: function(x, y) { return x * y; } - This is a function declaration, so it's fully hoisted with its complete body. The entire function is stored in memory and ready to be called even before the JavaScript engine reaches its declaration in the code. This is why multiply(2, 3) works perfectly and returns 6.

add: undefined - Here's the crucial difference! Even though add will eventually store a function, it's declared using var add = function() {...} (a function expression). During the memory phase, only the variable add is hoisted and initialized with undefined. The actual function body isn't assigned until the execution phase reaches line 11. This is why calling add(2, 3) before the assignment throws a TypeError: add is not a function - you're essentially trying to execute undefined().

Conclusion

Understanding JavaScript's execution mechanism is fundamental to becoming a proficient developer. Let's recap the essential concepts we've explored:

The Global Execution Context (GEC) is the foundation of JavaScript execution. Every time you run JavaScript code, the GEC is created first. It works in two critical phases:

• Memory Creation Phase: JavaScript prepares by scanning the code and allocating memory for variables and functions.

• Code Execution Phase: JavaScript runs your code line by line.

Hoisting is universal - not just limited to var. Here's how different declarations are hoisted:

• var variables are hoisted and initialized with undefined.

• let and const are hoisted but remain uninitialized in the TDZ.

• Function declarations are fully hoisted with their entire body.

• Function expressions and arrow functions follow variable hoisting rules

The Temporal Dead Zone (TDZ) is JavaScript's built-in safety mechanism. It exists from the start of the scope until the variable declaration line is reached. The TDZ prevents us from accessing let and const variables before they're declared, encouraging better coding practices and helping us avoid bugs.

Function hoisting behavior varies:

• Function declarations can be called before they appear in code.

• Function expressions behave like variables and cannot be called before assignment.

• Arrow functions follow the same rules as function expressions.

Why does this matter? Understanding these concepts helps you:

• Predict how your code will behave before running it.

• Avoid common errors like ReferenceError and TypeError.

• Write cleaner, more maintainable code.

• Debug issues faster when they arise.

• Make informed decisions about when to use var, let, or const.

The key takeaway: JavaScript doesn't just execute your code - it prepares first, then executes. The memory phase sets up the stage, and the execution phase performs the show. Master this two-phase process, and you'll have a solid understanding of how JavaScript works under the hood.

Now you're equipped with the knowledge to write better JavaScript code and understand exactly what's happening behind the scenes. Keep practicing these concepts, and they'll become second nature!

Happy Coding!

I previously wrote an article showing how to create a Figma/Miro Clone in React and TypeScript. The code in the article was designed to be as easy to understand, and in this article, we’re going to optimize it. The code used DndKit for dragging and dropping, and D3 Zoom for panning and zooming. There were four components (App, Canvas, Draggable and Addable), and about 250 lines of code. You do not need to read the original article to understand this one.

Standard optimizations such as useCallback, memo, and similar made it about twice as fast when dragging, but made no difference for panning and zooming. More creative/intensive optimizations made it about ten times as fast in most cases.

You can see the optimized code on GitHub and there is a live demo on GitHub pages to test out the speed with 100,000 cards.

Table of Contents

• How to Measure Performance in React Apps

• How to Investigate the performance

• How to Optimize Panning and Zooming the Canvas

• How to Optimize Dragging Cards Around the Canvas

• Results

• Summary

How to Measure Performance in React Apps

There are three common ways to measure performance in React Apps

• React Dev Tools profiler

• Chrome Dev Tools profiler, especially using custom tracks

• Profiler component

These tools are all great, but none of them are quite the right fit in this case. In most codebases, the time spent executing JavaScript code (both our code and that of the React framework) is the primary issue. However, after all your code has run and React has updated the Dom, the browser still has a lot of work to do:

In this case, this browser layout and rendering time was significant, and is not accounted for by the React profiling.

You can use custom tracks in the Chrome dev tools profiler, but it is very cumbersome to use.

For us, the JavaScript performance API is the best option, which gives results that are closer to those experienced by the user, and is relatively easy to use.

First, we make a call to performance.mark in the event handler that starts the action, with a string to describe the time point. For example, when starting a zoom or pan operation:

zoomBehavior.on("start", () => {
    performance.mark('zoomingOrPanningStart');
}

Then, in a useEffect hook, we call performance.mark again, and call performance.measure to calculate the time between the two points:

useEffect(() => {
    performance.mark('zoomingOrPanningEnd');
    performance.measure('zoomingOrPanning', 'zoomingOrPanningStart', 'zoomingOrPanningEnd');
});

The React docs states that useEffect usually fires after the browser has painted the updated screen, which is what we want.

This isn't perfect, and will vary depending on the machine specifications, and what else the machine is doing at the time, but it was good enough to verify which optimizations worked best. It is possible to go further if you need to. For example, using Cypress to automate and profile scenarios, potentially running many times to get a good mean, or using Browserstack to test on a variety of devices.

How to Investigate the Performance

Most of the investigation involved using the React Dev Tools profiler to record profiles of user interactions.

The performance data shows how many commits there were in the profile, and how long each one took, which is a great way to see if there are too many commits.

Each commit displays a flame chart showing which components rendered and why they re-rendered. This makes it much easier to find ways to avoid the re-rendering, and to check that memoization strategies are working as expected. This does have some caveats though. It often says 'The parent component rendered', which is misleading default text for when it doesn’t understand what happened (and is often due to a change in a parent context). It also says things like 'hook 9 changed', which makes it time consuming to work out exactly which hook changed.

The flame chart also shows how long each component took to render. This helps target problem components that we need to focus on.

How to Optimize Panning and Zooming the Canvas

The original Canvas element used the CSS transform translate3d(x, y, k) to pan and zoom the canvas. This works, but it doesn't scale child elements, so when the zoom changes, all the cards on the canvas have to be re-rendered with a new CSS transform for the new zoom level (scale(${canvasTransform.k})).

 <div
    ...
    className="canvas"
    style={{
        transform: `translate3d(${transform.x}px, ${transform.y}px, ${transform.k}px)`,
        ...
    }}>
    ...
</div>
<div
    className="card"
    style={{
        ...
        transform: `scale(${canvasTransform.k})`,
    }}>
    ...
</div>

I changed this to use translateX(x) translateY(y) scale(k), which has the same effect, but does scale child elements. This way, when the zoom changes, none of the cards will be re-rendered (the style of the card component no longer uses the canvasTransform.k).

 <div
    ...
    className="canvas"
    style={{
        transform: `translateX(${transform.x}px) translateY(${transform.y}px) scale(${transform.k})`,
        ...
    }}>
    ...
</div>
<div
    className="card"
    ...
</div>

The Canvas still needed to re-render whenever the pan or zoom changed, and it is possible to prevent this with useRef, and updating the CSS transform with direct JavaScript Dom manipulation in the d3-zoom event handler. This doesn’t make a significant improvement to the performance though, and is a definite hack, so the trade off is not worthwhile.

Both zooming and panning get a bit slower when the canvas is zoomed very far out and there are (a lot) more cards visible on the screen, just due to the browser having to render them all. It's still workable at 100,000 cards though. There are things you can do about this. An easy option is limiting the maximum zoom extent. This is a functional change, so potentially something that doesn’t meet requirements, but it is easy to do in d3-zoom using scaleExtent:

zoom<HTMLDivElement>().scaleExtent([0.1, 100])

Another option is to create a bitmap for very low zoom levels and render that as a single element. This may be difficult, but it means that there will be no change to the functionality.

How to Optimize Dragging Cards Around the Canvas

Starting a drag

The useDraggable hook from DndContext causes some re-renders when starting a drag operation.

It is possible to improve this by changing the Draggable component to just have this hook (and the things that use it) and having a DraggableInner component for everything else (inside a memo). This works well for reducing the re-renders, in that the DraggableInner almost never get re-rendered, and improves the speed of starting a drag operation. However, it was still fairly slow, and the time was all under the DndContext.

A better option is to create a new NonDraggable component, that looks exactly like the Draggable component, but does not hook up with DndContext. These cards are shown on the Canvas, and have an onMouseEnter event, to swap in the Draggable component for the active card, so that dragging continued to work.

const onMouseEnter = useCallback(() => {
    setHoverCard(card);
}, []);

This works well, and significantly improves the speed when starting a drag operation, but it was still quite slow with large numbers of cards. Nearly nothing was getting re-rendered, but there is still a time cost to when using memo, as it needs to check whether components have changed.

To fix this, we create an AllCards component, that contains all the cards on the canvas as NonDraggable components. Because it always renders all the cards, it nearly never needs to be re-rendered, and it is used with memo. So instead of each individual card using a memo (with the associated time cost), there is now just one component using a memo. To make it so that the dragging still works, the active Draggable component is rendered on top, obscuring the NonDraggable component beneath it. There is also a Cover component beneath that, so that when the Draggable component is dragged away, the NonDraggable component underneath remains hidden.

Original code, where each card is a Draggable component:

<DndContext ...>
    {cards.map((card) => (
        <Draggable card={card} key={card.id} canvasTransform={transform} />
    ))}
</DndContext>

Optimized code, where the AllCards component renders all the cards as NonDraggable components, and then a Cover and a Draggable component for the active card.

<AllCards cards={cards} setHoverCard={setHoverCard} />
<DndContext ...>
    <Cover card={hoverCard} />
    <Draggable card={hoverCard} canvasTransform={transform} />
</DndContext>

This works very well. With a low number of cards, the speed is about the same, but with a high numbers of cards, it’s about twenty times faster.

There is now a new potential performance issue with the onMouseEnter event that swaps in the Draggable component for the active card, but this just adds two components to the Dom, and is very quick even with large numbers of cards.

Finishing a drag

Finishing a drag operation is hard to optimize, as the position of a card changes, and that does need to re-render, which means that the AllCards component has to re-render as well.

You can see original code below. Even when using memo with the Draggable component, the end drag operation still takes 2500ms with 100,000 cards, mostly due to the complexity of the Draggable component and its integration with DndKit.

<DndContext ...>
    {cards.map((card) => (
        <Draggable card={card} key={card.id} canvasTransform={transform} />
    ))}
</DndContext>

However, we now use the NonDraggable components, which all memo successfully, and only the dragged card is re-rendered. There is still a time cost using the memo, and this is the slowest part of the solution, but it leads to an increase in speed to 500ms with 100,000 cards.

const NonDraggable = memo(...)

const AllCards = memo((cards, setHoverCard) => {
    <>
        {cards.map((card) => {
            <NonDraggable card={card} key={card.id} setHoverCard={setHoverCard} />);
        })}
    </>;
});

Results

The base unoptimized version started to get slow between 1000 and 5000 cards. Standard optimizations improved this to around 10,000 cards, and the more optimization took it to about 100,000 cards. The trade off is that the code becomes significantly more complicated, which makes it harder to understand and modify, especially for people new to the codebase.

Summary

It is unusual to display 100,000 or more items on screen in a standard React App, but in a highly graphical codebase, it becomes much more likely.

With these numbers, the browser rendering engine is likely to take a significant amount of time, so it is best to use the performance API to measure performance, instead of the usual React tools.

Standard React optimization strategies do work and improve the situation, but there is a need to go further, by finding ways to avoid renders, and even to avoid too many memo comparisons.

In this tutorial, you’ll learn what causes memory leaks and how to fix them.

Table Of Contents

• Prerequisites

• What Are Memory Leaks in React?

• When Does A Component Unmount?

• Common Causes Of Memory Leaks And How To Fix Them

  • Event Listeners

  • Timers

  • Subscriptions

  • Async Operations

• Conclusion

Prerequisites

Before you move on, make sure you have:

• Basic knowledge of JavaScript, React, and React hooks

• Understanding of event handling, timers, and asynchronous calls

• A React development setup.

If you don’t have a React development setup, you can head over to the memory-leak repo. Run the commands below to set it up:

# clone the repo
git clone <https://github.com/Olaleye-Blessing/freecodecamp-fix-memory-leak.git>

# navigate to the folder
cd freecodecamp-fix-memory-leak.git

# install the packages
pnpm install

# start development
pnpm dev

What Are Memory Leaks in React?

In JavaScript, memory leaks happen when an application allocates memory but fails to release it. This occurs even after the memory is no longer needed.

In React, memory leaks happen when a component creates resources but does not remove them when it unmounts. These resources can be event listeners, timers, or subscriptions.

As a user stays longer in the application, these unreleased resources accumulate. This accumulation causes the application to consume more RAM. This will eventually lead to several problems:

• A slow application

• The browser crashing

• A poor user experience

For example, a component might create a “resize” event listener when it mounts, but forgets to remove it when it unmounts. This builds up memory as the user stays longer in the application and resizes the screen.

When Does A Component Unmount?

A component unmounts when it no longer exists in the DOM. This can happen if:

1. A user navigates away from the page.

    <Routes>
      <Route path="/posts" element={<Posts />} />
      <Route path="/dashboard" element={<Dashboard />} />
    </Routes>
   

   The dashboard component will unmount immediately when a user navigates from /dashboard to any other route in the application.

2. A component is conditionally rendered.

    function App() {
      const [show, setShow] = useState(true);
   
      return <div>{show && <Component />}</div>;
    }
   

   <Component /> will unmount when show becomes false.

3. A component key changes.

    function App() {
      const [key, setKey] = useState(Date.now());
   
      return (
        <>
          <button onClick={() => setKey(Date.now())}>Change Key</button>
          <Form key={key} />
        </>
      );
    }
   

   The <Form /> component will unmount every time the key changes. Also note that a new <Form /> component will mount each time the key changes.

Common Causes Of Memory Leaks And How To Fix Them

As said earlier, there will be a memory leak when resources are not removed after a component unmounts. React useEffect allows you to return a function that will be called when a component unmounts.

useEffect(() => {
  return () => {
    // code to remove resources
  };
}, []);

You can clean any created resources in this returned function. We will go through how to clean up some of these resources.

Event Listeners

Event listeners persist if they are not removed after a component unmounts. Look at the code below:

import { useEffect, useState } from "react";

const EventListener = () => {
  const [windowWidth, setWindowWidth] = useState(0);

  useEffect(() => {
    function handleResize() {
      const width = window.innerWidth;
      console.log("__ Resizing Event Listerner __", width);
      setWindowWidth(width);
    }

    window.addEventListener("resize", handleResize);
  }, []);

  return <div>Width is: {windowWidth}</div>;
};

export default EventListener;

We do not remove the resize event listener on unmount, so every mount adds a new listener. This failure to clean up leads to a memory leak.

As shown in the GIF above, we log the width in the console every time we resize the window’s width. We still log the same information after component unmounts. Also, when we check the “Event Listeners” tab, the number of listeners keeps increasing by 2 instead of being just 1 each time we remount the component.

We see two listeners when the component mounts because React uses StrictMode in development. This helps to see side effects in the development mode. The same reason the listeners increase by 2 any time we mount the component.

To fix this memory leak, we need to remove the event listener in our cleanup function.

useEffect(() => {
  // previous code

  return () => {
    window.removeEventListener("resize", handleResize);
  };
}, []);

The cleanup function runs when the component unmounts. This, in turn, removes our event listener and prevents a memory leak.

Notice this time, nothing is shown in the console when we hide the component. Also, the resize event listener was reduced to 0 when we hid (unmounted) the component, and increased to 1 when we showed (mounted) it.

Timers

Timers like setInterval and setTimeout can also cause memory leaks if they are not cleared after the component unmounts. Look at this:

const Timers = () => {
  const [countDown, setCountDown] = useState(0);

  useEffect(() => {
    setInterval(() => {
      console.log("__ Set Interval __");
      setCountDown((prev) => prev + 1);
    }, 1000);
  }, []);

  console.log({ countDown });

  return <div>Countdown: {countDown}</div>;
};

The interval will continue to run even after React hides or unmounts the component.

Note that, in React 18+, React ignores a state update when a component already unmounts.

In the GIF, we notice that the console stops showing "__ Outside effect ” anytime we hide/unmount the component. But the string, " Interval __”, shows every time.

We can fix this by using the cleanup function. All timers (setInterval, setTimeout) return a unique timer ID that we can use to clear the timer after the component unmounts.

const [countDown, setCountDown] = useState(0);
useEffect(() => {
  const timer = setInterval(() => {
    console.count("__ Interval __");
    setCountDown((prev) => prev + 1);
  }, 1000);

  return () => {
    clearInterval(timer);
  };
}, []);

We now save the ID of the timer and use this ID to clear the interval when the component unmounts. The same method applies to setTimeout; save the ID and clear it with clearTimeout.

Subscriptions

When a component subscribes to external data, it’s always appropriate to unsubscribe after the component unmounts. Most data source returns a callback function to unsubscribe from such data. Take Firebase for an example:

import { collection, onSnapshot } from "firebase/firestore";
import { useEffect } from "react";

const Subscriptions = () => {
  useEffect(() => {
    const unsubscribe = onSnapshot(collection(db, "cities"), () => {
        // Respond to data
        // ...
    });
  }, [])

    return <div>Subscriptions</div>;
};

export default Subscriptions;

The onSnapshot function from firebase/firestore gets real-time updates from our database. It returns a callback function that stops listening to the DB updates. If you fail to call this function, our app continues to listen to these updates even when it no longer needs them.

useEffect(() => {
  const unsubscribe = onSnapshot(collection(db, "cities"), () => {
    // Respond to data
    // ...
  });

  return () => {
    unsubscribe();
  };
}, []);

Calling unsubscribe() in the returned function means we are no longer interested in listening to the data updates.

Async Operations

One common mistake is not cancelling an API call when it’s no longer needed. It's a waste of resources to allow an API call to keep running when the component unmounts. This is because the browser continues to hold references in memory until the promise resolves. Look at this example:

import { useEffect, useState } from "react";

interface Post {
  id: string;
  title: string;
  views: number;
}

const ApiCall = () => {
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState("");
  const [data, setData] = useState<Post[] | null>(null);

  useEffect(() => {
    const getTodos = async () => {
      try {
        setLoading(true);

        console.time("POSTS");
        const req = await fetch("<http://localhost:3001/posts>");
        const res = await req.json();
        console.timeLog("POSTS");
        setData(res.posts);
      } catch (error) {
        setError("Try again");
      } finally {
        setLoading(false);
      }
    };

    getTodos();
  }, []);

  return (
    <div style={{ marginTop: "2rem" }}>
      <p>ApiCall Component</p>
      {loading ? (
        <p>Loading...</p>
      ) : error ? (
        <p>{error}</p>
      ) : data ? (
        <p>Views: {data[0].views}</p>
      ) : null}
    </div>
  );
};

export default ApiCall;

This component fetches a list of posts from our server immediately it mounts. It changes the UI based on the state of the API call:

• It displays a loading text when you click the button.

• It shows an error if the API fails.

• It shows the data if the API succeeds.

We have a simple server that returns the list of posts. The problem with the server is that it takes three seconds for it to return the list of posts.

What happens when a user comes to this page but decides to leave before three seconds? (We simulate leaving the page by clicking the Hide Component button.)

As you can see, the browser still holds a reference to the request even though it’s no longer needed.

A proper way to fix this is to cancel the request when the component unmounts. We can do this by using the AbortController. We can use the abort method to cancel the request before it gets completed, thereby releasing memory.

import { useEffect, useState } from "react";

interface Post {
  id: string;
  title: string;
  views: number;
}

const ApiCall = () => {
  // previous code

  useEffect(() => {
    const controller = new AbortController();

    const getTodos = async () => {
      try {
        // previous code

        const req = await fetch("<http://localhost:3001/posts>", {
          signal: controller.signal,
        });

        // previous code
      } catch (error) {
        if (error instanceof Error && error.name === "AbortError") {
          console.log("Request was cancelled");
          return;
        }

        setError("Try again");
      } finally {
        setLoading(false);
      }
    };

    getTodos();

    return () => {
      controller.abort();
    };
  }, []);

  return (
    <div style={{ marginTop: "2rem" }}>
      <p>ApiCall Component</p>
      {/* previous code */}
    </div>
  );
};

export default ApiCall;

We created a controller to track our API request when the component mounts. We then attach the controller to our API request. Our cleanup function cancels the request if the users leave the page within three seconds.

We can see the result of this in the GIF below:

Most production React applications use external libraries to fetch APIs. For example, react query allows us to cancel a processing promise:

const query = useQuery({
  queryKey: ["todos"],
  queryFn: async ({ signal }) => {
    const todosResponse = await fetch("/todos", { signal });
    const todos = await todosResponse.json();

    return todos;
  },
});

Conclusion

Memory leaks can significantly impact your React application's performance and user experience. You can prevent these issues by properly cleaning up resources when a component unmounts. In summary, always remember to:

• Remove event listeners with removeEventListener.

• Clear timers with clearInterval and clearTimeout.

• Unsubscribe from external data sources.

• Cancel API requests using AbortController.

If the text exceeded the limit, a split button appeared, allowing users to open the full prompt in a separate split-view section (see the illustration below for better understanding).

Now, if the requirement had been just plain text, I could have solved it with a simple regex-based search. In fact, inside the split view itself, I initially used a regex approach for searching along with navigation to the matches. That worked fine.

Since I already had a working search helper function, I thought, “Why not reuse it for the global search as well?”

Well, I tried that. But this time, the UI started lagging whenever I clicked the next/previous buttons in the search bar. Even the pagination controls on the top-right slowed down during navigation. To figure out a better approach, I turned to AI tools for brainstorming and came across multiple ideas and concepts.

As developers, we use Google daily, and naturally, I became curious about how Google’s search works under the hood. I opened up Chrome DevTools, started typing in Google’s search bar, and noticed something interesting.

While Google Search updates results in real-time with each keystroke, we don’t have Google’s server power. In our apps, debouncing is a practical way to avoid unnecessary API calls and improve performance. That idea matched exactly what ChatGPT had suggested to me earlier.

So, I applied a similar approach to my project and finally delivered the feature using debouncing, along with React hooks like useTransition and useDeferredValue. That’s how the idea for this article came out.

In this article, I’ll show you how to optimize your application’s performance by implementing the debounce technique.

Table of Contents

• Problem Without Debouncing

• What is Debouncing?

• How to Implement Debouncing in JavaScript

• Benefits of Using Debouncing in Search

• Common Mistakes to Avoid

• Conclusion

• Before We End

Let’s dig in.

Problem Without Debouncing

Imagine you’re building a search bar that fetches results from an API. Every time the user types a letter, the search bar immediately makes a new request.

If someone types the word “JavaScript”, that means 10 separate API calls will be fired — one for each character.

Now, in Google Search, results update in real-time with every keystroke. But unlike Google, we don’t have massive infrastructure to handle that load. In most applications, firing a request for every single character quickly becomes inefficient.

At first, this might not seem like a big deal, but in practice it leads to serious problems. The browser has to manage a flood of unnecessary requests, the server gets overloaded with repeated calls, and the user ends up with a laggy or inconsistent experience. The whole interface feels heavy and unresponsive.

This is exactly the situation I ran into when I reused my simple regex-based search function for the global search. It worked fine for a small prompt inside the split view, but when applied at a larger scale with navigation buttons and pagination, the UI started freezing and slowing down.

What is Debouncing?

Debouncing is a technique, not a programming language feature. It’s simply a way to control how often a function gets called. Instead of running the function every single time an event happens, you delay its execution.

If the event keeps firing during that delay, the timer resets. The function only runs when the user finally pauses.

Think about typing into a search bar. Without debouncing, the app would make a request for every keystroke. With debouncing, the app waits until the user stops typing for a short time—say 300 milliseconds and then makes just one request with the final input.

Behind the scenes, this is usually implemented with setTimeout and clearTimeout. A timer starts when the event occurs, and if another event happens before the timer ends, the timer is cleared and restarted. Only when the user stops typing for the specified delay does the function execute.

How to Implement Debouncing in JavaScript

As I mentioned earlier, debouncing is not tied to any specific programming language. It’s simply a concept that can be implemented using timers. In JavaScript, we typically use setTimeout and clearTimeout to achieve this.

Here’s a simple example of a debounce function in JavaScript:

function debounce(fn, delay) {
  let timer;
  return function (...args) {
    clearTimeout(timer);
    timer = setTimeout(() => {
      fn.apply(this, args);
    }, delay);
  };
}

We start with a function debounce that takes two arguments:

• fn is the function we want to control, such as the API call.

• delay is how long we want to wait before actually running fn.

Inside, we declare a variable timer. This will hold the reference to the setTimeout.

The debounce function then returns another function. This returned function is the one that will actually run whenever an event (like typing in the input or API call) happens.

Every time the user types, the first thing you do is clearTimeout(timer). This cancels any previously scheduled function call. Then you create a new timeout with setTimeout.

If the user keeps typing before the delay finishes, the old timer is cleared and restarted. Only when they pause long enough does the timeout finish and fn gets executed.

Did you notice how I used fn.apply(this, args)? That’s just a safe way of calling the original function with the correct this context and passing along all arguments.

Now here’s how you use it in practice:

function fetchResults(query) {
  console.log("Fetching results for:", query);
  // Here you could call your API
}

// Wrap it with debounce
const debouncedSearch = debounce(fetchResults, 300);

// Attach to input event
const input = document.getElementById("search");
input.addEventListener("input", (e) => {
  debouncedSearch(e.target.value);
});

1. fetchResults is our actual search function. Normally, it would run for every keystroke.

2. We wrap it with debounce and set a delay of 300ms. That means it won’t run until the user stops typing for 300ms.

3. On every input event, instead of calling fetchResults directly, we call debouncedSearch. This ensures only the debounced version of the function executes.

So if a user types “hello,” instead of five API calls, only one or two will fire once they pause.

Benefits of Using Debouncing in Search

Using debouncing in a search feature may feel like a small optimization, but it has a big impact. The most obvious benefit is performance.

Instead of making a request for every single keystroke, your app waits until the user pauses, which saves both browser and server resources. The UI feels much smoother because it isn’t constantly being interrupted by unnecessary calls.

Debouncing also improves scalability. If hundreds or thousands of users are typing at once, you’re cutting down a huge number of wasted API calls. That means your backend can handle more users without getting overloaded.

There’s also an indirect benefit for SEO and analytics. When your app performs efficiently and feels snappy, users stay longer, interact more, and bounce less. This kind of responsiveness can make a big difference in how people perceive the quality of your product.

Common Mistakes to Avoid

While debouncing is powerful, there are a few mistakes developers often make. One common issue is setting the delay too high. If you make users wait one or two seconds before seeing results, the search will feel unresponsive.

On the other hand, a delay that’s too short may not reduce calls enough to be useful. A sweet spot is usually between 300–500 milliseconds, but it depends on your use case.

Another mistake is forgetting to clear old timers. Without clearing, your app may still execute older, outdated calls, which can lead to glitches or memory leaks. That’s why clearTimeout is just as important as setTimeout in any debounce function.

It’s also important to think about edge cases. What happens if the input is cleared quickly? Or if someone pastes a long string instead of typing? Testing these cases ensures your debounce function works smoothly in real-world scenarios.

Conclusion

When I first encountered the challenge of building a global search, I thought I could simply reuse my basic regex-based solution. However, the UI soon began to lag, and the user experience declined. It's surprising how such a small concept can significantly impact performance.

Debouncing ensures that your functions run at the right time, not every time. Whether you’re building a simple JavaScript app or working with React and Next.js, this technique helps reduce unnecessary calls, improves performance, and keeps your app scalable.

So the next time you build a search bar, remember: don’t just make it work, make it efficient.

Before We End

I hope you found this article insightful. I’m Ajay Yadav, a software developer and content creator.

You can connect with me on:

• Twitter/X and LinkedIn, where I share insights to help you improve 0.01% each day.

• Check out my GitHub for more projects.

• I also run a Hindi YouTube Channel where I share content about careers, software engineering, and technical writing.

See you in the next article — until then, keep learning!

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

When code becomes difficult to read or change, it slows down progress and can even cause bugs. To keep a codebase healthy and easy to work with, you’ll need to take care of it.

Improving and organizing old code can feel like a big task, but there are tools and methods that can make it easier. This guide will show how to refresh your codebase step by step which will make it simpler to work with and less likely to cause issues.

Table of Contents

1. How to Review Your Code Effectively

2. How to Identify Technical Debt and Problem Areas in Code

3. How to Measure Code Quality with Code Analysis Tools

4. AI Tools to Help You Improve Your Code

5. Version Control Best Practices for Code Changes

6. Conclusion

How to Review Your Code Effectively

Code reviews are essential for catching issues early, improving readability, and ensuring long-term maintainability. Reviewing your own code or someone else’s involves more than just scanning for errors – you’ll also want to make sure each part is clear, efficient, and follows good practices.

Here’s a step-by-step approach to help you review code effectively, with practical strategies, tools, and what to look for during the process.

Strategies for Effective Code Review

1. Break Down the Review Process: Reviewing code all at once can be overwhelming, especially in large projects. Focus on small sections of the codebase at a time, such as individual functions or modules. This approach helps you examine each part closely and avoids missing issues that could be overlooked in a quick scan.

2. Review for Clarity and Simplicity: Good code should be easy to read and understand. When reading through the code:

   • Variable and Function Names: Are variable names descriptive enough to convey their purpose? Long, unclear names make code harder to follow.

   • Function Length: Keep functions short and focused on one task. Long functions are harder to debug and maintain.

   • Comments and Documentation: Comments should explain why something is done rather than what is happening, which should be clear from the code itself. For instance, avoid excessive commenting on trivial lines and focus on complex logic or business rules.

3. Check for Code Reusability and Modularity: Look for repeated code or functions performing multiple tasks. By modularizing code, you make it easier to test, update, and reuse. In a review, look for:

   • Duplicate Code: Repeated code can often be refactored into a function.

   • Single Responsibility: Each function should handle one task, making it easier to maintain and update.

4. Examine Error Handling and Edge Cases: Robust code should handle unexpected inputs or errors gracefully. During a review, think about potential edge cases that could break the code:

   • Null or Undefined Values: Does the code check for undefined values where needed?

   • Out-of-Range Errors: Ensure array indexes and calculations won’t produce errors with edge cases.

   • Error Messages: Make sure error handling is meaningful, with clear error messages where applicable.

5. Look for Performance Issues: Performance may not always be critical, but it’s good to check for potential bottlenecks. Look for:

   • Loop Optimization: Avoid deeply nested loops or repeated work inside loops.

   • Database Queries: Minimize unnecessary database calls.

   • Heavy Computation in the Main Thread: Move any heavy processing outside the main application thread if possible.

6. Ensure Consistency with Coding Standards: Following a consistent coding style improves readability across the team. Many teams use linters or style guides to enforce these standards. Look for:

   • Code Format: Consistent indentation, spacing, and use of braces.

   • Naming Conventions: Follow agreed naming conventions (camelCase, snake_case, and so on) consistently.

Tools to Assist with Code Reviews

There are a number of tools out there that can help streamline your code reviews, whether you’re checking your own code or collaborating with others:

1. Linters (like ESLint and Pylint)

Linters check for syntax errors, code smells, and style guide violations. They are especially useful for catching minor issues, like inconsistent formatting or unused variables. We will discuss ESLint more in an upcoming section.

# Example: Run ESLint on a JavaScript project
npx eslint src/

2. Static Analysis Tools (like SonarQube)

These tools analyze code for deeper issues like security vulnerabilities, code duplication, and complex functions that might need refactoring.

# Configuring SonarQube to scan a project
sonar.projectKey=my_project
sonar.sources=src
sonar.host.url=http://localhost:9000
sonar.login=my_token

3. Automated Testing Tools

Running tests can verify that code changes don’t introduce new bugs. Use testing frameworks like Jest for JavaScript, PyTest for Python, or JUnit for Java to confirm your code behaves as expected.

Example of Refactoring During Code Review

Let’s say you encounter a long function with multiple responsibilities. The goal is to split it into smaller, focused functions. Here’s how you can do that:

// Original: A single function that handles everything
function processOrder(order) {
    // Calculate total price
    let total = 0;
    order.items.forEach(item => {
        total += item.price * item.quantity;
    });

    // Apply discount
    if (order.discountCode) {
        total = total * 0.9; // 10% discount
    }

    // Send order confirmation email
    sendEmail(order.customerEmail, 'Order Confirmation', 'Your order total is ' + total);
}

// Improved: Break into smaller functions for readability and reusability
function calculateTotal(order) {
    return order.items.reduce((sum, item) => sum + item.price * item.quantity, 0);
}

function applyDiscount(total, discountCode) {
    return discountCode ? total * 0.9 : total;
}

function sendConfirmationEmail(email, total) {
    sendEmail(email, 'Order Confirmation', 'Your order total is ' + total);
}

function processOrder(order) {
    let total = calculateTotal(order);
    total = applyDiscount(total, order.discountCode);
    sendConfirmationEmail(order.customerEmail, total);
}

Breaking down the process into smaller functions makes the code cleaner, more readable, and easier to test. Each function now has a single responsibility, which helps reduce bugs and makes future updates simpler.

How to Identify Technical Debt and Problem Areas in Code

Technical debt refers to the accumulation of issues within a codebase that arise when development shortcuts are taken, often to meet tight deadlines or speed up releases. While these shortcuts may enable quicker progress initially, they lead to complications down the line.

Technical debt requires proactive management. If you leave it unchecked, it can reduce productivity, create bugs, and slow down development.

Think of technical debt like financial debt: taking on debt can be helpful in the short term, but failing to address it or pay it down will lead to greater challenges.

Common causes of technical debt include:

• Rushed development cycles: When teams prioritize quick delivery over thorough design and testing, they may produce incomplete or hastily written code.

• Lack of planning for future changes: Sometimes, code is written without accounting for scalability, leading to issues as the project grows.

• Insufficient documentation or testing: Without proper documentation and test coverage, codebases become difficult to understand and validate over time.

• Outdated frameworks and dependencies: When frameworks or libraries aren’t updated, they can become incompatible with newer components or security standards, introducing risk and hindering future updates.

Types of Technical Debt

Technical debt manifests in different ways. Here are some common examples:

1. Code Duplication:

Repeated code across multiple places within a project can lead to inconsistencies, as fixing an issue or updating a feature in one area may not carry over to others. Refactoring duplicate code into reusable functions or components is an effective way to reduce this debt.

Example: In a web application, you might find similar code for user authentication scattered across different modules. Instead, centralizing this logic into a single authentication module ensures consistent updates.

2. Outdated Dependencies and Frameworks:

Using old libraries or frameworks can slow down development and introduce security vulnerabilities. Over time, dependencies may lose support or become incompatible with new features, making them costly to maintain.

Solution: Regularly update libraries and frameworks, and monitor for deprecations or vulnerabilities. This can be streamlined by using dependency managers, which help check for updates and security patches.

3. Complex, Long Functions with Multiple Responsibilities:

Large, complex functions that handle multiple tasks are difficult to understand, test, and modify. Known as “God functions,” these make debugging cumbersome and increase the risk of introducing new bugs.

Solution: Follow the Single Responsibility Principle (SRP). This means that each function or method should accomplish one task. Breaking down large functions into smaller, focused units makes the code easier to read and test.

Example: Instead of having a single processUserRequest function that handles authentication, logging, and database queries, split it into three functions: authenticateUser, logRequest, and queryDatabase.

4. Insufficient Error Handling:

Code that lacks proper error handling can lead to bugs and unexpected behavior, especially in larger systems. Without clear error messages, diagnosing and fixing issues can be challenging.

Solution: Include comprehensive error handling and ensure that meaningful error messages are displayed. Log errors in a way that helps developers track and diagnose issues.

5. Hardcoded Values:

Hardcoding values directly into code makes it difficult to adjust settings without modifying the source code. For example, using fixed URLs or credentials directly in the codebase can create security risks and maintenance headaches.

Solution: Use configuration files or environment variables to store values that might change. This improves security and allows for easy updates.

6. Lack of Documentation and Testing:

Documentation and testing are often neglected when time is short. But without proper documentation and test coverage, the code becomes challenging to understand and validate, slowing down development and increasing the risk of bugs.

Solution: Implement test-driven development (TDD) or include time in the development cycle for creating documentation and writing tests. Aim for at least basic test coverage for critical paths and functions.

How to Identify and Manage Technical Debt

Identifying technical debt is crucial if you want to address and improve it. Here are some strategies you can follow:

1. Code Reviews: Regular peer reviews help uncover areas of potential debt. In reviews, team members can flag complex code, lack of tests, or unclear logic, helping address these issues early.

2. Automated Static Code Analysis: Tools like SonarQube, Code Climate, and ESLint (for JavaScript) analyze codebases for code smells, vulnerabilities, and complexity. They’re effective for spotting issues like duplicate code, long functions, and outdated dependencies.

3. Regular Refactoring Sessions: Scheduling dedicated time for refactoring allows the team to improve existing code quality. During these sessions, focus on simplifying code, breaking down large functions, and removing duplicates.

4. Technical Debt Backlog: Track technical debt items in a backlog, prioritizing them alongside feature development. This backlog helps balance feature work with debt reduction and keeps everyone aware of existing debt.

How to Deal with Technical Debt in Code

Here’s a practical example to demonstrate how refactoring can help address technical debt, specifically by removing code duplication.

Example: Removing Duplicate Code

Let’s say we have two functions that send different types of emails but use repeated code:

# Duplicate code example
def send_welcome_email(user):
    send_email(user.email, "Welcome!", "Thanks for joining!")

def send_password_reset_email(user):
    send_email(user.email, "Password Reset", "Click here to reset your password.")

Each function has a similar structure, so refactoring can make the code cleaner and reduce duplication.

# Refactored code
def send_email_to_user(user, subject, message):
    send_email(user.email, subject, message)

# Use the refactored function
send_email_to_user(new_user, "Welcome!", "Thanks for joining!")
send_email_to_user(existing_user, "Password Reset", "Click here to reset your password.")

This example demonstrates how consolidation can reduce repetition and make the code more flexible.

How to Avoid Technical Debt

Proactively managing technical debt helps reduce it over time. Here are ways to avoid accumulating more debt:

• Establish Code Standards: Create and enforce coding standards within the team. Consistent practices reduce complexity, improve readability, and make it easier to identify issues early.

• Refactor Regularly: Rather than waiting for debt to accumulate, make minor improvements during routine work. A “leave it better than you found it” approach ensures code quality remains high over time.

• Encourage Thorough Testing: Strong test coverage identifies potential problems early, reducing the likelihood of code with hidden issues. Testing tools like Jest for JavaScript or PyTest for Python make it easy to add tests to each function and module.

• Plan for Scalability: Think about future needs when designing code. Avoid shortcuts that might restrict scalability and performance as the application grows.

• Limit Workarounds and Temporary Fixes: If temporary fixes are necessary, document them and prioritize removing them as soon as possible. Keeping track of these “quick fixes” ensures they don’t become long-term issues.

How to Measure Code Quality with Code Analysis Tools

Code quality tools can help you find issues that might not be obvious. They can point out things like unused variables, code that’s hard to read, or security problems. Popular tools include ESLint for JavaScript, Pylint for Python, and SonarQube for different programming languages.

Here’s how to set up a simple code check with ESLint:

1. Install ESLint:

    npm install eslint --save-dev
   

2. Initialize ESLint:

    npx eslint --init
   

   This command will prompt you to answer a few configuration questions. You can choose your preferred style guide and select a few options about your environment and file format.

3. Example Code with Issues

   Here’s a sample JavaScript file (example.js) with a few common issues:

    // example.js
   
    var x = 10;   // Unused variable
    let y = 5;
    const z = 'Hello World'
   
    function calculateSum(a, b) {
        return a + b
    }
   
    calculateSum(3, 4);
   
    // Missing semicolon and inconsistent indentation
    if(y > 3){
        console.log("Y is greater than 3")
    }
   

4. Run ESLint:

    npx eslint example.js
   

   After running this command, ESLint will analyze example.js and report any issues based on the configured rules.

5. ESLint Output

   ESLint provides detailed feedback about the issues it detects:

    /path/to/example.js
      1:5  warning  'x' is assigned a value but never used          no-unused-vars
      3:12  error    Missing semicolon                               semi
      6:25  error    Missing semicolon                               semi
      10:1  error    Expected indentation of 4 spaces but found 3    indent
      11:26 error    Missing semicolon                               semi
   
    ✖ 5 problems (4 errors, 1 warning)
   

   Here’s a breakdown of each issue detected by ESLint:

   • Unused Variable: ESLint identifies that x is declared but never used (no-unused-vars rule).

   • Missing Semicolons: ESLint flags lines where semicolons are missing at the end of statements (semi rule).

   • Inconsistent Indentation: ESLint notices that line 10 doesn’t follow consistent indentation (indent rule).

6. Fixing the Code

   Based on ESLint’s feedback, here’s the corrected code:

    // example.js
   
    let y = 5;
    const z = 'Hello World';
   
    function calculateSum(a, b) {
        return a + b;
    }
   
    calculateSum(3, 4);
   
    if (y > 3) {
        console.log("Y is greater than 3");
    }
   

   • We removed the unused variable x.

   • We added missing semicolons.

   • And we adjusted indentation for consistent spacing.

7. Re-run ESLint to Verify Fixes

   After making these changes, you can run npx eslint example.js again to confirm that there are no remaining issues. ESLint will return no output if everything is now clean, confirming that the code adheres to the configured standards.

Additional Tip: Auto-Fixing with ESLint

ESLint can automatically fix some issues for you. To do this, use the --fix flag:

npx eslint example.js --fix

This command will automatically correct issues like indentation, unused variables, and missing semicolons where possible. But it’s important to review the changes to ensure they align with your intended functionality.

Reviewing code, spotting technical debt, and using quality tools help keep the codebase healthy. If you follow these steps, your project will be easier to manage and less likely to break.

AI Tools to Help You Improve Your Code

Using AI tools to restructure code makes improving code quality much faster and easier. These tools help find issues, suggest changes, and can even automate some parts of the refactoring process.

I'll share some AI tools that can help you with code analysis, refactoring, and dependency management, based on my own experience and what I've found useful.

Best AI Tools for Code Restructuring

AI-powered tools are becoming more common, and they offer different ways to boost code quality and simplify refactoring. Here are some I've found helpful:

1. GitHub Copilot

GitHub Copilot is like a coding assistant that provides smart suggestions as you write code. It can complete code snippets, suggest new functions, and help rework existing code to make it more efficient. I’ve found it useful for writing repetitive code blocks or coming up with quick refactorings.

For example, let’s say you need to rewrite a function to be more efficient:

# Original function that checks if a number is prime
def is_prime(n):
    if n < 2:
        return False
    for i in range(2, n):
        if n % i == 0:
            return False
    return True

GitHub Copilot might suggest optimizing the function like this:

# Optimized version suggested by Copilot
def is_prime(n):
    if n < 2:
        return False
    for i in range(2, int(n**0.5) + 1):
        if n % i == 0:
            return False
    return True

The updated version checks factors only up to the square root of n, making it faster for large numbers.

2. QodoGen

QodoGen provides automated suggestions for refactoring and can detect common code issues, like unused variables or large functions doing too many tasks. It also helps split complex code into smaller, more manageable pieces and can explain sections of the code base or the entire codebase which will facilitate the restructuring process.

This tool is capable of doing this because, unlike other AI assistants and general purpose code generation tools, Qodo focuses on code integrity, while generating tests that help you understand how your code behaves. This can help you discover edge cases and suspicious behaviors, and make your code more robust.

For example, if you have a function handling multiple tasks, QodoGen might suggest breaking it down:

# Before refactoring
def handle_user_data(user_data):
    validate_data(user_data)
    save_to_database(user_data)
    send_welcome_email(user_data)

# After refactoring
def handle_user_data(user_data):
    validated_data = validate_data(user_data)
    save_data(validated_data)
    notify_user(validated_data)

Separating the steps makes the code easier to maintain and test.

3. ChatGPT for Code Assistance

ChatGPT can act as a helpful companion when working on code restructuring tasks. Arguably the most used coding assistant, it provides advice on refactoring strategies, explains how to implement changes, or offers example snippets. It’s like having an expert to consult whenever you need guidance or ideas.

For instance, if you’re unsure how to optimize a function or restructure a class, ChatGPT can provide sample code or describe best practices. You can also ask it for help with understanding errors or fixing specific problems in your code.

Just make sure you double-check the code it provides (same goes for all these AI assistants) as it can hallucinate and make mistakes.

Automated Tools for Refactoring and Analysis

AI tools not only assist with writing code but also with analyzing it for quality improvements:

1. SonarQube

SonarQube scans the code to detect bugs, vulnerabilities, and code smells. It generates reports with suggestions on what to fix, helping maintain a healthy codebase.

# Sample SonarQube configuration
sonar.projectKey=my_project
sonar.sources=src
sonar.host.url=http://localhost:9000
sonar.login=my_token

2. ReSharper

This tool integrates with Visual Studio and offers automatic refactoring options. It highlights code that can be simplified or cleaned up and suggests ways to optimize the codebase.

3. DepCheck for Dependency Management

AI tools like DepCheck help find unused dependencies in JavaScript projects, keeping package files clean.

# Running DepCheck to find unused dependencies
npx depcheck

How These Tools Help with Code Restructuring

Using AI tools like GitHub Copilot, QodoGen, and ChatGPT speeds up the process of code restructuring. They provide suggestions that save time and catch issues early, making the code easier to maintain.

Combining these tools with automated analysis tools like SonarQube and ReSharper ensures all aspects of the codebase are covered, from quality checks to refactoring.

These AI tools have other features that facilitate this process: for example, they all have a chat feature that lets you ask questions and get replies about your code and any best practices you should be following. Also, QodoGen allows you to add parts of or the whole codebase for context with the click of a button, along with other features for test generation and pull request reviews.

When restructuring your codebase, having a variety of AI tools can make the process smoother and more efficient. This is AI usage at its best.

Version Control Best Practices for Code Changes

Version control keeps track of code changes, making it easier to manage updates, collaborate with others, and fix issues. Following some best practices can help maintain a clean and organized codebase.

Let’s look at how to manage code changes, track updates, and ensure quality through code reviews.

Using Git Branching Strategies to Manage Code Changes

Git branching helps keep different versions of the code separate, allowing multiple developers to work without affecting the main codebase. Here are some common strategies:

1. Feature Branching

Feature branches allow developers to work on a new feature without changing the main codebase. Each feature gets its own branch, and once complete, it can be merged into the main branch.

# Creating a new feature branch
git checkout -b feature/new-login-page

# Working on the new feature and then committing changes
git add .
git commit -m "Added login page UI"

# Merging the feature branch into the main branch
git checkout main
git merge feature/new-login-page

2. GitFlow Strategy

This strategy involves using multiple branches for different stages of development, such as feature, develop, and release. It separates development work and allows smoother integration and deployment.

• Main Branch: Contains production-ready code.

• Develop Branch: Holds the latest completed work, ready for the next release.

• Feature Branches: Created from the develop branch for new features.

Example:

# Switch to the develop branch
git checkout develop

# Create a new branch for a feature
git checkout -b feature/upgrade-search

# Commit changes and push the feature branch
git add .
git commit -m "Improved search feature"
git push origin feature/upgrade-search

How to Track and Document Code Updates

Documenting code changes helps keep the team informed and makes it easier to understand what was done later. Here are some tips for tracking updates:

1. Writing Clear Commit Messages

Commit messages should explain what was changed and why. A clear message helps others know the purpose of each update.

Example:

# Good commit message
git commit -m "Fixed bug that caused login failure on mobile devices"

# Bad commit message
git commit -m "Fixed bug"

2. Using Tags to Mark Releases

Tags can be used to label important points in the project’s history, such as release versions. This makes it easier to find stable versions of the code.

# Create a tag for version 1.0
git tag v1.0

# Push the tag to the remote repository
git push origin v1.0

3. Creating and Using Changelogs

A changelog lists the changes made in each version, helping developers and users see what was updated or fixed.

Example format for a changelog:

## [1.0.1] - 2024-10-01
### Added
- New login feature

### Fixed
- Resolved search issue on homepage

### Changed
- Updated user dashboard layout

Importance of Code Reviews in Maintaining Code Quality

Code reviews help catch errors, share knowledge, and ensure code stays clean and maintainable. Here are some practices to follow for effective code reviews:

1. Keep Code Changes Small

Smaller changes are easier to review, making it more likely to spot mistakes. Large changes can be broken down into smaller parts.

2. Use Pull Requests for Reviews

Pull requests create a space for discussion around changes. Team members can review the changes, suggest improvements, and approve the updates.

# Push the feature branch to the remote repository
git push origin feature/new-feature

# Create a pull request on GitHub, GitLab, or Bitbucket

3. Provide Constructive Feedback

Code reviews should aim to improve the code without discouraging the developer. Suggest better ways to solve problems and explain the reasoning.

Example comments during a code review:

• "Consider using a list instead of a dictionary for this data structure, as it simplifies the code."

• "This function is doing multiple tasks. It might be clearer if we split it into two separate functions."

Using these practices helps ensure code changes are managed effectively, updates are well-documented, and the quality of the codebase remains high. Regular code reviews and proper branching strategies make it easier for teams to collaborate and keep the project on track.

Conclusion

Reviving and restructuring a codebase can seem like a big task, but taking small, planned steps makes it manageable. Start by checking the current state of the code and making a list of areas that need work. Set clear goals and create a plan to improve the code, step by step.

Using the tools we discussed here can help find issues, suggest changes, and even automate some tasks. Version control practices, such as branching strategies and code reviews, keep changes organized and ensure the quality stays high.

With a solid approach, even the messiest codebase can become clean, efficient, and easier to work with.

Resources

• AI tools have been developed to assist with the Git branching, Pull Request reviews and approval. Check out this article to read more on one of my favorites.

• If you want a step by step tutorial on how to revive and refactor your code, check out this youtube video.

• Check out this freecodecamp article on code restructuring to dive deeper.

Connect with me on LinkedIn, Twitter, and my peronal blog if you found this helpful.

There are several popular ways to create reusable code, and each has its strengths and weaknesses. But they all share a common goal: making it easier for you to avoid reinventing the wheel.

And now, with the improvements in AI, you can take advantage of the available technology to make the development process easier, faster, and more efficient.

In this article, we’ll explore the benefits of code reuse, discuss popular tools for finding reusable code (which, in my opinion, are the best tools to use), and examine how different solutions can help you work more efficiently.

Table of Contents

1. Benefits of Code Reuse

2. Popular Options for Code Reuse

3. Conclusion

The Benefits of Code Reuse

Reusing code brings many advantages that make software development faster and better. Using code that already works helps you avoid doing the same tasks again and again. It also helps you follow the “DRY” principle, and lets you focus on more important parts of your projects.

Time Savings and Faster Development Cycles

A key benefit of reusing code is the amount of time it saves. You no longer need to spend hours rewriting common functions or tasks that have already been solved. This allows you to quickly add these pieces to new projects and spend more time building new features that make your product unique.

Improved Code Quality

Code that has already been tested and proven tends to have fewer mistakes. Using reusable code that has been checked before means you can trust that it will work properly, reducing the chances of bugs and errors in the final product.

Increased Consistency

Reusing code helps create consistency across different projects. The same functions and logic are applied in every project, ensuring everything works in a similar way. This makes the codebase easier to understand and maintain.

Enhanced Collaboration and Knowledge Sharing

When teams share and reuse components, collaboration becomes easier. Team members can work together more efficiently, using familiar code pieces. This also helps spread knowledge across the team, as everyone benefits from understanding and using the same code.

Cost Efficiency

Reusing existing solutions helps reduce costs. Since you spend less time creating new code from scratch, the development process becomes cheaper. This can also lead to faster project completion, which saves money in the long run.

Popular Options for Code Reuse

There are several tools and platforms that developers rely on to find reuseable code. There are widely used options like Google, StackOverflow, and documentation. And on the other hand there are newer AI tools like ChatGPT, Gemini, and Codiumate to mention a few.

Each option has its own strengths and weaknesses, but they all aim to make coding easier and faster by offering pre-existing solutions. Below, we’ll look at some of the most popular options and compare how they help with code reuse.

Google Search

Google is one of the most widely-used tools for finding code snippets and tutorials. Developers often search for specific solutions, reading through blog posts, forums, and official documentation to find what they need.

Advantages:

• Access to a vast amount of information, tutorials, and resources across the web.

• Great for finding niche solutions or specific examples.

• Helpful for discovering documentation and learning new technologies.

Disadvantages:

• Finding the right solution often involves sifting through a lot of content.

• Not all resources are trustworthy or up-to-date.

• It can take longer to find specific, reusable code compared to other platforms.

Google in Action: A quick goggle search will show results comprised of articles and publications related to your question. Going through these articles might help with the exact code you are searching for.

Stack Overflow

Stack Overflow is a popular online forum where developers ask questions and share solutions to programming problems, and it’s been a reliable friend to developers over the years.

It has a massive library of answers and code snippets provided by the developer community. It also now has an AI feature which we’ll discuss in the next section. You get access to different solutions to the same problem provided by developers.

Advantages:

• Large collection of real-world code examples and solutions.

• Answers are often reviewed and voted on by other users, making it easier to find high-quality code.

• Covers a wide range of coding topics and issues.

Disadvantages:

• Requires manual searching, which can be time-consuming.

• Some solutions may be outdated or not relevant to modern development practices.

• It’s not always easy to find code that fits perfectly with your specific project needs.

StackOverflow in Action: You can just open up the site in your browser and search what ever question you need and the highest rated answers will be provided:

Multi-Purpose AI Tools (like ChatGPT and Gemini)

ChatGPT and Gemini are AI tools that help developers by providing code snippets and answering programming questions. They are known for their versatility, supporting a wide range of programming languages and offering quick suggestions on how to solve coding problems.

These tools are growing each day and have truly revolutionised the tech space. They can provide code snippets quickly and with sources.

Advantages:

• Can generate code for various languages and frameworks.

• Provides quick explanations and examples and sources.

• Easy to use for beginners and experienced developers alike.

Disadvantages:

• These AI toools are general-purpose, so they may not always provide the most optimized or accurate code for complex tasks and sometimes struggle with context.

• Since they’re not focused solely on coding, they might miss important details or suggest outdated solutions.

ChatGPT in Action: Let’s see ChatGPT in action with a simple question and the sample code it gives us:

Question: “Can you generate a function to validate form inputs in JavaScript?"

Response: Here’s a reusable JavaScript function to validate form inputs. This function will validate if inputs are not empty, and optionally check for conditions such as valid email addresses, minimum character length, and numeric validation. You can expand it depending on the form requirements.

function validateForm(inputs) {
  let errors = {};

  inputs.forEach(input => {
    const { name, value, type, required, minLength, pattern } = input;

    // Check if the input is required and empty
    if (required && !value) {
      errors[name] = `${name} is required`;
      return;
    }

    // Check for minimum length
    if (minLength && value.length < minLength) {
      errors[name] = `${name} must be at least ${minLength} characters`;
      return;
    }

    // Check for valid email format
    if (type === 'email' && !/\S+@\S+\.\S+/.test(value)) {
      errors[name] = 'Invalid email address';
      return;
    }

    // Check if the input matches the specified pattern (e.g., phone number)
    if (pattern && !new RegExp(pattern).test(value)) {
      errors[name] = `${name} is invalid`;
      return;
    }
  });

  return Object.keys(errors).length ? errors : true;
}

// Example usage:
const inputs = [
  { name: 'username', value: 'john_doe', required: true, minLength: 5 },
  { name: 'email', value: 'john@example', type: 'email', required: true },
  { name: 'password', value: '1234', required: true, minLength: 6 },
];

const validation = validateForm(inputs);
console.log(validation);

This response will save you the trouble of thinking about the logic and still gives space for customization. Just make sure to test the code to make sure it works for your purposes.

Overflow AI (from Stack Overflow)

Overflow AI is a generative AI tool integrated into the Stack Overflow platform where users can ask questions in natural language and receive summarized answers. The answers include proper citations for existing content from Stack Overflow’s massive library.

Overflow AI can provide code snippets and solutions to your problems using the highest rated answers. Just keep in mind that there doesn’t appear to be a free version at the moment, so you may have to pay for the service.

Advantages:

• Access to Stack Overflow’s large collection of real-world code examples and solutions.

• Answers provided are the highest voted answers to your specific question.

• Code provided is usually of the highest quality.

• It can be integrated into your IDE and Slack platform for teams.

Disadvantages:

• Some answers may not suit your specific needs for more complex problems or code.

• It struggles with context as other multi-purpose AI tools do as there is no way to train it specifically for your project.

OverFlow AI in Action: OverFlow AI is currently only available for Stack Overflow for Teams Enterprise. Companies are required to have a subscription for their teams.

Codiumate

Codiumate is an open-source AI-powered coding assistant designed specifically to enhance the software development process. It’s trained solely for the purpose of assisting developers by providing high quality and reusable code, iterative tests, PR reviews, and code completion.

It also has a chat feature which lets you ask questions. But the most impressive feature it has, in my view, is the option to input your entire codebase or chunks of it so that it has context for the code you need from it.

When it comes to reusing code effectively, having a tool specifically designed for that purpose makes all the difference. And it’s great that Codiumate is an open-source tool, too.

Advantages:

• Codiumate is specialized. While other tools like ChatGPT are useful for many tasks, Codiumate’s focus allows it to deliver more precise and relevant recommendations for code reuse.

• It can scan large codebases quickly, identifying opportunities to reuse code, and offering seamless integration options.

• It possesses features like automatic test creation and real-time bug detection.

• It has smart code completion, a coding assistant, and a PR-agent for Pull Request reviews(chrome extension) which makes it a one-stop shop.

Limitations:

• As an open-source tool, Codiumate may require some initial setup or customization to fit your specific development environments. This can take a little extra time upfront, especially for developers who aren't familiar with the tool. But once it's integrated, the time savings and improvements to code quality make it well worth the effort. You can find the link to setup here.

• Since Codiumate is designed specifically for code reuse, it may not be the best tool for handling broader queries outside the realm of coding. If you’re looking for more general advice or help with non-code-related tasks, you might still need to use other tools like ChatGPT. But for focused, efficient code reuse, Codiumate is a great choice.

Codiumate in Action: Let’s see Codiumate in action:

After setting Codiumate up (which takes about 2 minutes), you can access the chat feature where you can add the entire codebase or highlight part of it for context to get more specific results:

Question: “Can you generate a function to validate form inputs in JavaScript?"

Response:

You can expand this function to include more validations as needed, such as checking for special characters in the password, matching passwords, and so on by clicking the “continue this chat” button.

Additional Resources

There are a ton of AI tools and platforms available with similar features and we’re almost spoiled for choice at this point.

Here are a few additional resources about some of my favorite tools I discussed:

• Read more on Codiumate

• Read more on OverflowAI

• How to reuse code with codiumate (Youtube)

• Using AI to improve code quality

Conclusion

Reusing code is a useful practice that makes development faster and easier. It allows developers to focus on creating new features while keeping their projects consistent. Reusing code also helps teams work together better and share knowledge more easily.

There are a ton of AI platforms available like to help with code reuse, and each has its own benefits (and I haven’t covered them all here.

You should take advantage of these AI tools and make your choice based on which tools suits you more. Codiumate and OverflowAI stand out above the rest to me, but the right tool will depend on what you need at that moment.

In the end, AI tools are there to make the development process more streamlined, cheaper, and to ultimately make your life easier as a developer.

In the React ecosystem, performance optimization techniques can significantly enhance the user experience by reducing load times and improving responsiveness.

In this article, we will discuss eight effective techniques for optimizing the performance of your React application.

Table of Contents

1. Why Performance Optimization is Important
2. List visualization
3. Lazy Loading Images
4. Memoization
5. Throttling and Debouncing Events
6. Code Splitting
7. React Fragments
8. Web Workers
9. UseTransition Hook
10. Conclusion

Why Performance Optimization is Important

Optimizing the performance of your React application is crucial for several reasons:

• Better User Experience: A slow-loading or laggy application can lead to a poor user experience, negatively impacting your business. Users expect fast and responsive interactions, and performance optimization helps deliver that.
• Improved SEO: Search engines like Google consider page load times and overall performance when ranking websites. A well-optimized application will rank higher in search results, making it more visible to potential users.
• Reduced Bounce Rates: If your application takes too long to load or respond, users will likely leave and never return. By optimizing performance, you can reduce bounce rates and increase engagement.
• Cost Savings A performant application requires fewer resources (like servers and memory) to handle the same workload. This means lower hosting costs and reduced infrastructure needs.
• Competitive Advantage: A fast and efficient application sets you apart from competitors whose applications may be slower or less optimized. According to research by Portent, a website that loads within one second has a conversion rate five times higher than a site that takes ten seconds to load. Therefore, ensuring your React applications perform well is crucial for retaining users and maintaining a competitive edge.

8 React Performance Optimization Techniques

Below are eight React performance optimization techniques you can use to speed up your applications.

List visualization

List visualization, or windowing, involves rendering only the items currently visible on the screen.

When dealing with a large number of items in a list, rendering all the items at once can lead to slow performance and consume a significant amount of memory. List virtualization tackles this issue by rendering only a subset of the list items currently visible within the view, which conserves resources as the users scroll through the list.

The virtualization technique dynamically replaces rendered items with new ones, keeping the visible portion of the list updated and responsive. It efficiently allows you to render large lists or tabular data by only rendering the visible portion, recycling components as needed, and optimizing scroll performance.

There are different approaches to implementing list visualization in React, and one is using a popular library called React Virtualized.

To install react-virtualized, you can use the following command:

npm install react-virtualized --save

After installing react-virtualized, you can import the required components and styles. Below is an example of how to use the List component to create a virtualized list:

import React from 'react';
import { List } from 'react-virtualized';
import 'react-virtualized/styles.css'; // Import styles

// Your list data
const list = Array(5000).fill().map((_, index) => ({
  id: index,
  name: `Item ${index}`
}));

// Function to render each row
function rowRenderer({ index, key, style }) {
  return (
    <div key={key} style={style}>
      {list[index].name}
    </div>
  );
}

// Main component
function MyVirtualizedList() {
  return (
    <List
      width={300}
      height={300}
      rowCount={list.length}
      rowHeight={20}
      rowRenderer={rowRenderer}
    />
  );
}

export default MyVirtualizedList;

In this example, List is the main component provided by react-virtualized. The rowRenderer function defines how each row should be rendered. The width, height, rowCount, rowHeight, and rowRenderer props are essential for configuring the list's behavior and appearance.

React applications can handle massive amounts of data by leveraging list virtualization without sacrificing performance or user experience.

Lazy Loading Images

Similar to the list virtualization technique, lazy loading images prevents the creation of unnecessary DOM nodes, thereby boosting performance. Lazy loading allows you to defer or delay the loading of images until they are needed or visible to the user instead of loading all the images on page load.

The concept behind lazy loading is to initiate the load of a placeholder or a small low-resolution version of the image, typically a small-sized thumbnail or a blurred placeholder. As the user scrolls or interacts with the page, the actual image is loaded dynamically, replacing the placeholder when the user enters the viewport or when it becomes visible.

Lazy loading in React can be achieved using various libraries and techniques. One of the popular libraries is the react-lazyload.

To install react-lazyload, you can use the following command:

npm install --save react-lazyload

Below is an example of a simple React component that uses react-lazyload to implement lazy loading for images:

import React from 'react';
import LazyLoad from 'react-lazyload';

const MyLazyLoadedImage = ({ src, alt }) => {
  return (
    <LazyLoad height={200} offset={100}>
      {/* The height and offset props control when the image should start loading */}
      <img src={src} alt={alt} />
    </LazyLoad>
  );
};

export default MyLazyLoadedImage;

In this example, MyLazyLoadedImage uses the LazyLoad component from react-lazyload. The height prop specifies the height of the placeholder, and the offset prop determines how far below the viewport the placeholder should start loading.

Another approach is to use the intersection observer API, which is a web API that allows you to detect when an element enters or exists the viewport efficiently. Here's how we can use the Intersection Observer API along with the useEffect hook in React:

import React, { useEffect, useRef } from 'react';

const IntersectionLazyLoad = ({ src, alt }) => {
  const imageRef = useRef();

  useEffect(() => {
    const options = {
      root: null, // Use the viewport as the root
      rootMargin: '0px', // No margin around the root
      threshold: 0.5, // 50% of the image should be visible
    };

    const observer = new IntersectionObserver(handleIntersection, options);

    if (imageRef.current) {
      observer.observe(imageRef.current);
    }

    return () => {
      // Cleanup the observer when the component is unmounted
      observer.disconnect();
    };
  }, []);

  const handleIntersection = (entries) => {
    entries.forEach((entry) => {
      if (entry.isIntersecting) {
        // Load the image when it becomes visible
        imageRef.current.src = src;
        imageRef.current.alt = alt;
      }
    });
  };

  return <img ref={imageRef} style={{ height: '200px' }} alt="Placeholder" />;
};

export default IntersectionLazyLoad;

In this example, IntersectionLazyLoad uses the Intersection Observer API to determine when the image becomes visible in the viewport.

By utilizing this API along with React useEffect hook, you can implement your custom lazy loading solution for images in React.

Memoization

Memoization in React is a technique used to optimize the performance of functional components by caching the results of expensive computations or function calls. It's particularly useful when dealing with computationally intensive or frequently called functions with the same input values, as it helps avoid redundant calculations and improves the overall efficiency of the application.

In React, there are three techniques for memoization: React.memo(), useMemo(), and useCallback(). Let's delve into the details for each:

How to use React.memo()

This higher-order component wraps purely functional components to prevent re-rendering if the received props remain unchanged.

By using React.memo(), the rendering result is cached based on props. If the props haven't changed since the last render, React reuses the previously rendered result instead of redoing the rendering process. This saves time and resources.

Below is an example on how to use the React.memo with a functional component:

import React from 'react';

const Post = ({ signedIn, post }) => {
  console.log('Rendering Post');
  return (
    <div>
      <h2>{post.title}</h2>
      <p>{post.content}</p>
      {signedIn && <button>Edit Post</button>}
    </div>
  );
};

export default React.memo(Post);

In the code above, Post (functional component) depends on the signedIn and post props. By wrapping it with React.memo(), React will only re-render the Post component if either signedIn or post changes.

You can now use the memoized component like any other component in your application:

import React, { useState } from 'react';
import Post from './Post';

const App = () => {
  const [signedIn, setSignedIn] = useState(false);
  const post = { title: 'Hello World', content: 'Welcome to my blog!' };

  return (
    <div>
      <Post signedIn={signedIn} post={post} />
      <button onClick={() => setSignedIn(!signedIn)}>
        Toggle Signed In
      </button>
    </div>
  );
};

export default App;

When you click the Toggle Signed In button, it will toggle the signedIn state. Since Post is wrapped with React.memo(), it will only re-render when the signedIn prop changes, thus saving rendering time and resources

How to use useMemo()

The useMemo() hook optimizes performance by memoizing the result of a function call or an expensive computation. It caches the result and recalculates it only when the input values change. Below is an example on how to use the useMemo hook in functional component:

import React, { useMemo } from 'react';

function App() {
  const [count, setCount] = React.useState(0);
  const [otherState, setOtherState] = React.useState('');

  const expensiveComputation = (num) => {
    let i =  0;
    while (i <  1000000000) i++;
    return num * num;
  };

  const memoizedValue = useMemo(() => expensiveComputation(count), [count]);

  return (
    <div>
      <p>Count: {count}</p>
      <p>Square: {memoizedValue}</p>
      <button onClick={() => setCount(count +  1)}>Increase Count</button>
      <input type="text" onChange={(e) => setOtherState(e.target.value)} />
    </div>
  );
}

export default App;

In the code above, the expensiveComputation function simulates a resource-intensive operation, like squaring a number.

The useMemo hook is utilized to cache the result of this computation. The memoized value, stored in memoizedValue, is only recalculated when the count state changes, as count is specified as a dependency in the useMemo dependency array. Consequently, clicking the Increase Count button increments the count state, triggering a recalculation of the memoized value.

Conversely, changing the otherState via the input field does not prompt a recalculation, as otherState is not included in the useMemo dependency array.

How to use useCallback()

The useCallback() hook in React is used to memoize a function instead of memoizing the function result. It is particularly useful when passing events as props to child components to prevent unnecessary re-renders.

useCallback() memoizes the function, ensuring it remains the same across re-renders as long as the dependencies haven't changed.

This is especially beneficial when passing functions as props to child components, preventing unnecessary re-renders. It is often used with React.memo() to ensure child components do not re-render when unnecessary. Below is an exmple of how to use the useCallback() hook:

import React, { useState, useCallback } from 'react';

const ParentComponent = () => {
  const [count, setCount] = useState(0);

  // Define a function that increments the count state
  const incrementCount = () => {
    setCount(count + 1);
  };

  // Memoize the incrementCount function using useCallback
  const memoizedIncrement = useCallback(incrementCount, [count]);

  return (
    <div>
      <p>Count: {count}</p>
      <ChildComponent onIncrement={memoizedIncrement} />
    </div>
  );
};

const ChildComponent = React.memo(({ onIncrement }) => {
  console.log('Child component rendered');
  return (
    <div>
      <button onClick={onIncrement}>Increment Count</button>
    </div>
  );
});

export default ParentComponent;

In the code above, the ParentComponent is responsible for managing a state variable named count and introduces a function called incrementCount, which handles the incrementation of the count. Utilizing the useCallback hook, the incrementCount function is memoized, guaranteeing its stability across renders unless any of its dependencies, in this case, count, undergo changes.

On the other hand, the ChildComponent is a component nested within the parent. It receives the memoized onIncrement function from the parent as a prop.

To optimize performance and prevent unnecessary re-renders when the props remain constant, the ChildComponent is wrapped with React.memo(). This ensures that the child component will only re-render when its props, specifically the memoized function, experience changes, contributing to a more efficient rendering process.

It's important to note that useCallback should be used sparingly and only for performance-critical parts of your application. Overusing useCallback can actually lead to worse performance due to the overhead of memoization itself. Always measure the performance impact before and after using useCallback to ensure it's having the desired effect.

Throttling and Debouncing Events

Throttling in React is a technique used to limit the number of times a function or an event handler is invoked. It ensures that the function is called at a specified interval, preventing it from being executed too frequently.

Throttling allows you to control the rate at which the function is called by setting up a minimum time interval between each function invocation. If the function is called multiple times within that interval, only the first invocation is executed, and subsequent invocations are ignored until the interval elapses

Now, let's illustrate throttling with a code example. First, without throttling:

// Without throttling, this function will be called every time the event is triggered
function handleResize() {
  console.log('Window resized');
}

window.addEventListener('resize', handleResize);

With throttling, we can limit how often the handleResize function is called:

// Throttling function
function throttle(func, delay) {
  let lastCall =  0;
  return function(...args) {
    const now = new Date().getTime();
    if (now - lastCall < delay) {
      return;
    }
    lastCall = now;
    func(...args);
  };
}

// Throttled event handler
const throttledHandleResize = throttle(handleResize,  200);

window.addEventListener('resize', throttledHandleResize)

In this example, the throttle function wraps handleResize and ensures it's not called more often than every 200 milliseconds. If the resize event fires more frequently than that, the handleResize function will only be executed once every 200 milliseconds, reducing the potential for performance issues caused by rapid, repeated function calls

Debouncing, on the other hand, is also used to limit the number of times a function or an event handler is invoked. It ensures that the function is called only after a certain period of inactivity. Debouncing allows you to postpone the function call until the user has finished typing or a specific time has elapsed since the last event.

For example, imagine you have a search input field and want to trigger a search API request only when the user has finished typing for a certain duration, like 300ms.

With debouncing, the search function will only be invoked after the user stops typing for 300ms. If the user continues typing within that interval, the function call will be delayed until the pause occurs. Without debouncing, the function will be called for every keystroke, potentially leading to excessive function calls and unnecessary computation. let's demonstrate with a code example:

import React, { useState, useEffect } from 'react';

const SearchComponent = () => {
  const [searchTerm, setSearchTerm] = useState('');

  // Function to simulate a search API request
  const searchAPI = (query) => {
    console.log(`Searching for: ${query}`);
    // In a real application, you would make an API request here
  };

  // Debounce function to delay the searchAPI call
  const debounce = (func, delay) => {
    let timeoutId;
    return function (...args) {
      clearTimeout(timeoutId);
      timeoutId = setTimeout(() => {
        func(...args);
      }, delay);
    };
  };

  // Debounced search function
  const debouncedSearch = debounce(searchAPI, 300);

  // useEffect to watch for changes in searchTerm and trigger debouncedSearch
  useEffect(() => {
    debouncedSearch(searchTerm);
  }, [searchTerm, debouncedSearch]);

  // Event handler for the search input
  const handleSearchChange = (event) => {
    setSearchTerm(event.target.value);
  };

  return (
    <div>
      <label htmlFor="search">Search:</label>
      <input
        type="text"
        id="search"
        value={searchTerm}
        onChange={handleSearchChange}
        placeholder="Type to search..."
      />
    </div>
  );
};

export default SearchComponent;

With this setup, the searchAPI function will only be invoked after the user stops typing for 300ms, preventing excessive API requests and improving the overall performance of the search functionality.

Code Splitting

Code splitting in React is a technique used to split a large JavaScript bundle into smaller, manageable chunks. It helps improve performance by loading only the necessary code for a specific part of an application rather than loading the entire bundle upfront.

When you develop a new React application, all your JavaScript code is typically bundled together into a single file. This file contains all the components, libraries, and other code required for your application to function. But as your application grows, the bundle size can become quite large, resulting in slow initial load times for your users.

Code splitting allows you to divide a single bundle into multiple chunks, which can be loaded selectively based on the current needs of your application. Instead of downloading the entire bundle upfront, only the necessary code is fetched and executed when a user visits a particular page or triggers a specific action.

Below is a basic example of code splitting:

// AsyncComponent.js
import React, { lazy, Suspense } from 'react';

const DynamicComponent = lazy(() => import('./DynamicComponent'));

const AsyncComponent = () => (
  <Suspense fallback={<div>Loading...</div>}>
    <DynamicComponent />
  </Suspense>
);

export default AsyncComponent;


// DynamicComponent.js
import React from 'react';

const DynamicComponent = () => (
  <div>
    <p>This is a dynamically loaded component!</p>
  </div>
);

export default DynamicComponent;

In this example, AsyncComponent is a component that uses lazy and Suspense to perform code splitting. The DynamicComponent is dynamically imported using the import() syntax.

When AsyncComponent is rendered, React will load DynamicComponent only when it is needed, reducing the initial bundle size and improving the application's performance. The fallback prop in Suspense specifies what to render while waiting for the dynamic import to resolve, providing a better user experience during the loading process.

React Fragments

React Fragments are a feature introduced in React 16.2 that allows you to group multiple elements together without adding an additional DOM node. This is particularly useful when you need to return multiple elements from a component's render method, but you don't want to introduce unnecessary DOM elements that could affect the layout or styles of your application.

Imagine you are arranging books on a bookshelf. Each book represents a React component, and the bookshelf represents the DOM.

Normally, if you have multiple books, you might want to group them together under a category label (analogous to a DOM element like a <div>). But sometimes you just want to place the books side by side without a label because the label itself doesn't hold any value and only takes up physical space.

React Fragments are like the option to arrange the books without a label, saving space and making the arrangement cleaner.

Here's an example of how to utilize React fragments:

import React from 'react';

function BookShelf() {
  return (
    <>
      <Book title="React for Beginners" />
      <Book title="Mastering Redux" />
      <Book title="JavaScript Essentials" />
    </>
  );
}

function Book({ title }) {
  return <li>{title}</li>;
}

export default BookShelf;

In this example, the BookShelf component returns a list of Book components without wrapping them in a <div> or other unnecessary DOM element. Instead, it uses the <> shorthand syntax for React Fragments.

This results in a cleaner DOM structure, which can improve the performance of your React application by reducing the number of elements that the browser has to process and render. Using fragments can also reduce unnecessary markup and contribute to a cleaner and more efficient render tree.

Web Workers

JavaScript operates as a single-threaded application designed to handle synchronous tasks.

When a web page is being rendered, JavaScript executes multiple tasks, including manipulating DOM elements, managing UI interactions, handling API response data, and enabling CSS animations, all within a single thread. Despite its efficiency in managing these tasks, executing them in a single thread can sometimes lead to performance bottlenecks.

Web Workers serve as a solution to alleviate the burden on the main thread. They allow the execution of scripts in the background on a separate thread, distinct from the main JavaScript thread.

This separation enables the handling of computationally intensive tasks, execution of long-running operations, or management of tasks that might otherwise block the main thread. By doing so, Web Workers contribute to maintaining user interface responsiveness and overall application performance.

To use web worker in React, create a new JavaScript file that will contain the code for the worker thread:

// worker.js
self.onmessage = function(event) {
  var input = event.data;
  var result = performHeavyComputation(input);
  postMessage(result);
};

function performHeavyComputation(input) {
  // Insert your heavy computation logic here
  return input *   2; // Just a placeholder operation
}

In your React component, instantiate the Web Worker and establish a communication channel with it:

import React, { useEffect, useRef } from 'react';

function MyComponent() {
  const workerRef = useRef();

  useEffect(() => {
    // Initialize the worker
    workerRef.current = new Worker('path-to-your-worker-file.js');

    // Handle incoming messages from the worker
    workerRef.current.onmessage = (event) => {
      console.log('Message received from worker:', event.data);
    };

    // Cleanup the worker when the component unmounts
    return () => {
      workerRef.current.terminate();
    };
  }, []);

  // Function to send a message to the worker
  const sendMessageToWorker = (message) => {
    workerRef.current.postMessage(message);
  };

  // Rest of your component
  return (
    // ...
  );
}

In this example, a Web Worker is initialized in the useEffect hook and stored in a ref for future use. Messages from the worker are handled with an onmessage event listener, and the worker is terminated when the component is unmounted to clean up resources. The sendMessageToWorker function demonstrates how to communicate with the worker using postMessage

UseTransition Hook

The useTransition hook in React plays a pivotal role in improving the performance of applications by allowing the marking of state updates as non-blocking transitions. This capability enables React to defer rendering for these updates, preventing UI blocking and enhancing overall responsiveness.

When utilizing useTransition, state updates within the startTransition function are treated as low-priority transitions, susceptible to interruption by higher-priority state updates. So if a high-priority update occurs during a transition, React may prioritize finishing the high-priority update, interrupting the ongoing transition.

This non-blocking transition mechanism is valuable in preventing UI blocking during intensive operations such as data fetching or large-scale updates. By deferring the rendering of components associated with transition updates, React ensures that the user interface remains responsive even in scenarios where the UI might otherwise become unresponsive.

This example demonstrates the use of useTransition in a React component:

import React, { useState, useTransition } from 'react';

function MyComponent() {
  const [state, setState] = useState(initialState);
  const [isPending, startTransition] = useTransition();

  function handleClick() {
    startTransition(() => {
      setState(newState); // This state update is marked as a transition
    });
  }

  return (
    <>
      {/* Your component JSX */}
      <button onClick={handleClick}>Update State</button>
      {isPending && <div>Loading...</div>}
    </>
  );
}

This example showcases how React avoids blocking the UI during transitions triggered by user actions, allowing for interruption if higher-priority state updates are detected.

Note that useTransition is part of the Concurrent Mode API, introduced in React 18 and later versions. As a powerful tool for altering the default behavior of state updates, make sure you use it with care, considering the specific implications of deferring rendering within the context of your application.

Conclusion

Optimizing the performance of a React application involves a combination of strategies, from the fundamental understanding of React's diffing algorithm to leveraging built-in features and third-party tools.

By applying these techniques judiciously, you can create applications that are not only visually appealing but also performant, leading to a better overall user experience.