DEV Community: Vishal Solanki

Core Web Vitals in 2026: fixing LCP, INP and CLS in Next.js

Vishal Solanki — Mon, 26 Oct 2026 19:57:14 +0000

Most slow sites don't have one big problem. They have many small waits, stacked in the wrong order. On one production app I cut the JavaScript bundle by about half, and the biggest gains showed up exactly where they matter most: on low-end phones on ordinary mobile connections.

This is the playbook I use to find and fix those waits in a Next.js site, organised around the three numbers Google actually measures.

The three metrics, and what "good" means

Metric	What it measures	Good	Poor
LCP, Largest Contentful Paint	How long until the biggest thing on screen (usually a hero image or headline) appears	2.5 s or less	over 4 s
INP, Interaction to Next Paint	How long the page takes to visibly respond after a tap, click or key press	200 ms or less	over 500 ms
CLS, Cumulative Layout Shift	How much the layout jumps around while loading	0.1 or less	over 0.25

Google judges each one at the 75th percentile of real visits, separately for mobile and desktop. INP replaced First Input Delay in March 2024, and it's the one most sites now fail, because it covers every interaction, not just the first.

Field data versus lab data

PageSpeed Insights shows two different things on one page:

The top section is field data: real Chrome users over the last 28 days (the Chrome UX Report). This is what Google uses.
The Lighthouse score underneath is lab data: one simulated load on a throttled device. It's great for debugging, varies from run to run, and is not what ranks you.

A Lighthouse 100 with failing field data is still failing. A Lighthouse 70 with green field data is fine.

Measure first

Guessing wastes days. Find out which metric fails, on which pages, before you change anything.

Search Console → Core Web Vitals groups your URLs by problem.
PageSpeed Insights names the LCP element and the worst layout shifts on a given page.
Chrome DevTools → Performance shows the LCP element, each interaction's INP and every layout shift, live, as you use the page.
Your own real-user data, sent to analytics from a small client component:

"use client";
import { useReportWebVitals } from "next/web-vitals";

export function WebVitals() {
  useReportWebVitals((metric) => {
    // Send LCP, INP and CLS to your analytics, e.g. as a GA4 event or to your own endpoint.
    window.dataLayer?.push({ event: "web_vitals", name: metric.name, value: metric.value, rating: metric.rating });
  });
  return null;
}

Fixing LCP

1. Find out what the LCP element is. PageSpeed Insights tells you. The fix is completely different for an image than for a heading.

2. If it's an image, serve it with next/image, tell the browser to fetch it early, and give it accurate sizes:

import Image from "next/image";

<Image
  src="/hero.jpg"
  alt="The living room at dusk"
  width={1600}
  height={900}
  sizes="100vw"
  preload
/>

In Next.js 16, preload replaced the old priority prop. Use it on one image per page, the LCP one. Enable modern formats once in next.config.ts with images: { formats: ["image/avif", "image/webp"] }.

3. If it's text, the font is usually the bottleneck. next/font self-hosts and preloads it. Keep only the weights and subsets you actually use.

4. Don't hide the LCP element behind an intro animation. Text that starts at opacity: 0 and waits for JavaScript to fade it in can't count as painted until it's visible. On this site the hero intro only plays on desktop. Phones get the hero immediately.

5. Check the server response. Statically generated pages served from a CDN are fastest. If time to first byte is slow, everything after it is slow too.

Fixing INP

INP is the delay between a user's input and the next frame the browser paints. It's almost always caused by too much JavaScript running on the main thread at the wrong moment.

1. Ship less JavaScript. Keep components on the server unless they need state, effects or browser APIs. Push "use client" as far down the tree as you can, and check what each route actually ships in your bundle analysis. Less code means less to download, parse and hydrate before the page can respond.

2. Show feedback first, then do the heavy work. Break long tasks up so the browser can paint in between:

// Let the browser paint before continuing a long task.
const yieldToMain = () =>
  globalThis.scheduler?.yield?.() ?? new Promise((resolve) => setTimeout(resolve, 0));

async function onApplyFilters() {
  setLoading(true); // visible feedback, painted right away
  await yieldToMain();
  const results = expensiveFilter(allItems); // the slow part
  setItems(results);
}

3. Mark expensive re-renders as non-urgent. For things like filtering a long list as someone types, wrap the update in startTransition (from useTransition) or render from useDeferredValue, so typing stays responsive while the list catches up.

4. Keep animation off the main thread where you can. Animate transform and opacity rather than top, width or height. Don't read layout (getBoundingClientRect, offsetHeight) inside scroll handlers. Load heavy animation code only for the sections that use it, and honour prefers-reduced-motion.

5. Load third-party scripts late. Tag managers, chat widgets and heatmaps often cause the worst INP. On this site, Google Tag Manager loads on the first interaction, or after a few seconds if there isn't one.

Fixing CLS

1. Reserve space for everything that loads later. Give images width and height. Give embeds, videos and ads a fixed aspect-ratio box.

2. Stop fonts from shifting text. next/font generates a fallback font with matching metrics, which removes most of the jump when the real font arrives. For long body text you can go further with display: "optional": on a slow first visit the fallback simply stays, rather than swapping mid-read. This site uses that for its body font.

3. Never insert content above what's already on screen. Cookie bars, promo banners and "related" blocks should overlay the page or have space reserved for them.

4. Animate with transform. Changing height, margin or top moves everything below. A transform or an opacity fade doesn't.

A 30-minute audit routine

Open Search Console → Core Web Vitals. Note which metric fails, on mobile or desktop, and which URL groups.
Run PageSpeed Insights on one URL from each failing group. Write down the LCP element and the largest layout shifts.
Open the page in Chrome DevTools with CPU throttling at 4× and a "Fast 4G" network. Record a Performance trace while loading the page and tapping the main controls.
In the trace, look for long tasks (over 50 ms) right after load and right after each tap. Note what code they belong to.
Fix the single biggest item, deploy, and wait. Field data trails your changes by up to 28 days, so give each fix time to show.

FAQ

Do Core Web Vitals affect Google rankings?

Yes, as part of Google's page experience signals. Relevance and content quality still matter more, so a fast page with the wrong content won't outrank a slower page that answers the question. Speed is what keeps people on the page once they arrive.

Why does PageSpeed Insights give a different score every time?

The Lighthouse score is a single simulated run, and it varies with server response time and test conditions. Judge progress by the field data at the top of the report and in Search Console.

Do I need a Lighthouse score of 100?

No. Aim to pass all three Core Web Vitals in field data, on mobile, for your important pages. Past that point, your time is usually better spent on content.

Is your site slow on phones, or failing Core Web Vitals in Search Console? I find the cause and fix it.

Originally published on vishalsolanki.online.

Next.js as a backend: Server Actions, Route Handlers or a separate Node.js API?

Vishal Solanki — Mon, 26 Oct 2026 19:56:57 +0000

"Do we need a separate backend?" is one of the first questions on almost every new project I take on. Usually the honest answer is: not yet. Next.js can do most of what a small product's backend needs. But there are clear signs that a separate Node.js API is worth the extra moving parts, and it's much cheaper to spot them early.

