DEV Community: Kushang Tailor

100+ Job Applications, 2 Months, Zero Offers — Why I Started Riding an Uber Delivery Bike

Kushang Tailor — Fri, 10 Jul 2026 14:18:11 +0000

Never break when your time is tough — just stay calm, stay active, and keep moving.

🎯 The Application That Broke Me

I stopped counting after 100.

I applied to every role that matched my resume, including:

WordPress Developer
Full-Stack Developer
Frontend Developer
Backend Developer
Business Development Executive - Entry Level
Project Manager - Entry Level
Junior React Native Developer
Senior WordPress Developer

Two months. Every relevant listing I could find. Custom cover letters for the ones that mattered. Follow-ups. LinkedIn messages to hiring managers who never wrote back.

Nothing worked out.

Not one offer. Barely a handful of interviews. A few "we'll get back to you" emails that never came back.

So a few weeks ago, I picked up a food and package delivery job on Uber, riding my own Hero Xtreme 125 through morning and evening traffic. I'm writing this because I think a lot of developers reading this are living some version of the same story right now, and nobody in our field likes to say it out loud. I do.

📊 The Market Isn't in Your Head — It's Actually This Bad

If job hunting in 2026 feels harder than it should, that's not you being unskilled or unlucky. The numbers back you up.

The time it takes to get a first job offer jumped from 57 days to 83 days in 2025 — almost a month and a half longer than before. Entry-level hiring at the biggest tech companies dropped 25% between 2023 and 2024, and it still hasn't bounced back. Software job postings are still down more than a third from pre-pandemic levels, and about 7% lower than they were just a year ago.

It's not just a "big tech" problem either. At one well-known Indian engineering institute, fewer than a quarter of a graduating class of 400 students had job offers just months before their course ended. Students there are calling it a "jobpocalypse." Tech layoffs crossed 150,000 in a single year not long ago, and even though the number has come down since, Q1 2026 alone saw close to 80,000 more tech workers lose their jobs.

Here's the part that hurts if you're early in your career: it's not spread evenly. Jobs for young software developers have dropped almost 20% from their late-2022 peak. Senior and specialist roles are actually growing at some companies — Google alone posted 62% more engineering openings in the first half of 2026 than a year earlier — but that growth sits at the top of the experience ladder, not at the entry point most of us are trying to get through.

So if you've sent 50, 80, 100+ applications and heard mostly silence — you're not the exception. You're the current normal.

⚡ What's Actually Causing This

Four things are happening at once, and it helps to name them instead of just feeling them.

1. AI is eating the "easy" tickets first. Company leaders aren't hiding it anymore. Microsoft's CEO has said AI now writes a real chunk of the code in some of their projects. Salesforce's CEO said his company hired zero new engineers in a recent year because AI tools closed that gap. The small, simple tasks that used to be a junior developer's way in — quick bug fixes, boilerplate features, basic integrations — are exactly what AI coding tools now handle well. That doesn't mean developers are useless, but it does remove a lot of the "starter" work companies used to hire freshers for.

2. Companies are still recovering from over-hiring in 2021-2022. A lot of today's layoffs trace back to companies that doubled their engineering teams during the cheap-money pandemic years and are now cutting that back. This has nothing to do with your skills. It's a hiring hangover that started years before you even applied.

3. Global conflicts are adding extra pressure on hiring budgets. With active wars and unrest going on in multiple regions right now, companies are dealing with higher energy costs, shakier supply chains, and more cautious investors. Reports through 2026 show business leaders openly saying this instability is a factor in tighter, slower hiring decisions — money is moving toward "safe" spends like cybersecurity and core AI infrastructure, and away from riskier hiring plans, especially at the entry level.

4. The bar for "entry-level" quietly moved higher. Companies don't just want a degree and a to-do-list app on your GitHub anymore. They want real, shipped work — actual projects, actual collaboration, actual production experience — squeezed into what used to be an entry-level ask. It's a classic trap: you need production experience to get hired, and you need to get hired to gain production experience.

None of this means the field is dying. Developer roles are still expected to grow well into the next decade, and plenty of companies are hiring hard for the right profile. But "the right profile" has shifted, and nobody warns you about that shift until you're three months deep into rejections.

🚀 What Skills Are Actually in Demand Right Now

Going through current hiring data and job posts, the same pattern keeps showing up:

Working with AI tools is no longer a bonus — it's expected. More than half of tech job posts now ask for AI/ML familiarity, and daily use of tools like GitHub Copilot, Cursor, Codex, or Claude Code is fast becoming a basic skill, not an impressive one.
Depth over "I can do everything." The generalist pitch is losing ground to developers with real, provable depth in one lane — cloud, DevOps, ML, security, or a specific ecosystem.
For WordPress specifically, the bar has moved well past "I can install a theme and turn on WooCommerce." Companies now want REST API and headless WordPress experience, React-based block development, clean OOP plugin architecture, solid Git habits, and comfort with the platform's built-in AI tooling. WordPress still runs over 40% of the web, so the demand is real — it's just concentrated on developers who've moved past template installs.
Proof over polish. A strong GitHub history, published articles, or real shipped projects now carry more weight than a clean resume, since most hires still come through referrals and visible work, not cold applications.

⚖️ My Skills vs. What's Actually Demanded

Here's where I had to be honest with myself instead of just angry at the market.

What I bring: I've built and shipped 4 WordPress plugins from scratch, following pure OOP architecture, WordPress VIP coding standards, and proper sanitization/escaping at every layer. I've built enterprise-level websites and web apps using React and Next.js, including headless WordPress setups where the frontend is fully decoupled from the CMS. Performance and security aren't an afterthought for me — I bake them into the build from day one, whether that's caching strategy, query optimization, or basic hardening against common attack vectors. I also actively use AI tools like Codex, Claude, and GitHub Copilot as part of my real workflow — not just to autocomplete a line, but to help scaffold plugins, debug tricky WordPress hooks, and speed up full web app builds. On top of that, I keep a solid, active GitHub history and write technical articles regularly, so my work is documented and public, not sitting in private repos nobody sees.

Where the gap actually is: the problem wasn't that I lacked AI fluency — I use these tools daily and build with them. The real gap was in how I was positioning myself. I was applying into the same volume-heavy, entry-level pool as everyone else, instead of clearly showing recruiters that I already work the way the market now expects: AI-assisted, specialization-focused, with real production and architecture experience behind me. My resume wasn't telling that story loudly enough.

That gap isn't a character flaw. It's a positioning problem, and it's fixable — just not in the two months I had bills to pay in the meantime.

🛵 Why I Joined Uber

I didn't join Uber because I gave up on development. I joined because rent, food, and basic responsibilities don't pause for a job market correction, and two months of zero income while sending applications into a void just isn't sustainable for anyone.

Delivery work on my own bike gave me something a regular part-time job couldn't: income starting almost right away, with zero disruption to my ability to keep applying, interviewing, and writing during the hours I wasn't riding. It's physically harder than sitting at a desk, and yes, some pride had to be swallowed. But a bridge is a bridge, and I'd rather ride one than fall through the gap it's covering.

✅ The Onboarding Process Was Refreshingly Simple

Compared to the black-hole application process I'd just been through, signing up to deliver was almost jarring in how simple it was:

No bond. No lock-in agreement of any kind.
No fixed shift hours — I choose when I ride, and I choose when I stop.
Document verification, a basic orientation, and I was live on the app within days, not weeks.
Full control to log off any time — no penalty for taking a day off for an interview or a writing deadline. That flexibility is exactly why it works as a bridge income source. I run two shifts a day — morning and evening — and build the rest of my day around job hunting and content work.

💰 The Actual Numbers: What My Hero Xtreme 125 Earns Me

Let's do this properly, because vague "I make decent money" claims don't help anyone else weighing this option.

My setup: a Hero Xtreme 125, petrol at roughly ₹100/liter, riding two shifts a day — morning and evening — spending roughly ₹100 in fuel per shift (about ₹200/day, close to 2 liters). I also take one full day off every week to rest, both for me and the bike.

Hours/day	Gross earning	Fuel cost	Net earning/day
6 hrs (standard)	₹700–800	~₹200	₹500–600
8 hrs (extended)	₹1,000+	~₹200–250	₹750–800+
10 hrs (long day)	~₹1,250–1,300	~₹280–300	~₹950–1,000
12 hrs (max stretch)	~₹1,450–1,550	~₹320–350	~₹1,100–1,200

Notice the per-hour rate drops a bit as the hours climb — that's normal, since the best surge-pricing windows (early morning and evening rush) get used up first, and the extra hours are usually slower, lower-paying stretches.

Scaling this out with a weekly off day built in — roughly 26 riding days a month:

Period	6 hrs/day	8 hrs/day	10 hrs/day	12 hrs/day
Monthly (net)	~₹14,300	~₹20,000–20,800	~₹25,350	~₹29,900–31,200
Yearly (net)	~₹1,71,600	~₹2,40,000–2,49,600	~₹3,04,200	~₹3,58,800–3,74,400

A quick mileage sanity check: the Xtreme 125 is rated over 60 kmpl on paper, but real-world, stop-start delivery riding usually brings that down to somewhere between 40 and 50 kmpl. At ₹100/liter, that's roughly ₹2–2.5 per km, which lines up closely with the ₹200/day I actually spend across two shifts covering around 80–100 km total.

Worth being upfront about the parts this table doesn't show: chain lubrication, oil changes, tyre wear, and regular servicing add up over months of daily riding. So the real net is a little lower than the fuel-only numbers suggest once you spread maintenance across the year. I'd set aside roughly ₹500–800 a month for that on top of fuel.

It's not developer-salary money. It's not meant to be. It's meant to keep the lights on while I fix the real problem — landing the next role.

💭 A Few Things I'd Add From My Side

A few honest thoughts that didn't fit neatly into the sections above but felt worth saying:

This isn't a failure story, it's a sequencing story. The job search didn't stop. It just stopped being the only thing paying the bills while it played out.
Writing kept me sane. Publishing articles and working on side projects during this stretch gave me something the job hunt alone couldn't — a sense of moving forward on days when applications went nowhere.
The stigma is the hardest part, not the job itself. Riding a delivery bike after years of writing production code messes with your head more than the physical work does. Worth saying plainly, because I suspect a lot of developers going through something similar feel that shame alone.
Flexibility is underrated as a survival tool. A gig with no bond and no fixed hours meant I never had to choose between an interview and a shift. That mattered more than the pay itself.
The market will turn — but not by waiting. Every report on this points the same way: demand for developers who can specialize and work fluently with AI tools is actually growing, even while generic entry-level postings shrink. The move isn't to give up on development. It's to close the gap between how you're positioned and what's currently getting hired.

🌱 Where This Leaves Me

I'm still applying. I'm still writing. I'm still building and the rest of my plugins work in whatever hours are left after two shifts on the bike. The Uber income isn't the destination — it's what's making sure I don't have to pause the actual goal while the market sorts itself out.

If you're in the same spot right now — sending applications into what feels like a void — you're not behind, and you're not broken. The data shows the market genuinely shifted under everyone's feet at the same time. The only real move is to keep adjusting how you show up, while keeping the lights on however you need to.

If this resonated with you, or you're going through something similar, I'd genuinely like to hear how you're handling it. Drop a comment.

Sources referenced: IEEE Spectrum, Rest of World, The Pragmatic Engineer's 2026 job market deep-dive, Final Round AI's 2026 software engineering market report, Second Talent's 2026 tech job market trends, SQ Magazine's layoff statistics roundup, Forbes' 2026 midyear geopolitical trends tracker, IDC's 2026 IT spending outlook, and current WordPress hiring guides from Wisemonk and Boundev.

Why I Stopped Trusting 'Just Embed the Video' and Built VidDefer Instead

Kushang Tailor — Tue, 07 Jul 2026 13:00:00 +0000

🎬 Why I Built VidDefer — And Why Your Video-Heavy WordPress Site Probably Needs It

Let me start with a confession: for years, I treated video embeds like they were "free." Drop a YouTube iframe into a post, hit publish, move on. No big deal, right?

Wrong. Dead wrong.

The moment I actually opened DevTools on a client site with 15+ embedded YouTube videos on a single landing page, I understood why the Core Web Vitals report looked like a crime scene. Every single embed was silently loading its own player, its own scripts, its own tracking pixels — before the visitor had even scrolled past the hero section.

That frustration is the entire origin story of VidDefer – Deferred Video Embeds, a plugin I just shipped to the WordPress.org repository.

This isn't a "top 10 performance tips" article. It's the story of a real problem, why existing solutions didn't fully cut it, and how VidDefer approaches it differently — plus an honest breakdown of who actually needs this plugin (spoiler: not everyone does).

💡 Where the Idea Actually Came From

I didn't wake up one day and decide "I should build a video lazy-load plugin." It came from a pattern I kept noticing across client projects:

A course platform with a video per lesson page.
A real estate site with property walkthrough videos on every listing.
A recipe blog embedding a YouTube tutorial in nearly every post.
A SaaS marketing site with a demo video stacked on top of three testimonial videos, all on the homepage. Every single one of these sites had the same complaint: "Our PageSpeed score is terrible, and we don't know why — we already optimized images and enabled caching."

The answer was almost always hiding in plain sight: multiple video iframes loading simultaneously on page load, each one pulling in third-party JavaScript before a visitor had shown any intent to actually watch anything.

Existing lazy-load plugins handled images beautifully. Videos were treated like an afterthought — usually just "lazy load the iframe attribute" without actually deferring the heavy scripts behind it. That gap is where VidDefer was born.

🎯 Why This Plugin? What Problem Does It Actually Solve?

Here's the technical reality most WordPress users don't realize: a standard YouTube or Vimeo embed doesn't just load a video. It loads:

The full embedded player iframe
YouTube/Vimeo's own JavaScript player framework
Analytics and tracking scripts bundled by the provider
Preconnect and font requests tied to the player UI All of this fires immediately on page load, whether or not the visitor ever intends to press play. Multiply that by every video on the page, and you've got a serious Largest Contentful Paint (LCP) and Total Blocking Time (TBT) problem — even if your images and fonts are perfectly optimized.

VidDefer solves this with a simple idea: show a lightweight thumbnail placeholder first, and only load the real player when the visitor clicks it (or scrolls to it, if you enable that mode). The visitor sees a legitimate, good-looking video preview instantly. The heavy player only loads on genuine interaction.

The result: pages that used to ship hundreds of kilobytes of unused video-player JavaScript on load now ship a tiny thumbnail image instead — until the user actually asks for the video.

🎥 Built Specifically for Video-Heavy Sites — Not Every Site Needs This

I want to be upfront about something most plugin marketing pages avoid saying: if your site has one video, buried at the bottom of one blog post, you probably don't need VidDefer. The performance gain there is marginal.

This plugin earns its place specifically on:

Course and membership sites with a video embedded on every lesson page
Real estate and travel sites using video walkthroughs across dozens of listings
SaaS and agency landing pages stacking demo videos, testimonial videos, and explainer videos together
Media and review blogs that embed a YouTube video in nearly every article
Portfolio and creative sites showcasing multiple embedded reels or showcases per page If your site falls into "video-heavy" territory — meaning multiple embeds per page, or video embeds across a large percentage of your total pages — that's exactly where VidDefer is designed to shine. On a content-light, video-light site, a general-purpose performance plugin will likely already cover you. VidDefer isn't trying to replace that; it's solving a narrower, deeper problem for sites where video embeds are the actual bottleneck.

🔍 The Real-World Problem, In Numbers

Here's a rough breakdown of what a single unoptimized YouTube embed typically drags along with it on load, compared to a deferred thumbnail placeholder:

A standard embedded iframe pulls in the player framework, related scripts, and thumbnail assets that can easily add several hundred kilobytes and multiple third-party requests — before playback even starts.
A deferred placeholder, by contrast, is just a compressed thumbnail image and a small play-button overlay, with the actual plugin script itself weighing in at under 2KB gzipped. Now multiply that by five, ten, or fifteen embeds on a single page — which is completely normal for course platforms or video-heavy blogs — and you can see why Core Web Vitals scores collapse on these page types specifically, even when everything else on the site is well-optimized.

⚙️ Which Third-Party Scripts Does VidDefer Actually Defer?

This is the part developers usually want to know, so let's get specific. On visitor interaction (click or scroll trigger, depending on your settings), VidDefer defers and then loads:

Video Source	What Gets Deferred	What Loads Only on Interaction
YouTube	The full YouTube iframe player + its embedded scripts	Real YouTube iframe player, pulling thumbnails from YouTube's public thumbnail CDN
Vimeo	The full Vimeo iframe player + its embedded scripts	Real Vimeo iframe player, with thumbnail/title metadata fetched via Vimeo's public oEmbed API and cached locally via WordPress transients
Self-hosted video	The `<video>` element and its associated MP4/WebM/OGV source loading	The actual video file, only once the visitor triggers playback

A few implementation details worth calling out for fellow developers:

Vimeo thumbnail/title data is fetched via a secure server-to-server request and then cached using WordPress transients, so your site only contacts Vimeo once per video, not on every page load.
YouTube thumbnails are pulled straight from YouTube's public thumbnail CDN — no API key required, no quota limits to worry about.
The plugin intercepts embeds using PHP output buffering, so it works regardless of whether the video was added via Gutenberg, Elementor, Divi, WPBakery, or hand-coded HTML.

📊 Without VidDefer vs. With VidDefer

Aspect	Without VidDefer	With VidDefer
Initial page load	Every embedded video loads its full iframe + scripts immediately	Only a lightweight thumbnail image loads initially
Third-party requests on load	Multiple requests per video (player framework, tracking, fonts)	Zero third-party requests until visitor interacts
JavaScript weight	Grows with every additional embedded video	Plugin adds under 2KB gzipped, regardless of video count
LCP / TBT impact	Degrades significantly on video-heavy pages	Minimal impact — thumbnails are lightweight and render fast
Visitor experience	Player controls appear before intent to watch is shown	Clean thumbnail + play button, feels intentional and fast
GDPR / privacy exposure	Third-party cookies/scripts may load before consent	No third-party connection made until visitor clicks play
Accessibility	Depends entirely on the embed provider's markup	WCAG 2.1 keyboard-accessible placeholders built in
Page builder compatibility	N/A	Works with Gutenberg, Elementor, Divi, and WPBakery via output buffering

🥊 Competitors vs. VidDefer

There are a handful of established performance plugins that touch video lazy loading as a side feature. Here's an honest, non-exaggerated comparison of where VidDefer differs:

General-purpose performance/caching plugins (the big all-in-one optimization suites): most of these treat video lazy loading as one small checkbox buried inside a much larger feature set focused on caching, minification, and image optimization. It works, but it's rarely built with video-specific controls like thumbnail quality, play-button styling, or per-video exclusion classes.
Dedicated "lazy load for videos" plugins: a few of these exist, but many are YouTube-only, require an API key, or haven't been updated in a while. Vimeo and self-hosted video support is often missing entirely.
Manually coding it yourself: totally possible if you're comfortable writing custom output-buffering logic and thumbnail-fetching code for three different video sources — but that's a real time investment for something that should be a five-minute plugin activation. VidDefer's niche is being video-first and multi-source from day one: YouTube, Vimeo, and self-hosted videos, all handled the same way, with zero configuration required to get the core benefit, and deeper customization available for anyone who wants it (thumbnail quality, play button style, colors, exclusions, GDPR overlay).

To be fair to the alternatives: if you only need basic image lazy loading and video is a minor part of your site, an all-in-one performance plugin is still a perfectly reasonable choice. VidDefer is for when video is the primary performance bottleneck, not a footnote.

➕ A Few Additional Things Worth Knowing

No API key required — YouTube thumbnails come from the public CDN, Vimeo data comes from the public oEmbed endpoint. Nothing to configure, nothing to break when a key expires.
Exclusion support — Add a no-lazy class to any video, iframe, or wrapping element to skip it entirely, useful for popups and lightboxes that need immediate access to the player.
YouTube Shorts are handled automatically, since they use the same embed format as standard YouTube videos.
Three play button styles and custom colors mean the placeholder doesn't have to look like an obvious plugin bolt-on — it can match your site's branding.
Built-in GDPR/privacy notice overlay is a nice side effect of the deferred-loading architecture: since no third-party connection happens until the click, you get a natural checkpoint to show a consent notice first.

🚀 Try It, Break It, Tell Me About It

If your site has more than a couple of embedded videos per page — especially across course content, listings, or media-heavy posts — I'd genuinely love for you to try VidDefer – Deferred Video Embeds and see what it does to your Core Web Vitals numbers.

It's version 1.0.0, freshly published, so bug reports and feature requests through the support forum are extremely welcome. If you've solved this problem a different way on your own sites, I'd love to hear that too — drop a comment below.

The Abilities API: Teaching Your Site to Say 'Here's What I Can Do'

Kushang Tailor — Mon, 06 Jul 2026 11:48:27 +0000

"The power of WordPress has always lived in its thousands of functions, scattered across core, plugins, and themes — undiscoverable to anything except a developer willing to read the source." — that's roughly the problem the WordPress AI Team set out to fix, and the Abilities API is their answer.

If you've built anything non-trivial on WordPress, you already know the pattern: you need a piece of functionality, so you write a function, hook it somewhere, maybe wrap it in a REST route if something external needs to reach it, then write the validation by hand, then the permission check, then the docs nobody reads. Repeat for every plugin, every site, every developer who comes after you.

WordPress 6.9 ships a new core API that quietly rewires that whole pattern. It's called the Abilities API, and it's the first of four "AI Building Blocks" the WordPress AI Team is rolling into core. But don't let the "AI" framing make you think this is some bolt-on chatbot feature — what it actually gives you is a standardized, typed, permissioned, discoverable way to expose any unit of functionality, whether the consumer is an admin dashboard, a REST client, a WP-CLI command, or yes, an AI agent.

Let's unpack it properly, then build some things with it.

🤔 So What Exactly Is an "Ability"?

Strip away the AI marketing for a second. An Ability is just a self-contained, named unit of functionality with four parts:

A unique name — namespace/ability-name, where the namespace is usually your plugin slug
A schema — what input it expects, what output it returns, both described in JSON Schema
A permission check — who (or what) is allowed to run it
An execution callback — the actual PHP logic

That's it. Once registered, this single definition is simultaneously usable from PHP directly, from WP-CLI, over the REST API, and — because the shape maps cleanly onto the Model Context Protocol (MCP) — from any AI agent that knows how to read a tool registry.

Compare that to how we've always done it: a custom function, a separate register_rest_route() call with its own validation logic, a manual current_user_can() check buried somewhere in the callback, and zero discoverability unless someone reads your code or your (probably outdated) documentation. The Abilities API collapses all of that glue code into one declarative registration.

🧩 Why This Is Landing Now

This isn't a random feature drop. It's the foundation piece of WordPress's broader push to make itself legible to AI systems — the same instinct that's been driving MCP adoption across the dev tooling world. The official Abilities API GitHub repository frames it plainly: a unified registry that's both human-readable and machine-readable, so capabilities are discoverable by developers and by automation tools across different platforms, AI agents included.

Once an ability is registered with show_in_rest enabled, it's automatically reachable at /wp-json/wp-abilities/v1/{namespace}/{ability}. Pair that with the WordPress MCP Adapter plugin, and an AI agent can ask your site "what can you do?" and get back a structured, typed answer instead of a guess. That's a genuinely different posture for WordPress — moving from "AI tools reverse-engineer your REST routes" to "your site publishes its own capability menu."

And the practical upside isn't AI-exclusive at all. Every ability you register also gives you, for free: automatic input/output validation, a colocated permission check, a REST endpoint with the correct HTTP verb already chosen for you, and a single place future-you (or the next developer on the project) can look to understand what a plugin actually does.

🏗️ The Core Building Blocks

Before writing code, it helps to know the vocabulary, since the API leans on five primitives:

