DEV Community: Jay Malhotra

5 WordPress Speed Fixes That Actually Move Core Web Vitals

Jay Malhotra — Sun, 15 Nov 2026 10:20:38 +0000

A slow WordPress site hurts user experience, conversions and search visibility. After years of building and tuning WordPress and WooCommerce sites, these are the five fixes I reach for first, in order of impact.

1. Fix the Largest Contentful Paint (LCP) element

On most pages the LCP element is a hero image. Serve it in a modern format (WebP or AVIF), size it correctly for the viewport, and never lazy-load it. Add fetchpriority="high" so the browser fetches it early.

<img src="hero.webp" width="1200" height="600"
     fetchpriority="high" alt="Hero image">

2. Audit plugins before adding caching

Caching masks a heavy site, it does not fix it. Deactivate plugins one by one and measure. Replace multi-purpose plugins that load scripts on every page with lighter alternatives, or load their assets only where needed.

add_action( 'wp_enqueue_scripts', function () {
    if ( ! is_page( 'contact' ) ) {
        wp_dequeue_script( 'contact-form-7' );
        wp_dequeue_style( 'contact-form-7' );
    }
}, 100 );

3. Reduce layout shift (CLS)

Always set width and height on images and embeds, and reserve space for ads, banners and cookie notices. Preload key web fonts and use font-display: swap to avoid text jumping.

4. Defer non-critical JavaScript

Third-party scripts such as chat widgets, analytics and trackers often block rendering. Load them with defer or after user interaction, and remove any you no longer use.

5. Use proper caching and a CDN

Page caching, object caching (Redis or Memcached) and a CDN cut server response time (TTFB) dramatically, especially for WooCommerce stores where uncached pages are expensive. Exclude cart, checkout and account pages from page caching.

Measure, then fix

Test with PageSpeed Insights and the Chrome DevTools Performance panel, and check field data in Search Console. Fix the biggest bottleneck first, re-measure, and repeat.

What is the biggest performance problem you have run into on a WordPress site? Share it in the comments.

Want the long version? I keep a full WordPress speed checklist on my site — more of my work is at jaymalhotra.in.

Use AI Like a Teammate, Not a Search Engine

Jay Malhotra — Sun, 15 Nov 2026 10:20:03 +0000

Most people use AI like a search engine: ask a question, get an answer, close the tab. That works for quick lookups, but it leaves most of the value on the table.

The developers getting the most out of AI treat it like a teammate. Here is the approach I use after completing Anthropic's courses on AI Fluency, Claude Code and Agent Skills.

1. Give it a goal, not a prompt

"Write a function that validates emails" is a prompt. "Our signup form accepts invalid emails and support is getting complaints; find where validation happens and fix it" is a goal. The second gives the AI context, a problem and a definition of done.

2. Let it plan the steps

Ask for a plan before any code is written. Reviewing a five-line plan is far cheaper than reviewing a wrong 500-line change, and it surfaces misunderstandings early.

3. Give it the right tools and skills

An assistant that can read your project, run tests and follow your team's conventions beats one working from a pasted snippet. Agent skills are a good way to package repeatable instructions, such as your code style or deployment checklist, so you do not re-explain them every session.

4. Review the output, do not just accept it

AI can be confidently wrong. Read the diff, run the tests and check edge cases. You stay responsible for what ships.

The takeaway

AI does not replace your judgment, it multiplies it. The better you define the problem, the better the result.

How are you using AI in your workflow: search engine or teammate? Let me know in the comments.

I build WordPress, Next.js and Laravel products with AI where it genuinely helps — see my work and certifications at jaymalhotra.in.

The WordPress speed checklist I use on every client site

Jay Malhotra — Sun, 15 Nov 2026 09:00:00 +0000

A slow website quietly costs you leads, sales and rankings. The good news: most WordPress speed problems come from the same handful of causes. This is the checklist I work through on client sites, roughly in order of impact.

1. Measure first

Run the page through PageSpeed Insights and note LCP, INP and CLS for mobile.
Check real-user data in Google Search Console → Core Web Vitals.
Use a waterfall tool (WebPageTest or browser DevTools) to see what actually loads and in what order.

Always test the mobile result — that is what Google uses for ranking.

2. Hosting and server

Use a current PHP version (8.2+) and enough memory for your traffic.
Enable server-level or object caching (Redis/Memcached) where the host supports it.
Put a CDN in front of the site — Cloudflare's free plan alone is a big win for global visitors.

3. Page caching