This post covers what each server-side feature in Next.js is actually for, where each one falls short, and when to add Express, NestJS or another service next to it.

The four server tools in Next.js

Tool	What it's for	Who calls it
Server Components	Reading data and rendering it to HTML	Your own pages, during render
Server Actions	Mutations from your own UI: forms, buttons	Your own client code, over POST
Route Handlers (`route.ts`)	Public HTTP endpoints that return anything: JSON, files, XML	Anyone: webhooks, mobile apps, partners, other services
Proxy (`proxy.ts`)	Code that runs before a request: redirects, rewrites, headers	Every matching request

In Next.js 16, Middleware was renamed to Proxy. It does the same job; the new name says more clearly what it's for.

Reading data: go straight to the source

In a Server Component, read from the database or the upstream service directly, ideally through one data access layer:

// app/orders/page.tsx
import { getOrdersFor } from "@/lib/data/orders";
import { getSession } from "@/lib/auth";

export default async function Orders() {
  const session = await getSession();
  const orders = await getOrdersFor(session.userId);
  return <OrderList orders={orders} />;
}

A common mistake is calling your own Route Handler from a Server Component, like fetch("/api/orders"). That adds an HTTP round trip to your own server, and for pages pre-rendered at build time it fails outright, because there's no server running during the build. The Next.js docs call this out explicitly.

Mutations from your own UI: Server Actions

For forms and buttons in your app, Server Actions are the simplest option: no endpoint to name, progressive enhancement for forms, and you can revalidate the page in the same round trip.

Two things to know:

They're public POST endpoints. Check the session, ownership and input inside every action. My Server Actions security checklist covers this step by step.
They're queued. Actions from the same client run one after another. That's right for mutations, but it makes them a poor choice for fetching data.

Public endpoints: Route Handlers

Reach for a Route Handler when something other than your own UI needs to talk to your app:

Webhooks: payment providers, CRMs and messaging tools post events to a URL you give them.
Other clients: a mobile app, a partner integration or an internal tool that needs JSON.
OAuth and payment callbacks, where a third party redirects the user back to you.
Non-HTML responses: RSS, CSV exports, generated files.

// app/api/webhooks/payments/route.ts
export async function POST(request: Request) {
  const body = await request.text();
  const signature = request.headers.get("x-signature");
  if (!verifySignature(body, signature)) return new Response("Invalid signature", { status: 401 });

  const event = JSON.parse(body);
  await handlePaymentEvent(event); // idempotent: the provider may retry
  return new Response(null, { status: 204 });
}

Treat every Route Handler like any public API: verify signatures or tokens, validate the payload, rate-limit, and never put a mutation behind GET.

Before the request: Proxy

Proxy is good at cheap, request-level decisions: redirecting old URLs, rewriting a path, adding security headers, sending signed-out users to the login page early. It is not a complete auth layer. The Next.js docs are explicit about this: still verify the session where the data is read or changed, because a misconfigured matcher can let a request through.

When a separate Node.js API is worth it

Next.js on its own starts to strain when one or more of these is true:

Several clients share the same business logic. A web app, a mobile app and partner integrations all need the same rules. A standalone API, documented and versioned, keeps those rules in one place and lets each client move at its own pace.
You have long-running or background work. Queues, scheduled jobs, large imports, PDF generation, anything that runs for minutes. Serverless functions have execution time limits, and request handlers aren't a good home for a job runner anyway.
You need persistent connections. WebSockets and long-lived streams for chat, live tracking or collaborative editing need a server that keeps connections open, or a managed real-time service.
The work is CPU-heavy. Image or video processing and heavy calculations shouldn't slow down page rendering.
Teams or scaling are separate. A dedicated backend team, separate deploys, or very different traffic patterns between the website and the API.
Compliance requires it. Some industries need sensitive processing in a specific network, region or audited service.

If none of these apply, a separate API mostly adds a second deploy, a second set of logs, CORS settings and an extra network hop.

The middle path: Next.js as the backend for your frontend

You don't have to choose all or nothing. A common, solid setup:

Core services (Node.js with Express or NestJS, or anything else) own the business logic, the database and the background jobs.
Next.js is the backend for the frontend. Server Components read from those services. Server Actions call them for mutations. Route Handlers expose only what outside clients need.
The browser never talks to the core services directly. Tokens and service credentials stay on the Next.js server, and the user's session lives in an httpOnly cookie.

This is roughly how I approach sensitive flows on real products: moving operations that used to run in the browser onto the server, behind secure cookies, so tokens and business rules are never exposed to client-side JavaScript.

Keep one data access layer either way

Whichever setup you choose, put data access behind one server-only module and call it from Server Components, Server Actions and Route Handlers alike:

src/
  app/
    orders/page.tsx                 ← reads via lib/data
    orders/actions.ts               ← "use server", thin, calls lib/data
    api/webhooks/payments/route.ts  ← public endpoint, calls lib/data
  lib/
    auth.ts                         ← getSession()
    data/
      orders.ts                     ← import "server-only"; queries + permission checks

If you later move to a separate API, only lib/data changes: it calls the API instead of the database. The pages, actions and handlers stay as they are.

A decision checklist

Question	If yes
Is the only client your Next.js web app?	Start with Next.js alone
Will a mobile app or partners need the same logic soon?	Plan a standalone API, or at least a clean data layer you can move
Any jobs that run longer than a normal request?	Add a worker or queue service
Real-time features (chat, live updates)?	Add a WebSocket server or a managed real-time service
Heavy CPU work?	Separate service
Separate backend team or very different scaling needs?	Separate API
None of the above?	Next.js alone; revisit when one becomes true

FAQ

Can Next.js replace Express?

For many web apps, yes. Server Components, Server Actions and Route Handlers cover reading, writing and public endpoints. Express or NestJS still wins for long-running jobs, persistent connections, multiple clients sharing one versioned API, and teams that want the backend deployed separately.

Should I build REST endpoints for my own frontend?

Usually not. Read data in Server Components and write with Server Actions. Build Route Handlers when a client other than your own UI needs them.

Is a Next.js backend production-ready?

Yes, with the same discipline as any backend: validation, authentication and authorisation on every entry point, rate limits on public ones, logging and monitoring, and keeping the framework patched.

Planning a new product, or untangling an existing one? I design and build both sides, from interface to API. Tell me what you're building.

Originally published on vishalsolanki.online.

How to get your website cited by ChatGPT, Perplexity and Google AI Mode

Vishal Solanki — Mon, 26 Oct 2026 19:56:36 +0000

More people now ask an assistant "who's a good web developer in Noida?" or "how much does a website cost?" instead of scrolling ten blue links. When the answer names three businesses, being one of them is the new page one.

This is often called GEO (generative engine optimisation) or AEO (answer engine optimisation). Most of it is ordinary good SEO, plus a few things that now matter more than they used to.