Primitive	What it is
Ability	A `WP_Ability` instance — the unit of functionality itself
Category	A grouping bucket abilities are filed under, must be registered first
Registry	The central store; you rarely touch it directly
Schema	JSON Schema for input and output validation
Permission callback	Returns `true`, `false`, or a `WP_Error` — required, no defaults

Two hooks matter most: wp_abilities_api_categories_init (register your categories here, it fires first) and wp_abilities_api_init (register your abilities here, the Abilities API's answer to rest_api_init). Get the order backwards and your abilities silently fail to register — there's no fatal error, they just won't show up.

🛠️ Registering Your First Ability — The Right Way

Let's build something real instead of a toy example. Here's a small, OOP, PHPCS-friendly plugin structure that registers an ability returning a sanitized snapshot of site health data — the kind of thing a monitoring dashboard or an AI agent might genuinely want to query.

File structure first, because structure matters as much as the code:

site-pulse/
├── site-pulse.php
├── includes/
│   ├── class-site-pulse-bootstrap.php
│   └── abilities/
│       └── class-site-pulse-health-ability.php
└── assets/
    └── scss/
        └── admin.scss

site-pulse.php — the entry point, guarded against older WordPress versions:

<?php
/**
 * Plugin Name: Site Pulse
 * Description: Exposes a read-only site health Ability for dashboards and AI agents.
 * Version:     1.0.0
 * Author:      Your Name
 * Text Domain: site-pulse
 *
 * @package SitePulse
 */

defined( 'ABSPATH' ) || exit;

if ( ! class_exists( 'WP_Ability' ) ) {
    add_action(
        'admin_notices',
        static function () {
            wp_admin_notice(
                esc_html__( 'Site Pulse requires WordPress 6.9 or later (Abilities API).', 'site-pulse' ),
                array( 'type' => 'error' )
            );
        }
    );
    return;
}

require_once __DIR__ . '/includes/class-site-pulse-bootstrap.php';

Site_Pulse_Bootstrap::get_instance()->init();

includes/class-site-pulse-bootstrap.php — a singleton that owns the registration hooks, keeping things pure OOP rather than loose functions:

<?php
/**
 * Plugin bootstrap.
 *
 * @package SitePulse
 */

defined( 'ABSPATH' ) || exit;

/**
 * Class Site_Pulse_Bootstrap
 */
final class Site_Pulse_Bootstrap {

    /**
     * Singleton instance.
     *
     * @var Site_Pulse_Bootstrap|null
     */
    private static ?Site_Pulse_Bootstrap $instance = null;

    /**
     * Get singleton instance.
     *
     * @return Site_Pulse_Bootstrap
     */
    public static function get_instance(): Site_Pulse_Bootstrap {
        if ( null === self::$instance ) {
            self::$instance = new self();
        }

        return self::$instance;
    }

    /**
     * Hook everything up.
     */
    public function init(): void {
        add_action( 'wp_abilities_api_categories_init', array( $this, 'register_categories' ) );
        add_action( 'wp_abilities_api_init', array( $this, 'register_abilities' ) );
    }

    /**
     * Register the ability category.
     */
    public function register_categories(): void {
        wp_register_ability_category(
            'site-pulse-monitoring',
            array(
                'label'       => __( 'Site Monitoring', 'site-pulse' ),
                'description' => __( 'Read-only diagnostic abilities for this site.', 'site-pulse' ),
            )
        );
    }

    /**
     * Register the abilities.
     */
    public function register_abilities(): void {
        require_once __DIR__ . '/abilities/class-site-pulse-health-ability.php';
        Site_Pulse_Health_Ability::register();
    }
}

includes/abilities/class-site-pulse-health-ability.php — the ability definition itself, with validation, sanitization, and escaping treated as non-negotiable:

<?php
/**
 * Site health Ability.
 *
 * @package SitePulse
 */

defined( 'ABSPATH' ) || exit;

/**
 * Class Site_Pulse_Health_Ability
 */
final class Site_Pulse_Health_Ability {

    /**
     * Register this ability with the Abilities API registry.
     */
    public static function register(): void {
        wp_register_ability(
            'site-pulse/get-health-snapshot',
            array(
                'label'               => __( 'Get Site Health Snapshot', 'site-pulse' ),
                'description'         => __( 'Returns sanitized counts of posts, plugins, and PHP/WordPress versions. Read-only, no side effects.', 'site-pulse' ),
                'category'            => 'site-pulse-monitoring',
                'output_schema'       => array(
                    'type'       => 'object',
                    'properties' => array(
                        'published_posts' => array( 'type' => 'integer' ),
                        'active_plugins'  => array( 'type' => 'integer' ),
                        'wp_version'      => array( 'type' => 'string' ),
                        'php_version'     => array( 'type' => 'string' ),
                    ),
                ),
                'execute_callback'    => array( __CLASS__, 'execute' ),
                'permission_callback' => static fn() => current_user_can( 'manage_options' ),
                'meta'                => array(
                    'show_in_rest' => true,
                    'annotations'  => array(
                        'readonly'    => true,
                        'destructive' => false,
                        'idempotent'  => true,
                    ),
                ),
            )
        );
    }

    /**
     * Execute callback — builds and sanitizes the snapshot.
     *
     * @return array<string, mixed>
     */
    public static function execute(): array {
        $counts = wp_count_posts( 'post' );

        return array(
            'published_posts' => absint( $counts->publish ?? 0 ),
            'active_plugins'  => count( (array) get_option( 'active_plugins', array() ) ),
            'wp_version'      => sanitize_text_field( get_bloginfo( 'version' ) ),
            'php_version'     => sanitize_text_field( PHP_VERSION ),
        );
    }
}

Notice what's happening here beyond the registration boilerplate: absint() and sanitize_text_field() are doing real work on every value before it leaves the callback, the permission callback checks a specific capability rather than a vague "is logged in" check, and the annotations honestly declare this ability as readonly so the REST layer routes it to GET instead of POST. Lying about annotations doesn't just mis-route HTTP verbs — it tells AI planners an operation is safe when it isn't, or unsafe when it's perfectly harmless.

Calling it is now trivial from anywhere in PHP:

$ability = wp_get_ability( 'site-pulse/get-health-snapshot' );

if ( $ability ) {
    $snapshot = $ability->execute();

    if ( ! is_wp_error( $snapshot ) ) {
        // $snapshot is your validated, sanitized array.
    }
}

That is_wp_error() check isn't optional — WP_Error is truthy in PHP, so a lazy if ( $result ) will happily treat a failed execution as a success. It's a small gotcha that'll bite you exactly once before you remember it forever.

💡 Real-World Plugin & Theme Ideas Worth Building

Here's where it gets genuinely fun. The Abilities API isn't just a cleaner way to write what you already write — it opens doors to functionality that was previously too much glue code to justify. A few ideas worth exploring, ranging from "build this weekend" to "this could be a product":

An accessibility audit ability. Register theme-slug/audit-accessibility that scans the current page's rendered blocks for missing alt text, low-contrast color combinations from your theme.json palette, and heading-order violations, returning a structured report. An AI agent — or your own admin dashboard widget — can call it on every save and flag problems before publish.

A form-to-anything webhook bridge. Instead of hardcoding a Zapier-style integration into your form plugin, expose forms/dispatch-submission as an ability with a destructive: false, idempotent: false annotation. Any MCP-aware automation tool can now trigger it directly, and you've built one integration point instead of fifteen one-off ones for Slack, CRM, email, and whatever your client asks for next quarter.

A content-brief generator for editorial teams. Register an ability that takes a topic and target keyword, pulls related internal posts via WP_Query, and returns a structured outline scaffold (headings, suggested internal links, estimated word count). Editors trigger it from a custom block; an AI writing assistant can call the exact same ability with the exact same guarantees.

A WooCommerce-style order lookup ability for support tooling. Something like shop/get-order-summary, gated behind a manage_woocommerce-equivalent capability, returning sanitized order status, fulfillment stage, and customer-safe details — perfect for an internal support chatbot that needs to answer "where's my order" without anyone hand-rolling a bespoke REST route and praying the auth is airtight.

A multilingual content-sync checker. If you're running WPML or Polylang, an ability that compares a post against its translations and flags stale or missing language versions turns a manual QA chore into something a scheduled agent — or a WP-CLI cron — can run unattended.

A headless "what can this site do" discovery endpoint for client handoff. If you build sites for clients who later bring in their own developers, registering a clean set of abilities for your custom post types and meta fields means the next dev (human or AI-assisted) can discover your site's custom functionality without spelunking through your codebase first.

The common thread: anywhere you'd normally write a custom REST route, an AJAX handler, or a WP-CLI command and worry separately about validation and permissions, an ability gives you all three in one declarative block.

🔐 The Security Checklist That Actually Matters Here

The Abilities API gives you structure, but it doesn't give you security by default — that part is still on you, every time:

Validate first, trust nothing. Input schemas run before your permission callback, which is good, but a schema only checks shape, not business logic. Add your own bounds checking inside the callback.
Sanitize on the way in, escape on the way out. Just because input passed JSON Schema validation doesn't mean it's safe to drop into a database query or render unescaped. Treat ability input exactly like REST input, because functionally, it is.
Scope permission callbacks tightly. Reach for the narrowest WordPress capability that fits, not is_user_logged_in() as a catch-all. A destructive ability gated behind a weak permission check is a vulnerability with a discoverable REST endpoint attached.
Be honest with annotations. readonly, destructive, and idempotent aren't cosmetic — they determine the HTTP verb your endpoint accepts and what automated tools assume is safe to retry.
Never leak secrets through output schemas. The output schema is effectively a public contract once show_in_rest is true. Treat it the same way you'd treat a public API response.

🌐 Where This Goes Next

WordPress 6.9 ships the server-side foundation: registration, the registry, REST exposure. A JavaScript client for browser-side abilities is already developing in parallel via the Gutenberg packages, aimed at things like AI agents driving the block editor itself — selecting blocks, navigating the admin, executing client-side actions the same way server abilities execute PHP. That's expected to mature further as later releases build on this 6.9 foundation.

The bigger shift, though, isn't really technical — it's architectural. WordPress has spent two decades as an ecosystem of brilliant, scattered functionality held together by conventions and tribal knowledge. The Abilities API is the first serious core-level attempt to make that functionality legible — to humans skimming a registry, to automation tools composing workflows, and yes, to AI agents trying to understand what a site can actually do before they touch it.

If you're building plugins or themes today, this is a good moment to start thinking in abilities even before you have an AI use case in mind. The validation, permission, and discoverability benefits pay for themselves regardless of who — or what — ends up calling your code.

Have you registered your first Ability yet, or found a use case I didn't cover here? I'd love to hear what you're building with it — drop a comment below. 👇

Monitoring Tools for React Apps — Which One Do You Actually Need?

Kushang Tailor — Sat, 27 Jun 2026 16:32:55 +0000

Read Time: ~14 minutes | A practical guide to the tools that tell you your app is on fire — before your users do

This article is a bonus companion to the React Mastery Series. You don't need to have read the series — it stands on its own.

📌 What You'll Learn

✅ The three categories of monitoring (and why all three matter)
✅ Honest comparison of 7 popular monitoring tools
✅ Full Sentry + Vercel Analytics setup walkthrough
✅ LogRocket, Datadog, New Relic, Bugsnag, and FullStory — when each makes sense
✅ Stack recommendations by team size
✅ A decision framework that actually helps you choose

🔥 The Problem with Shipping Blind

Here's a scenario that's more common than anyone admits.

You ship a new feature on Friday afternoon. Users start hitting it. Somewhere in that flow — a race condition, a missing null check, a third-party API returning an unexpected shape — something breaks. Users see a white screen. Or worse, a silent failure where data just stops saving.

You find out Monday morning. From an email. Sent by your most patient user.

That's what shipping without monitoring looks like. The good news: it's a solved problem. The honest news: there are seven popular tools that claim to solve it, and picking the wrong one wastes setup time and money.

This article cuts through the noise.

🏗️ The Three Categories of Monitoring

Before comparing tools, it's worth understanding that "monitoring" isn't one thing. It covers three distinct problems:

1. Error Monitoring

The question it answers: What broke, where exactly, and for whom?

When a user hits an unhandled exception, an API call crashes, or a component throws during render — error monitoring captures the full context: stack trace, browser, OS, user identity, and the sequence of events that led to the crash.

Without this, you're debugging from a vague user description. With it, you open a dashboard and see the exact file, line, and call stack.

2. Performance Monitoring

The question it answers: How fast is my app, and where is it slow?

This tracks real user experience — how long pages take to load, how quickly API routes respond, and how your Core Web Vitals (LCP, FID, CLS) look across different devices and regions.

A component that renders in 80ms on your MacBook Pro can take 400ms on a mid-range Android device in India. Performance monitoring shows you the real picture, not the one you see on your dev machine.

3. Session Replay

The question it answers: What was the user actually doing when things went wrong?

This records a video-like reconstruction of the user's session — every click, scroll, input, and network request — leading up to the moment something broke. Instead of reproducing a bug through guesswork, you watch it happen.

🛠️ The 7 Tools — Deep Dive

1. Sentry

Category: Error + Performance + Session Replay
Best for: Most React and Next.js apps
Free tier: 5,000 errors/month — generous enough for many side projects

Sentry is the default choice for good reason. One SDK covers all three monitoring categories, the Next.js integration is first-class, and the setup is handled mostly by a wizard in a single command.

What makes it stand out: The concept of breadcrumbs. Before an error lands in your Sentry dashboard, you see the full sequence of what happened — which API calls fired, which buttons the user clicked, which console messages appeared. It's like having a black box recorder in your app.

npm install @sentry/nextjs
npx @sentry/wizard@latest -i nextjs

This generates three config files automatically. Your .env.local needs one variable:

NEXT_PUBLIC_SENTRY_DSN=https://your-key@sentry.io/project-id

Capturing context with errors:

import * as Sentry from '@sentry/nextjs';

// Add user context once — all future errors are attributed to this user
Sentry.setUser({ id: user.id, email: user.email });

// Capture exceptions with tags for filtering
try {
  await processOrder(orderId);
} catch (error) {
  Sentry.captureException(error, {
    tags: { module: 'checkout', action: 'processOrder' },
    extra: { orderId },
  });
  throw error; // Always re-throw — don't swallow errors silently
}

Session Replay config (from sentry.client.config.ts):

Sentry.init({
  dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
  tracesSampleRate: 0.1,           // Sample 10% of requests for performance
  replaysSessionSampleRate: 0.05,  // Record 5% of all sessions
  replaysOnErrorSampleRate: 1.0,   // Always record when an error occurs
  integrations: [Sentry.replayIntegration()],
});

The replaysOnErrorSampleRate: 1.0 line is the most valuable one. Every single error comes with a replay. You watch the bug happen, you fix it, you close the ticket.

Verdict: Start here. It's not glamorous advice, but it's the right one.

2. Vercel Analytics

Category: Performance Monitoring
Best for: Any app deployed on Vercel
Free tier: ✅ Completely free on hobby plans

If you deploy on Vercel, this is the easiest performance win you'll ever get. No SDK to install, no configuration file, no API key. Enable it in the Vercel dashboard and it starts tracking Core Web Vitals for real users immediately.

npm install @vercel/analytics

// app/layout.tsx — that's literally the entire setup
import { Analytics } from '@vercel/analytics/react';

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <body>
        {children}
        <Analytics />
      </body>
    </html>
  );
}

What you get:

Real user LCP, FID, and CLS scores per page
Breakdown by country, device type, and browser
Score over time (did your last deploy make things faster or slower?)
No sampling — every page view is counted

What you don't get: Error monitoring, session replay, or backend performance data. It's a performance-only tool.

Verdict: Add this in 5 minutes if you're on Vercel. It pairs perfectly with Sentry.

3. LogRocket

Category: Session Replay (primary) + Error Monitoring
Best for: Teams who want the deepest possible understanding of user behaviour
Free tier: 1,000 sessions/month

LogRocket is what you reach for when Sentry's session replay isn't quite enough context. Where Sentry replays the visual session, LogRocket records everything:

Every Redux/Zustand action dispatched
Every network request and response (with payloads)
Every console log, warning, and error
Every DOM mutation
Mouse movements, rage clicks, and dead clicks

The replay experience in LogRocket is closer to watching a movie than a wireframe reconstruction. You see pixel-perfect what the user saw.

npm install logrocket logrocket-react

// app/providers.tsx
'use client';
import LogRocket from 'logrocket';
import setupLogRocketReact from 'logrocket-react';
import { useEffect } from 'react';

export function LogRocketProvider({ children }: { children: React.ReactNode }) {
  useEffect(() => {
    LogRocket.init('your-app-id/project-name');
    setupLogRocketReact(LogRocket);
  }, []);

  return <>{children}</>;
}

// Identify users after login
LogRocket.identify(user.id, {
  name: user.name,
  email: user.email,
  plan: user.subscriptionTier,
});

Where LogRocket earns its keep: You have a bug that users report but you can't reproduce. You pull up their specific session in LogRocket and watch exactly what they did, what the API returned, and what state looked like when it broke. The reproduction step disappears entirely.

Where it's overkill: Small teams, early-stage apps, internal tools. The free tier is limited and the paid plans can add up.

Verdict: Use it when Sentry replay gives you the what but you still need the why.

4. Datadog

Category: Error + Performance + Infrastructure + Logs
Best for: Larger teams, microservices, or when you need one dashboard for everything
Free tier: ❌ No meaningful free tier — starts at ~$15/host/month

Datadog is where monitoring goes when your app grows into infrastructure. It's not primarily a React tool — it monitors servers, databases, containers, queues, and services alongside your frontend. When a slow API route is caused by a slow database query on an overloaded server, Datadog connects all of those dots in one place.

// Instrumenting custom metrics from Next.js API routes
import tracer from 'dd-trace';
tracer.init({ service: 'my-nextjs-app', env: process.env.NODE_ENV });

// app/api/orders/route.ts
export async function POST(request: NextRequest) {
  const span = tracer.startSpan('create.order');

  try {
    const order = await db.orders.create({ data: await request.json() });
    span.finish();
    return NextResponse.json(order, { status: 201 });
  } catch (error) {
    span.setTag('error', true);
    span.finish();
    throw error;
  }
}

The real power is distributed tracing — a single user action that touches three microservices shows up as one connected trace, so you can see which service introduced the latency.

Where Datadog earns its place: You have a dedicated DevOps or platform team. You're running on Kubernetes. You need compliance-grade log retention. Your on-call rotation needs a single pane of glass.

Where it's wrong: Solo developers, early-stage products, anything on Vercel that Vercel Analytics already covers. The learning curve and cost are both real.

Verdict: Right tool, wrong time — until your infrastructure complexity demands it.

5. New Relic

Category: Performance + Error + Infrastructure
Best for: Full-stack performance monitoring across backend and frontend
Free tier: ✅ 100GB/month data ingest — surprisingly generous

New Relic sits between Sentry and Datadog in the complexity spectrum. It does frontend error monitoring, backend performance tracing, and infrastructure monitoring — but with a gentler learning curve than Datadog and a real free tier.

npm install newrelic @newrelic/next

// next.config.js
const withNewRelic = require('@newrelic/next');

module.exports = withNewRelic({
  // your existing Next.js config
});

New Relic's strongest feature is browser agent performance monitoring — it captures real user timing data (not just Lighthouse scores) and shows you where time is actually spent: DNS lookup, connection, first byte, DOM processing, and so on. For apps with complex rendering pipelines, that level of detail is invaluable.

Verdict: Worth evaluating if you need backend performance tracing but find Datadog's pricing hard to justify. The free tier is real and usable.

6. Bugsnag

Category: Error Monitoring
Best for: Teams who want Sentry's core feature set with a simpler interface
Free tier: 7,500 errors/month

Bugsnag does one thing and does it well: error monitoring. No session replay, no performance dashboards, no infrastructure metrics. Just clean, well-organised error tracking with good grouping, filtering, and alerting.

npm install @bugsnag/js @bugsnag/plugin-react

// app/providers.tsx
'use client';
import Bugsnag from '@bugsnag/js';
import BugsnagPluginReact from '@bugsnag/plugin-react';
import { useEffect } from 'react';

Bugsnag.start({
  apiKey: process.env.NEXT_PUBLIC_BUGSNAG_API_KEY!,
  plugins: [new BugsnagPluginReact()],
});

const ErrorBoundary = Bugsnag.getPlugin('react')!.createErrorBoundary(React);

export function BugsnagProvider({ children }: { children: React.ReactNode }) {
  return <ErrorBoundary>{children}</ErrorBoundary>;
}

Where Bugsnag wins: Some developers genuinely find Sentry's dashboard overwhelming — too many features, too many options. Bugsnag is focused and clean. If your team's goal is simply "know when errors happen and who's affected", Bugsnag delivers that without distraction.

Verdict: A genuine Sentry alternative — pick whichever dashboard your team actually opens.

7. FullStory

Category: Session Replay + UX Analytics
Best for: Product and UX teams at scale
Free tier: ❌ Paid only (free trial available)

FullStory is the enterprise session replay tool. Where LogRocket focuses on the developer experience (stack traces, network calls, console logs), FullStory focuses on the product experience — funnel analysis, rage click heatmaps, frustration signals, and quantitative UX insights.

It answers questions like: "What percentage of users who reach step 3 of our checkout abandon it, and what are they doing right before they leave?" That's a product analytics question, not a debugging question. FullStory is built for it.

For most development teams, it's outside the scope of what monitoring means. But for product-focused companies where user behaviour data directly drives roadmap decisions, it's the right tool.

Verdict: Powerful, but it's a product analytics tool more than a developer monitoring tool. Worth knowing about — not where you start.

📊 Side-by-Side Comparison

Tool	Errors	Performance	Session Replay	Free Tier	Best Starting Point
Sentry	✅	✅	✅	✅ Generous	Solo to mid-size teams
Vercel Analytics	❌	✅	❌	✅ Free	Any Vercel deployment
LogRocket	✅	✅	✅ Deep	✅ Limited	Teams debugging UX issues
Datadog	✅	✅	❌	❌ Paid	Multi-service / enterprise
New Relic	✅	✅	❌	✅ 100GB	Full-stack perf focus
Bugsnag	✅	❌	❌	✅ 7.5k errors	Teams wanting simplicity
FullStory	❌	❌	✅ Deep	❌ Trial	Product/UX teams at scale

🗺️ The Decision Framework

Stop reading comparison tables and ask yourself two questions:

Question 1: What's your app's biggest risk right now?

"I need to know when errors happen"
└─→ Sentry or Bugsnag

"I need to know if my app is slow for real users"
└─→ Vercel Analytics + Sentry Performance

"I need to watch what users do when things break"
└─→ Sentry (Session Replay) or LogRocket

"I need to monitor servers, queues, and services together"
└─→ Datadog or New Relic

Question 2: What's your team size?

Solo developer or side project
└─→ Sentry free tier + Vercel Analytics. Done.

Small team (2–10 engineers)
└─→ Sentry + Vercel Analytics. Add LogRocket if UX debugging is painful.

Mid-size team (10–50 engineers)
└─→ Sentry + Vercel Analytics + LogRocket or New Relic depending on backend complexity.

Large team / enterprise
└─→ Datadog (or Datadog + Sentry). Add FullStory if product analytics is a priority.

🏆 Recommended Stacks by Scenario

The Indie Developer / Side Project Stack

Sentry (free tier) — errors, perf, session replay
Vercel Analytics (free) — Core Web Vitals

Total cost: $0
Setup time: ~30 minutes
Coverage: everything you actually need at this stage

The Early-Stage Startup Stack

Sentry Team plan — error monitoring + performance + replay
Vercel Analytics — real user page speed
LogRocket Startup plan — deep session replay for support and UX

Total cost: ~$100–200/month depending on traffic
Setup time: ~2 hours
Coverage: full observability stack

The Scaled Production Stack

Datadog — infrastructure, APM, logs, dashboards, alerting
Sentry — error monitoring (Datadog's error experience isn't as polished)
FullStory — user behaviour analytics for product team

