DEV Community: Salman Ahmed

How I Actually Make WordPress Sites Fast (Not the Usual 'Install a Cache Plugin' Advice)

Salman Ahmed — Thu, 03 Sep 2026 10:45:16 +0000

Quick answer: To speed up a WordPress site, fix things in the order that actually moves the numbers — not the order plugins suggest. Start by diagnosing the real bottleneck (usually images or your host), then work through image format and sizing, quality hosting, page + object caching, your render path (defer CSS/JS, preload the LCP image), web fonts, and database bloat. Done right, most business sites go from a 30–50 mobile PageSpeed score to 90+. Below is the exact process I use on client sites.

I optimize WordPress sites for a living. Here's what actually works.

Hey, I'm Salman — I build and optimize WordPress sites for businesses across six countries, and every site I ship targets 90+ on Google PageSpeed. Over 120 builds, I've learned that most "speed up your WordPress site" articles get the order wrong. They hand you a list of 10 plugins and call it done.

The real answer is more boring: image format > caching > render path > everything else. If you fix those four in the right order, you've done 80% of the work before you touch a single "advanced" setting. This guide walks through the full process — the same one I run on paid client work — including the developer-level steps the plugin-vendor blogs skip because they're trying to sell you their plugin.

This is a practitioner's guide, not a vendor pitch. I don't sell a caching plugin, so I'll tell you honestly where the free tools are enough and where paid is worth it.

Why WordPress Speed Matters (the short version)

You already know fast is better, so I'll keep this tight:

Conversions: Google's own research found that as page load goes from 1s to 3s, the probability of a bounce jumps 32%. Slow pages quietly leak sales.
SEO: Core Web Vitals are a confirmed Google ranking signal, and page speed feeds directly into them. Faster sites get crawled more and rank more easily.
Trust: A site that loads instantly feels more professional before a visitor reads a single word. Speed is the first impression.

The point isn't to chase a perfect 100 score for bragging rights. It's to make the site feel instant for real people on real phones. Let's diagnose yours first.

Step 1: Diagnose Before You Optimize

The biggest mistake I see: people install five plugins and hope. You can't fix what you haven't measured. Spend 15 minutes here first — it tells you which of the later steps actually matter for your site.

The tools I actually use to diagnose

Google PageSpeed Insights — start here. It pulls real-user "field data" (how your actual visitors experience the site) plus a lab test. The field data is what Google uses for rankings, so it's the number that counts.
GTmetrix or DebugBear — for the request "waterfall." This shows you exactly which file is blocking the load, in what order. It's how you find the one 2MB hero image or the render-blocking font that's wrecking everything.
Query Monitor (plugin) — the developer's secret weapon. It surfaces slow database queries and which plugin is responsible for them. Most "mystery slowness" is one badly-coded plugin, and this finds it in minutes.

Read the waterfall, not just the score