An honest caveat: none of the AI companies publish exactly how they choose sources. What follows is what their crawler documentation says, plus what keeps showing up in 2026 industry studies. Treat precise percentages you see online, including in vendor reports, as rough signals.

Where each assistant gets its answers

Assistant	Where live answers come from	What that means for you
Google AI Overviews and AI Mode	Google's own index (Googlebot)	Normal Google SEO. The page must be indexed and allowed in snippets.
Gemini app	Google Search	Same as above
ChatGPT search	OpenAI's crawler (`OAI-SearchBot`) plus Bing results	Allow `OAI-SearchBot` and get indexed in Bing
Microsoft Copilot	Bing	Bing Webmaster Tools and Bing Places
Perplexity	Its own crawler (`PerplexityBot`) and other indexes	Fresh, well-structured pages it can reach
Claude	Web search plus Anthropic's crawlers (`Claude-SearchBot`)	Being findable and mentioned on trusted sites

When an assistant answers without searching, it falls back on what it learned in training, which comes from the public web: GitHub, Reddit, Stack Overflow, news sites, popular blogs. Getting into that takes being mentioned in those places over time.

Step 1: Make sure the crawlers can reach you

Start with robots.txt. "Allow everyone" is the simplest setting that keeps you visible:

User-Agent: *
Allow: /

Sitemap: https://www.example.com/sitemap.xml

If you ever add rules, know which bot does what:

Bot	Owner	Used for
`Googlebot`	Google	Search, including AI Overviews and AI Mode
`Google-Extended`	Google	Gemini training and grounding outside Search. Blocking it does not remove you from AI Overviews.
`bingbot`	Microsoft	Bing and Copilot
`OAI-SearchBot`	OpenAI	Showing sites in ChatGPT search
`GPTBot`	OpenAI	Model training
`PerplexityBot`	Perplexity	Perplexity's search index
`ClaudeBot`, `Claude-SearchBot`	Anthropic	Training, and search

Then check the layer robots.txt can't see: your CDN or hosting firewall. Some bot-protection presets block AI crawlers by default. Test it directly:

curl -s -o /dev/null -w "%{http_code}\n" \
  -A "Mozilla/5.0 (compatible; OAI-SearchBot/1.0; +https://openai.com/searchbot)" \
  https://www.example.com/

You want 200. A 403 means something in front of your site is turning the crawler away.

Finally, make sure your important text is in the HTML the server sends. Most AI crawlers don't run JavaScript, so content that only appears after hydration may as well not exist for them. My Next.js SEO checklist has a one-line test for this.

Step 2: Get indexed by Bing, not just Google

Bing is easy to forget, and it feeds Microsoft Copilot and part of ChatGPT search.

Open Bing Webmaster Tools and import your site from Google Search Console. It takes one click and needs no extra verification.
Confirm your sitemap is listed.
Turn on IndexNow so Bing hears about new and updated pages within minutes instead of waiting for a crawl.

Step 3: Write pages an AI can quote

Assistants build answers out of short, self-contained passages. Pages that get cited tend to make that easy:

Answer first. Put the direct answer in the first one or two sentences under each heading, then explain.
Use question headings that match how people ask: "How much does a Next.js website cost in India?"
Be specific. Numbers, ranges, timelines, versions and dates are quotable. Vague reassurance isn't.
Use tables and lists for comparisons and steps.
Show who wrote it and when, with an author line, a publish date and "updated on" when you revise.
Keep it current. Refresh your most important pages at least twice a year.

Here's the difference in practice.

Hard to quote:

Pricing depends on many factors, so every project is different. Get in touch for a quote tailored to your needs.

Easy to quote:

A 5–8 page business website in Next.js typically takes 3–5 weeks. Price depends mainly on design work, CMS needs and integrations; tell me those three and I can give you a range on the first call.

The second version answers a real question in a way an assistant can repeat and attribute.

Step 4: Be one clear identity

An assistant has to be confident that "Your Name, web developer, Your City" is one specific person or business with a specific speciality. Help it:

Use the same one-line description on your site, LinkedIn, GitHub, Google Business Profile and directory listings.
Add sameAs links to your Person or Organization structured data, pointing at those profiles.
Have an About page that states the facts plainly: what you do, where, for how long, for whom.
Pick two or three specialities and repeat them. "The Next.js performance person" is easier for an assistant to recommend than "does everything".

Step 5: Get mentioned where AI looks

This is the step most people skip, and it's the one that moves the needle most. Industry studies in 2026 keep finding that mentions of a brand on other trusted sites line up with AI citations more closely than backlinks alone, and that many cited pages aren't in Google's top ten at all.

Places worth your time:

"Best of" lists and directories: Clutch, GoodFirms and similar sites rank for "best developers in [city]" and get quoted by assistants. Get listed, then get reviews.
Reddit and Quora: genuinely helpful answers in the communities your clients and peers use. Mention your work only when it actually answers the question.
GitHub: useful public repositories with your name and site in the README.
LinkedIn: posts and articles are public and indexed.
Stack Overflow: good answers in your speciality.
Press: journalist-request platforms such as Qwoted and Featured.com. One quote in a real publication outweighs dozens of directory links.
YouTube: short walkthroughs. Transcripts are indexed and quoted.

Step 6: Measure it

There's no single "AI rank" to check, so measure it three ways.

A monthly prompt check. On the first of each month, ask the same questions in ChatGPT (with search on), Perplexity, Gemini, Copilot and Claude, and log the answers:

Prompt	Mentioned?	Linked?	Who's named instead?
Who is [your name], the [role] from [city]?
Recommend a freelance [speciality] developer in [city]
How much does a [service] cost in [country]?

The last column is the useful one. It shows you which sites and lists the assistants trust, so you know where to get yourself listed.

Referral traffic. In Google Analytics, look for sessions from chatgpt.com, perplexity.ai, gemini.google.com, copilot.microsoft.com and claude.ai. ChatGPT adds utm_source=chatgpt.com to many of its links. Group them into one "AI assistants" channel.

Ask your leads. Add "How did you find me?" to your contact form with an "AI assistant" option. Analytics can't see someone who read your name in a chat and typed your URL later; the form can.

Google has also started rolling out an AI Overviews and AI Mode report in Search Console. It's in beta, shows impressions only and isn't available for every site yet.

What about llms.txt?

llms.txt is a proposed Markdown file at the root of your site that summarises it for language models. No major search engine has confirmed using it, and Google has said it doesn't. It takes ten minutes to write, so add one if you like, but don't expect it to change anything on its own.

What doesn't work

Blocks of "AI-friendly" keywords stuffed into a page.
Hundreds of thin, auto-generated pages. Google calls this scaled content abuse.
Text hidden from visitors but aimed at bots.
Fake reviews and fake listings.

All of these risk your normal search rankings too, and assistants increasingly lean on the same quality signals.

FAQ

If I block GPTBot, do I disappear from ChatGPT search?

No. OpenAI uses separate crawlers: GPTBot collects training data, and OAI-SearchBot is what surfaces sites in ChatGPT search. You can block one and allow the other.

Does blocking Google-Extended remove me from AI Overviews?