Total cost: varies by scale
Setup time: 1–2 days for full integration
Coverage: enterprise-grade observability

⚡ The 30-Minute Setup (Sentry + Vercel Analytics)

If you want to go from zero monitoring to production-ready coverage right now, here's exactly what to do.

Step 1 — Sentry setup (15 minutes)

npm install @sentry/nextjs
npx @sentry/wizard@latest -i nextjs

Add your DSN to .env.local:

NEXT_PUBLIC_SENTRY_DSN=your-dsn-from-sentry-dashboard

Update sentry.client.config.ts to enable replay:

import * as Sentry from '@sentry/nextjs';

Sentry.init({
  dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
  tracesSampleRate: 0.1,
  replaysSessionSampleRate: 0.05,
  replaysOnErrorSampleRate: 1.0,
  integrations: [Sentry.replayIntegration()],
});

Step 2 — Identify users after login (5 minutes)

// Call this once after successful authentication
import * as Sentry from '@sentry/nextjs';

function onAuthSuccess(user: User) {
  Sentry.setUser({
    id: user.id,
    email: user.email,
  });
}

Step 3 — Vercel Analytics (5 minutes)

npm install @vercel/analytics

// app/layout.tsx
import { Analytics } from '@vercel/analytics/react';

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <body>
        {children}
        <Analytics />
      </body>
    </html>
  );
}

Enable it in the Vercel dashboard: Project → Analytics → Enable.

Step 4 — Set up one alert (5 minutes)

In Sentry: Alerts → Create Alert → Issue Alert → "First seen" trigger → send to your email or Slack. Now you get notified the moment a new error type appears in production.

That's it. You're monitored.

💡 Final Thoughts: Start Simple, Evolve With Your App

The most common monitoring mistake isn't choosing the wrong tool — it's not having any monitoring at all because the choice felt overwhelming.

Pick Sentry. Add Vercel Analytics. Configure one alert. You now know more about what's happening in your production app than 60% of teams shipping React today.

When your scale demands more, you'll know — because Sentry will show you exactly where your current setup is falling short.

Observability isn't a destination. It's a habit you build incrementally.

🔗 Quick Links

Sentry: sentry.io — Start here
Vercel Analytics: vercel.com/analytics — Free with Vercel
LogRocket: logrocket.com — Deep session replay
Datadog: datadoghq.com — Enterprise observability
New Relic: newrelic.com — Full-stack performance
Bugsnag: bugsnag.com — Simple error tracking
FullStory: fullstory.com — UX analytics

💬 What's Your Stack?

Which monitoring tool does your team use in production — and is there one that surprised you with how good (or painful) it was? Drop it in the comments. Real team experiences are always more useful than comparison tables.

This article is a bonus companion to the React Mastery Series — a complete six-part guide from React fundamentals to production engineering. Read the full series here.

React in Production — Ship It, Monitor It, Sleep at Night

Kushang Tailor — Tue, 23 Jun 2026 04:06:58 +0000

Read Time: ~15 minutes | The gap between "it works on my machine" and "it works for everyone, always"

Prerequisites: The full React Mastery Series — Parts 1–5

Part 6: The Finale 🎉

📌 What You'll Learn

By the end of this guide, you'll be able to:

✅ Implement authentication with JWT and session cookies
✅ Add OAuth (Google / GitHub login) in minutes
✅ Set up CI/CD with GitHub Actions to automate your deployments
✅ Catch and monitor errors in production with Sentry
✅ Protect routes and handle auth state globally
✅ Avoid the most common production mistakes React developers make
✅ Understand what "production-ready" actually means in practice

🏁 You Made It Here — Now What?

Five articles in, you can build fast, well-structured, testable React apps. You know your hooks, your state patterns, your performance levers, and your Next.js data flows.

What you haven't done yet is ship something real, break it, watch it burn, and fix it gracefully — that's what production is.

This final part covers the things that separate a side project from a product people actually rely on: authentication that doesn't embarrass you, a CI/CD pipeline that ships your code automatically, and error monitoring that tells you something broke before your users do.

🔐 Authentication: JWT vs Session Cookies

Authentication is one of those topics where developers either overcomplicate it or cut too many corners. Let's get the fundamentals right first.

The Two Main Approaches

JWT (JSON Web Token)
└─ Token stored on client (localStorage or cookie)
└─ Server is stateless — doesn't store sessions
└─ Fast to verify (no DB lookup per request)
└─ Hard to invalidate before expiry (logout is tricky)

Session Cookies
└─ Session ID stored in an httpOnly cookie
└─ Session data lives on the server (DB or cache)
└─ Easy to invalidate (delete the session record)
└─ Requires DB lookup on every authenticated request

Recommendation for most apps: session cookies with httpOnly — more secure by default, easier logout, slightly more setup.

JWT makes sense when: you have multiple services that need to verify auth without sharing a database (microservices, third-party APIs).

Building JWT Auth in Next.js

Install dependencies:

npm install jsonwebtoken bcryptjs
npm install --save-dev @types/jsonwebtoken @types/bcryptjs

Step 1 — User login API route:

// app/api/auth/login/route.ts
import { NextRequest, NextResponse } from 'next/server';
import jwt from 'jsonwebtoken';
import bcrypt from 'bcryptjs';

const JWT_SECRET = process.env.JWT_SECRET!;

export async function POST(request: NextRequest) {
  const { email, password } = await request.json();

  // 1. Find user in database
  const user = await db.users.findUnique({ where: { email } });

  if (!user) {
    return NextResponse.json({ error: 'Invalid credentials' }, { status: 401 });
  }

  // 2. Compare hashed password
  const isValid = await bcrypt.compare(password, user.passwordHash);

  if (!isValid) {
    return NextResponse.json({ error: 'Invalid credentials' }, { status: 401 });
  }

  // 3. Create token (expires in 7 days)
  const token = jwt.sign(
    { userId: user.id, email: user.email },
    JWT_SECRET,
    { expiresIn: '7d' }
  );

  // 4. Set token in httpOnly cookie (safer than localStorage)
  const response = NextResponse.json({ success: true });
  response.cookies.set('auth-token', token, {
    httpOnly: true,   // JS can't read this cookie
    secure: true,     // HTTPS only
    sameSite: 'lax',  // CSRF protection
    maxAge: 60 * 60 * 24 * 7, // 7 days in seconds
  });

  return response;
}

Step 2 — Verify token in middleware:

// middleware.ts (runs before every request)
import { NextRequest, NextResponse } from 'next/server';
import { jwtVerify } from 'jose'; // jose works in Edge runtime; jsonwebtoken doesn't

const JWT_SECRET = new TextEncoder().encode(process.env.JWT_SECRET!);

export async function middleware(request: NextRequest) {
  const token = request.cookies.get('auth-token')?.value;

  // Protect /dashboard and all routes under it
  if (request.nextUrl.pathname.startsWith('/dashboard')) {
    if (!token) {
      return NextResponse.redirect(new URL('/login', request.url));
    }

    try {
      await jwtVerify(token, JWT_SECRET);
      return NextResponse.next(); // Token valid — let the request through
    } catch {
      // Token invalid or expired
      const response = NextResponse.redirect(new URL('/login', request.url));
      response.cookies.delete('auth-token');
      return response;
    }
  }

  return NextResponse.next();
}

export const config = {
  matcher: ['/dashboard/:path*'], // Only run middleware on these routes
};

Step 3 — Logout:

// app/api/auth/logout/route.ts
import { NextResponse } from 'next/server';

export async function POST() {
  const response = NextResponse.json({ success: true });
  response.cookies.delete('auth-token');
  return response;
}

🌐 OAuth: Google & GitHub Login in Minutes

OAuth is the "Sign in with Google" button your users already expect. In Next.js, NextAuth.js (Auth.js v5) handles the entire OAuth dance for you.

npm install next-auth@beta

Configure Auth.js:

// auth.ts (project root)
import NextAuth from 'next-auth';
import Google from 'next-auth/providers/google';
import GitHub from 'next-auth/providers/github';

export const { handlers, auth, signIn, signOut } = NextAuth({
  providers: [
    Google({
      clientId: process.env.GOOGLE_CLIENT_ID!,
      clientSecret: process.env.GOOGLE_CLIENT_SECRET!,
    }),
    GitHub({
      clientId: process.env.GITHUB_CLIENT_ID!,
      clientSecret: process.env.GITHUB_CLIENT_SECRET!,
    }),
  ],
  callbacks: {
    // Add custom data to the session
    session({ session, token }) {
      if (session.user && token.sub) {
        session.user.id = token.sub;
      }
      return session;
    },
  },
});

Mount the handler:

// app/api/auth/[...nextauth]/route.ts
import { handlers } from '@/auth';
export const { GET, POST } = handlers;

Protect a page with the session:

// app/dashboard/page.tsx
import { auth } from '@/auth';
import { redirect } from 'next/navigation';

export default async function DashboardPage() {
  const session = await auth();

  if (!session) {
    redirect('/login'); // Not signed in — send them away
  }

  return (
    <div>
      <h1>Welcome, {session.user?.name}</h1>
      <p>Logged in as {session.user?.email}</p>
    </div>
  );
}

Sign in / sign out buttons:

'use client';
import { signIn, signOut } from 'next-auth/react';

export function AuthButtons() {
  return (
    <div>
      <button onClick={() => signIn('google')}>Sign in with Google</button>
      <button onClick={() => signIn('github')}>Sign in with GitHub</button>
      <button onClick={() => signOut()}>Sign Out</button>
    </div>
  );
}

Add GOOGLE_CLIENT_ID, GOOGLE_CLIENT_SECRET, GITHUB_CLIENT_ID, GITHUB_CLIENT_SECRET, and NEXTAUTH_SECRET to your .env.local, and you have fully working social login.

🔄 CI/CD with GitHub Actions

Shipping manually is how bugs reach production. A CI/CD pipeline runs your tests, checks your build, and deploys automatically — every single time you push code.

What the Pipeline Does

Developer pushes code to GitHub
         ↓
GitHub Actions triggers automatically
         ↓
Install dependencies
         ↓
Run linter (ESLint)
         ↓
Run type checker (TypeScript)
         ↓
Run test suite (Jest)
         ↓
Build the app
         ↓
If all green → Deploy to Vercel ✅
If any red   → Block deploy, notify developer ❌

Full GitHub Actions Workflow

# .github/workflows/ci.yml

name: CI / CD Pipeline

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  quality:
    name: Lint, Type Check & Test
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Run ESLint
        run: npm run lint

      - name: Run TypeScript check
        run: npx tsc --noEmit

      - name: Run tests
        run: npm test -- --coverage --watchAll=false
        env:
          CI: true

      - name: Build app
        run: npm run build
        env:
          NEXT_PUBLIC_API_URL: ${{ secrets.NEXT_PUBLIC_API_URL }}

  deploy:
    name: Deploy to Vercel
    needs: quality          # Only runs if the quality job passes
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main' # Only deploy from main branch

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Deploy to Vercel
        uses: amondnet/vercel-action@v25
        with:
          vercel-token: ${{ secrets.VERCEL_TOKEN }}
          vercel-org-id: ${{ secrets.VERCEL_ORG_ID }}
          vercel-project-id: ${{ secrets.VERCEL_PROJECT_ID }}
          vercel-args: '--prod'

Add VERCEL_TOKEN, VERCEL_ORG_ID, and VERCEL_PROJECT_ID to your GitHub repository's Secrets (Settings → Secrets and variables → Actions). Get the token from Vercel's dashboard.

Now every pull request runs the full quality check. Only clean, tested, built code reaches production.

🚨 Error Monitoring with Sentry

Tests catch bugs before users see them. Sentry catches the ones that slip through anyway — and tells you exactly where, why, and how often.

Setup

npm install @sentry/nextjs
npx @sentry/wizard@latest -i nextjs

The wizard creates sentry.client.config.ts, sentry.server.config.ts, and sentry.edge.config.ts automatically. You just need your DSN from the Sentry dashboard.

sentry.client.config.ts:

import * as Sentry from '@sentry/nextjs';

Sentry.init({
  dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
  tracesSampleRate: 0.1,     // Capture 10% of transactions for performance
  replaysSessionSampleRate: 0.1,
  replaysOnErrorSampleRate: 1.0, // Always capture replay when there's an error
  environment: process.env.NODE_ENV,
});

Capturing Errors Manually

import * as Sentry from '@sentry/nextjs';

async function processPayment(orderId: string) {
  try {
    const result = await paymentGateway.charge(orderId);
    return result;
  } catch (error) {
    // Send to Sentry with context
    Sentry.captureException(error, {
      tags: { component: 'checkout', action: 'processPayment' },
      extra: { orderId },
    });
    throw error; // Re-throw — don't silently swallow it
  }
}

Setting User Context

After login, tell Sentry who the user is — errors become instantly attributable:

import * as Sentry from '@sentry/nextjs';

function onLoginSuccess(user: User) {
  Sentry.setUser({
    id: user.id,
    email: user.email,
    username: user.name,
  });
}

function onLogout() {
  Sentry.setUser(null); // Clear on logout
}

Now when an error hits Sentry, you see exactly which user experienced it, what they were doing, and the full stack trace — no guessing.

🗂️ Production Environment Variables

Your app has three environments, and each needs its own config:

# .env.local (development — never commit this)
DATABASE_URL=postgresql://localhost:5432/myapp_dev
NEXT_PUBLIC_API_URL=http://localhost:3000
JWT_SECRET=dev-secret-not-for-production

# Vercel → Project Settings → Environment Variables → Preview
DATABASE_URL=postgresql://host/myapp_staging
NEXT_PUBLIC_API_URL=https://staging.myapp.com
JWT_SECRET=staging-secret-32-chars-minimum

# Vercel → Project Settings → Environment Variables → Production
DATABASE_URL=postgresql://host/myapp_prod
NEXT_PUBLIC_API_URL=https://myapp.com
JWT_SECRET=prod-secret-64-chars-cryptographically-random

Rules to live by:

// ✅ NEXT_PUBLIC_ prefix = visible in the browser (safe for public URLs)
const apiUrl = process.env.NEXT_PUBLIC_API_URL;

// ✅ No prefix = server-only (safe for secrets, DB URLs, API keys)
const dbUrl = process.env.DATABASE_URL;

// ❌ Never put secrets in NEXT_PUBLIC_ variables
// ❌ Never commit .env.local to Git (add it to .gitignore)
// ❌ Never hardcode secrets — even "temporarily"

🧱 Production-Ready Checklist

Before you consider any app production-ready, run through this honestly:

Security

□ All auth routes protected by middleware
□ Passwords hashed with bcrypt (never stored plain)
□ httpOnly cookies used (not localStorage for tokens)
□ Environment variables never committed to Git
□ API routes validate and sanitize all input
□ Rate limiting on login and sensitive endpoints
□ HTTPS enforced (Vercel does this automatically)

Reliability

□ Error Boundaries wrap independent UI sections
□ Sentry (or equivalent) capturing all unhandled errors
□ API routes return meaningful error messages + HTTP codes
□ Loading and error states handled in every data component
□ CI pipeline blocks deploys when tests fail

Performance

□ Images use next/image (WebP, lazy loading, no CLS)
□ Fonts loaded via next/font (no layout shift)
□ Route-based code splitting in place
□ No console.log left in production code
□ Largest Contentful Paint (LCP) < 2.5s

Observability

□ Error monitoring active (Sentry)
□ Performance monitoring configured
□ Structured logging in API routes
□ Alerts set up for error spikes

💣 Production Mistakes Worth Learning From

These are real patterns that get real apps in trouble — most of them avoidable with about 20 minutes of setup.

Mistake 1: Storing tokens in localStorage

// ❌ XSS attack can steal this
localStorage.setItem('token', jwtToken);

// ✅ httpOnly cookie — JavaScript can't touch it
response.cookies.set('auth-token', token, { httpOnly: true, secure: true });

Mistake 2: Not validating API inputs

// ❌ Trusting anything the client sends
export async function POST(req: NextRequest) {
  const { email, role } = await req.json();
  await db.users.create({ data: { email, role } }); // 😱 user just gave themselves 'admin'
}

// ✅ Validate the shape and strip unexpected fields
export async function POST(req: NextRequest) {
  const body = await req.json();
  const email = String(body.email ?? '').trim();

  if (!email || !email.includes('@')) {
    return NextResponse.json({ error: 'Invalid email' }, { status: 400 });
  }

  await db.users.create({ data: { email, role: 'user' } }); // role is hardcoded
}

Mistake 3: Exposing server errors to clients

// ❌ Leaks your stack trace and internals
return NextResponse.json({ error: error.message }, { status: 500 });

// ✅ Log the real error server-side, send a generic message
console.error('[API Error]', error);
Sentry.captureException(error);
return NextResponse.json({ error: 'Something went wrong.' }, { status: 500 });

Mistake 4: No rate limiting on auth routes

// Install: npm install @upstash/ratelimit @upstash/redis
import { Ratelimit } from '@upstash/ratelimit';
import { Redis } from '@upstash/redis';

const ratelimit = new Ratelimit({
  redis: Redis.fromEnv(),
  limiter: Ratelimit.slidingWindow(5, '1 m'), // 5 attempts per minute
});

export async function POST(request: NextRequest) {
  const ip = request.ip ?? '127.0.0.1';
  const { success } = await ratelimit.limit(ip);

  if (!success) {
    return NextResponse.json({ error: 'Too many attempts.' }, { status: 429 });
  }

  // ... rest of login logic
}

Mistake 5: Forgetting to handle token expiry on the client

// ✅ Intercept 401 responses globally and redirect to login
export async function fetchWithAuth(url: string, options?: RequestInit) {
  const response = await fetch(url, options);

  if (response.status === 401) {
    // Token expired — send user back to login
    window.location.href = '/login';
    return;
  }

  return response;
}

🎓 The Full Journey — What You've Built Over This Series

You started with "What is React?" and you're finishing with production deployments, auth systems, and error monitoring. That's not a small leap. Here's everything you've learned across all six parts:

Part 1 — Foundations
   React, components, hooks, setup, file structure

Part 2 — Advanced Hooks & State
   Custom hooks, useReducer, Context, Redux, Zustand, Jotai

Part 3 — Performance
   React.memo, useMemo, useCallback, code splitting, virtualization

Part 4 — Full-Stack with Next.js
   App Router, Server Components, API routes, deployment

Part 5 — Testing & Debugging
   Jest, React Testing Library, async tests, Error Boundaries

Part 6 — Production
   Auth, OAuth, CI/CD, Sentry, security, production patterns

You now have the full picture. Not just "React developer" — full-stack, production-capable, test-covered React engineering.

🔗 Quick Resources

Auth.js (NextAuth v5): authjs.dev
Sentry for Next.js: docs.sentry.io/platforms/javascript/nextjs
GitHub Actions: docs.github.com/actions
Upstash Rate Limiting: upstash.com/docs/ratelimit
Vercel Environment Variables: vercel.com/docs/environment-variables

💬 You've Reached the End — What's Next for You?

Six articles. A complete React engineering curriculum. What are you building with it?

If you've followed this series from Part 1, I'd genuinely love to hear what you took away most — a concept that finally clicked, a project you shipped, or even something I got wrong. Drop it in the comments.

And if you're hungry for what comes after production React, the natural next steps are: React Native for mobile, Turborepo for monorepos, and tRPC for end-to-end type safety without REST boilerplate.

Go build something real. 🚀

Testing & Debugging React Apps — Write Code You Can Actually Trust

Kushang Tailor — Thu, 18 Jun 2026 04:26:01 +0000

Read Time: ~14 minutes | Ship with confidence — because guessing is not a strategy

Prerequisites: React fundamentals, hooks, state management, Next.js basics (Parts 1–4)

📌 What You'll Learn

By the end of this guide, you'll be able to:

✅ Understand the three layers of testing and what each one covers
✅ Set up Jest and React Testing Library from scratch
✅ Write unit tests for components, hooks, and utility functions
✅ Write integration tests that test real user flows
✅ Test async behaviour — API calls, loading states, and errors
✅ Debug like a pro with React DevTools and browser tools
✅ Use Error Boundaries to catch crashes gracefully in production

🤔 Why Testing Feels Painful (And Why It Doesn't Have To)

Let's be real — most developers skip testing early on. Not because they don't care about quality, but because they were introduced to testing the wrong way: abstract theory, complicated setup, and tests that take longer to write than the code itself.

Here's the shift in mindset that makes it click:

You're not writing tests for the computer. You're writing tests for Future You.

Future You, at 2 AM, having just changed a utility function, needs to know if something broke without manually clicking through 40 screens. Tests are that safety net.

The other thing nobody tells you: you don't need to test everything. You test the things that would hurt if they broke.

🏗️ The Three Layers of Testing

Think of testing as a pyramid. Wide base, narrow top.

        /‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾\
       /   E2E Tests (few) \     → Cypress, Playwright
      /‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾\
     /  Integration Tests (some) \  → React Testing Library
    /‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾\
   /    Unit Tests (many)         \  → Jest
  /‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾\

Layer	What It Tests	Speed	Confidence
Unit	One function or component in isolation	Fast (~ms)	Low–Medium
Integration	Multiple parts working together	Medium (~s)	High
E2E	Full app in a real browser	Slow (~min)	Highest

For most React projects, you want lots of unit tests, a solid set of integration tests, and a handful of E2E tests for critical flows like login and checkout. This article focuses on unit and integration — the layer that gives you the best return on time invested.

⚙️ Setup: Jest + React Testing Library

If you created your project with Create React App, Jest is already configured. For Vite or Next.js, here's the setup.

For Next.js

npm install --save-dev jest jest-environment-jsdom @testing-library/react @testing-library/jest-dom @testing-library/user-event

Create jest.config.ts in your project root:

// jest.config.ts
import type { Config } from 'jest';
import nextJest from 'next/jest.js';

const createJestConfig = nextJest({ dir: './' });

const config: Config = {
  testEnvironment: 'jsdom',
  setupFilesAfterFramework: ['<rootDir>/jest.setup.ts'],
  moduleNameMapper: {
    '^@/(.*)$': '<rootDir>/$1', // Resolve @ path aliases
  },
};

export default createJestConfig(config);

Create jest.setup.ts:

// jest.setup.ts
import '@testing-library/jest-dom';
// This gives you matchers like .toBeInTheDocument(), .toHaveTextContent() etc.

Add the test script to package.json:

{
  "scripts": {
    "test": "jest",
    "test:watch": "jest --watch",
    "test:coverage": "jest --coverage"
  }
}

Run your first test:

npm test

✅ Unit Testing: Components

The golden rule of React Testing Library: test what the user sees, not implementation details.

That means — test for text on screen, buttons, inputs, and form behaviour. Don't test state variables, component internals, or CSS class names.

Testing a Simple Component

// components/Greeting.tsx
interface Props {
  name: string;
  isLoggedIn: boolean;
}

export default function Greeting({ name, isLoggedIn }: Props) {
  if (!isLoggedIn) {
    return <p>Please log in to continue.</p>;
  }
  return <h1>Welcome back, {name}!</h1>;
}

// components/Greeting.test.tsx
import { render, screen } from '@testing-library/react';
import Greeting from './Greeting';

describe('Greeting', () => {
  it('shows a welcome message when the user is logged in', () => {
    render(<Greeting name="Kushang" isLoggedIn={true} />);

    expect(screen.getByText('Welcome back, Kushang!')).toBeInTheDocument();
  });

  it('shows a login prompt when the user is not logged in', () => {
    render(<Greeting name="Kushang" isLoggedIn={false} />);

    expect(screen.getByText('Please log in to continue.')).toBeInTheDocument();
  });

  it('does not show the welcome message when logged out', () => {
    render(<Greeting name="Kushang" isLoggedIn={false} />);

    expect(screen.queryByText(/Welcome back/)).not.toBeInTheDocument();
  });
});

Notice the pattern every test follows — Arrange, Act, Assert:

Arrange: render the component
Act: interact with it (if needed)
Assert: check what's visible

Testing a Button Click

// components/Counter.tsx
import { useState } from 'react';

export default function Counter() {
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>Increment</button>
      <button onClick={() => setCount(0)}>Reset</button>
    </div>
  );
}