A PageSpeed score is a symptom. The waterfall is the diagnosis. Look for: a big gap before anything loads (that's a slow host/TTFB), a giant image near the top (that's your LCP problem), or a wall of small CSS/JS files blocking render (that's your render path). Match the symptom to the fix:

Symptom you seeLikely causeWhere to fix it (in this guide)

Long delay before anything appearsSlow hosting / high TTFBStep 3 (Hosting)
One huge image loads slowly at the topUnoptimized LCP imageStep 2 (Images) + Core Web Vitals
Layout jumps around as it loadsNo image dimensions / late fontsCore Web Vitals (CLS)
Buttons feel laggy when tappedHeavy JavaScriptStep 5 (Render path) + INP
Slow even for repeat visitorsNo cachingStep 4 (Caching)

Step 2: Core Web Vitals — the 2026 framework that actually matters

Most older speed guides are out of date here, so pay attention: in March 2024, Google replaced FID (First Input Delay) with INP (Interaction to Next Paint). If a guide still talks about FID, it hasn't been updated — and neither has its advice. There are three vitals, and each has a clear cause-and-fix.

MetricWhat it measuresGoodNeeds workPoor

LCP (Largest Contentful Paint)How fast the main content (usually the hero image/heading) appears≤ 2.5s2.5–4s> 4s
INP (Interaction to Next Paint)How fast the page responds when a user taps or clicks≤ 200ms200–500ms> 500ms
CLS (Cumulative Layout Shift)How much the layout jumps around while loading≤ 0.10.1–0.25> 0.25

Fixing LCP (the one that matters most)

LCP is almost always your hero image or main heading. The fixes, in order: serve the hero in WebP/AVIF, size it correctly (don't load a 2000px image into an 800px slot), preload it so the browser fetches it immediately, and make sure it is not lazy-loaded (lazy-loading the LCP element is the single most common mistake I fix on client sites). Verify in PageSpeed Insights after each change.

Fixing INP (the new one most sites fail)

INP is about JavaScript. When a tap takes 400ms to respond, it's because the main thread is busy running scripts. Fixes: remove unused plugins (every plugin adds JS), defer non-critical JavaScript, and cut heavy third-party scripts (chat widgets, multiple analytics tags, ad scripts). On a typical bloated business site, removing 3–4 unnecessary plugins fixes INP on its own.

Fixing CLS (the easy win)

CLS comes from elements that load without reserved space. Two fixes cover 90% of cases: always set explicit width and height on images, and load fonts with font-display: swap plus a preload so text doesn't reflow when the custom font arrives. Reserve space for ad/embed slots too.

Step 3: Get Hosting Right (TTFB is where speed begins)

No plugin can fix slow hosting. If your server takes 1.5 seconds to send the first byte (TTFB), you've lost the race before the browser draws anything. Cheap shared hosting that crams thousands of sites onto one server is the most common hidden bottleneck I find.

Aim for TTFB under ~500ms (ideally under 200ms). Check it in the GTmetrix waterfall or PageSpeed.
Use quality managed or cloud hosting — Cloudways, Kinsta, or a solid VPS. You don't need the most expensive plan; you need a host that isn't overselling.
Upgrade PHP. Running PHP 8.1+ instead of an old 7.x version can cut server processing time meaningfully — and it's a free, one-click change in most hosting panels. Test on staging first.
Add object caching (Redis) if your host supports it. For dynamic sites (WooCommerce especially), a Redis object cache stops WordPress from re-running the same database queries on every load. This is a developer-level step the vendor blogs rarely mention.

Step 4: Caching — Done Once, Done Right

Caching saves a ready-made copy of your page so the server doesn't rebuild it from scratch for every visitor. It's the highest-leverage single setting on most sites. You do not need a stack of caching plugins — pick one and configure it properly.

Page caching — the big one. Serves static HTML to visitors. Built into LiteSpeed Cache (free, if your host runs LiteSpeed) or WP Rocket (paid, the most beginner-friendly).
Browser caching — tells repeat visitors' browsers to keep static files (logo, CSS) locally. Usually a checkbox in the same plugin.
Object caching — covered in Step 3; for dynamic/eCommerce sites.

Honest take on plugins: if your host runs LiteSpeed, LiteSpeed Cache is free and excellent — start there before paying for anything. If not, WP Rocket is worth the money for how much it does in one dashboard (caching + minification + lazy load + preload). W3 Total Cache and WP Super Cache are free and capable but fiddlier to set up. There's no need to own more than one.

Step 5: Optimize the Render Path (CSS, JavaScript & Fonts)

This is where the score climbs from "okay" to "fast." The render path is everything the browser must process before it can paint the page. Bloated, render-blocking CSS and JS are what keep most well-hosted sites stuck in the 60s.

Minify & combine CSS and JS to cut file size and requests (LiteSpeed/WP Rocket do this).
Defer non-critical JavaScript so it loads after the page is interactive, not before.
Eliminate render-blocking resources — inline the small bit of "critical CSS" the top of the page needs, and load the rest asynchronously.
Tame web fonts: self-host them, preload the one or two you actually use, subset to the characters you need, and use font-display: swap. Random Google Fonts loaded from a third party are a sneaky speed (and now privacy) tax.
Remove unused CSS/JS — a tool like the free Perfmatters-style asset manager (or LiteSpeed's "remove unused CSS") stops plugin styles from loading on pages that don't use them.

Step 6: The Rest of the Checklist (real, but lower-leverage)

Once the five steps above are done, these clean up the long tail. Don't start here — finish here.

Database cleanup: clear post revisions, spam, and transients with a tool like WP-Optimize. Helps most on older sites.
A CDN (Cloudflare's free tier is plenty for most) serves static files from a server near each visitor — a real win if you have an international audience.
Cut third-party scripts: every chat widget, pixel, and embedded video adds weight. Load only what earns its place; lazy-load YouTube embeds.
Choose a lightweight theme/builder setup: a bloated theme stacked with a heavy page builder fights you on every page. I build on clean Elementor or block-based setups and strip what isn't used.
Keep everything updated: WordPress core, themes, and plugins ship performance and security fixes. Update on staging, then live.

A Real Optimization: Ummah Financial Solutions

Theory is cheap, so here's a real one. Ummah Financial Solutions is a UK accounting and finance brand. The site looked great but felt sluggish on mobile when it came to me — a 34 on Google PageSpeed, an LCP of 6.2 seconds, and a noticeable jump in the layout as the hero image and fonts loaded in. For a finance brand asking people to trust them with their money, that slow, janky first impression was quietly costing enquiries.

I ran the diagnosis from Step 1, then worked the fixes in priority order. Here's the before and after:

MetricBeforeAfter

Mobile PageSpeed score34*92*
LCP (mobile)6.2s*1.8s*
CLS0.28*0.01*
Total page weight4.1 MB*720 KB*

What actually moved the numbers, in order of impact: converting the hero and section images to WebP and preloading the LCP image (that one change alone took LCP from 6.2s to roughly 2.6s), adding properly-configured page caching, deferring the render-blocking scripts two plugins were injecting, self-hosting the web fonts, and setting explicit image dimensions to kill the layout shift. No silver bullet — just the order above, applied properly. The result: a site that scores 90+, loads in well under two seconds on a mid-range phone, and finally feels as trustworthy as the brand behind it. You can see the full build in my portfolio.

Should You DIY This or Hire Someone?

Honestly? Steps 1–4 are very doable yourself over a weekend if you're comfortable in the WordPress dashboard — diagnosing, picking a good host, and setting up one caching plugin will get most sites a long way. Be careful with Step 5 (render path) — aggressively deferring JS or removing CSS can break your layout, so test on staging.

It's worth hiring a developer when: the site is a store (WooCommerce speed is its own discipline), you've tried the basics and you're stuck in the 60s, or your time is simply worth more than the weekend it'll take to learn this. That's exactly the kind of work I do — see my WordPress speed optimization service (free audit included), or just send me your URL and I'll tell you honestly what's slowing it down. (Budgeting a new build rather than a fix? Here's my honest WordPress pricing guide.)

Frequently Asked Questions

How long does it take to speed up a WordPress site?

For a typical business site, the high-impact work (diagnosis, hosting, caching, image optimization) takes a focused day. A deeper optimization including render-path and Core Web Vitals tuning is usually 2–3 days. eCommerce sites take longer because every product image and dynamic page needs attention.

Can I speed up WordPress without buying a plugin?

Yes, to a real extent. Upgrading PHP, choosing a good host, compressing images, and (if your host runs LiteSpeed) using the free LiteSpeed Cache plugin will get most sites to a good score at zero plugin cost. Paid tools like WP Rocket mainly buy convenience — doing in one dashboard what would otherwise take several free plugins and more setup time.

What is a good WordPress PageSpeed score?

Aim for 90+ on mobile in Google PageSpeed Insights — that's the target I hold every client site to. But don't obsess over a perfect 100. What matters more is passing Core Web Vitals (LCP under 2.5s, INP under 200ms, CLS under 0.1) on real-user field data, because that's what Google actually uses for ranking.

Does website speed really affect SEO?

Yes. Core Web Vitals are a confirmed Google ranking factor, and they're built on speed metrics. Speed also affects SEO indirectly: faster sites have lower bounce rates and get crawled more efficiently. It won't outrank great content on its own, but between two similar pages, the faster one wins.

What's the difference between INP and FID?

INP (Interaction to Next Paint) replaced FID (First Input Delay) as a Core Web Vital in March 2024. FID only measured the delay on the first interaction; INP measures responsiveness across all interactions during the visit, so it's a stricter, more realistic measure. If a guide still references FID, its advice is out of date.

Why is my WordPress site still slow after installing a caching plugin?

Caching only fixes one layer. If your site is still slow, the bottleneck is usually elsewhere — unoptimized images (the #1 culprit), slow hosting/TTFB, render-blocking JavaScript from too many plugins, or heavy third-party scripts. Run the diagnosis in Step 1: the waterfall will show you exactly which one it is.

I'm Salman Ahmed, a freelance WordPress developer and web designer in Karachi. I've built 120+ sites for clients across the UK, US, Canada, Germany and Pakistan. Originally published on salmanahmed.tech.

Converting Figma Designs to Elementor Without Losing the Design

Salman Ahmed — Thu, 03 Sep 2026 10:42:34 +0000

Quick answer: There are three ways to convert a Figma design to Elementor:
(1) rebuild it manually in Elementor — the most reliable and what pros use,
(2) use a Figma-to-Elementor plugin or AI tool to auto-generate a rough draft you then clean up, or
(3) hire a developer. Manual conversion gives pixel-perfect, fast, clean results but takes skill; auto tools are fast but produce bloated markup and break on mobile. Below is the exact manual process I use, plus where the automated tools actually help.

I've converted 30+ Figma designs to Elementor. Here's the honest process.

Hey, I'm Salman — I build WordPress sites for a living, and a big chunk of that is turning Figma designs into live Elementor websites. I've shipped 30+ of these conversions for designers, agencies, and business owners.

Here's the thing most guides won't tell you: the hard part of Figma-to-Elementor isn't dragging widgets onto the canvas. It's breakpoint drift — the reason a conversion looks perfect on desktop and falls apart on a phone. Figma's auto-layout does not map 1:1 to Elementor's flex containers, so if you trust Elementor's responsive presets to "just handle it," you get overlapping text, squished images, and a tablet view nobody signed off on. The fix is boring but reliable: you rebuild every breakpoint by hand. More on that below.

This guide walks the full process — the manual method step by step, an honest look at the plugins and AI tools, best practices, and how long it actually takes.

The 3 Ways to Convert Figma to Elementor

Before the how-to, know your options. There's no single "right" way — it depends on your skill, timeline, and how much quality matters.

MethodBest forQualitySpeed

Manual rebuild in ElementorPixel-perfect, production sitesHighest — clean, fast, responsiveSlowest (but reliable)
Figma-to-Elementor plugin / AI toolA rough first draft to refineLow-to-medium — bloated, needs cleanupFast to draft, slow to fix
Hire a developerClient work, no time to learnHighest (if they know breakpoints)Fastest for you

My honest take: there is no "one-click" tool that produces a clean, production-ready Elementor site from Figma. The auto-generators are improving, but they output heavy markup that hurts performance and rarely survives contact with real mobile devices. For anything a client or customer will see, manual conversion (or hiring someone who does it manually) wins. Here's how it's done.

How to Convert Figma to Elementor Manually (Step by Step)

Step 1: Prep your Figma file first

Good conversion starts before Elementor. In Figma: make sure the design uses proper auto-layout (so you understand the intended spacing and stacking), define text styles and color styles (these become your Elementor global fonts and colors), and confirm you have the mobile and tablet frames — not just desktop. If the designer only gave you a desktop frame, agree on the responsive behaviour before you build, not after. Export all images and icons at 2x in SVG (icons/logos) or WebP (photos).

Step 2: Set up the Elementor foundation

Don't build a single section until the foundation is right. In Elementor's Site Settings, set your global colors and fonts to match the Figma styles exactly — this is what keeps the whole site consistent and lets you change a brand color in one place later. Use a lightweight theme (Hello Elementor or a blank block theme) so nothing fights your design. Set the content width and default spacing to match the Figma canvas.

Step 3: Build with Containers, section by section

Use Elementor's flexbox containers — not the old section/column structure (it's deprecated and heavier). Work top to bottom, one section at a time: header, hero, then each content block. For each, match the Figma padding, gap, font size, and alignment precisely. Nest containers the way the Figma auto-layout is grouped, and it maps far more cleanly. Reuse global styles instead of hard-coding values on every element.

Step 4: Rebuild every breakpoint by hand (the step that matters)

This is where amateur conversions fall apart. After the desktop build looks perfect, switch to tablet, then mobile, and manually adjust each one — font sizes, padding, container direction (row → column), image sizes, and element order. Do not assume Elementor's responsive defaults will hold; they won't, because Figma auto-layout and Elementor flex resize differently. Check the Figma mobile frame and rebuild to match it. On a 10-section page that's an extra hour or two — and it's the difference between "looks great everywhere" and "looks weird on tablet."

Step 5: Optimize for speed and clean output

A pixel-perfect site that loads in 6 seconds failed. Keep the build lean: don't stack unnecessary containers, serve images in WebP with correct dimensions, preload the hero image, and limit heavy add-on widgets. (I go deep on this in my guide to WordPress speed optimization — the same rules apply to Elementor builds.) A clean manual conversion should still score 90+ on PageSpeed.

Step 6: QA on real devices

Preview isn't enough. Test on an actual phone and tablet, check every breakpoint, click every link and button, and confirm forms work. This is where you catch the last 5% that separates a professional build from a "good enough" one.

Figma to Elementor With Plugins & AI Tools

You'll find tools that promise to auto-convert Figma to Elementor or WordPress — some plugins, some AI-based (and Elementor's own AI features are growing). Here's my honest assessment after testing them: they're genuinely useful for generating a rough first draft or a single section quickly, especially for simple layouts. But they consistently produce bloated, over-nested markup, hard-code values instead of using global styles, and break on mobile — so you spend as long cleaning up as you would have building it right. Use them to speed up a draft if you like, but plan to rebuild the structure and every breakpoint yourself. Treat the output as a starting sketch, never the finished site.

Best Practices & Common Mistakes

The mistakes I see most often in DIY Figma-to-Elementor conversions — and what to do instead:

Common mistakeDo this instead

Trusting Elementor's responsive presetsRebuild tablet + mobile breakpoints by hand
Using old sections/columnsUse flexbox containers (lighter, closer to Figma auto-layout)
Hard-coding colors and fonts per elementSet global styles once in Site Settings
Exporting huge PNGs from FigmaSVG for icons/logos, WebP for photos, sized correctly
Stacking containers & heavy add-ons for effectsKeep the DOM lean so PageSpeed stays 90+
Skipping real-device QATest on an actual phone and tablet before launch

How Long Does a Figma to Elementor Conversion Take?

Realistic timelines from my own projects: a single landing page is about 2–3 days done properly (build + all breakpoints + QA). A full 10-page site is roughly 7–10 days. Automated tools can shave the initial draft time, but the breakpoint and cleanup work — the part that actually determines quality — takes the same effort either way. If a timeline sounds too fast to include manual responsive work, that's usually a sign the breakpoints are being skipped.

DIY or Hire a Developer?

If you're comfortable in Elementor and have the time, the manual process above will get you a clean result — just don't skip Step 4. If it's client work, your time is better spent elsewhere, or you've hit the "looks weird on tablet" wall, that's exactly what I do: pixel-perfect Figma to Elementor conversion with every breakpoint rebuilt by hand, fast and clean. Send me your Figma file and I'll tell you honestly what it'll take — get in touch here.

Frequently Asked Questions

Can you convert Figma to Elementor automatically?

Partly. Figma-to-Elementor plugins and AI tools can auto-generate a rough draft, which is handy for simple sections. But none produce a clean, production-ready site — the output is bloated and breaks on mobile, so it needs significant manual cleanup. For anything customer-facing, a manual rebuild (or hiring someone who does it manually) gives a far better result.

Is Figma to Elementor conversion pixel-perfect?

It can be, if it's done manually with care. Pixel-perfect means matching every padding, font size, spacing, and interaction from the Figma file — and rebuilding each breakpoint to match the mobile and tablet frames. Automated conversions are rarely pixel-perfect, especially on responsive views.

What's the best plugin to convert Figma to Elementor?

There's no plugin I'd trust to produce a finished site. The auto-converters are fine for drafting a layout quickly, but you'll rebuild the structure and breakpoints regardless. My advice: skip the search for a magic plugin and invest the time in a clean manual build (or hire it out) — it's faster in the long run than fixing bloated auto-generated markup.

Why does my Figma design look different in Elementor on mobile?

Because Figma's auto-layout and Elementor's flex containers resize differently, and Elementor's responsive presets don't replicate your Figma mobile frame automatically. The fix is to manually adjust each breakpoint — font sizes, padding, stacking direction, and element order — to match the Figma mobile and tablet designs. This "breakpoint drift" is the single most common cause of conversions that look off on phones.

How much does a Figma to Elementor conversion cost?

It depends on the number of pages and complexity. As a rough guide from my own work, a single landing page starts around a few hundred dollars and a full multi-page site scales from there. Automated tools are cheaper up front but cost you in cleanup and quality. For a firm quote, share your Figma file and page count.