No. AI Overviews and AI Mode are part of Google Search and use Googlebot. Google-Extended only controls use of your content for Gemini outside Search.

How long does this take?

Being named for your own name can happen within weeks once you're indexed and your profiles agree with each other. Being recommended for competitive local or niche questions usually takes months, because it depends on mentions building up on other sites.

I build sites that are fast, findable in search and easy for AI assistants to quote. Tell me about yours.

Originally published on vishalsolanki.online.

PHP2Shell (CVE-2026-109618 and CVE-2026-109619): is your website affected, and how to fix it

Vishal Solanki — Mon, 26 Oct 2026 19:56:19 +0000

On 21 October 2026, the PHP project released emergency updates for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, now known as PHP2Shell. They let an attacker run commands on a web server with a single crafted request, without an account and without touching your site's own code.

If your website, shop or admin panel runs on PHP, and that includes most WordPress, WooCommerce, Laravel, Drupal and Magento sites, this is worth ten minutes of your time today.

Short version: update the PHP runtime that serves your site to 8.2.35, 8.3.36, 8.4.27 or 8.5.12 (or your vendor's patched package), then restart PHP. Updating WordPress or your plugins does not fix this. The widely shared session.upload_progress.enabled=0 setting is not a complete fix.

Last checked: 24 October 2026. This is a fast-moving story; follow PHP's official advisories for changes.

What PHP2Shell is, in plain words

Both flaws are in the PHP engine itself, not in WordPress, Laravel or any plugin. That's what makes them unusual: a site with perfectly secure code is still exposed, because the attack happens while PHP is still reading the incoming request, before your application runs at all. Security researchers have shown that even a one-line "Hello World" page on a vulnerable PHP version can be attacked.

CVE-2026-109618: when PHP runs out of memory partway through reading a form submission, it leaves half-built data behind, and its cleanup code later treats that data as valid. An attacker who shapes that leftover data can make the cleanup run a command.
CVE-2026-109619: a PHP worker can carry stale data from one request into the next. Researchers confirmed command execution through this route as well, including via the upload-progress feature, which is on by default.

Both are rated 9.2 out of 10 (CVSS v4.0). Researchers also showed that an attacker can read memory from a PHP worker, which can include other visitors' session tokens, passwords and API keys, even without running a command.

They were found by Wiz Research, Calif and OpenAI's Codex Security team. Details leaked a day before the planned disclosure, so PHP released the fixes early.

Is it being exploited?

Exploitation attempts started before the patches shipped. AWS reported attempts as early as 17 October, Cloudflare saw attack traffic and attackers changing their payloads to get past its firewall rules, and watchTowr reported active exploitation attempts against both flaws on 21 October. At the time of writing, public reports hadn't confirmed a specific successful break-in, but several organisations took services offline as a precaution.

Treat this as urgent, not theoretical.

Which sites are affected?

Any server where PHP answers web requests, in any of these setups:

How PHP runs	Affected?	Notes
Apache with `mod_php`	Yes, highest risk	A single request can trigger the attack before any of your code runs
PHP-FPM (Nginx, Apache, most VPS setups)	Yes	Confirmed command execution through the second flaw
php-cgi	Yes
FrankenPHP	Yes
LiteSpeed / LSAPI (common on shared hosting)	Yes
PHP only used on the command line, never serving web requests	Lower risk	Still update, but the web attack path doesn't apply

Affected versions go back to PHP 5.4. These are the first fixed releases:

PHP branch	Vulnerable	First fixed
8.5	below 8.5.12	8.5.12
8.4	below 8.4.27	8.4.27
8.3	below 8.3.36	8.3.36
8.2	below 8.2.35	8.2.35
8.1, 8.0, 7.4	all	No official release. PHP published source patches; check your host or distribution, or upgrade to 8.2+

PHP 8.2 itself reaches end of life on 31 December 2026, so if you're upgrading anyway, go to 8.3 or newer.

Not affected: sites with no PHP at all, such as a static site, or a Next.js or Node.js app. But if your Next.js front end talks to a PHP backend (for example headless WordPress), that backend server is affected.

How to check and fix it, by type of hosting

Shared hosting (cPanel, Hostinger, GoDaddy, Bluehost and similar)

You usually can't patch PHP yourself here. Your host does it.

Find your PHP version. In WordPress, go to Tools → Site Health → Info → Server. In cPanel, look for Select PHP Version or MultiPHP Manager.
Ask your host directly whether their PHP builds include the fixes for CVE-2026-109618 and CVE-2026-109619. Hosts often patch without changing the version number you see, so the version alone doesn't tell you.
If you're on PHP 7.4, 8.0 or 8.1, ask the host to move you to 8.3 or newer, and test your site afterwards. Older plugins sometimes need updating first.

A short message you can send:

Hi, my site [domain] runs on your PHP. Can you confirm the PHP version serving it includes the patches for CVE-2026-109618 and CVE-2026-109619 (PHP2Shell)? If not, when will it be patched?

WordPress, WooCommerce, Laravel and other PHP apps

Keep your app and plugins updated as always, but understand that this isn't an application bug. Updating WordPress, a plugin or Laravel does not update the PHP engine underneath. That comes from your host, your server's package manager or your container image.

VPS or dedicated server (Ubuntu, Debian, RHEL)

Check what actually serves your site. php -v on the command line can be a different build from the one PHP-FPM or Apache uses, so check the web runtime too (your control panel, or a temporary phpinfo() page that you delete straight after).
Update through your package manager and restart every PHP process:

# Debian / Ubuntu (package names vary, e.g. php8.3-fpm)
sudo apt update && sudo apt upgrade
sudo systemctl restart php8.3-fpm   # PHP-FPM
sudo systemctl restart apache2      # if you use mod_php

Distribution packages often carry the fix under an older-looking version number. Confirm the fix is in the package's changelog rather than trusting the version string:

apt changelog php8.3-fpm | grep -m1 CVE-2026-109618

Docker and Kubernetes

Rebuild your images on a patched PHP base image, redeploy, and make sure no old containers are still running. Also check images you didn't build yourself: some third-party apps bundle their own PHP.

If you can't patch today

PHP is clear that only updating fully fixes this. These steps reduce exposure while you arrange the update:

Put a firewall in front of PHP. Cloudflare switched on protective rules for its customers before disclosure, but it also saw attackers changing payloads to get around them, so treat this as a stopgap.
Limit request sizes at your web server or proxy, and keep post_max_size low.
PHP's temporary guidance for CVE-2026-109618 is to enforce memory_limit=-1 at the administrator level, together with request-size limits in front of PHP and a memory limit on the container.
For CVE-2026-109619: session.upload_progress.enabled=0, plus fatal_error_backtraces=0 on PHP 8.5, then restart every worker. This blocks the confirmed paths but not every variant, and does nothing for CVE-2026-109618.
Restrict access to anything that doesn't need to be public, such as admin panels, staging sites and internal tools.

Signs you might have been attacked

If your server ran an unpatched PHP version while exposed to the internet, look back through your logs for:

Unusually large form or multipart POST requests, followed by memory-limit errors or bursts of HTTP 500 responses.
Oddly large PHPSESSID cookies in responses.
PHP workers restarting without explanation.
Shell commands or processes started by your web server user (for example www-data).

If you see any of these, assume secrets in memory may have leaked: rotate database passwords, API keys and admin passwords, invalidate active sessions, and check for new admin users or modified files.

After you patch

The fix adds a new hard memory limit. Hitting it ends the process, so review memory_limit and post_max_size against what your site actually needs, and test uploads and large forms.
PHP has since published an advisory for a related issue, CVE-2026-115560, in the session upload progress feature, which affects even the patched releases. It's due to be fixed in PHP's next regular release. Watch PHP's advisories and update again when that's out.

Running Next.js? Different bug, same month

If your site is built with Next.js, PHP2Shell doesn't apply, but there's a separate security release to install. On 14 October 2026, Next.js fixed:

CVE-2026-96889, a critical remote code execution flaw in the Image Optimization API when SVG files are processed, through the sharp image library on Linux.
A second critical remote code execution flaw in use cache functions that return typed arrays (Next.js 16).
A high-severity denial-of-service issue affecting App Router apps that use Server Actions.

Upgrade to Next.js 16.4.1 or 15.5.28 or later, and make sure your lockfile resolves sharp to 0.35.5 or later. Running npm audit will flag both. More on hardening Server Actions in my security checklist.

FAQ

I updated WordPress and all my plugins. Am I safe?

Not from this. PHP2Shell is in the PHP engine, which your host or server provides. Check the PHP version and ask your host to confirm the patch.

Does a WordPress security plugin protect me?

A plugin runs inside your application, after PHP has already read the request. This attack happens before that point, so an in-app plugin can't block it. A firewall in front of the server can reduce the risk; only patching removes it.

My site is small. Would anyone really target it?

Attacks like this are automated: bots scan the whole internet for vulnerable servers, regardless of size. Security researchers estimate tens of millions of internet-facing PHP servers may be exposed.

How do I know the patch worked?

Confirm the version serving web requests (not just the command line) is a fixed release, or that your distribution's package changelog mentions both CVEs, and that every PHP process has been restarted since the update.

Sources

Not sure what your site runs on, or whether your host has patched it? I can check your setup, apply the fix or move you to a supported version. Get in touch.

Originally published on vishalsolanki.online.

Securing Next.js Server Actions: a 10-point checklist for 2026

Vishal Solanki — Mon, 26 Oct 2026 19:56:01 +0000

Server Actions are the nicest way to write mutations in Next.js. You write an async function, mark it "use server", pass it to a form, and you're done: no API route, no fetch call, no loading-state plumbing.

That convenience hides one fact you need to keep in mind every time: each exported Server Action is a public HTTP endpoint. Anyone can call it with a POST request, from anywhere, with any arguments, whether or not your UI shows the button.

On real products I've moved sensitive operations out of the browser and into server-side code built on Server Actions and secure cookies. This is the checklist I use for every action since.

What Next.js already does for you

It's worth knowing exactly where the built-in protection stops.

Built in	What it means
Encrypted, non-deterministic action IDs	The client calls an action by an ID, not by its name. IDs change between builds.
Dead-code elimination	Actions your app never uses are removed at build time and don't become endpoints.
POST only	Actions can't be triggered by a link, an image tag or a prefetch.
Origin check	When the browser sends an `Origin` header, it must match the host. That blocks most cross-site request forgery.
Body size limit	Request bodies are capped at 1 MB by default.

What it does not do: check who is calling, check whether they're allowed to touch this record, validate the arguments, or limit how often they can call. Those are your job, inside every action.

1. Authenticate inside the action, every time

A login check on the page does not protect the actions defined on that page. The page check runs when the page renders. The action runs later, on its own request, and can be called without ever loading the page.

"use server";

import { getSession } from "@/lib/auth";

export async function updateProfile(formData: FormData) {
  const session = await getSession();
  if (!session) throw new Error("Not signed in");
  // ...
}

2. Authorise the specific record

Being signed in only proves who the caller is. It doesn't prove they own the thing they're changing. If an action takes an ID, check ownership, or someone will change the ID and edit another user's data. This bug has a name, insecure direct object reference (IDOR), and it's one of the most common ones I find.

export async function deleteAddress(addressId: string) {
  const session = await getSession();
  if (!session) throw new Error("Not signed in");

  const address = await db.address.findUnique({ where: { id: addressId } });
  if (!address || address.userId !== session.userId) throw new Error("Not found");

  await db.address.delete({ where: { id: addressId } });
}

Return the same "Not found" whether the record doesn't exist or belongs to someone else, so the action can't be used to probe which IDs exist.

3. Validate every argument

TypeScript types disappear at runtime. A caller can send any shape, any length and any type. Validate on the server with a schema:

import { z } from "zod";

const Profile = z.object({
  name: z.string().trim().min(1).max(100),
  email: z.string().trim().email().max(200),
  city: z.string().trim().max(80).optional(),
});

export async function updateProfile(formData: FormData) {
  const session = await getSession();
  if (!session) throw new Error("Not signed in");

  const parsed = Profile.safeParse(Object.fromEntries(formData));
  if (!parsed.success) return { error: "Please check the highlighted fields." };

  await db.user.update({ where: { id: session.userId }, data: parsed.data });
  return { ok: true };
}

You don't need a library for small forms. A plain function that trims, checks lengths and checks values against a fixed list works just as well, as long as it runs on the server and has a small test.

4. Keep the database and secrets behind a server-only layer

Put database access, API keys and permission checks in one data access layer, and mark it so it can never end up in a client bundle:

// lib/data/addresses.ts
import "server-only";

export async function deleteAddressFor(userId: string, addressId: string) {
  // ownership check + delete, as in step 2
}

Then actions stay thin: read the session, validate the input, call the data layer. Auditing one folder is much easier than auditing every "use server" function in the app.

5. Return only what the client needs

Whatever an action returns is sent to the browser. Don't return the whole database row with password hashes, internal flags or other users' data. Pick the fields the UI needs.

The same goes for errors. Log the real error on the server, and send the user a short, generic message. A stack trace or a raw SQL error tells an attacker far more than it tells your user.

6. Keep sessions in httpOnly, secure cookies

Tokens in localStorage can be read by any script that runs on your page, including a compromised third-party one. An httpOnly cookie can't. Set it from a Server Action or Route Handler, where Next.js can send the Set-Cookie header:

import { cookies } from "next/headers";

export async function signIn(formData: FormData) {
  // ...verify credentials, create a session...
  (await cookies()).set("session", sessionId, {
    httpOnly: true, // not readable from JavaScript
    secure: true, // HTTPS only
    sameSite: "lax", // not sent on most cross-site requests
    path: "/",
    maxAge: 60 * 60 * 24 * 7, // one week
  });
}

Store a random session ID in the cookie and keep the session data on the server, or sign or encrypt the cookie's contents. Never put anything in a cookie you'd be unhappy for the user to edit.

7. Rate-limit, and stop the obvious bots

Sign-in, sign-up, password reset, OTP and contact forms get hammered. Limit how often one client can call them:

import { headers } from "next/headers";
import { rateLimit } from "@/lib/rate-limit"; // backed by Redis or your host's KV store

export async function requestOtp(formData: FormData) {
  const ip = (await headers()).get("x-forwarded-for")?.split(",")[0]?.trim() ?? "unknown";
  if (!(await rateLimit(`otp:${ip}`, { limit: 5, windowSeconds: 600 }))) {
    return { error: "Too many attempts. Try again in a few minutes." };
  }
  // ...
}

The limit has to live in a shared store, not in a variable in memory, because serverless functions don't share memory between instances. Turn on your host's firewall or bot protection as well.

For public forms, a hidden honeypot field catches most simple bots cheaply: real people never fill it in, so any submission that does can be quietly dropped. The contact form on this site works that way.

8. Understand the CSRF protection, and don't break it

Next.js compares the request's Origin header with the host the request arrived at, and rejects actions that don't match. That covers most cross-site request forgery, together with SameSite cookies.

Two ways to break it by accident:

Behind a reverse proxy that forwards its own host instead of the public one, valid requests start failing. Add the public host to experimental.serverActions.allowedOrigins in next.config.ts, rather than disabling anything.
Mutations in GET Route Handlers. A GET request can be triggered by a link or an image tag from any site. Anything that changes data should be a Server Action or a POST, PUT or DELETE handler.

9. Mind the size of what's sent

The 1 MB default body limit is there to stop huge payloads from tying up your server. If you need file uploads, don't just raise the limit: upload straight from the browser to object storage with a short-lived signed URL, then send the resulting file key to a Server Action.

10. Keep Next.js patched

Framework bugs are part of your attack surface too. On 14 October 2026, Next.js fixed two critical remote code execution flaws (one in image optimisation of SVG files, CVE-2026-96889, and one in use cache functions returning typed arrays) and a high-severity denial-of-service issue in App Router apps that use Server Actions. The fixes are in 16.4.1 and 15.5.28. Make sure sharp resolves to 0.35.5 or later as well.

Run npm audit regularly, read the advisories it reports, and update to the patched release. If you also run PHP anywhere, see PHP2Shell: is your website affected.

The audit checklist

Run through this for every file that contains "use server":

#	Question	Fix if not
1	Does the action check the session itself?	Call your auth helper first thing
2	Does it check the caller owns the record?	Compare the owner ID before reading or writing
3	Are all arguments validated on the server?	Schema or validation function
4	Is database and secret access in a `server-only` layer?	Move it, keep the action thin
5	Does it return only what the UI needs?	Pick fields, generic errors
6	Are sessions in `httpOnly`, `secure` cookies?	Move tokens out of `localStorage`
7	Are public or sensitive actions rate-limited?	Shared-store limiter, honeypot, host firewall
8	Does anything mutate data on GET?	Move it to a Server Action or a POST handler
9	Are uploads going through the action body?	Signed direct-to-storage uploads
10	Does `npm audit` report Next.js advisories?	Update to the patched version

FAQ

Are Server Actions secure?

They're as secure as the code inside them. The transport is solid: POST only, an origin check and unguessable IDs. But authentication, authorisation, validation and rate limiting are always your responsibility, just as they would be in an Express route.

Should I use Server Actions or Route Handlers for mutations?

Use Server Actions for mutations that come from your own UI. Use Route Handlers when something outside your app needs to call you, like a webhook, a mobile app or a partner integration. I compare the options in detail in Next.js as a backend: Server Actions, Route Handlers or a separate Node.js API.

Do I need my own CSRF tokens?

Usually not. The built-in origin check plus SameSite cookies covers the common cases. You'd add tokens if you have to support very old browsers, or you've deliberately relaxed cookie or origin settings.

Want a security review of your Next.js app's actions and API routes? Get in touch.

Originally published on vishalsolanki.online.

Next.js SEO checklist for 2026: 12 fixes for the App Router

Vishal Solanki — Mon, 26 Oct 2026 19:55:34 +0000

Most Next.js sites that don't rank aren't missing a secret trick. They're missing basics the framework already gives you: a unique title per page, one canonical URL, a sitemap with honest dates, and content that's actually in the HTML.

This is the checklist I run on every App Router site, including this one. Each item comes with code you can copy.

Short version: set metadataBase, give every page its own title and description, pick one canonical host, generate sitemap.ts and robots.ts, add JSON-LD, keep one real H1 with real text, make sure your content is server-rendered, and set up Search Console and Bing.

1. Set `metadataBase` and a title template

In the root layout, tell Next.js your production URL once. Every relative URL in your metadata (canonicals, Open Graph images) is resolved against it.

// app/layout.tsx
import type { Metadata } from "next";

export const metadata: Metadata = {
  metadataBase: new URL("https://www.example.com"),
  title: { default: "Example — What you do, where you do it", template: "%s — Example" },
  description: "One or two sentences a searcher would actually click on.",
};

With the template, a page that sets title: "Pricing" shows up in search as "Pricing — Example", so your brand is on every result without repeating it by hand.

2. Give every page its own title and description

Duplicate titles are the most common problem I find in audits. For dynamic routes, use generateMetadata:

// app/blog/[slug]/page.tsx
export async function generateMetadata({ params }) {
  const post = await getPost((await params).slug);
  return {
    title: post.title,
    description: post.description,
    alternates: { canonical: `/blog/${post.slug}` },
  };
}

Keep titles around 50–60 characters with the main keyword near the start. Descriptions don't change rankings directly, but they decide whether people click, so write them like a small ad: who it's for, what they get, one proof point.

3. Pick one canonical host and redirect the rest

example.com, www.example.com, your *.vercel.app address and http:// are four copies of the same site as far as Google is concerned. Pick one, use it as metadataBase, add a canonical to every page (as above) and permanently redirect the others.

On Vercel, set the primary domain in the dashboard. For an old deployment address, a host-based redirect in next.config.ts does the job. This one sends an old Vercel URL, and everything it ranked for, to the real domain:

// next.config.ts
async redirects() {
  return [
    {
      source: "/:path*",
      has: [{ type: "host", value: "old-project.vercel.app" }],
      destination: "https://www.example.com/:path*",
      permanent: true,
    },
  ];
}

4. Generate the sitemap, with honest dates

// app/sitemap.ts
import type { MetadataRoute } from "next";

export default async function sitemap(): Promise<MetadataRoute.Sitemap> {
  const posts = await getPosts();
  return [
    { url: "https://www.example.com", lastModified: "2026-10-24" },
    ...posts.map((p) => ({
      url: `https://www.example.com/blog/${p.slug}`,
      lastModified: p.updated ?? p.date,
    })),
  ];
}

Two details matter. Google ignores priority and changeFrequency, so don't spend time tuning them. It does use lastModified, but only while it stays accurate. If every URL shows the build date on every deploy, Google learns to ignore it. Change the date when the content changes, and only then.

5. Add `robots.ts`, and don't block what you want

// app/robots.ts
import type { MetadataRoute } from "next";

export default function robots(): MetadataRoute.Robots {
  return {
    rules: { userAgent: "*", allow: "/" },
    sitemap: "https://www.example.com/sitemap.xml",
  };
}

If you want to show up in ChatGPT search and Perplexity answers, keep their crawlers (OAI-SearchBot, PerplexityBot) allowed. Also check your hosting firewall or CDN: some bot-protection settings block AI crawlers even when robots.txt allows them. I go deeper on this in how to get cited by ChatGPT, Perplexity and Google AI Mode.

6. Describe the page with JSON-LD

Structured data tells search engines what a page is: a person, a business, an article, a product. Render it as a script tag from a server component:

const schema = {
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  headline: post.title,
  datePublished: post.date,
  author: { "@type": "Person", name: "Your Name", url: "https://www.example.com" },
};

return (
  <script
    type="application/ld+json"
    dangerouslySetInnerHTML={{ __html: JSON.stringify(schema).replace(/</g, "\\u003c") }}
  />
);

The .replace escapes < so no string inside your data can close the script tag early. The Next.js docs recommend it. Check the result with Google's Rich Results Test.

For a personal or freelance site, a Person and a ProfessionalService on the homepage plus a BlogPosting on each post covers most of what matters. Only mark up what's visible on the page.

7. One real H1, with real text

Search engines read the text inside your headings, not what they look like. Until recently, Google read my own homepage H1 as "I BUILD 01 IDEA THINGS 02 INTERACTION FOR THE WEB. 03 PRODUCT", because an animated word swap lived inside the heading. Visitors never saw that jumble. Crawlers saw nothing else.

The fix was to draw the decorative words with CSS (::before and ::after with content: attr(data-word)), so the heading's text is simply "I build things for the web." The animation looks exactly the same.

One <h1> per page.
No decorative fragments, counters or icons with text inside it.
Don't hide keyword text from visitors. Google treats hidden text as spam.

8. Make sure the content is in the HTML

Server components render to HTML by default, which is exactly what you want. Problems start when important text only appears after client-side JavaScript runs: inside a useEffect, behind a tab that only mounts on click, or drawn on a canvas. Google can render JavaScript, but later and less reliably, and most AI crawlers don't run it at all.

The quick test: fetch the page the way a crawler does and search for a sentence you care about.

curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1)" https://www.example.com/ | grep -c "a sentence from your page"