// components/Counter.test.tsx
import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import Counter from './Counter';

describe('Counter', () => {
  it('starts at zero', () => {
    render(<Counter />);
    expect(screen.getByText('Count: 0')).toBeInTheDocument();
  });

  it('increments the count when the button is clicked', async () => {
    const user = userEvent.setup();
    render(<Counter />);

    await user.click(screen.getByRole('button', { name: 'Increment' }));
    expect(screen.getByText('Count: 1')).toBeInTheDocument();

    await user.click(screen.getByRole('button', { name: 'Increment' }));
    expect(screen.getByText('Count: 2')).toBeInTheDocument();
  });

  it('resets the count to zero', async () => {
    const user = userEvent.setup();
    render(<Counter />);

    await user.click(screen.getByRole('button', { name: 'Increment' }));
    await user.click(screen.getByRole('button', { name: 'Increment' }));
    await user.click(screen.getByRole('button', { name: 'Reset' }));

    expect(screen.getByText('Count: 0')).toBeInTheDocument();
  });
});

userEvent simulates real user interactions — clicking, typing, tabbing. It's more realistic than fireEvent and the recommended choice today.

🔗 Integration Testing: Real User Flows

Integration tests are where the real confidence comes from. Instead of testing one component, you test a complete flow — like filling out and submitting a form.

Testing a Login Form

// components/LoginForm.tsx
import { useState } from 'react';

interface Props {
  onSubmit: (email: string, password: string) => void;
}

export default function LoginForm({ onSubmit }: Props) {
  const [email, setEmail]       = useState('');
  const [password, setPassword] = useState('');
  const [error, setError]       = useState('');

  const handleSubmit = (e: React.FormEvent) => {
    e.preventDefault();

    if (!email || !password) {
      setError('Both fields are required.');
      return;
    }

    onSubmit(email, password);
  };

  return (
    <form onSubmit={handleSubmit}>
      <label htmlFor="email">Email</label>
      <input
        id="email"
        type="email"
        value={email}
        onChange={(e) => setEmail(e.target.value)}
      />

      <label htmlFor="password">Password</label>
      <input
        id="password"
        type="password"
        value={password}
        onChange={(e) => setPassword(e.target.value)}
      />

      {error && <p role="alert">{error}</p>}

      <button type="submit">Log In</button>
    </form>
  );
}

// components/LoginForm.test.tsx
import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import LoginForm from './LoginForm';

describe('LoginForm', () => {
  it('calls onSubmit with email and password when the form is valid', async () => {
    const user      = userEvent.setup();
    const onSubmit  = jest.fn(); // Mock function — tracks calls
    render(<LoginForm onSubmit={onSubmit} />);

    await user.type(screen.getByLabelText('Email'), 'hello@example.com');
    await user.type(screen.getByLabelText('Password'), 'secret123');
    await user.click(screen.getByRole('button', { name: 'Log In' }));

    expect(onSubmit).toHaveBeenCalledWith('hello@example.com', 'secret123');
    expect(onSubmit).toHaveBeenCalledTimes(1);
  });

  it('shows an error message when fields are empty', async () => {
    const user = userEvent.setup();
    render(<LoginForm onSubmit={jest.fn()} />);

    await user.click(screen.getByRole('button', { name: 'Log In' }));

    expect(screen.getByRole('alert')).toHaveTextContent('Both fields are required.');
  });

  it('does not call onSubmit when fields are empty', async () => {
    const user     = userEvent.setup();
    const onSubmit = jest.fn();
    render(<LoginForm onSubmit={onSubmit} />);

    await user.click(screen.getByRole('button', { name: 'Log In' }));

    expect(onSubmit).not.toHaveBeenCalled();
  });
});

These three tests cover the happy path, the validation error, and the guard against bad calls. That's most of what this form can do — and they take under a minute to run.

⏳ Testing Async Behaviour

Most real components talk to an API. Here's how to test those flows without making actual network requests.

Mocking an API Call

// components/UserProfile.tsx
import { useEffect, useState } from 'react';

interface User {
  id: number;
  name: string;
  email: string;
}

export default function UserProfile({ userId }: { userId: number }) {
  const [user, setUser]       = useState<User | null>(null);
  const [loading, setLoading] = useState(true);
  const [error, setError]     = useState('');

  useEffect(() => {
    fetch(`/api/users/${userId}`)
      .then((r) => {
        if (!r.ok) throw new Error('Failed to load user.');
        return r.json();
      })
      .then((data) => { setUser(data); setLoading(false); })
      .catch((err) => { setError(err.message); setLoading(false); });
  }, [userId]);

  if (loading) return <p>Loading profile...</p>;
  if (error)   return <p role="alert">{error}</p>;

  return (
    <div>
      <h2>{user?.name}</h2>
      <p>{user?.email}</p>
    </div>
  );
}

// components/UserProfile.test.tsx
import { render, screen, waitFor } from '@testing-library/react';
import UserProfile from './UserProfile';

// Mock the global fetch API
global.fetch = jest.fn();

const mockUser = { id: 1, name: 'Kushang Tailor', email: 'kushang@example.com' };

describe('UserProfile', () => {
  afterEach(() => jest.clearAllMocks()); // Clean up between tests

  it('shows a loading state first', () => {
    (fetch as jest.Mock).mockResolvedValueOnce({
      ok: true,
      json: async () => mockUser,
    });

    render(<UserProfile userId={1} />);
    expect(screen.getByText('Loading profile...')).toBeInTheDocument();
  });

  it('shows the user name and email after loading', async () => {
    (fetch as jest.Mock).mockResolvedValueOnce({
      ok: true,
      json: async () => mockUser,
    });

    render(<UserProfile userId={1} />);

    await waitFor(() => {
      expect(screen.getByText('Kushang Tailor')).toBeInTheDocument();
      expect(screen.getByText('kushang@example.com')).toBeInTheDocument();
    });
  });

  it('shows an error message when the API fails', async () => {
    (fetch as jest.Mock).mockResolvedValueOnce({ ok: false });

    render(<UserProfile userId={1} />);

    await waitFor(() => {
      expect(screen.getByRole('alert')).toHaveTextContent('Failed to load user.');
    });
  });
});

waitFor keeps polling the assertion until it passes (or times out). It's how you deal with async state updates in tests.

🪝 Testing Custom Hooks

Custom hooks need their own tests because they hold logic that multiple components share. Use renderHook from React Testing Library:

// hooks/useCounter.ts
import { useState } from 'react';

export function useCounter(initial = 0) {
  const [count, setCount] = useState(initial);

  return {
    count,
    increment: () => setCount((c) => c + 1),
    decrement: () => setCount((c) => c - 1),
    reset:     () => setCount(initial),
  };
}

// hooks/useCounter.test.ts
import { renderHook, act } from '@testing-library/react';
import { useCounter } from './useCounter';

describe('useCounter', () => {
  it('starts with the initial value', () => {
    const { result } = renderHook(() => useCounter(10));
    expect(result.current.count).toBe(10);
  });

  it('increments the count', () => {
    const { result } = renderHook(() => useCounter());

    act(() => result.current.increment());

    expect(result.current.count).toBe(1);
  });

  it('decrements the count', () => {
    const { result } = renderHook(() => useCounter(5));

    act(() => result.current.decrement());

    expect(result.current.count).toBe(4);
  });

  it('resets to the initial value', () => {
    const { result } = renderHook(() => useCounter(3));

    act(() => result.current.increment());
    act(() => result.current.increment());
    act(() => result.current.reset());

    expect(result.current.count).toBe(3);
  });
});

act wraps anything that causes state updates. It makes sure React processes all the state changes before your assertion runs.

🔥 Debugging: React DevTools Deep Dive

Testing catches bugs before they reach users. Debugging finds the ones that sneak through anyway.

Components Tab

Open DevTools → React tab → Components. Here's what you can do:

Select any component in the tree → see:
├─ Props (current values)
├─ State (useState values)
├─ Hooks (all hook values in order)
└─ Rendered by (parent chain)

You can also edit props and state live in the panel — no code change needed. Incredibly useful for testing edge cases.

Profiler Tab (Performance Debugging)

Already covered in Part 3, but worth repeating the workflow:

1. Open React DevTools → Profiler tab
2. Click ● Record
3. Interact with the slow part of your app
4. Click ■ Stop
5. Look for wide bars (slow renders) and grey bars (unnecessary renders)

Grey bars mean a component re-rendered but produced identical output — a prime candidate for React.memo.

Highlight Updates

In React DevTools settings, enable "Highlight updates when components render". Every re-render flashes a coloured outline on the component. If things are flashing that shouldn't be, you've found your problem.

🚨 Error Boundaries: Catching Crashes in Production

Here's something try/catch cannot do: catch errors thrown during rendering. Error Boundaries handle exactly that — they're React's safety net for when a component tree crashes.

// components/ErrorBoundary.tsx
import { Component, ReactNode } from 'react';

interface Props {
  children: ReactNode;
  fallback?: ReactNode;
}

interface State {
  hasError: boolean;
  error: Error | null;
}

export class ErrorBoundary extends Component<Props, State> {
  constructor(props: Props) {
    super(props);
    this.state = { hasError: false, error: null };
  }

  static getDerivedStateFromError(error: Error): State {
    return { hasError: true, error };
  }

  componentDidCatch(error: Error, info: React.ErrorInfo) {
    // Send to your error tracking service (Sentry, Datadog, etc.)
    console.error('Caught by ErrorBoundary:', error, info.componentStack);
  }

  render() {
    if (this.state.hasError) {
      return (
        this.props.fallback ?? (
          <div className="error-state">
            <h2>Something went wrong.</h2>
            <p>We're looking into it — try refreshing the page.</p>
            <button onClick={() => this.setState({ hasError: false, error: null })}>
              Try Again
            </button>
          </div>
        )
      );
    }

    return this.props.children;
  }
}

Wrap it around sections that could fail independently:

// app/dashboard/page.tsx
import { ErrorBoundary } from '@/components/ErrorBoundary';
import { SalesChart } from '@/components/SalesChart';
import { RecentOrders } from '@/components/RecentOrders';

export default function DashboardPage() {
  return (
    <div className="dashboard">
      {/* If SalesChart crashes, only this section shows an error */}
      <ErrorBoundary fallback={<p>Chart unavailable — try again later.</p>}>
        <SalesChart />
      </ErrorBoundary>

      {/* RecentOrders is unaffected by SalesChart crashing */}
      <ErrorBoundary fallback={<p>Orders unavailable — try again later.</p>}>
        <RecentOrders />
      </ErrorBoundary>
    </div>
  );
}

The result: one section crashing doesn't take down the entire page. Your users see a graceful fallback instead of a blank white screen.

🧪 Common Testing Queries — Which One to Use

React Testing Library gives you several ways to query the DOM. Here's when to use each:

// Priority 1: Accessible roles (best — mirrors what screen readers see)
screen.getByRole('button', { name: 'Submit' })
screen.getByRole('heading', { name: 'Welcome' })
screen.getByRole('textbox', { name: 'Email' })

// Priority 2: Labels (great for form fields)
screen.getByLabelText('Email Address')

// Priority 3: Placeholder (acceptable for inputs)
screen.getByPlaceholderText('Search...')

// Priority 4: Text content (good for readable text)
screen.getByText('Loading...')

// Priority 5: Test IDs (last resort — add data-testid only if nothing else works)
screen.getByTestId('product-card')

The philosophy: if you're querying by class name or component name, you're testing implementation, not behaviour. A CSS refactor will break your tests for no good reason.

📊 What a Healthy Test Suite Looks Like

Here's a realistic coverage target for a production React app:

Type	Target Coverage	Run Time
Utility functions	90–100%	< 1s
Custom hooks	80–90%	< 5s
Components (unit)	70–80%	< 30s
User flows (integration)	Key flows covered	< 2 min
E2E	Login, checkout, critical paths	< 10 min

100% coverage is a myth worth ignoring. A well-tested login flow, cart checkout, and search filter give you far more confidence than 100% coverage on a heading component.

💡 Debugging Checklist (When Things Go Wrong)

Before spending an hour on a bug, run through this:

□ Check the browser console — is there an error message?
□ Check the Network tab — did the API call succeed? What did it return?
□ Add a console.log right before the broken code
□ Open React DevTools → Components → check the props and state
□ Is the component re-rendering when it shouldn't? (Highlight updates)
□ Is it an async timing issue? (Add a debugger statement in the useEffect)
□ Are you mutating state directly? (Should always use setState)
□ Is a dependency array in useEffect missing something?
□ Did a prop change shape or become undefined?
□ Is the issue only in production? (Check .env variables)

Nine times out of ten, the bug is in the console, the network tab, or a missing dependency array.

🔗 Quick Resources

React Testing Library: testing-library.com/react
Jest Docs: jestjs.io
React DevTools: Chrome Web Store → "React Developer Tools"
Vitest (fast alternative to Jest): vitest.dev
Cypress (E2E): cypress.io
Playwright (E2E): playwright.dev

💬 What's Your Testing Philosophy?

Do you write tests before the code (TDD), after, or only when something breaks? No judgement either way — I'm genuinely curious what workflow actually sticks for people in the real world. Drop it in the comments!

Coming in Part 6:

Authentication flows (JWT, session, OAuth)
Real-world deployment patterns
Error monitoring with Sentry
CI/CD with GitHub Actions
Lessons from production React apps at scale

Happy testing! 🧪

Full-Stack with Next.js — From React Dev to Full-Stack Engineer

Kushang Tailor — Wed, 10 Jun 2026 06:29:33 +0000

Read Time: ~15 minutes | The bridge from React UI library to production full-stack framework

Prerequisites: React fundamentals, hooks, state management (Parts 1–3)

📌 What You'll Learn

By the end of this guide, you'll be able to:

✅ Understand what Next.js adds on top of React (and why it matters)
✅ Navigate the App Router with file-based routing
✅ Know when to use Server Components vs Client Components
✅ Fetch data on the server without a separate backend
✅ Build API routes that replace a Node/Express server
✅ Optimize images and fonts automatically
✅ Build and deploy a real blog platform to Vercel in under 10 minutes

🤔 What Is Next.js (And Why Does It Exist)?

React is a UI library—it renders components beautifully, but it has no opinion about routing, data fetching, server-side rendering, or deployment. You assemble all of that yourself.

Next.js is the full-stack framework built on React that makes those decisions for you. It's like React + routing + data fetching + a server + a build pipeline, all in one cohesive package.

React alone:
UI rendering ✅ | Routing ❌ | Data fetching ❌ | SSR ❌ | API ❌

Next.js (React + framework):
UI rendering ✅ | Routing ✅ | Data fetching ✅ | SSR ✅ | API ✅

Why the Industry Adopted Next.js So Fast

By 2025, Next.js is used by Vercel, Netflix, TikTok, Twitch, Notion, and GitHub among thousands of production applications. The reasons are practical:

SEO out of the box — pages are server-rendered, so search engines see real content
No Express server needed — API routes live inside the same codebase
Automatic optimizations — images, fonts, and scripts are optimized for free
Deployment in seconds — Vercel hosting knows Next.js deeply

⚖️ Next.js vs The Alternatives

Criteria	Create React App	Vite	Next.js	Remix
Routing	Manual (React Router)	Manual	Built-in	Built-in
SSR / SSG	❌	❌	✅	✅
API Routes	❌	❌	✅	✅
SEO	Poor (CSR only)	Poor (CSR only)	Excellent	Excellent
Image Optimization	Manual	Manual	Automatic	Manual
Learning Curve	Low	Low	Medium	Medium
Bundle Splitting	Manual	Auto	Auto	Auto
Best For	Prototypes	SPAs, tools	Full-stack apps	Form-heavy apps
Vercel Deploy	Manual	Manual	One click	One click

The takeaway: Use Next.js whenever your app needs SEO, a backend, or server-side data. Use Vite for internal dashboards or SPAs where SEO doesn't matter.

🚀 Setup & Project Structure

Create a Next.js App

# Create project (accept all defaults)
npx create-next-app@latest my-blog
cd my-blog
npm run dev

You'll be asked a few questions—say Yes to TypeScript (optional), Yes to Tailwind (optional), and Yes to the App Router (essential for 2025).

Project Structure (App Router)

my-blog/
├── app/                    # ← Heart of your app (App Router)
│   ├── layout.tsx          # Root layout (wraps every page)
│   ├── page.tsx            # Home page → renders at /
│   ├── globals.css         # Global styles
│   ├── about/
│   │   └── page.tsx        # About page → renders at /about
│   └── blog/
│       ├── page.tsx        # Blog list → renders at /blog
│       └── [slug]/
│           └── page.tsx    # Single post → renders at /blog/my-post
├── public/                 # Static assets (images, fonts, etc.)
├── components/             # Shared UI components
├── lib/                    # Utility functions, DB connections
├── next.config.js          # Next.js configuration
└── package.json

The magic: file path = URL path. No router config, no <Route> components. Just create a file and the route exists.

📁 File-Based Routing (App Router)

Page Files

Every page.tsx inside app/ becomes a route:

// app/page.tsx → renders at /
export default function HomePage() {
  return <h1>Welcome Home</h1>;
}

// app/about/page.tsx → renders at /about
export default function AboutPage() {
  return <h1>About Us</h1>;
}

// app/blog/page.tsx → renders at /blog
export default function BlogListPage() {
  return <h1>All Posts</h1>;
}

Dynamic Routes (Parameters in URLs)

// app/blog/[slug]/page.tsx → renders at /blog/any-post-title
interface Props {
  params: { slug: string };
}

export default function PostPage({ params }: Props) {
  return <h1>Post: {params.slug}</h1>;
  // /blog/hello-world → params.slug = "hello-world"
  // /blog/my-react-guide → params.slug = "my-react-guide"
}

Layout Files (Shared UI Across Routes)

// app/layout.tsx → wraps EVERY page in your app
export default function RootLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <html lang="en">
      <body>
        <nav>
          <a href="/">Home</a>
          <a href="/blog">Blog</a>
          <a href="/about">About</a>
        </nav>
        <main>{children}</main>
        <footer>© 2025 My Blog</footer>
      </body>
    </html>
  );
}

// app/blog/layout.tsx → wraps only /blog/* routes
export default function BlogLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <div className="blog-container">
      <aside>
        <h3>Categories</h3>
        {/* Sidebar here */}
      </aside>
      <article>{children}</article>
    </div>
  );
}

Why layouts are powerful: Your nav and footer render once and persist across page navigations—no re-mounting, no flicker.

Special Files at a Glance

Filename	Purpose
`page.tsx`	The visible UI for a route
`layout.tsx`	Wrapper shared across child routes
`loading.tsx`	Auto-shown while page data loads
`error.tsx`	Error boundary for a route
`not-found.tsx`	Custom 404 page
`route.ts`	API endpoint (replaces Express route)

⚡ Server Components vs Client Components

This is the concept that trips up most React developers moving to Next.js.

Server Components (Default in App Router)

In Next.js App Router, every component is a Server Component by default. They run on the server, never in the browser.

// app/blog/page.tsx
// ✅ Server Component (no "use client" directive)
// Runs on the server — can access databases, env vars, file system

async function getBlogPosts() {
  const response = await fetch('https://api.example.com/posts', {
    next: { revalidate: 3600 } // Re-fetch every hour
  });
  return response.json();
}

export default async function BlogPage() {
  const posts = await getBlogPosts(); // Direct async/await — no useEffect!

  return (
    <div>
      <h1>Blog Posts</h1>
      {posts.map((post: Post) => (
        <article key={post.id}>
          <h2>{post.title}</h2>
          <p>{post.excerpt}</p>
          <a href={`/blog/${post.slug}`}>Read more →</a>
        </article>
      ))}
    </div>
  );
}

What Server Components can do:

✅ async/await directly (no useEffect + useState loading dance)
✅ Access databases and file system directly
✅ Use secret env variables safely
✅ Import heavy libraries without bloating the client bundle
❌ No useState, useEffect, event handlers
❌ No browser APIs (window, document)

Client Components (`"use client"` directive)

Add "use client" at the top when you need interactivity:

"use client"; // ← This one line switches to a Client Component

import { useState } from 'react';

export default function SearchBar({ onSearch }: { onSearch: (q: string) => void }) {
  const [query, setQuery] = useState('');

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

Client Components are for:

✅ useState, useEffect, custom hooks
✅ Event handlers (onClick, onChange)
✅ Browser APIs
✅ Third-party libraries needing the DOM
❌ Direct database/file system access
❌ Secret environment variables

The Golden Pattern: Server Shell + Client Islands

// app/blog/page.tsx — Server Component (default)
import SearchBar from '@/components/SearchBar'; // Client Component
import PostList from '@/components/PostList';   // Server Component

async function getPosts() {
  // Runs on server — safe to use secrets, DB, etc.
  const posts = await db.posts.findMany();
  return posts;
}

export default async function BlogPage() {
  const posts = await getPosts(); // Direct DB call — no API needed

  return (
    <div>
      {/* Client island — handles user input */}
      <SearchBar onSearch={(q) => console.log(q)} />

      {/* Server component — rendered on server */}
      <PostList posts={posts} />
    </div>
  );
}

Mental model: Server Components are the shell (fast, SEO-friendly, secure). Client Components are interactive islands inside that shell. Use the minimum number of Client Components necessary.

🌐 Data Fetching in Next.js

Three Patterns You'll Use

1. Static Data (SSG) — Build time, cached forever

// app/about/page.tsx
// Data fetched once at build time — ultra fast

export default async function AboutPage() {
  const team = await fetch('https://api.example.com/team').then(r => r.json());
  // This fetch runs ONCE when you build — result is cached as static HTML

  return (
    <div>
      {team.map((member: Member) => (
        <div key={member.id}>{member.name}</div>
      ))}
    </div>
  );
}

2. Revalidated Data (ISR) — Refreshes every N seconds

// app/blog/page.tsx
// Re-fetches every 60 seconds — fresh but still cached

async function getPosts() {
  const res = await fetch('https://api.example.com/posts', {
    next: { revalidate: 60 } // Refresh every 60 seconds
  });
  return res.json();
}

3. Dynamic Data (SSR) — Every request, always fresh

// app/dashboard/page.tsx
// Runs on every request — real-time data

async function getUserData(userId: string) {
  const res = await fetch(`https://api.example.com/users/${userId}`, {
    cache: 'no-store' // Never cache — always fresh
  });
  return res.json();
}

Fetching Strategy Decision

Is data the same for everyone?
├─ Yes, never changes → Static (no revalidate)
├─ Yes, but updates sometimes → ISR (revalidate: N seconds)
└─ No, user-specific or real-time → Dynamic (cache: 'no-store')

🔌 API Routes: Your Backend Lives Here

Next.js route.ts files replace Express, Fastify, or any separate Node server.

Basic CRUD API

// app/api/posts/route.ts → handles GET /api/posts & POST /api/posts
import { NextRequest, NextResponse } from 'next/server';

// In-memory store (use a real DB in production)
const posts = [
  { id: 1, title: 'Hello Next.js', slug: 'hello-nextjs' },
  { id: 2, title: 'Server Components', slug: 'server-components' },
];

// GET /api/posts
export async function GET() {
  return NextResponse.json(posts);
}

// POST /api/posts
export async function POST(request: NextRequest) {
  const body = await request.json();

  if (!body.title) {
    return NextResponse.json(
      { error: 'Title is required' },
      { status: 400 }
    );
  }

  const newPost = {
    id: posts.length + 1,
    title: body.title,
    slug: body.title.toLowerCase().replace(/\s+/g, '-'),
  };

  posts.push(newPost);
  return NextResponse.json(newPost, { status: 201 });
}

Dynamic API Routes

// app/api/posts/[id]/route.ts → handles /api/posts/1, /api/posts/42, etc.
import { NextRequest, NextResponse } from 'next/server';

interface Params {
  params: { id: string };
}

// GET /api/posts/1
export async function GET(_req: NextRequest, { params }: Params) {
  const post = await db.posts.findUnique({
    where: { id: parseInt(params.id) },
  });

  if (!post) {
    return NextResponse.json({ error: 'Post not found' }, { status: 404 });
  }

  return NextResponse.json(post);
}

// PATCH /api/posts/1
export async function PATCH(request: NextRequest, { params }: Params) {
  const body = await request.json();

  const updated = await db.posts.update({
    where: { id: parseInt(params.id) },
    data: { title: body.title },
  });

  return NextResponse.json(updated);
}

// DELETE /api/posts/1
export async function DELETE(_req: NextRequest, { params }: Params) {
  await db.posts.delete({ where: { id: parseInt(params.id) } });
  return NextResponse.json({ success: true });
}

The result: a full REST API, no separate server, no CORS headaches—everything in one codebase.

🖼️ Image & Font Optimization (Free Performance Wins)

The `<Image>` Component

Never use a plain <img> in Next.js—use next/image instead:

import Image from 'next/image';

// ❌ Plain HTML img — unoptimized
<img src="/hero.jpg" alt="Hero" width={1200} height={600} />

// ✅ Next.js Image — automatic WebP, lazy loading, no layout shift
<Image
  src="/hero.jpg"
  alt="Hero"
  width={1200}
  height={600}
  priority     // Load this image eagerly (above the fold)
/>

// ✅ Fill mode for responsive containers
<div style={{ position: 'relative', height: '300px' }}>
  <Image
    src="/cover.jpg"
    alt="Post cover"
    fill
    style={{ objectFit: 'cover' }}
    sizes="(max-width: 768px) 100vw, 50vw"
  />
</div>

What next/image gives you for free:

Converts to WebP/AVIF automatically (30-50% smaller)
Lazy loads by default (only loads when in viewport)
Prevents Cumulative Layout Shift (CLS)
Generates multiple sizes for different screen widths

Font Optimization

// app/layout.tsx
import { Inter, Fira_Code } from 'next/font/google';

// Fonts are downloaded at build time — no runtime network request
const inter = Inter({
  subsets: ['latin'],
  display: 'swap',      // Show fallback font until loaded
  variable: '--font-inter',
});

const firaCode = Fira_Code({
  subsets: ['latin'],
  display: 'swap',
  variable: '--font-fira-code',
});

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en" className={`${inter.variable} ${firaCode.variable}`}>
      <body style={{ fontFamily: 'var(--font-inter)' }}>
        {children}
      </body>
    </html>
  );
}