Serve cached HTML to anonymous visitors. A good caching plugin (or the host's built-in cache) can cut server response time from a second to a few milliseconds. Exclude cart, checkout and account pages on WooCommerce sites.

4. Images (usually the biggest win)

Serve modern formats — WebP or AVIF.
Resize images to the size they are displayed; never upload a 4000px photo for a 600px slot.
Lazy-load images below the fold, but never lazy-load the hero/LCP image — preload it instead.
Always set width and height to prevent layout shift (CLS).

5. Theme and page builder

Heavy multipurpose themes and page builders load a lot of CSS and JavaScript on every page. If a site is slow, this is often the root cause. Options: switch to a lightweight theme, use the builder's performance settings (load assets only where used), or rebuild key templates in native blocks.

6. Plugins and third-party scripts

Audit every plugin — deactivate anything unused and replace heavy ones with lighter alternatives.
Delay non-critical scripts (chat widgets, heatmaps, social embeds) until user interaction.
Load analytics and tag managers efficiently; each extra tag adds main-thread work that hurts INP.

7. CSS, JavaScript and fonts

Minify and combine where it helps, and remove unused CSS.
Defer non-critical JavaScript.
Self-host fonts or limit families and weights; use font-display: swap and preload the main font file.

8. Database housekeeping

Clean up post revisions, expired transients, spam comments and orphaned plugin tables. Large, bloated wp_options autoload data is a common hidden cause of slow back ends.

9. Re-test and monitor

After each change, re-run your measurements so you know what actually helped. Then keep an eye on Core Web Vitals monthly — new plugins and marketing scripts tend to creep back in.

Need a hand?

If your WordPress or WooCommerce site feels sluggish, I offer focused speed and Core Web Vitals work. Send me the URL and I'll tell you where the biggest wins are.

Originally published at jaymalhotra.in.

WordPress vs Next.js for a business website: how to actually choose

Jay Malhotra — Sun, 15 Nov 2026 09:00:00 +0000

“Should we build on WordPress or Next.js?” is one of the most common questions I get from clients. Both are excellent. Both are also the wrong answer for some projects. Here is how I think about the decision after years of shipping sites on each.

The short answer

Choose WordPress when non-technical people will publish content often, you need a mature plugin ecosystem (forms, SEO, WooCommerce, memberships), and budget matters.
Choose Next.js when the site behaves more like an application — dashboards, logins, custom data, heavy interactivity — or when you need top-tier performance at scale and have developers to maintain it.
Consider both (headless WordPress + Next.js front end) when you want WordPress editing with a fully custom, very fast front end — and can afford the extra complexity.

1. Who edits the site?

This is the question that decides most projects. WordPress gives editors a familiar admin, a visual block editor, revisions, roles and scheduling out of the box. With a Next.js site, content usually lives in a headless CMS (Sanity, Contentful, Strapi or headless WordPress) — powerful, but it is another system to set up and pay for.

If your marketing team publishes weekly and doesn't want to call a developer for every landing page, WordPress is hard to beat.

2. Performance

Next.js has an edge out of the box: static generation, image optimisation, code-splitting and edge rendering are built in. But a well-built WordPress site — lean theme, no page-builder bloat, proper caching and a CDN — comfortably passes Core Web Vitals too. Most slow WordPress sites are slow because of heavy themes and too many plugins, not because of WordPress itself.

3. SEO

Both can rank equally well. WordPress makes on-page SEO easy for editors with plugins like Yoast or Rank Math. Next.js gives developers fine-grained control over metadata, structured data and rendering. What matters far more than the framework: content quality, internal linking, page speed and backlinks.

4. Cost — build and ongoing

Build: a marketing site on WordPress is usually faster and cheaper to deliver, because so much exists already (forms, SEO, caching, eCommerce).
Hosting: both can be inexpensive. Next.js runs well on Vercel, Netlify or Cloudflare; WordPress needs PHP hosting with good caching.
Maintenance: WordPress needs regular core, theme and plugin updates and security hardening. Next.js has fewer moving parts in production, but changes nearly always need a developer.

5. eCommerce

For most small and mid-sized stores, WooCommerce (WordPress) or Shopify is the pragmatic choice — payments, tax, shipping and inventory are solved problems. A custom Next.js storefront makes sense for brands with unusual product logic or very high traffic, usually on top of Shopify or another commerce API.

6. Custom features and integrations

If the project involves user accounts, dashboards, complex forms, third-party APIs or AI features, Next.js (often with a Laravel or Node back end) gives you a cleaner foundation. WordPress can do a lot of this with custom plugins, but past a certain point you are fighting the platform.

A quick decision checklist

Will non-developers publish or edit content every week? → lean WordPress.
Is it primarily a marketing or content site? → lean WordPress.
Does it need logins, dashboards or app-like interactivity? → lean Next.js.
Is raw performance at scale a business requirement? → lean Next.js (or headless).
Do you have ongoing developer support? → if not, WordPress is easier to own.

My take

Pick the platform that fits how your team works and where the product is going — not the one that is trending. I build on both, and I'm happy to recommend against the more expensive option when it isn't needed. If you're weighing this decision for your own project, tell me what you're building and I'll give you a straight answer.

Originally published at jaymalhotra.in.