If it prints 0, that text isn't in the HTML a crawler receives.

9. Open Graph images per page

Add an opengraph-image.tsx file to a route segment and Next.js generates the image and the meta tags for you:

// app/blog/[slug]/opengraph-image.tsx
import { ImageResponse } from "next/og";

export const size = { width: 1200, height: 630 };
export const contentType = "image/png";

export default async function Image({ params }: { params: Promise<{ slug: string }> }) {
  const post = await getPost((await params).slug);
  return new ImageResponse(
    <div style={{ display: "flex", fontSize: 64, padding: 80 }}>{post.title}</div>,
    size,
  );
}

It won't change your rankings, but links shared on LinkedIn, WhatsApp and X look like something worth opening instead of a grey box.

10. Speed: images, fonts and third-party scripts

Core Web Vitals feed into ranking, and they decide whether visitors stay long enough to read anything.

Images: use next/image with width and height (or fill inside a sized parent) so space is reserved. Add preload to the one image that is your largest paint. In Next.js 16, preload replaced the old priority prop.
Fonts: use next/font. It self-hosts the font and generates a size-matched fallback, which removes most font-swap layout shift.
Third-party scripts: load analytics and tag managers late. On this site, Google Tag Manager loads on the first interaction, or after a few seconds if there isn't one, so it never competes with the first paint.