Why this matters: Google Fonts loaded the old way block rendering and cause layout shift. Next.js downloads fonts at build time—zero runtime latency, zero layout shift.

🏗️ Real-World: Building a Blog Platform

Let's put everything together and build a real blog with posts and an API.

Step 1: Project Setup

npx create-next-app@latest nextjs-blog
cd nextjs-blog
npm install gray-matter    # Parse markdown frontmatter
npm install next-mdx-remote # Render MDX content
npm run dev

Step 2: Post Data (Markdown Files)

<!-- posts/hello-nextjs.md -->
---
title: "Hello Next.js"
date: "2025-06-01"
excerpt: "A quick intro to why Next.js changes everything."
author: "Your Name"
---

# Hello Next.js

This is my first post rendered from markdown...

Step 3: Library to Read Posts

// lib/posts.ts
import fs from 'fs';
import path from 'path';
import matter from 'gray-matter';

const postsDir = path.join(process.cwd(), 'posts');

export function getAllPosts() {
  const slugs = fs.readdirSync(postsDir);

  return slugs
    .map((filename) => {
      const slug = filename.replace(/\.md$/, '');
      const fullPath = path.join(postsDir, filename);
      const fileContents = fs.readFileSync(fullPath, 'utf8');
      const { data } = matter(fileContents);

      return {
        slug,
        title: data.title as string,
        date: data.date as string,
        excerpt: data.excerpt as string,
        author: data.author as string,
      };
    })
    .sort((a, b) => (a.date > b.date ? -1 : 1));
}

export function getPostBySlug(slug: string) {
  const fullPath = path.join(postsDir, `${slug}.md`);
  const fileContents = fs.readFileSync(fullPath, 'utf8');
  const { data, content } = matter(fileContents);

  return {
    slug,
    content,
    title: data.title as string,
    date: data.date as string,
    author: data.author as string,
  };
}

Step 4: Blog List Page (Server Component)

// app/blog/page.tsx
import { getAllPosts } from '@/lib/posts';
import Link from 'next/link';

export const metadata = {
  title: 'Blog | My Next.js Blog',
  description: 'Thoughts on React, Next.js, and web development.',
};

export default function BlogPage() {
  // Direct file system access — no API call, no useEffect
  const posts = getAllPosts();

  return (
    <main>
      <h1>Blog</h1>
      <p>{posts.length} posts published</p>

      <div className="post-grid">
        {posts.map((post) => (
          <article key={post.slug}>
            <time>{new Date(post.date).toLocaleDateString()}</time>
            <h2>
              <Link href={`/blog/${post.slug}`}>{post.title}</Link>
            </h2>
            <p>{post.excerpt}</p>
            <span>{post.author}</span>
          </article>
        ))}
      </div>
    </main>
  );
}

Step 5: Single Post Page (Dynamic Route)

// app/blog/[slug]/page.tsx
import { getPostBySlug, getAllPosts } from '@/lib/posts';
import { notFound } from 'next/navigation';

// Pre-generate all post pages at build time
export async function generateStaticParams() {
  const posts = getAllPosts();
  return posts.map((post) => ({ slug: post.slug }));
}

// Generate dynamic metadata per post
export async function generateMetadata({ params }: { params: { slug: string } }) {
  const post = getPostBySlug(params.slug);
  return {
    title: `${post.title} | My Blog`,
    description: post.title,
  };
}

export default function PostPage({ params }: { params: { slug: string } }) {
  const post = getPostBySlug(params.slug);

  if (!post) notFound(); // Shows app/not-found.tsx automatically

  return (
    <article>
      <header>
        <h1>{post.title}</h1>
        <time>{new Date(post.date).toLocaleDateString()}</time>
        <span>By {post.author}</span>
      </header>

      {/* Render markdown as HTML */}
      <div dangerouslySetInnerHTML={{ __html: post.content }} />
    </article>
  );
}

Step 6: API Route for Posts

// app/api/posts/route.ts
import { getAllPosts } from '@/lib/posts';
import { NextResponse } from 'next/server';

// GET /api/posts — returns all posts as JSON
export async function GET() {
  const posts = getAllPosts();
  return NextResponse.json(posts);
}

Step 7: Loading & Error States

// app/blog/loading.tsx — Shows while blog page loads
export default function BlogLoading() {
  return (
    <div>
      {[1, 2, 3].map((i) => (
        <div key={i} className="post-skeleton">
          <div className="skeleton-title" />
          <div className="skeleton-text" />
        </div>
      ))}
    </div>
  );
}

// app/blog/error.tsx — Shows if blog page throws
'use client';

export default function BlogError({ error, reset }: {
  error: Error;
  reset: () => void;
}) {
  return (
    <div>
      <h2>Something went wrong loading the blog</h2>
      <p>{error.message}</p>
      <button onClick={reset}>Try again</button>
    </div>
  );
}

🚀 Deploying to Vercel in Under 10 Minutes

Vercel is the company behind Next.js. Their platform knows Next.js deeply—deployment is as simple as pushing code.

Step 1: Push to GitHub

git init
git add .
git commit -m "Initial blog setup"
git branch -M main
git remote add origin https://github.com/yourusername/my-blog.git
git push -u origin main

Step 2: Connect to Vercel

Go to vercel.com and sign up with GitHub
Click "New Project" → Import your repo
Vercel detects Next.js automatically—click Deploy That's it. Your app is live.

What Vercel Provides Automatically

✅ HTTPS certificate (SSL)
✅ Global CDN (fast worldwide)
✅ Automatic deploys on every git push
✅ Preview URLs for every pull request
✅ Environment variable management
✅ Edge Network for API routes
✅ Analytics dashboard
✅ Serverless functions (your API routes)

Environment Variables

# .env.local (never commit this file)
DATABASE_URL=postgresql://user:pass@host/db
NEXT_PUBLIC_API_URL=https://api.example.com  # NEXT_PUBLIC_ = visible in browser
SECRET_API_KEY=abc123  # No prefix = server-only (secure)

// Accessing env vars
const dbUrl = process.env.DATABASE_URL;           // Server only ✅
const apiUrl = process.env.NEXT_PUBLIC_API_URL;   // Both client + server ✅

Add the same variables in Vercel's dashboard under Project → Settings → Environment Variables.

📊 Performance Wins You Get for Free

When you deploy to Vercel with Next.js:

Optimization	Technique	Gain
Static pages	Pre-rendered HTML	Near-instant load
Dynamic pages	Edge SSR	<100ms TTFB globally
Images	WebP + lazy load	30-50% smaller
Fonts	Build-time download	0ms font latency
JavaScript	Auto code-splitting	Smallest possible bundles
API Routes	Serverless functions	Scales to zero, instant cold start

💡 Final Thoughts: Next.js as a Career Investment

The jump from React developer to Next.js full-stack engineer is one of the highest-ROI moves you can make in 2025.

What changes:

You go from "I build UIs" to "I build and ship entire applications"
You stop needing a separate backend team for simple APIs
Your apps get SEO, performance, and scalability built in The learning order that makes sense:

React Fundamentals (Part 1)
        ↓
Advanced Hooks & State (Part 2)
        ↓
Performance Optimization (Part 3)
        ↓
Next.js Full-Stack ← YOU ARE HERE
        ↓
Testing (Part 5)
        ↓
Production-Grade React (Part 6)

You're not adding a new tool—you're graduating to a platform.

🔗 Quick Resources

Next.js Docs: nextjs.org/docs — The best framework docs in the ecosystem
Next.js Learn: nextjs.org/learn — Official interactive tutorial
Vercel: vercel.com — Deploy Next.js in one click
Prisma: prisma.io — Best ORM for Next.js + database
shadcn/ui: ui.shadcn.com — Component library built for Next.js

💬 What's Your Next.js Story?

Have you made the jump from React to Next.js? Are you still on the fence? What's holding you back? Drop your experience in the comments—especially if you've hit any gotchas with Server Components. That's usually where people get stuck first!

Covered in Part 5:

Unit testing with Jest & React Testing Library
Testing Server Components and API routes
Debugging with React DevTools and browser tools
Error boundaries in production
CI/CD pipeline basics

Happy shipping! 🚀

🗄️ WordPress Database Tables: The Complete Developer's Guide

Kushang Tailor — Tue, 09 Jun 2026 13:13:26 +0000

📌 What You'll Learn

What WordPress actually is under the hood (beyond the marketing pitch)
How WordPress structures its database — and why it's built that way
What database engine WordPress runs on
Every core table explained with real-world examples
Which admin panel settings map to which tables (side-by-side)
Performance and security teaser for the next article

🌐 What is WordPress?

Let's be real — most developers have a short answer ready: "It's a blogging platform." But that undersells it massively.

WordPress is an open-source Content Management System (CMS) built with PHP and backed by a MySQL-compatible database. It powers roughly 43% of all websites on the internet as of 2024. That's not a CMS anymore — that's infrastructure.

At its core, WordPress is a framework for managing content, users, settings, and relationships between all of them. When you install WordPress, it doesn't just unzip some files — it creates an entire relational database schema with 12 default tables that handle everything from your blog post drafts to your plugin options.

Here's what makes WordPress interesting from a developer's perspective:

It separates content from presentation — posts, pages, and custom post types live in the DB; themes only control how they look
It's hook-driven — the database structure is designed to be extended without modification
It stores almost everything as key-value metadata — giving it tremendous flexibility at the cost of query complexity > 💡 Developer Insight: WordPress uses the Entity-Attribute-Value (EAV) pattern for metadata (postmeta, usermeta, options). This makes it incredibly extensible but also means you'll often see wide tables replaced by tall ones.

🧱 Database Fundamentals of WordPress

Before we jump into tables, let's set the stage with some foundational concepts.

The WordPress Database Prefix

Every WordPress table has a configurable prefix — by default, wp_. This is defined in wp-config.php:

$table_prefix = 'wp_';

Why does this matter?

Security: Changing the prefix from wp_ makes SQL injection attacks targeting default table names harder
Multisite: WordPress Multisite creates additional tables for each site (e.g., wp_2_posts, wp_3_posts)
Multiple Installs: You can run multiple WordPress installs in the same database using different prefixes ### WPDB — The WordPress Database Abstraction Layer

WordPress doesn't let you write raw SQL queries directly (well, you can, but you shouldn't). It provides the global $wpdb object — an instance of the wpdb class that abstracts all database interactions:

global $wpdb;

// Safe query with placeholder
$results = $wpdb->get_results(
    $wpdb->prepare(
        "SELECT * FROM {$wpdb->posts} WHERE post_status = %s LIMIT %d",
        'publish',
        10
    )
);

The $wpdb object also gives you named table properties so you never hardcode table names:

Property	Resolves To
`$wpdb->posts`	`wp_posts`
`$wpdb->postmeta`	`wp_postmeta`
`$wpdb->users`	`wp_users`
`$wpdb->options`	`wp_options`

🐬 What Database Does WordPress Use?

WordPress officially uses MySQL or its compatible forks:

Engine	Compatibility	Notes
MySQL	✅ Full	The default and most tested
MariaDB	✅ Full	Drop-in replacement, used by most hosts
Percona Server	✅ Full	MySQL fork with performance enhancements
SQLite	⚠️ Experimental	Supported via plugin (since WP 6.1 experimental)
PostgreSQL	❌ Not Official	Possible via third-party plugins only

Minimum Requirements (as of WordPress 6.x)

MySQL: 5.7.0 or higher
MariaDB: 10.3 or higher
PHP: 7.4+ (8.0+ recommended) ### Storage Engine: InnoDB vs MyISAM

Modern WordPress installations use InnoDB as the default storage engine — and for good reason:

Feature	InnoDB	MyISAM
Foreign keys	✅	❌
Transactions	✅	❌
Row-level locking	✅	❌ (table-level)
Full-text search	✅ (MySQL 5.6+)	✅
Crash recovery	✅	⚠️ Limited

Why this matters: If you're running a high-traffic site or using WooCommerce, InnoDB's row-level locking is critical. MyISAM locks the entire table on writes — a problem when multiple users are checking out simultaneously.

📋 All WordPress Core Tables — Explained with Examples

Here's a complete walkthrough of every default table WordPress creates.

1. `wp_posts` — The Heart of WordPress

This is the most important table in the entire WordPress ecosystem. Almost everything in WordPress is a post.

Schema overview:

CREATE TABLE wp_posts (
    ID               BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT,
    post_author      BIGINT(20) UNSIGNED NOT NULL DEFAULT 0,
    post_date        DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
    post_date_gmt    DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
    post_content     LONGTEXT NOT NULL,
    post_title       TEXT NOT NULL,
    post_excerpt     TEXT NOT NULL,
    post_status      VARCHAR(20) NOT NULL DEFAULT 'publish',
    comment_status   VARCHAR(20) NOT NULL DEFAULT 'open',
    ping_status      VARCHAR(20) NOT NULL DEFAULT 'open',
    post_name        VARCHAR(200) NOT NULL DEFAULT '',
    post_modified    DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
    post_type        VARCHAR(20) NOT NULL DEFAULT 'post',
    PRIMARY KEY (ID)
);

What post_type stores:

`post_type` Value	What It Represents
`post`	Blog posts
`page`	Static pages
`attachment`	Media uploads
`revision`	Auto-saved revisions
`nav_menu_item`	Navigation menu items
`custom_css`	Customizer CSS
`product`	WooCommerce products
`any_cpt`	Your custom post types

Real-world example:

global $wpdb;

// Get all published posts with their authors
$posts = $wpdb->get_results(
    $wpdb->prepare(
        "SELECT ID, post_title, post_status, post_type
         FROM {$wpdb->posts}
         WHERE post_type = %s
         AND post_status = %s
         ORDER BY post_date DESC
         LIMIT %d",
        'post',
        'publish',
        5
    )
);

2. `wp_postmeta` — The Post's Extra Drawers

If wp_posts is the filing cabinet, wp_postmeta is all the sticky notes attached to each folder. Every piece of additional data tied to a post lives here.

CREATE TABLE wp_postmeta (
    meta_id    BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT,
    post_id    BIGINT(20) UNSIGNED NOT NULL DEFAULT 0,
    meta_key   VARCHAR(255) DEFAULT NULL,
    meta_value LONGTEXT,
    PRIMARY KEY (meta_id),
    KEY post_id (post_id),
    KEY meta_key (meta_key(191))
);

What lives in wp_postmeta:

`meta_key`	Example Value	Set By
`_thumbnail_id`	`42`	WordPress core (featured image)
`_edit_lock`	`1712345678:1`	Block editor
`_wp_page_template`	`page-full-width.php`	Theme
`_price`	`29.99`	WooCommerce
`_yoast_wpseo_title`	`My Custom SEO Title`	Yoast SEO

Real-world example:

// Get all posts that have a featured image set
$posts_with_thumbnail = $wpdb->get_col(
    "SELECT DISTINCT post_id
     FROM {$wpdb->postmeta}
     WHERE meta_key = '_thumbnail_id'"
);

⚠️ Performance Note: The meta_key index is only 191 characters long (not 255). This is a UTF-8 MB4 limitation. Long meta keys won't be indexed fully — keep your custom meta keys short and consistent.

3. `wp_users` — The User Registry

This table stores the core identity of every user on your WordPress site.

CREATE TABLE wp_users (
    ID                  BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT,
    user_login          VARCHAR(60) NOT NULL DEFAULT '',
    user_pass           VARCHAR(255) NOT NULL DEFAULT '',
    user_nicename       VARCHAR(50) NOT NULL DEFAULT '',
    user_email          VARCHAR(100) NOT NULL DEFAULT '',
    user_url            VARCHAR(100) NOT NULL DEFAULT '',
    user_registered     DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
    user_activation_key VARCHAR(255) NOT NULL DEFAULT '',
    user_status         INT(11) NOT NULL DEFAULT 0,
    display_name        VARCHAR(250) NOT NULL DEFAULT '',
    PRIMARY KEY (ID),
    KEY user_login_key (user_login),
    KEY user_nicename (user_nicename),
    KEY user_email (user_email)
);

🔐 Security Note: user_pass stores a hashed password using WordPress's wp_hash_password() function (based on phpass). Never store or compare plain text passwords — always use wp_check_password().

Real-world example:

// Get users registered in the last 30 days
$new_users = $wpdb->get_results(
    $wpdb->prepare(
        "SELECT ID, user_login, user_email, user_registered
         FROM {$wpdb->users}
         WHERE user_registered >= DATE_SUB(NOW(), INTERVAL %d DAY)
         ORDER BY user_registered DESC",
        30
    )
);

4. `wp_usermeta` — User Preferences and Roles

Just like wp_postmeta extends posts, wp_usermeta extends users.

CREATE TABLE wp_usermeta (
    umeta_id   BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT,
    user_id    BIGINT(20) UNSIGNED NOT NULL DEFAULT 0,
    meta_key   VARCHAR(255) DEFAULT NULL,
    meta_value LONGTEXT,
    PRIMARY KEY (umeta_id),
    KEY user_id (user_id),
    KEY meta_key (meta_key(191))
);

Key rows stored here:

`meta_key`	Example `meta_value`	Meaning
`wp_capabilities`	`a:1:{s:13:"administrator";b:1;}`	User role
`wp_user_level`	`10`	Legacy user level
`session_tokens`	(serialized array)	Active login sessions
`dismissed_wp_pointers`	`wp111_privacy`	Admin UI tips dismissed
`show_admin_bar_front`	`true`	Admin bar visibility

💡 Interesting Fact: User roles are stored as serialized PHP arrays in wp_usermeta. The key is {prefix}capabilities. This is why switching table prefixes can break user roles — the key name changes!

5. `wp_options` — The Site's Brain

This is arguably the most queried table in WordPress on every single page load. Every WordPress setting, every plugin configuration, every theme mod — it all ends up here.

CREATE TABLE wp_options (
    option_id    BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT,
    option_name  VARCHAR(191) NOT NULL DEFAULT '',
    option_value LONGTEXT NOT NULL,
    autoload     VARCHAR(20) NOT NULL DEFAULT 'yes',
    PRIMARY KEY (option_id),
    UNIQUE KEY option_name (option_name),
    KEY autoload (autoload)
);

The autoload column is critical. If set to yes, WordPress loads this option on every single page request via a single SELECT query. Too many autoloaded options = slow site.

Key options and what they control:

`option_name`	Example Value	Controls
`siteurl`	`https://example.com`	Site URL
`blogname`	`My Awesome Site`	Site title
`blogdescription`	`Just another site`	Tagline
`admin_email`	`admin@example.com`	Admin email
`active_plugins`	(serialized array)	Active plugins list
`template`	`twentytwentyfour`	Active theme
`permalink_structure`	`/%postname%/`	URL structure
`uploads_use_yearmonth_folders`	`1`	Media organization
`wp_user_roles`	(serialized array)	All defined roles

Real-world example:

// Check autoloaded options bloat
$autoloaded = $wpdb->get_results(
    "SELECT option_name, LENGTH(option_value) as option_size
     FROM {$wpdb->options}
     WHERE autoload = 'yes'
     ORDER BY option_size DESC
     LIMIT 20"
);

foreach ( $autoloaded as $option ) {
    echo esc_html( $option->option_name ) . ': ' . esc_html( size_format( $option->option_size ) ) . '<br>';
}

6. `wp_terms` — The Taxonomy Vocabulary

Terms are the individual labels — like a category named "Technology" or a tag called "JavaScript".

CREATE TABLE wp_terms (
    term_id    BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT,
    name       VARCHAR(200) NOT NULL DEFAULT '',
    slug       VARCHAR(200) NOT NULL DEFAULT '',
    term_group BIGINT(10) NOT NULL DEFAULT 0,
    PRIMARY KEY (term_id),
    KEY slug (slug(191)),
    KEY name (name(191))
);

7. `wp_term_taxonomy` — What Kind of Term Is It?

A term alone doesn't know if it's a category, tag, or custom taxonomy. That's wp_term_taxonomy's job.

CREATE TABLE wp_term_taxonomy (
    term_taxonomy_id BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT,
    term_id          BIGINT(20) UNSIGNED NOT NULL DEFAULT 0,
    taxonomy         VARCHAR(32) NOT NULL DEFAULT '',
    description      LONGTEXT NOT NULL,
    parent           BIGINT(20) UNSIGNED NOT NULL DEFAULT 0,
    count            BIGINT(20) NOT NULL DEFAULT 0,
    PRIMARY KEY (term_taxonomy_id),
    UNIQUE KEY term_id_taxonomy (term_id, taxonomy),
    KEY taxonomy (taxonomy)
);

taxonomy column values:

Value	Represents
`category`	Post categories
`post_tag`	Post tags
`nav_menu`	Navigation menus
`link_category`	Blogroll categories
`wp_theme`	Theme-related terms
`product_cat`	WooCommerce categories

8. `wp_term_relationships` — The Many-to-Many Bridge

This table connects posts to their terms. A post can have many categories; a category can have many posts. Classic many-to-many.

CREATE TABLE wp_term_relationships (
    object_id        BIGINT(20) UNSIGNED NOT NULL DEFAULT 0,
    term_taxonomy_id BIGINT(20) UNSIGNED NOT NULL DEFAULT 0,
    term_order       INT(11) NOT NULL DEFAULT 0,
    PRIMARY KEY (object_id, term_taxonomy_id),
    KEY term_taxonomy_id (term_taxonomy_id)
);