The full playbook is in Core Web Vitals in 2026: fixing LCP, INP and CLS in Next.js.

11. Real 404s and clean redirects

A missing page must return a 404 status, not a friendly page with a 200. Call notFound() for unknown slugs, and set dynamicParams = false on statically generated routes so unknown URLs 404 automatically.
Add an app/not-found.tsx that matches your design and links to your most useful pages.
Use permanent redirects (308) when a URL has moved for good and temporary ones (307) when it hasn't.
Avoid redirect chains. Each extra hop costs crawl time and a little speed for visitors.

12. Tell Google and Bing the site exists

Verify your domain in Google Search Console with a DNS record (that covers every subdomain and protocol), submit sitemap.xml and request indexing for your key pages.
Import the property into Bing Webmaster Tools. Bing also powers Microsoft Copilot and feeds ChatGPT search, so it's worth the two minutes.
Check the Pages report weekly. "Crawled – currently not indexed" usually means a page is thin, duplicated or not linked from anywhere.

The checklist

#	Check	Where
1	`metadataBase` and a title template	`app/layout.tsx`
2	Unique title and description on every page	`generateMetadata`
3	One canonical host, the rest redirected	`alternates.canonical`, `redirects()`
4	Sitemap with accurate `lastModified`	`app/sitemap.ts`
5	Search and AI crawlers allowed	`app/robots.ts`, CDN or firewall rules
6	JSON-LD, validated	Server component script tag
7	One real H1 per page	Your components
8	Key text in the server HTML	The `curl` test
9	Open Graph image per page	`opengraph-image.tsx`
10	Good Core Web Vitals	PageSpeed Insights, Search Console
11	Real 404s, no redirect chains	`not-found.tsx`, `notFound()`
12	Search Console and Bing set up	Their dashboards

FAQ

Is Next.js good for SEO?

Yes. Server rendering, the Metadata API, file-based sitemaps and robots, and built-in image and font optimisation cover most technical SEO out of the box. What it can't do is choose your keywords, write your content or earn links. That part is still on you.

Do I still need a package like next-seo?

Not with the App Router. The built-in Metadata API covers what next-seo used to do for the Pages Router.

How long until a new Next.js site ranks?

Your own name usually ranks within a few weeks of being indexed. Competitive service keywords take months of useful content and links. Search Console shows you where you stand long before the traffic arrives.

Want this checklist run on your site, with the fixes done for you? That's what I do.

Originally published on vishalsolanki.online.

How map() and Map are Different in JavaScript.

Vishal Solanki — Mon, 26 Aug 2024 18:50:08 +0000

map() and Map are two of the most commonly confused topics in JavaScript because their names are so similar. However, they serve very different purposes. The map() function is used for iterating over arrays, while the Map object is a data structure that helps organize data in a structured way. Let’s dive into these concepts — I’ll do my best to make them easy to understand with clear examples.

`map()`

The map() function is available for Arrays in JavaScript. It Iterate over each element in an array, modifies them, and returns a new array. map() is mainly used to transform the elements of an array based on the function you provide.
For Example:

const numberList = [1,2,3,4,5,6,7,8,9];
const doubledList = numberList?.map((number)=> number*2)
console.log(doubledList);
console.log(numberList);
// output: [2, 4, 6, 8, 10, 12, 14, 16, 18]
// output: [1,2,3,4,5,6,7,8,9]