Real-world example:

// Get all posts in the "News" category (term_id = 5)
$news_posts = $wpdb->get_results(
    $wpdb->prepare(
        "SELECT p.ID, p.post_title
         FROM {$wpdb->posts} p
         INNER JOIN {$wpdb->term_relationships} tr ON p.ID = tr.object_id
         INNER JOIN {$wpdb->term_taxonomy} tt ON tr.term_taxonomy_id = tt.term_taxonomy_id
         WHERE tt.term_id = %d
         AND tt.taxonomy = %s
         AND p.post_status = %s",
        5,
        'category',
        'publish'
    )
);

9. `wp_termmeta` — Metadata for Terms

Added in WordPress 4.4, this table works the same as wp_postmeta and wp_usermeta but for taxonomy terms.

CREATE TABLE wp_termmeta (
    meta_id    BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT,
    term_id    BIGINT(20) UNSIGNED NOT NULL DEFAULT 0,
    meta_key   VARCHAR(255) DEFAULT NULL,
    meta_value LONGTEXT,
    PRIMARY KEY (meta_id),
    KEY term_id (term_id),
    KEY meta_key (meta_key(191))
);

Common use cases:

Storing a category's banner image ID
WooCommerce product category thumbnails
Custom taxonomy term colors or icons

10. `wp_comments` — Every Comment Ever Made

CREATE TABLE wp_comments (
    comment_ID           BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT,
    comment_post_ID      BIGINT(20) UNSIGNED NOT NULL DEFAULT 0,
    comment_author       TINYTEXT NOT NULL,
    comment_author_email VARCHAR(100) NOT NULL DEFAULT '',
    comment_author_url   VARCHAR(200) NOT NULL DEFAULT '',
    comment_author_IP    VARCHAR(100) NOT NULL DEFAULT '',
    comment_date         DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
    comment_date_gmt     DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
    comment_content      TEXT NOT NULL,
    comment_karma        INT(11) NOT NULL DEFAULT 0,
    comment_approved     VARCHAR(20) NOT NULL DEFAULT '1',
    comment_agent        VARCHAR(255) NOT NULL DEFAULT '',
    comment_type         VARCHAR(20) NOT NULL DEFAULT 'comment',
    comment_parent       BIGINT(20) UNSIGNED NOT NULL DEFAULT 0,
    user_id              BIGINT(20) UNSIGNED NOT NULL DEFAULT 0,
    PRIMARY KEY (comment_ID)
);

comment_approved values:

Value	Meaning
`1`	Approved (visible)
`0`	Pending moderation
`spam`	Marked as spam
`trash`	Soft deleted

11. `wp_commentmeta` — Comment Metadata

Same EAV pattern — extended data for comments. Akismet stores its spam detection data here.

CREATE TABLE wp_commentmeta (
    meta_id    BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT,
    comment_id BIGINT(20) UNSIGNED NOT NULL DEFAULT 0,
    meta_key   VARCHAR(255) DEFAULT NULL,
    meta_value LONGTEXT,
    PRIMARY KEY (meta_id),
    KEY comment_id (comment_id),
    KEY meta_key (meta_key(191))
);

12. `wp_links` — The Legacy Blogroll

CREATE TABLE wp_links (
    link_id          BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT,
    link_url         VARCHAR(255) NOT NULL DEFAULT '',
    link_name        VARCHAR(255) NOT NULL DEFAULT '',
    link_image       VARCHAR(255) NOT NULL DEFAULT '',
    link_target      VARCHAR(25) NOT NULL DEFAULT '',
    link_description VARCHAR(255) NOT NULL DEFAULT '',
    link_visible     VARCHAR(20) NOT NULL DEFAULT 'Y',
    link_owner       BIGINT(20) UNSIGNED NOT NULL DEFAULT 1,
    link_rating      INT(11) NOT NULL DEFAULT 0,
    link_updated     DATETIME NOT NULL DEFAULT '0000-00-00 00:00-00',
    link_rel         VARCHAR(255) NOT NULL DEFAULT '',
    link_notes       MEDIUMTEXT NOT NULL,
    link_rss         VARCHAR(255) NOT NULL DEFAULT '',
    PRIMARY KEY (link_id),
    KEY link_visible (link_visible)
);

📌 Worth Knowing: wp_links is a relic from the blogroll era (pre-WordPress 3.5). The Links Manager was hidden in WordPress 3.5 and is no longer shown by default. You'll still find it in the database, and some legacy plugins still use it — but for new projects, it's effectively retired.

🗺️ Admin Settings ↔ Database Table Mapping

Here's where it all comes together. This is the cheat sheet you'll want to bookmark.

Settings → General

Admin Setting	Table	`option_name` / Column
Site Title	`wp_options`	`blogname`
Tagline	`wp_options`	`blogdescription`
WordPress Address (URL)	`wp_options`	`siteurl`
Site Address (URL)	`wp_options`	`home`
Admin Email	`wp_options`	`admin_email`
Membership (Anyone can register)	`wp_options`	`users_can_register`
New User Default Role	`wp_options`	`default_role`
Site Language	`wp_options`	`WPLANG`
Timezone	`wp_options`	`timezone_string`
Date Format	`wp_options`	`date_format`
Time Format	`wp_options`	`time_format`

Settings → Reading

Admin Setting	Table	`option_name`
Your homepage displays	`wp_options`	`show_on_front` (`posts`/`page`)
Homepage (static page)	`wp_options`	`page_on_front` (stores Post ID)
Posts page	`wp_options`	`page_for_posts` (stores Post ID)
Blog pages show at most	`wp_options`	`posts_per_page`
Syndication feeds show	`wp_options`	`posts_per_rss`
Search engine visibility	`wp_options`	`blog_public`

Settings → Discussion

Admin Setting	Table	`option_name`
Allow comments on new posts	`wp_options`	`default_comment_status`
Comment must be approved	`wp_options`	`comment_moderation`
Hold comment for moderation	`wp_options`	`comment_max_links`
Comment author must have approved comment	`wp_options`	`comment_previously_approved`
Before a comment appears	`wp_options`	`require_name_email`
Notify by email (new comment)	`wp_options`	`comments_notify`

Settings → Permalinks

Admin Setting	Table	`option_name`
Permalink structure	`wp_options`	`permalink_structure`
Category base	`wp_options`	`category_base`
Tag base	`wp_options`	`tag_base`

Posts & Pages (Content)

Admin Section	Table Affected	Key Column
New Post / Draft / Publish	`wp_posts`	`post_status`, `post_date`
Post Categories	`wp_terms`, `wp_term_taxonomy`, `wp_term_relationships`	`taxonomy = 'category'`
Post Tags	`wp_terms`, `wp_term_taxonomy`, `wp_term_relationships`	`taxonomy = 'post_tag'`
Featured Image	`wp_postmeta`	`meta_key = '_thumbnail_id'`
Custom Fields	`wp_postmeta`	Any custom `meta_key`
Page Template	`wp_postmeta`	`meta_key = '_wp_page_template'`
Revisions	`wp_posts`	`post_type = 'revision'`
Media Uploads	`wp_posts`, `wp_postmeta`	`post_type = 'attachment'`

Users & Profiles

Admin Section	Table Affected	Key Column
Add New User	`wp_users`	`user_login`, `user_email`
User Role	`wp_usermeta`	`meta_key = 'wp_capabilities'`
Profile bio, URL	`wp_usermeta`	`meta_key = 'description'`, `'url'`
Application Passwords	`wp_usermeta`	`meta_key = '_application_passwords'`
Sessions	`wp_usermeta`	`meta_key = 'session_tokens'`

Appearance → Menus

Admin Section	Table Affected	Notes
Menu structure	`wp_posts`	Each item = a row with `post_type = 'nav_menu_item'`
Menu assignment	`wp_term_taxonomy`	`taxonomy = 'nav_menu'`
Menu items order	`wp_postmeta`	`meta_key = '_menu_item_menu_item_parent'`

Comments

Admin Section	Table Affected	Key Column
Approved comments	`wp_comments`	`comment_approved = '1'`
Pending comments	`wp_comments`	`comment_approved = '0'`
Spam	`wp_comments`	`comment_approved = 'spam'`
Trash	`wp_comments`	`comment_approved = 'trash'`
Akismet spam data	`wp_commentmeta`	`meta_key = 'akismet_*'`

🔍 Bonus: How WordPress Uses Its Tables Together (A Query Walkthrough)

Let's trace what happens when WordPress loads a single blog post page (/?p=42):

-- Step 1: Get the post
SELECT * FROM wp_posts WHERE ID = 42 AND post_status = 'publish';

-- Step 2: Get all post meta (custom fields, featured image, SEO data)
SELECT meta_key, meta_value FROM wp_postmeta WHERE post_id = 42;

-- Step 3: Get post categories and tags
SELECT t.name, t.slug, tt.taxonomy
FROM wp_terms t
INNER JOIN wp_term_taxonomy tt ON t.term_id = tt.term_id
INNER JOIN wp_term_relationships tr ON tt.term_taxonomy_id = tr.term_taxonomy_id
WHERE tr.object_id = 42;

-- Step 4: Get approved comments
SELECT * FROM wp_comments WHERE comment_post_ID = 42 AND comment_approved = '1';

-- Step 5: Get site options (runs on every request via autoload)
SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes';

That's a minimum of 5 queries for a single page load — and that's before any plugin adds its own. This is why query caching and object caching are so important in WordPress performance tuning (which we'll cover in the next article).

💡 Multisite: How Tables Scale

When WordPress Multisite is enabled, each subsite gets its own set of prefixed tables:

wp_posts          ← Site 1 (main)
wp_2_posts        ← Site 2
wp_3_posts        ← Site 3
wp_options        ← Site 1 (main)
wp_2_options      ← Site 2
wp_3_options      ← Site 3

But some tables are shared across the network:

Shared Table	Purpose
`wp_users`	All users across all sites
`wp_usermeta`	All user metadata (capabilities per site stored here)
`wp_blogs`	Registry of all sites in the network
`wp_site`	Network-level site data
`wp_sitemeta`	Network-level settings
`wp_blog_versions`	DB version tracking per site
`wp_registration_log`	User registration log
`wp_signups`	Pending user/blog signups

🧹 Common Database Health Issues (And Which Tables to Check)

Problem	Table to Inspect	What to Look For
Site slowing down	`wp_options`	Bloated autoloaded options
Revisions eating storage	`wp_posts`	Rows with `post_type = 'revision'`
Orphaned metadata	`wp_postmeta`	`meta_key = '_edit_lock'` with no matching post
Spam comments	`wp_comments`	`comment_approved = 'spam'` piling up
Transient clutter	`wp_options`	`option_name LIKE '_transient_%'`
User role issues	`wp_usermeta`	Corrupted `wp_capabilities` serialized data

🎯 Final Thoughts

WordPress's database schema is deceptively simple on the surface — just 12 tables. But once you understand what each table does, how they relate to each other, and how the admin panel maps directly to rows and columns, you start to see WordPress not as a blogging tool, but as a well-engineered content framework that's been refined over 20 years.

Key takeaways from this article:

wp_posts is the universal content container — not just posts, but pages, menus, attachments, and custom post types
The EAV pattern (postmeta, usermeta, options) makes WordPress extensible but requires careful query design
wp_options with autoload = 'yes' runs on every request — keep it lean
The prefix system enables multisite scalability and adds a basic security layer
Every admin UI action maps directly to a database operation you can inspect and optimize Understanding this foundation isn't just academic — it directly affects how fast your queries run, how you architect custom plugins, and how you protect your data.

🔜 Next Up: DB Performance & Security in WordPress

Now that you know what the tables are, the next article dives into how to protect and optimize them:

Indexing strategies for high-traffic WordPress sites
Transient API — the right way to cache DB queries
Query Monitor — profiling slow queries in real time
Hardening — changing table prefixes, restricting DB permissions, and preventing SQL injection
Backup strategies and point-in-time recovery
WP_Query vs $wpdb — when to use each > 📌 Save this article and follow along — the next one is where the real performance gains are.

Did this article help you understand WordPress's database structure better? Drop a comment below — especially if you've run into a tricky table-related bug in the wild. Those make the best war stories. 🛠️

Performance Optimization & Advanced Patterns in React

Kushang Tailor — Thu, 04 Jun 2026 04:27:55 +0000

Read Time: ~13 minutes | Real techniques to make your React apps genuinely fast

Prerequisites: Custom hooks, useReducer, Context API (Parts 1 & 2)

📌 What You'll Learn

By the end of this guide, you'll be able to:

✅ Understand exactly how and when React re-renders
✅ Use React.memo to stop unnecessary re-renders
✅ Apply useMemo and useCallback correctly (not blindly)
✅ Split code and lazy-load components with React.lazy + Suspense
✅ Profile and diagnose bottlenecks with React DevTools
✅ Optimize a real 1,000-item product dashboard
✅ Measure real before/after performance gains

⚡ Why Performance Actually Matters

Before jumping into code, let's anchor this in reality.

A 1-second delay in page response → 7% drop in conversions
A 100ms improvement in load time  → 1% increase in revenue (Amazon)
53% of mobile users leave          → if page takes > 3s to load

React apps can get slow in very specific ways—usually not because React itself is slow, but because we accidentally make it do more work than necessary.

The golden rule of React performance:

"Don't re-render what hasn't changed."

🔄 How React Rendering Works (The Foundation)

Before you optimize anything, you need to understand why React re-renders.

The 3 Triggers for a Re-render

1. State changes       → setState or useState setter called
2. Props change        → Parent passed new values
3. Context changes     → A Provider's value changed

The Ripple Effect (The Real Problem)

function Parent() {
  const [count, setCount] = useState(0);

  return (
    <div>
      <button onClick={() => setCount(count + 1)}>Click: {count}</button>
      <Child />        {/* Re-renders every time! Even if nothing changed */}
      <AnotherChild /> {/* Re-renders too! */}
    </div>
  );
}

When Parent re-renders, every child re-renders by default—even if their props didn't change. With 50 components, this becomes a problem fast.

🛡️ React.memo: Stop Unnecessary Re-renders

React.memo is a higher-order component that memoizes your component. It only re-renders if its props actually changed.

Without React.memo (Expensive)

// ❌ ProductCard re-renders on every parent update
function ProductCard({ product }) {
  console.log(`Rendering: ${product.name}`);
  return (
    <div>
      <h3>{product.name}</h3>
      <p>${product.price}</p>
    </div>
  );
}

// In a list of 1000 products = 1000 unnecessary re-renders

With React.memo (Efficient)

// ✅ Only re-renders when product prop actually changes
const ProductCard = React.memo(function ProductCard({ product }) {
  console.log(`Rendering: ${product.name}`);
  return (
    <div>
      <h3>{product.name}</h3>
      <p>${product.price}</p>
    </div>
  );
});

Custom Comparison for React.memo

// React.memo does shallow comparison by default
// For complex objects, provide a custom comparator:

const ProductCard = React.memo(
  function ProductCard({ product, onBuyClick }) {
    return (
      <div>
        <h3>{product.name}</h3>
        <button onClick={() => onBuyClick(product.id)}>Buy</button>
      </div>
    );
  },
  // Custom comparator: only re-render if these specific fields changed
  (prevProps, nextProps) =>
    prevProps.product.id === nextProps.product.id &&
    prevProps.product.price === nextProps.product.price
);

When to use React.memo:

✅ Components that render frequently with the same props
✅ Large lists (50+ items)
✅ Components with expensive calculations in render
❌ Simple components (overhead isn't worth it)

🧠 useMemo: Cache Expensive Calculations

useMemo memoizes the result of a function. React skips recalculating it unless dependencies change.

Without useMemo (Recalculates Every Render)

function ProductDashboard({ products, filters }) {
  // ❌ This runs on EVERY render—even if products/filters didn't change
  const filteredProducts = products
    .filter(p => p.price >= filters.minPrice && p.price <= filters.maxPrice)
    .filter(p => filters.category === 'all' || p.category === filters.category)
    .sort((a, b) => b.rating - a.rating)
    .slice(0, 100);

  return <ProductList items={filteredProducts} />;
}

With useMemo (Only Recalculates When Dependencies Change)

import { useMemo } from 'react';

function ProductDashboard({ products, filters }) {
  // ✅ Only recalculates when products or filters actually change
  const filteredProducts = useMemo(() => {
    return products
      .filter(p => p.price >= filters.minPrice && p.price <= filters.maxPrice)
      .filter(p => filters.category === 'all' || p.category === filters.category)
      .sort((a, b) => b.rating - a.rating)
      .slice(0, 100);
  }, [products, filters]);

  return <ProductList items={filteredProducts} />;
}

useMemo for Derived Statistics

function SalesDashboard({ orders }) {
  // Expensive aggregation—only recalculate when orders change
  const stats = useMemo(() => ({
    totalRevenue: orders.reduce((sum, o) => sum + o.total, 0),
    averageOrder: orders.reduce((sum, o) => sum + o.total, 0) / orders.length,
    topProduct: orders
      .flatMap(o => o.items)
      .reduce((acc, item) => {
        acc[item.name] = (acc[item.name] || 0) + item.quantity;
        return acc;
      }, {}),
    conversionRate: (orders.filter(o => o.completed).length / orders.length) * 100
  }), [orders]);

  return (
    <div>
      <StatCard label="Revenue" value={`$${stats.totalRevenue}`} />
      <StatCard label="Avg Order" value={`$${stats.averageOrder.toFixed(2)}`} />
      <StatCard label="Conversion" value={`${stats.conversionRate.toFixed(1)}%`} />
    </div>
  );
}

⚠️ The useMemo Mistake Most Developers Make

// ❌ DON'T memoize cheap calculations—overhead cost > savings
const doubled = useMemo(() => count * 2, [count]);

// ✅ DO memoize genuinely expensive calculations
const processedData = useMemo(() => heavyDataTransformation(dataset), [dataset]);

Rule of thumb: Use useMemo when the calculation takes noticeable time (>1ms) or when the result is passed to a memoized child component.

📞 useCallback: Stable Function References

useCallback memoizes a function itself. This matters because new function instances on every render break React.memo.

The Problem (Why We Need useCallback)

function Parent() {
  const [count, setCount] = useState(0);

  // ❌ New function reference on every render!
  // React.memo on Child won't help—it sees a "new" prop every time
  const handleClick = (id) => {
    console.log(`Clicked: ${id}`);
  };

  return (
    <>
      <button onClick={() => setCount(c => c + 1)}>Update: {count}</button>
      <MemoizedChild onItemClick={handleClick} />
    </>
  );
}

The Solution (useCallback + React.memo Pair)

import { useCallback } from 'react';

function Parent() {
  const [count, setCount] = useState(0);
  const [cart, setCart] = useState([]);

  // ✅ Same function reference—only changes when cart changes
  const handleAddToCart = useCallback((product) => {
    setCart(prev => [...prev, product]);
  }, []); // Empty deps—setCart is stable, no need to include

  // ✅ Same function reference—only changes when cart changes
  const handleRemoveFromCart = useCallback((productId) => {
    setCart(prev => prev.filter(p => p.id !== productId));
  }, []);

  return (
    <>
      <button onClick={() => setCount(c => c + 1)}>Update: {count}</button>
      <MemoizedProductList
        onAdd={handleAddToCart}
        onRemove={handleRemoveFromCart}
      />
    </>
  );
}

// React.memo now works correctly—stable function references
const MemoizedProductList = React.memo(function ProductList({ onAdd, onRemove }) {
  return <div>...products...</div>;
});

React.memo + useCallback = Real Gains

Without optimization: 1000 items × parent update = 1000 re-renders
With React.memo only: 1000 items × new function ref = 1000 re-renders (same!)
With React.memo + useCallback: 1000 items × same function ref = 0 re-renders ✅

✂️ Code Splitting: Load Only What You Need

A React app bundled as one giant file makes users download everything—even pages they never visit. Code splitting fixes this.

Without Code Splitting (Heavy Initial Load)

// ❌ Every page loads at startup—even ones user never visits
import Dashboard from './pages/Dashboard';
import Analytics from './pages/Analytics'; // Heavy charts library
import AdminPanel from './pages/AdminPanel'; // Rarely visited
import Reports from './pages/Reports';

function App() {
  return (
    <Routes>
      <Route path="/dashboard" element={<Dashboard />} />
      <Route path="/analytics" element={<Analytics />} />
      <Route path="/admin" element={<AdminPanel />} />
      <Route path="/reports" element={<Reports />} />
    </Routes>
  );
}

With React.lazy + Suspense (Smart Loading)

import { lazy, Suspense } from 'react';

// ✅ Each page only loads when the user navigates to it
const Dashboard  = lazy(() => import('./pages/Dashboard'));
const Analytics  = lazy(() => import('./pages/Analytics'));
const AdminPanel = lazy(() => import('./pages/AdminPanel'));
const Reports    = lazy(() => import('./pages/Reports'));

function App() {
  return (
    <Suspense fallback={<LoadingSpinner />}>
      <Routes>
        <Route path="/dashboard" element={<Dashboard />} />
        <Route path="/analytics" element={<Analytics />} />
        <Route path="/admin" element={<AdminPanel />} />
        <Route path="/reports" element={<Reports />} />
      </Routes>
    </Suspense>
  );
}

function LoadingSpinner() {
  return (
    <div style={{ display: 'flex', justifyContent: 'center', padding: '2rem' }}>
      <div className="spinner">Loading...</div>
    </div>
  );
}

Real impact: Splitting a 2 MB bundle into 6 route-based chunks means the home page loads a 300 KB chunk instead of 2 MB. That's a 6× improvement in initial load.

Component-Level Splitting (Heavy Components)

// Lazy load a heavy chart component (D3, chart.js etc.)
const HeavyChart = lazy(() => import('./components/HeavyChart'));
const RichTextEditor = lazy(() => import('./components/RichTextEditor'));

function ProductPage({ product }) {
  const [showChart, setShowChart] = useState(false);

  return (
    <div>
      <h1>{product.name}</h1>
      <button onClick={() => setShowChart(true)}>View Price History</button>

      {showChart && (
        <Suspense fallback={<p>Loading chart...</p>}>
          <HeavyChart data={product.priceHistory} />
        </Suspense>
      )}
    </div>
  );
}

🔬 React DevTools Profiler: Find Real Bottlenecks

Never guess at performance problems. The React DevTools Profiler shows you exactly what's slow.

Setup

1. Install React DevTools browser extension (Chrome/Firefox)
2. Open DevTools → "Profiler" tab
3. Click the record (●) button
4. Interact with your app
5. Stop recording
6. Analyze the flame graph

Reading the Flame Graph

Flame Graph (wider = longer render time):
┌────────────────────── App (2.1ms) ───────────────────────────────┐
│  ┌─── Header (0.1ms) ─┐  ┌────── ProductList (1.9ms) ──────────┐ │
│  └────────────────────┘  │  ┌── ProductCard (0.8ms) ───────┐   │ │
│                           │  └──────────────────────────────┘   │ │
│                           │  ┌── ProductCard (0.7ms) ───────┐   │ │
│                           │  └──────────────────────────────┘   │ │
│                           └─────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────────┘

💡 ProductList is the bottleneck → optimize here first

What to Look For

🔴 Components re-rendering unnecessarily    → Use React.memo
🔴 Long render times (>16ms)               → Use useMemo
🔴 Cascading re-renders                    → Check Context usage
🔴 Functions recreating on each render     → Use useCallback
🟡 Components rendering >10ms             → Investigate closer
🟢 Components rendering <1ms              → Leave them alone

🏗️ Real-World Optimization: Product Dashboard (Before vs After)

Let's optimize a real slow component—a product dashboard with 1,000+ items.

The Slow Version (Before)

// ❌ Before optimization - renders slowly with large datasets
function ProductDashboard({ products, user }) {
  const [searchTerm, setSearchTerm] = useState('');
  const [sortBy, setSortBy] = useState('name');
  const [category, setCategory] = useState('all');

  // Recalculates on EVERY render (even typing a letter!)
  const filteredProducts = products
    .filter(p => p.name.toLowerCase().includes(searchTerm.toLowerCase()))
    .filter(p => category === 'all' || p.category === category)
    .sort((a, b) => a[sortBy] > b[sortBy] ? 1 : -1);

  // New function on every render—breaks memoization downstream
  const handleAddToWishlist = (id) => {
    api.addToWishlist(user.id, id);
  };

  return (
    <div>
      <SearchBar value={searchTerm} onChange={e => setSearchTerm(e.target.value)} />
      <FilterBar onSort={setSortBy} onCategory={setCategory} />
      <div className="product-grid">
        {filteredProducts.map(product => (
          // Re-renders ALL cards on every keystroke
          <ProductCard
            key={product.id}
            product={product}
            onWishlist={handleAddToWishlist}
          />
        ))}
      </div>
    </div>
  );
}

Performance Profile (Before):

Typing one character in search:
→ filteredProducts recalculates: 1000 items × filter × sort = ~18ms
→ All 1000 ProductCards re-render: ~45ms
→ Total: ~63ms per keystroke = janky, visible lag

The Optimized Version (After)

import { useState, useMemo, useCallback } from 'react';

// ✅ After optimization - smooth at any scale

// Memoize ProductCard so it only re-renders when its own data changes
const ProductCard = React.memo(function ProductCard({ product, onWishlist }) {
  return (
    <div className="product-card">
      <img src={product.image} alt={product.name} loading="lazy" />
      <h3>{product.name}</h3>
      <p>${product.price}</p>
      <span className="badge">{product.category}</span>
      <button onClick={() => onWishlist(product.id)}>♡ Wishlist</button>
    </div>
  );
});

function ProductDashboard({ products, user }) {
  const [searchTerm, setSearchTerm] = useState('');
  const [sortBy, setSortBy] = useState('name');
  const [category, setCategory] = useState('all');

  // ✅ Only recalculates when its dependencies change
  const filteredProducts = useMemo(() => {
    const lower = searchTerm.toLowerCase();
    return products
      .filter(p => p.name.toLowerCase().includes(lower))
      .filter(p => category === 'all' || p.category === category)
      .sort((a, b) => a[sortBy] > b[sortBy] ? 1 : -1);
  }, [products, searchTerm, category, sortBy]);

  // ✅ Same function reference—memoized children stay stable
  const handleAddToWishlist = useCallback((id) => {
    api.addToWishlist(user.id, id);
  }, [user.id]);

  return (
    <div>
      <SearchBar value={searchTerm} onChange={e => setSearchTerm(e.target.value)} />
      <FilterBar onSort={setSortBy} onCategory={setCategory} />
      <div className="product-grid">
        {filteredProducts.map(product => (
          <ProductCard
            key={product.id}
            product={product}
            onWishlist={handleAddToWishlist}
          />
        ))}
      </div>
    </div>
  );
}

Performance Profile (After):

Typing one character in search:
→ filteredProducts recalculates: still ~8ms (filtering is inherent work)
→ Only changed ProductCards re-render: ~2ms (most skip!)
→ Total: ~10ms per keystroke = smooth, no visible lag

Improvement: 63ms → 10ms = 6.3× faster 🚀

📜 Virtualization: The Nuclear Option for Long Lists

When you have 10,000+ items, even memoized renders are too slow. Virtualization renders only what's visible on screen.

import { FixedSizeList } from 'react-window'; // npm install react-window

function VirtualizedProductList({ products }) {
  const Row = ({ index, style }) => (
    <div style={style}>
      <ProductCard product={products[index]} />
    </div>
  );

  return (
    <FixedSizeList
      height={600}      // Visible container height
      itemCount={products.length}
      itemSize={120}    // Each row height in px
      width="100%"
    >
      {Row}
    </FixedSizeList>
  );
}

Without virtualization: 10,000 DOM nodes = browser struggles
With virtualization:    ~10 DOM nodes visible = butter smooth 🧈

DOM nodes rendered: 10,000 → ~10 (99.9% reduction)

📊 Performance Benchmarks: Real Numbers

Here's what these optimizations actually deliver at different scales:

Dataset Size	Before (ms)	After (ms)	Improvement
100 items	8ms	3ms	2.7× faster
500 items	28ms	6ms	4.7× faster
1,000 items	63ms	10ms	6.3× faster
5,000 items	290ms	15ms	19× faster
10,000 items	600ms+	18ms (virtual)	33× faster

Techniques Used by Dataset Size

Size	Use
1–50 items	Nothing needed
50–500 items	React.memo + useCallback
500–5,000 items	+ useMemo for filtering
5,000+ items	+ react-window virtualization

⚙️ Additional Quick Wins

1. Lazy Load Images

// ✅ Images only load when in viewport
<img src={product.image} alt={product.name} loading="lazy" />

2. Debounce Search Input

import { useMemo } from 'react';
import { debounce } from 'lodash';

function SearchBar({ onSearch }) {
  // Debounce: only fires after user stops typing for 300ms
  const debouncedSearch = useMemo(
    () => debounce(onSearch, 300),
    [onSearch]
  );

  return <input onChange={e => debouncedSearch(e.target.value)} />;
}

3. Avoid Object/Array Literals in JSX

// ❌ New object created every render
<Component style={{ color: 'red', margin: 16 }} />

// ✅ Stable reference
const STYLE = { color: 'red', margin: 16 };
<Component style={STYLE} />

4. Key Prop Best Practices

// ❌ Using index as key breaks memoization when list reorders
{items.map((item, index) => <Item key={index} item={item} />)}

// ✅ Use stable, unique ID
{items.map(item => <Item key={item.id} item={item} />)}

🎯 Performance Optimization Checklist

Before shipping any React app, run through these:

Render Efficiency
□ No unnecessary re-renders (check with Profiler)
□ React.memo on frequently-rendered components
□ useCallback for functions passed as props
□ useMemo for expensive calculations
□ Stable keys in all lists (not index)
□ Avoid new objects/arrays in JSX props

Bundle Size
□ Route-based code splitting with React.lazy
□ Heavy components split and lazy-loaded
□ Tree-shaking verified (check bundle analyzer)
□ Dependencies audited (remove unused ones)

Load Performance
□ Images have loading="lazy"
□ Search inputs debounced
□ API calls appropriately cached
□ Virtualization for lists > 1000 items

💡 The Optimization Mindset

Here's something most articles won't tell you: premature optimization is a mistake.

Don't add useMemo and useCallback everywhere by default. Every memoization adds:

Memory overhead (storing the cached value)
Complexity (developers must understand the dependency array)
Potential bugs (stale closures from wrong dependencies)

The right workflow is:

1. Build it first       → Write clean, readable code
2. Measure it           → Profile with React DevTools
3. Find the bottleneck  → Identify the actual slow part
4. Optimize that part   → Apply the right technique
5. Measure again        → Confirm improvement

"Measure, don't guess."

🔗 Quick Resources

React DevTools: Chrome Web Store → Search "React DevTools"
react-window: github.com/bvaughn/react-window — Virtualized lists
Bundle Analyzer: webpack-bundle-analyzer — Visualize your bundle
Why Did You Render: github.com/welldone-software/why-did-you-render — Track unnecessary renders
React Profiler API: react.dev/reference/react/Profiler

🚀 Final Thoughts: Fast React is Intentional React

Performance isn't luck. The patterns in this article—memoization, code splitting, virtualization, and profiling—are deliberate decisions you make at the right moment.

The hierarchy:

Step 1: Write correct, clean code first
Step 2: Profile to identify slow components
Step 3: Apply React.memo to stop re-renders
Step 4: Apply useCallback to stabilize function props
Step 5: Apply useMemo to skip expensive calculations
Step 6: Code split heavy routes and components
Step 7: Virtualize lists beyond 1000 items
Step 8: Profile again to confirm wins

You don't need all eight steps for every app—just the ones your profiler tells you to.

💬 What's Your Performance Story?

Have you ever shipped a slow React app and had to go back and optimize it? What was the bottleneck—re-renders, bundle size, or something else entirely? Drop your story in the comments!

Covered in Part 4:

Next.js file-based routing
Server vs Client Components
API routes that replace a backend
getStaticProps vs getServerSideProps
Deploying to Vercel in under 10 minutes

Happy optimizing! 🚀

Google I/O 2026: Welcome to the Agentic Gemini Era 🚀

Kushang Tailor — Tue, 02 Jun 2026 11:05:18 +0000

Ten years after going "AI-first," Google didn't just show up at I/O 2026 — it showed up with receipts.

Held on May 19–20 at the Shoreline Amphitheatre in Mountain View, California, Google I/O 2026 was less of a developer conference and more of a statement. CEO Sundar Pichai took the stage with a clear message: AI shouldn't just answer your questions — it should work for you, around the clock, across every screen you own. Here's everything that dropped, broken down cleanly.

🧠 The Star of the Show: Gemini Gets a Full Glow-Up

If there's one thread running through every single I/O 2026 announcement, it's Gemini. Google didn't just update its AI — it rebuilt the entire experience around it.

Gemini 3.5 Flash

Google launched Gemini 3.5 Flash, a faster, more efficient multimodal model built for real-world performance across devices. It's not just about raw power — it's about making AI feel instant rather than impressive.

Gemini Omni

This is the headline model. Gemini Omni can take text, images, audio, video clips — basically anything — and transform them into entirely new outputs. During the keynote demo, users changed video backgrounds, applied cinematic effects, and created selfie-based avatar videos just by describing what they wanted. All Omni-generated content is automatically watermarked via SynthID, so you'll always know what was AI-made.

Gemini Spark — Your 24/7 AI Agent

Think of Gemini Spark as the AI that never clocks out. It's a personal AI agent that proactively manages your tasks, sends you relevant updates, and keeps working in the background — even when you've moved on. It's launching first in the U.S. as part of the AI Ultra plan ($100/month) and rolls out globally soon after.

New Gemini App Design

The Gemini app got a complete redesign with a smarter search box that accepts text, images, files, videos, and even Chrome tabs as inputs. Regional dialects are now supported too, making the experience feel far more personal.

🔍 Search Just Got Its Biggest Upgrade in Decades

Google Search didn't get a tweak — it got a full rethink.

AI Mode and AI Overviews are now deeply embedded in Search, offering personalized, real-time answers that go beyond a list of links. But the real shift is that Search is now agentic — meaning it can take action, not just answer.

A new intelligent Search box accepts multi-modal inputs (text, images, video, files). And with Gemini Spark integrated, search results can evolve over time — you ask a question once, and Gemini keeps tracking it for you, delivering updates as things change.

Google also introduced "preview of perspectives" — pulling in real discussions from social media and online communities to give Search a more human dimension.

🛒 Shopping Gets Seriously Smart: Universal Cart

One of the most practical announcements? The Universal Cart — and it's genuinely clever.

Add items to your cart from anywhere in Google's ecosystem: while browsing Search, chatting with Gemini, watching YouTube, or even reading Gmail. Once items are in your cart, AI gets to work automatically — hunting for deals, tracking price history, alerting you when something's back in stock, and even flagging incompatible product combinations (live demo showed it catching a mismatched CPU and motherboard mid-build).

It integrates with Google Wallet for loyalty perks and payment optimization, and Gemini Spark can complete the checkout entirely on your behalf. Universal Cart rolls out in the U.S. this summer, with YouTube and Gmail support following shortly after.

👓 Hardware: The Glasses Are (Almost) Here

The most buzz-worthy hardware reveal? Android XR intelligent eyewear — co-developed with Samsung, with designs from Warby Parker and Gentle Monster.

Audio Glasses (arriving Fall 2026) let you listen to music, take calls, make coffee orders, take photos, and access Gemini — all hands-free. Think Ray-Ban Meta glasses, but running on Google's full AI stack.

Display Glasses are still in development, promising in-lens information overlays and live language translation, coming at a later date.

🎬 Creative Tools: Google Flow, Stitch & More

Google expanded its creative suite in a big way:

Google Flow now covers video editing, music production, and creative workflows — all powered by Gemini Omni inside for multi-action jumps across audio and video.
Google Flow Music debuts as a standalone creative tool.
Flow Tools let you customize AI generation agents to match your creative style.
Stitch and Google Pics get new updates empowering designers and marketers to streamline content production with less back-and-forth.

🧑‍💻 Developer Tools: Antigravity 2.0 & AI Studio

Developers weren't left out — not by a long shot.

Antigravity 2.0, Google's answer to GitHub Copilot and Claude Code, launches as a full agent-first desktop IDE powered by Gemini 3.5 Flash. It runs 12x faster on token usage compared to the previous version, supports multi-agent orchestration, and integrates directly with Google Workspace APIs. It's available globally, for free.

Google AI Studio also got major upgrades — native Kotlin support for building Android apps, Workspace integration, and one-click deployment to Cloud Run. There's also a new Migration Agent in Android Studio that converts React Native, iOS, or web-based apps into native Kotlin Android apps — turning weeks of work into just hours.

WebMCP, a proposed open web standard, lets developers expose browser-based tools to AI agents for faster, more precise execution — with an experimental origin trial starting in Chrome 149.

🔬 Gemini for Science: AI That Could Change the World

Perhaps the most quietly significant announcement was Gemini for Science — a collection of AI research tools paired with a Co-Scientist collaborative AI partner designed to help researchers accelerate discoveries. Google demonstrated Gemini running full-scale weather and meteorological simulations, and even modeling cellular behavior to help identify new disease treatments. This isn't just cool tech — it's AI working on genuinely hard problems.

🔒 AI Safety & Transparency: SynthID + CodeMender

Google doubled down on responsible AI development. SynthID — Google's digital watermarking tech — has now embedded imperceptible signals into over 100 billion images, videos, and audio content totalling 60,000 years of material.

The new C2PA content credentials are coming to Gemini and Chrome, letting you right-click any image in Chrome and ask Gemini whether it was AI-generated or camera-captured — and whether it was edited with AI afterward.

For developers, the CodeMender API helps identify and resolve software vulnerabilities automatically, making security less of an afterthought.

⚡ The Engine Behind It All: TPU 8th Gen

Behind every fast AI experience is infrastructure, and Google's is formidable. The 8th-generation TPUs take a dual-chip approach — TPU 8t for large-scale pretraining (nearly 3x the raw computing power of the previous gen) and TPU 8i for inference. Training can now be distributed across more than 1 million TPUs globally, making Google's the largest training cluster in the world.

The Big Picture

Google I/O 2026 wasn't about one killer feature — it was about one clear direction. Gemini is no longer a chatbot. It's becoming the invisible layer running underneath Search, Gmail, YouTube, shopping, your glasses, and your daily workflow. Whether that excites or unnerves you might depend on your comfort with AI doing more of your thinking for you.

But one thing is clear: Google is moving fast, and this year's I/O was less of a preview and more of a promise.

Did a specific announcement catch your eye? Drop a comment — we'd love to know what you're most excited (or worried) about.

Advanced Hooks & State Management Patterns in React

Kushang Tailor — Fri, 29 May 2026 12:51:09 +0000

Read Time: ~14 minutes | Building on React fundamentals to master state management at scale

Prerequisites: Familiarity with React basics, useState, useEffect (Part 1)

📌 What You'll Learn

By the end of this guide, you'll understand:

✅ Creating powerful custom hooks
✅ When and how to use useReducer
✅ Managing state globally with Context API
✅ Redux fundamentals and when to use it
✅ Modern alternatives: Zustand and Jotai
✅ Choosing the right pattern for your project
✅ Real-world shopping cart implementation

🎣 Custom Hooks: Reusing Logic Across Components

Custom hooks are regular JavaScript functions that let you extract component logic into reusable functions. They're one of the most powerful React patterns.

Rule #1: Custom Hooks Must Start with "use"

// ✅ Correct - starts with "use"
function useFormInput(initialValue) {
  const [value, setValue] = useState(initialValue);

  return {
    value,
    bind: {
      value,
      onChange: e => setValue(e.target.value)
    },
    reset: () => setValue(initialValue)
  };
}

// ❌ Wrong - doesn't start with "use"
function formInput(initialValue) { ... }

Example #1: useFormInput Hook

import { useState } from 'react';

function useFormInput(initialValue = '') {
  const [value, setValue] = useState(initialValue);

  return {
    value,
    setValue,
    bind: {
      value,
      onChange: e => setValue(e.target.value)
    },
    reset: () => setValue(initialValue)
  };
}

// Using the custom hook
function LoginForm() {
  const email = useFormInput('');
  const password = useFormInput('');

  const handleSubmit = (e) => {
    e.preventDefault();
    console.log(email.value, password.value);
    email.reset();
    password.reset();
  };

  return (
    <form onSubmit={handleSubmit}>
      <input {...email.bind} placeholder="Email" type="email" />
      <input {...password.bind} placeholder="Password" type="password" />
      <button type="submit">Login</button>
    </form>
  );
}

Why it's powerful: Logic is extracted once, reused everywhere. Need form input validation? Add it once to the hook.

Example #2: useFetch Hook - Data Loading Pattern

This is one of the most practical custom hooks for real projects:

import { useState, useEffect } from 'react';

function useFetch(url, options = {}) {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    let isMounted = true; // Prevent memory leaks

    const fetchData = async () => {
      try {
        setLoading(true);
        const response = await fetch(url, options);
        if (!response.ok) throw new Error(`Error: ${response.status}`);

        const json = await response.json();
        if (isMounted) setData(json);
      } catch (err) {
        if (isMounted) setError(err.message);
      } finally {
        if (isMounted) setLoading(false);
      }
    };

    fetchData();
    return () => { isMounted = false; }; // Cleanup
  }, [url, options]);

  return { data, loading, error };
}

// Using it
function ProductList() {
  const { data: products, loading, error } = useFetch('/api/products');

  if (loading) return <p>Loading products...</p>;
  if (error) return <p>Error: {error}</p>;

  return (
    <ul>
      {products.map(product => (
        <li key={product.id}>{product.name}</li>
      ))}
    </ul>
  );
}

Key insight: The component doesn't need to know about fetch logic—it just uses the hook.

Example #3: useLocalStorage Hook - Persistence Pattern

function useLocalStorage(key, initialValue) {
  const [storedValue, setStoredValue] = useState(() => {
    try {
      const item = window.localStorage.getItem(key);
      return item ? JSON.parse(item) : initialValue;
    } catch (error) {
      console.error(error);
      return initialValue;
    }
  });

  const setValue = (value) => {
    try {
      const valueToStore = value instanceof Function ? value(storedValue) : value;
      setStoredValue(valueToStore);
      window.localStorage.setItem(key, JSON.stringify(valueToStore));
    } catch (error) {
      console.error(error);
    }
  };

  return [storedValue, setValue];
}

// Using it - Dark mode preference persists across page reloads
function App() {
  const [isDarkMode, setIsDarkMode] = useLocalStorage('darkMode', false);

  return (
    <div className={isDarkMode ? 'dark' : 'light'}>
      <button onClick={() => setIsDarkMode(!isDarkMode)}>
        Toggle Dark Mode
      </button>
    </div>
  );
}

🔄 useReducer: Complex State Logic

When you have multiple state variables that depend on each other, useReducer is cleaner than useState.

useReducer vs useState

Scenario	Best Choice
Single simple value (count, toggle)	useState
Multiple related values	useReducer
State depends on previous state	useReducer
Complex state transitions	useReducer
Need to pass dispatch to children	useReducer

Complete useReducer Example: Todo App

import { useReducer } from 'react';

// Reducer function - pure, testable
function todoReducer(state, action) {
  switch(action.type) {
    case 'ADD_TODO':
      return {
        ...state,
        todos: [...state.todos, {
          id: Date.now(),
          text: action.payload,
          completed: false
        }]
      };

    case 'TOGGLE_TODO':
      return {
        ...state,
        todos: state.todos.map(todo =>
          todo.id === action.payload
            ? { ...todo, completed: !todo.completed }
            : todo
        )
      };

    case 'DELETE_TODO':
      return {
        ...state,
        todos: state.todos.filter(todo => todo.id !== action.payload)
      };

    case 'SET_FILTER':
      return { ...state, filter: action.payload };

    default:
      return state;
  }
}

function TodoApp() {
  const initialState = {
    todos: [],
    filter: 'all' // all, active, completed
  };

  const [state, dispatch] = useReducer(todoReducer, initialState);

  const filteredTodos = state.todos.filter(todo => {
    if (state.filter === 'active') return !todo.completed;
    if (state.filter === 'completed') return todo.completed;
    return true;
  });

  return (
    <div>
      <input
        onKeyPress={(e) => {
          if (e.key === 'Enter') {
            dispatch({ type: 'ADD_TODO', payload: e.target.value });
            e.target.value = '';
          }
        }}
        placeholder="Add a todo..."
      />

      <ul>
        {filteredTodos.map(todo => (
          <li key={todo.id}>
            <input
              type="checkbox"
              checked={todo.completed}
              onChange={() => dispatch({ 
                type: 'TOGGLE_TODO', 
                payload: todo.id 
              })}
            />
            <span style={{
              textDecoration: todo.completed ? 'line-through' : 'none'
            }}>
              {todo.text}
            </span>
            <button onClick={() => dispatch({ 
              type: 'DELETE_TODO', 
              payload: todo.id 
            })}>
              Delete
            </button>
          </li>
        ))}
      </ul>

      <div>
        {['all', 'active', 'completed'].map(f => (
          <button
            key={f}
            onClick={() => dispatch({ type: 'SET_FILTER', payload: f })}
            style={{
              fontWeight: state.filter === f ? 'bold' : 'normal'
            }}
          >
            {f.charAt(0).toUpperCase() + f.slice(1)}
          </button>
        ))}
      </div>
    </div>
  );
}

Why useReducer wins here:

All state changes go through dispatch—easy to debug and test
Reducer is a pure function—predictable and testable
Complex state logic stays organized in one place

🌍 Context API: Global State Without Libraries

Context API lets you share state across components without prop drilling.

Problem: Prop Drilling

// ❌ Passing props through 5 levels is messy
<App theme={theme} />
  <Header theme={theme} />
    <Nav theme={theme} />
      <Button theme={theme} />

Solution: Context API

import { createContext, useContext, useState } from 'react';

// Step 1: Create context
const ThemeContext = createContext();

// Step 2: Create provider component
export function ThemeProvider({ children }) {
  const [isDark, setIsDark] = useState(false);

  const value = {
    isDark,
    toggleTheme: () => setIsDark(prev => !prev),
    colors: isDark
      ? { bg: '#1a1a1a', text: '#ffffff' }
      : { bg: '#ffffff', text: '#000000' }
  };

  return (
    <ThemeContext.Provider value={value}>
      {children}
    </ThemeContext.Provider>
  );
}

// Step 3: Create custom hook to use context
export function useTheme() {
  const context = useContext(ThemeContext);
  if (!context) {
    throw new Error('useTheme must be used within ThemeProvider');
  }
  return context;
}

// Step 4: Wrap your app
function App() {
  return (
    <ThemeProvider>
      <Header />
      <MainContent />
      <Footer />
    </ThemeProvider>
  );
}

// Step 5: Use anywhere
function Button() {
  const { isDark, toggleTheme, colors } = useTheme();

  return (
    <button
      onClick={toggleTheme}
      style={{ background: colors.bg, color: colors.text }}
    >
      {isDark ? '☀️ Light' : '🌙 Dark'}
    </button>
  );
}

When to use Context API:

✅ Theme settings (light/dark mode)
✅ User authentication state
✅ Language/locale preferences
❌ Frequently changing data (performance issues)

📦 Redux: Enterprise-Grade State Management

Redux is a predictable state container. It's overkill for small apps but essential for large ones.

Redux Flow

Action → Reducer → Store → Components Update

Complete Redux Example: Shopping Cart

import { createStore } from 'redux';

// Step 1: Define initial state
const initialState = {
  items: [],
  total: 0,
  loading: false
};