/* Here map function created a new array where
 every element of the original array is doubled. */

`Map`

Also known as the Map object, it is a built-in JavaScript feature that lets us store key-value pairs, similar to an object. However, here the catch is that in a Map object a key can be of any type — you can even use an entire object as a key. This is different from objects, where keys are usually limited to strings and symbols.

For Example:

// Create a new Map
const myMap = new Map();

// Use different types as keys
const keyString = "a string"; // using string as a key
const keyObject = {name:'i am a key'}; //using a object as a key
const keyFunction = function() {}; // using a function as a key

// Set values in the Map
myMap.set(keyString, "This is a string key");
myMap.set(keyObject, "This is an object key");
myMap.set(keyFunction, "This is a function key");

// Get values from the Map
console.log(myMap.get(keyString)); 
// Output: "This is a string key"

console.log(myMap.get(keyObject));  
// Output: "This is an object key"

console.log(myMap.get(keyFunction)); 
// Output: "This is a function key"

console.log(myMap)   
/* Output: Map(3) {
  'a string' => 'This is a string key',
  { name: 'i am a key' } => 'This is an object key',
  [Function: keyFunction] => 'This is a function key'
}*/

Try running this code in your editor to understand it more clearly, but here’s a summary of what’s happening:

First, we are creating a new Map object like this:

const myMap = new Map();

Then we create some variables and assign them different data types, like a string and an object.
After that, we use the .set() method provided by the Map object to create key-value pairs in the myMap object Like this:

myMap.set(key,value);

We then access those values using the .get() method:

myMap.get(key)

In the final console.log, you can see how the values and keys are stored in a similar way to an object within the myMap object. The key difference is that they can all be of different types.

With this I think we’ve clarified the difference between map() and Map, but it might still be challenging to understand where and how to use the Map object in real-life projects. Let’s look at a real-life example to see how the Map object can be useful and how it can be applied in practical situations.

Example: Shopping Cart

To better understand how the Map object can be useful in real-life projects, let’s explore a practical example in an e-commerce application. We’ll look at how a Map can be used to manage a shopping cart.

In a E-commerce Application , you will need to manage items in a shopping cart. Each item will have a unique ID and some other data like product details and its quantity. Now you will have to manage these items like adding or updating them.

Lets see how we can achieve this with Map Object and why it is more effective then other methods.

// Create a new Map for the shopping cart
const cart = new Map();

// Adding Items to the Cart:
/* When a user adds a product to the cart, 
you can check if the product already exists in the cart. 
If it does, you increase the quantity; 
if not, you add it as a new entry. */

function addToCart(product, quantity = 1) {
       if (cart.has(product.id)) {
           // If product is already in the cart, update the quantity
           let cartItem = cart.get(product.id);
           cartItem.quantity += quantity;
       } else {
           // If product is not in the cart, add it
           cart.set(product.id, {
               name: product.name,
               price: product.price,
               quantity: quantity
           });
       }
   }

const product1 = { id: 101, name: 'Laptop', price: 999 };
const product2 = { id: 102, name: 'Smartphone', price: 499 };
addToCart(product1, 1);
addToCart(product2, 2);
addToCart(product1, 1); // Adding the same product again

//Accessing Items from the Cart:
//You can easily retrieve the details of a product in the cart using its ID.

console.log(cart.get(101)); 
console.log(cart.get(102));
// Output: { name: 'Laptop', price: 999, quantity: 2 }
// Output: { name: 'Smartphone', price: 499, quantity: 1 }

/* This output shows that the `Laptop` has been added twice 
and `smartphone` is added only once, so the quantity is updated to 2 and 1. */

//Removing Items from the Cart:
function removeFromCart(productId) {
       cart.delete(productId);
   }

 removeFromCart(102); // Removes the 'Smartphone' from the cart

Pretty easy right. I hope this example helps you see how Map can be used in a real-life frontend development scenario! Let me know if you have any more questions.

DEV Community: Vishal Solanki

Core Web Vitals in 2026: fixing LCP, INP and CLS in Next.js

The three metrics, and what "good" means

Field data versus lab data

Measure first

Fixing LCP

Fixing INP

Fixing CLS

A 30-minute audit routine

FAQ

Do Core Web Vitals affect Google rankings?

Why does PageSpeed Insights give a different score every time?

Do I need a Lighthouse score of 100?

Next.js as a backend: Server Actions, Route Handlers or a separate Node.js API?

The four server tools in Next.js

Reading data: go straight to the source

Mutations from your own UI: Server Actions

Public endpoints: Route Handlers

Before the request: Proxy

When a separate Node.js API is worth it

The middle path: Next.js as the backend for your frontend

Keep one data access layer either way

A decision checklist

FAQ

Can Next.js replace Express?

Should I build REST endpoints for my own frontend?

Is a Next.js backend production-ready?

How to get your website cited by ChatGPT, Perplexity and Google AI Mode

Where each assistant gets its answers

Step 1: Make sure the crawlers can reach you

Step 2: Get indexed by Bing, not just Google

Step 3: Write pages an AI can quote

Step 4: Be one clear identity

Step 5: Get mentioned where AI looks

Step 6: Measure it

What about llms.txt?

What doesn't work

FAQ

If I block GPTBot, do I disappear from ChatGPT search?

Does blocking Google-Extended remove me from AI Overviews?

How long does this take?

PHP2Shell (CVE-2026-109618 and CVE-2026-109619): is your website affected, and how to fix it

What PHP2Shell is, in plain words

Is it being exploited?

Which sites are affected?

How to check and fix it, by type of hosting

Shared hosting (cPanel, Hostinger, GoDaddy, Bluehost and similar)

WordPress, WooCommerce, Laravel and other PHP apps

VPS or dedicated server (Ubuntu, Debian, RHEL)

Docker and Kubernetes

If you can't patch today

Signs you might have been attacked

After you patch

Running Next.js? Different bug, same month

FAQ

I updated WordPress and all my plugins. Am I safe?

Does a WordPress security plugin protect me?

My site is small. Would anyone really target it?

How do I know the patch worked?

Sources

Securing Next.js Server Actions: a 10-point checklist for 2026

What Next.js already does for you

1. Authenticate inside the action, every time

2. Authorise the specific record

3. Validate every argument

4. Keep the database and secrets behind a server-only layer

5. Return only what the client needs

6. Keep sessions in httpOnly, secure cookies

7. Rate-limit, and stop the obvious bots

8. Understand the CSRF protection, and don't break it

9. Mind the size of what's sent

10. Keep Next.js patched

The audit checklist

FAQ

Are Server Actions secure?

Should I use Server Actions or Route Handlers for mutations?

Do I need my own CSRF tokens?

Next.js SEO checklist for 2026: 12 fixes for the App Router

1. Set metadataBase and a title template

2. Give every page its own title and description

1. Set `metadataBase` and a title template

5. Add `robots.ts`, and don't block what you want

`map()`

`Map`