// Step 2: Create reducer
function cartReducer(state = initialState, action) {
  switch(action.type) {
    case 'ADD_ITEM':
      const existingItem = state.items.find(
        item => item.id === action.payload.id
      );

      if (existingItem) {
        return {
          ...state,
          items: state.items.map(item =>
            item.id === action.payload.id
              ? { ...item, quantity: item.quantity + 1 }
              : item
          ),
          total: state.total + action.payload.price
        };
      }

      return {
        ...state,
        items: [...state.items, { ...action.payload, quantity: 1 }],
        total: state.total + action.payload.price
      };

    case 'REMOVE_ITEM':
      const removedItem = state.items.find(
        item => item.id === action.payload
      );
      return {
        ...state,
        items: state.items.filter(item => item.id !== action.payload),
        total: state.total - (removedItem.price * removedItem.quantity)
      };

    case 'CLEAR_CART':
      return initialState;

    default:
      return state;
  }
}

// Step 3: Create store
const store = createStore(cartReducer);

// Step 4: Dispatch actions
store.dispatch({
  type: 'ADD_ITEM',
  payload: { id: 1, name: 'Laptop', price: 1200 }
});

console.log(store.getState());
// { items: [{id: 1, name: 'Laptop', price: 1200, quantity: 1}], total: 1200 }

Redux Pros & Cons:

✅ Predictable state changes
✅ Time-travel debugging (Redux DevTools)
✅ Great for large, complex apps
❌ Boilerplate code (actions, reducers, selectors)
❌ Steep learning curve

⚡ Zustand: Lightweight Alternative to Redux

Zustand is simpler than Redux with minimal boilerplate.

import { create } from 'zustand';

// Create store in one place
const useCartStore = create((set) => ({
  items: [],
  total: 0,

  // Actions
  addItem: (item) => set((state) => ({
    items: [...state.items, item],
    total: state.total + item.price
  })),

  removeItem: (id) => set((state) => {
    const removedItem = state.items.find(item => item.id === id);
    return {
      items: state.items.filter(item => item.id !== id),
      total: state.total - removedItem.price
    };
  }),

  clearCart: () => set({
    items: [],
    total: 0
  })
}));

// Use anywhere - no Provider needed!
function ShoppingCart() {
  const { items, total, removeItem } = useCartStore();

  return (
    <div>
      <h2>Cart: ${total}</h2>
      {items.map(item => (
        <div key={item.id}>
          {item.name} - ${item.price}
          <button onClick={() => removeItem(item.id)}>Remove</button>
        </div>
      ))}
    </div>
  );
}

Why Zustand is Awesome:

✅ No Provider wrapper needed
✅ Minimal boilerplate
✅ Great performance
✅ TypeScript friendly
✅ Smaller bundle size

🎯 Jotai: Atom-Based State Management

Jotai takes a different approach—primitive atoms instead of a single store.

import { atom, useAtom } from 'jotai';

// Create atoms (primitive pieces of state)
const cartItemsAtom = atom([]);
const cartTotalAtom = atom(0);

// Derived atom (computed from other atoms)
const cartCountAtom = atom(
  (get) => get(cartItemsAtom).length
);

// Use atoms in components
function ShoppingCart() {
  const [items, setItems] = useAtom(cartItemsAtom);
  const [total, setTotal] = useAtom(cartTotalAtom);
  const [count] = useAtom(cartCountAtom);

  const addItem = (item) => {
    setItems([...items, item]);
    setTotal(total + item.price);
  };

  return (
    <div>
      <h2>Cart ({count} items): ${total}</h2>
      <button onClick={() => addItem({ name: 'Laptop', price: 1200 })}>
        Add Laptop
      </button>
    </div>
  );
}

Jotai Benefits:

✅ Fine-grained reactivity
✅ Only components using changed atoms re-render
✅ Great for complex interdependent state
✅ No Provider overhead

🛒 Real-World Example: Shopping Cart with Multiple Patterns

Let's build a shopping cart using Context API + useReducer (the practical combination):

import { createContext, useContext, useReducer } from 'react';

// 1. Create context
const CartContext = createContext();

// 2. Reducer
function cartReducer(state, action) {
  switch(action.type) {
    case 'ADD_TO_CART': {
      const existingItem = state.items.find(
        item => item.id === action.payload.id
      );

      if (existingItem) {
        return {
          ...state,
          items: state.items.map(item =>
            item.id === action.payload.id
              ? { ...item, quantity: item.quantity + 1 }
              : item
          )
        };
      }

      return {
        ...state,
        items: [...state.items, { ...action.payload, quantity: 1 }]
      };
    }

    case 'REMOVE_FROM_CART':
      return {
        ...state,
        items: state.items.filter(item => item.id !== action.payload)
      };

    case 'UPDATE_QUANTITY':
      return {
        ...state,
        items: state.items.map(item =>
          item.id === action.payload.id
            ? { ...item, quantity: action.payload.quantity }
            : item
        ).filter(item => item.quantity > 0)
      };

    case 'CLEAR_CART':
      return { ...state, items: [] };

    default:
      return state;
  }
}

// 3. Provider component
export function CartProvider({ children }) {
  const [state, dispatch] = useReducer(cartReducer, { items: [] });

  const total = state.items.reduce(
    (sum, item) => sum + (item.price * item.quantity),
    0
  );

  const value = {
    items: state.items,
    total,
    addToCart: (product) => dispatch({ type: 'ADD_TO_CART', payload: product }),
    removeFromCart: (id) => dispatch({ type: 'REMOVE_FROM_CART', payload: id }),
    updateQuantity: (id, quantity) => dispatch({
      type: 'UPDATE_QUANTITY',
      payload: { id, quantity }
    }),
    clearCart: () => dispatch({ type: 'CLEAR_CART' })
  };

  return (
    <CartContext.Provider value={value}>
      {children}
    </CartContext.Provider>
  );
}

// 4. Custom hook
export function useCart() {
  const context = useContext(CartContext);
  if (!context) {
    throw new Error('useCart must be used within CartProvider');
  }
  return context;
}

// 5. Usage
function ProductCard({ product }) {
  const { addToCart } = useCart();

  return (
    <div>
      <h3>{product.name}</h3>
      <p>${product.price}</p>
      <button onClick={() => addToCart(product)}>
        Add to Cart
      </button>
    </div>
  );
}

function Cart() {
  const { items, total, removeFromCart, updateQuantity } = useCart();

  return (
    <div>
      <h2>Shopping Cart</h2>
      {items.length === 0 ? (
        <p>Your cart is empty</p>
      ) : (
        <>
          {items.map(item => (
            <div key={item.id}>
              <h4>{item.name}</h4>
              <input
                type="number"
                value={item.quantity}
                onChange={(e) => updateQuantity(item.id, parseInt(e.target.value))}
              />
              <p>${item.price * item.quantity}</p>
              <button onClick={() => removeFromCart(item.id)}>Remove</button>
            </div>
          ))}
          <h3>Total: ${total.toFixed(2)}</h3>
        </>
      )}
    </div>
  );
}

// 6. App structure
function App() {
  return (
    <CartProvider>
      <ProductCard product={{ id: 1, name: 'Laptop', price: 1200 }} />
      <Cart />
    </CartProvider>
  );
}

🎯 Choosing Your State Management Tool

Decision Tree

Is your app small (< 5 components)?
├─ Yes → Use useState directly
└─ No → Continue

Do you need to share state between many components?
├─ Yes → Continue
└─ No → Use useState + prop drilling

Is the state changing frequently (> 10 times/sec)?
├─ Yes → Use Jotai or Zustand
└─ No → Continue

Is your team familiar with Redux?
├─ Yes → Consider Redux
└─ No → Consider Zustand

Do you need middleware (logging, analytics)?
├─ Yes → Use Redux
└─ No → Use Zustand or Context API

Quick Comparison

Tool	Best For	Learning Curve	Bundle Size
useState	Simple state	Easiest	0 KB
useReducer	Complex state	Easy	0 KB
Context API	Theme, auth	Easy	0 KB
Redux	Large apps	Hard	10 KB
Zustand	Medium apps	Easy	2 KB
Jotai	Granular updates	Medium	5 KB

🎓 Performance Considerations

Context API Performance Pitfall

// ❌ BAD - Entire app re-renders on state change
function ThemeProvider({ children }) {
  const [isDark, setIsDark] = useState(false);

  return (
    <ThemeContext.Provider value={{ isDark, setIsDark }}>
      {children}
    </ThemeContext.Provider>
  );
}

// ✅ GOOD - Memoize context value
function ThemeProvider({ children }) {
  const [isDark, setIsDark] = useState(false);

  const value = useMemo(() => ({ isDark, setIsDark }), [isDark]);

  return (
    <ThemeContext.Provider value={value}>
      {children}
    </ThemeContext.Provider>
  );
}

Key insight: Zustand and Jotai automatically optimize this. Redux requires careful selector use.

🚀 Advanced Pattern: Combining Approaches

Real projects often use multiple state management tools:

// Global app state → Redux/Zustand
// Theme & Auth → Context API
// UI state (modals, dropdowns) → useState
// Form data → Custom useForm hook

This is normal and healthy—don't over-engineer.

💡 Final Thoughts: State Management Maturity

Beginner Phase

Use useState everywhere
Props for simple sharing
useReducer when state gets complex

Intermediate Phase

Context API for theme, auth, user
useReducer for complex components
Custom hooks for reusable logic

Advanced Phase

Zustand for app state
Context for cross-cutting concerns
Jotai for highly granular updates
Redux only if you have 50+ components

📚 Key Takeaways

Custom hooks are the foundation—master these first
useReducer scales better than useState for complex state
Context API is perfect for theme/auth, not data caches
Zustand is the modern, simple alternative to Redux
Jotai excels at fine-grained reactivity
Choose based on app size, not hype

🔗 Quick Resources

Redux Docs: redux.js.org
Zustand: github.com/pmndrs/zustand
Jotai: jotai.org
React Query (for server state): tanstack.com/query
Context API Docs: react.dev/reference/react/useContext

💬 What's Your State Management Journey?

Have you struggled with prop drilling? Built a custom hook? Migrated from Redux? Share your experience in the comments—I'd love to hear what state management patterns your team uses!

Covered in Part 3:

useMemo & useCallback deep dive
Code splitting and lazy loading
Suspense and React.lazy()
Performance profiling with DevTools
Real optimization case studies

Happy state managing! 🚀

⚡ WordPress Performance: The Real Truth They Don't Tell You

Kushang Tailor — Sat, 23 May 2026 11:07:01 +0000

Security myths, speed secrets & a practical step-by-step guide

Let's be honest for a second. Somewhere on the internet, there's a developer passionately arguing that WordPress is "garbage," and a dozen others defending it to their last breath. The reality? It's somewhere in the middle — and that's what we're going to dig into today.

WordPress powers 43%+ of the entire web as of 2026. That's not a typo. Almost half of every website you've visited today probably runs on it. But with great popularity comes great responsibility — and unfortunately, also great misunderstanding, especially around performance and security.

So grab your coffee ☕, because we're going to bust some myths, look at some real-world security news, and then give you a proper no-nonsense roadmap to making your WordPress site scream fast.

📖 Table of Contents

The "Fragile CMS" Myth & Real Truth About WordPress Security
What Is Performance in WordPress?
Why Performance Actually Matters
Global News: WordPress Security in 2024–2025
Step-by-Step: How to Improve WordPress Performance
Bonus Performance Points Worth Knowing

1. 🔓 The "Fragile CMS" Myth & Real Truth About WordPress Security

"WordPress is insecure." If you've been in web development for more than five minutes, you've heard this. And while there's some truth buried in there, the full picture is way more nuanced.

Is WordPress inherently insecure?

No. WordPress core itself is well-maintained by a large dedicated security team and gets rapid patches. The real culprits? Plugins, themes, and user behavior.

Stat	Figure
WP hacks via vulnerable plugins or themes	97%
Share of entire web running on WordPress (2026)	43%
Plugins in the official repository	59,000+
Average time WordPress patches a critical CVE	~14 days

⚠️ Real Talk: Using an outdated plugin with a known vulnerability on 40% of the web is a massive attack surface. That's not WordPress being fragile — that's the plugin ecosystem carrying risks at scale.

What actually makes WordPress "fragile"?

✅ Abandoned plugins — Installed years ago, never updated, now a liability.
✅ Nulled themes — "Free premium" themes from shady sources often contain backdoors.
✅ Weak credentials — Admin username still "admin"? Password "123456"? That's an open door.
✅ No SSL / HTTPS — Transmitting data in plain text in 2026 is unacceptable.
✅ Shared hosting environments — One compromised site on a shared server can bleed into others.
✅ No WAF (Web Application Firewall) — Letting all traffic directly hit your app server.

✅ The Truth: WordPress is as secure as you make it. The CMS itself is solid. The responsibility lies with developers and site owners. A well-configured WordPress site with updated software, proper roles, and a WAF is genuinely hard to crack.

2. 🚀 What Is Performance in WordPress?

When developers talk about "WordPress performance," they usually mean a mix of several things — not just one magic number. Think of it as a health score for your website, measured from multiple angles.

Metric	What It Measures	Target
LCP (Largest Contentful Paint)	How fast the biggest element loads	< 2.5s
FID (First Input Delay)	How fast the page responds to first interaction	< 100ms
CLS (Cumulative Layout Shift)	Visual stability — do things jump around?	< 0.1
TTFB (Time to First Byte)	Server response speed	< 600ms
INP (Interaction to Next Paint)	Overall responsiveness of the page	< 200ms

These are Google's Core Web Vitals — and they directly affect your Google Search ranking. Slow WordPress site? Lower SEO. It's that simple and that brutal.

💡 Did You Know? Google officially uses Core Web Vitals as a ranking signal since 2021. A 1-second improvement in page load time can increase conversions by up to 7%. That's not a nerd stat — that's real money.

3. 💰 Why Performance Actually Matters

You might think performance is a "nice to have" thing — something you tackle after your site is already live and humming. But performance is foundational to everything: user experience, revenue, and even security.

The Business Case 📊

Stat	Impact
53%	of users abandon a page that takes longer than 3 seconds
7%	conversion drop for every 1-second delay
2×	faster sites get 2x more organic traffic on average
#1	factor in user satisfaction per Google UX research

The Security Connection 🔒

Here's something most tutorials miss: Performance and security are deeply connected. A slow WordPress site is often a symptom of bloated, outdated, or poorly coded plugins — the exact same things that create security holes. When you optimize performance, you almost always improve security too.

Removing unused plugins = fewer attack vectors
Enabling caching = less DB load = less attack surface
Using a CDN = DDoS mitigation + speed
Optimizing images = faster loads + cleaner codebase

4. 📰 Global News: WordPress Security in 2024–2025

Let's look at some real incidents — because nothing drives home the importance of performance + security like actual events.

🗞️ October 2024 — WPScan / Wordfence

LiteSpeed Cache Plugin — 6M+ Sites Affected

A critical privilege escalation vulnerability was found in the LiteSpeed Cache plugin, which has over 6 million active installs. The flaw allowed unauthenticated users to gain admin-level access. It was patched quickly, but millions of sites running unpatched versions remained exposed for weeks.

🗞️ January 2025 — Patchstack

WordPress Supply Chain Attack via Nulled Plugin Repositories

Attackers embedded malicious code into cracked/nulled versions of popular WordPress plugins distributed on unofficial sites. Sites using these plugins were silently backdoored, with data being siphoned to external servers for months before detection.

🗞️ March 2025 — WordPress.org

The WP Engine Controversy & Plugin Access Dispute

A high-profile legal and operational dispute between Automattic and WP Engine raised questions about plugin repository access control, with some plugins being temporarily pulled — highlighting the fragility of relying on third-party hosting ecosystems for critical site infrastructure.

🔑 Takeaway: The common thread across all these incidents? Plugins + outdated software + lack of monitoring. A fast, well-maintained WordPress site is almost always a more secure one too.

5. 🛠️ Step-by-Step: How to Improve WordPress Performance

Here's a practical, step-by-step playbook. Each step includes a short example so you can actually do something today — not just read and feel good about it.

Step 1 — Choose the Right Hosting 🏗️

Your hosting is your performance foundation. No amount of optimization can fix bad hosting. Go with a host that offers PHP 8.2+, server-side caching (OPcache), and NVMe SSD storage.

💡 Quick Pick: Managed WordPress: Kinsta, WP Engine, or Cloudways. VPS: DigitalOcean + ServerPilot or Nginx + PHP-FPM.

Step 2 — Enable PHP OPcache & Upgrade to PHP 8.2+ 🐘

PHP 8.2 is significantly faster than PHP 7.x. Combined with OPcache (which caches compiled PHP bytecode), you can cut server-side execution time by 30–50%.

; Enable OPcache in php.ini
opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.revalidate_freq=0
opcache.fast_shutdown=1

Step 3 — Implement Full-Page Caching 🗄️

Caching is the single biggest performance win for most WordPress sites. Instead of generating every page dynamically, caching serves pre-built HTML files to visitors.

// Add to wp-config.php
define( 'WP_CACHE', true );

// Use with a caching plugin like WP Rocket, W3 Total Cache,
// or LiteSpeed Cache (after patching!)

⭐ Recommended Plugins: WP Rocket (paid, best DX), LiteSpeed Cache (free, great on LiteSpeed servers), W3 Total Cache (free, powerful but complex).

Step 4 — Optimize Your Database 🗃️

WordPress databases accumulate garbage over time: post revisions, spam comments, transient options, orphaned metadata. Clean them regularly.

// Limit post revisions to 3 (default is unlimited!)
define( 'WP_POST_REVISIONS', 3 );

// Or disable revisions entirely for heavy content sites
define( 'WP_POST_REVISIONS', false );

-- Remove all auto-drafts
DELETE FROM wp_posts WHERE post_status = 'auto-draft';

-- Clean expired transients
DELETE FROM wp_options
WHERE option_name LIKE '_transient_%'
AND option_value < UNIX_TIMESTAMP();

Step 5 — Optimize Images 🖼️

Images are typically 60–80% of a page's total weight. This is the easiest win on any WordPress site.

A. Convert to WebP format
WebP is 25–35% smaller than JPEG at comparable quality. Use Imagify, ShortPixel, or the built-in WordPress WebP support (6.1+).

B. Add lazy loading
WordPress 5.5+ adds loading="lazy" to images by default. Make sure it's not disabled in your theme.

C. Use proper image dimensions
Don't upload a 4000×3000px image and let CSS scale it down. Always resize to the largest display size you actually need.

// Allow WebP uploads (WordPress 5.8+ handles this natively)
add_filter(
    'upload_mimes',
    function( $mimes ) {
        $mimes['webp'] = 'image/webp';
        return $mimes;
    }
);

Step 6 — Minify & Dequeue Unused CSS/JS Assets ⚙️

Every unminified JavaScript or CSS file is extra kilobytes and an extra HTTP request. Minification strips comments and whitespace; removing unused scripts cuts load entirely.

// Dequeue scripts you don't actually need
add_action( 'wp_enqueue_scripts', function() {
    // Remove comment-reply JS from non-singular pages
    if ( ! is_singular() || ! comments_open() ) {
        wp_dequeue_script( 'comment-reply' );
    }

    // Remove block library CSS if not using Gutenberg blocks
    wp_dequeue_style( 'wp-block-library' );
    wp_dequeue_style( 'wp-block-library-theme' );
}, 100 );

Step 7 — Use a CDN (Content Delivery Network) 🌐

A CDN caches your static assets (images, CSS, JS) across global servers and serves them from the closest node to your visitor. A user in Tokyo shouldn't be fetching your CSS from a server in New York.

✅ CDN Options: Cloudflare (free tier is excellent, includes WAF), BunnyCDN (affordable, fast), KeyCDN. Most caching plugins integrate directly with these.

Step 8 — Optimize WP_Query & Reduce Database Queries 🔍

Every time WordPress loads a page, it runs multiple database queries. Bad custom queries can balloon this from 20 to 200+. Keep your queries lean.

// ❌ Bad — fetches all post data unnecessarily
$bad_query = new WP_Query([
    'post_type'      => 'post',
    'posts_per_page' => 10,
]);

// ✅ Good — optimized, no unnecessary data
$good_query = new WP_Query([
    'post_type'               => 'post',
    'posts_per_page'          => 10,
    'no_found_rows'           => true,  // Skip count query
    'update_post_meta_cache'  => false, // Skip meta cache
    'update_post_term_cache'  => false, // Skip term cache
    'fields'                  => 'ids', // Only get IDs
]);

Step 9 — Enable GZIP / Brotli Compression 📦

Text-based assets (HTML, CSS, JS) compress extremely well. Brotli can reduce file sizes 20–26% more than GZIP. Enable it at the server level.

# .htaccess — Enable GZIP (Apache)
<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html
  AddOutputFilterByType DEFLATE text/css
  AddOutputFilterByType DEFLATE application/javascript
  AddOutputFilterByType DEFLATE application/json
  AddOutputFilterByType DEFLATE image/svg+xml
</IfModule>

Step 10 — Use Object Caching with Redis or Memcached 🚀

Object caching stores the results of expensive database queries in fast in-memory storage. Without it, every page load recalculates the same queries from scratch.

// wp-config.php — Redis Object Cache (with Redis Object Cache plugin)
define( 'WP_REDIS_HOST',         '127.0.0.1' );
define( 'WP_REDIS_PORT',         6379 );
define( 'WP_REDIS_TIMEOUT',      1 );
define( 'WP_REDIS_READ_TIMEOUT', 1 );
define( 'WP_REDIS_DATABASE',     0 );

6. 🎯 Bonus Performance Points Worth Knowing

These extra points don't need a whole section each, but they're absolutely worth knowing — and many developers miss them entirely.

🔌 Audit Your Plugins Ruthlessly
Every active plugin adds load time. If you have 30+ plugins, audit them hard. Does each one really need to run on every page? Use Query Monitor to identify plugin-level bottlenecks.

🌍 Preconnect & Preload Critical Resources
Tell the browser in advance what it'll need. Add <link rel="preconnect"> for Google Fonts or third-party APIs, and rel="preload" for critical fonts and CSS.

📱 Don't Forget Mobile Performance
Google uses mobile-first indexing. Test your performance on a throttled mobile device — not just desktop. Tools: Lighthouse, WebPageTest with the "Moto G4" profile.

🔐 Enable HTTP/2 or HTTP/3
HTTP/2 allows multiplexed requests (multiple assets in one connection). HTTP/3 (QUIC) is even faster. Most modern hosts support HTTP/2; Cloudflare auto-enables HTTP/3.

📊 Monitor Continuously with Real User Monitoring (RUM)
One-off audits aren't enough. Use Google Search Console's Core Web Vitals report or tools like SpeedCurve / New Relic to catch regressions before your users do.

🛡️ Keep the Security ↔ Performance Loop Tight
Run a security audit (Wordfence, Patchstack) alongside every performance audit. The same bloated plugin hurting your score is probably the same one creating a CVE risk.

🏁 Wrapping Up

WordPress isn't going anywhere. It's the most widely-used CMS on the planet, and when configured correctly, it can be both blazing fast and genuinely secure.

The "fragile CMS" narrative is mostly a story about neglect — outdated plugins, zero caching, poor hosting, and zero monitoring. You now have the tools to change that story for your sites.

✅ Your Quick-Win Checklist

[ ] Move to PHP 8.2+ with OPcache enabled
[ ] Enable full-page caching (WP Rocket or LiteSpeed Cache)
[ ] Audit and remove unnecessary plugins
[ ] Optimize images — convert to WebP, enable lazy load
[ ] Set up a CDN (Cloudflare free tier is a great start)
[ ] Clean your database and limit post revisions
[ ] Add Redis object caching
[ ] Enable GZIP / Brotli compression
[ ] Monitor Core Web Vitals monthly

Start with just two or three of these today. You'll see a difference. And then come back for the rest 💪

Got a performance tip that's saved your site? Drop it in the comments — let's build a killer thread! 👇