Audit My Site Get Started

Category: IT or ops leader

  • How to Speed Up a WordPress Site

    How to Speed Up a WordPress Site

    The short answer

    There are seven usual suspects: slow server response, no caching, unoptimized images, a missing or misconfigured CDN, plugin or theme bloat, database bloat, and render-blocking code. None of them has a single fix that covers all seven, and treating one symptom (a slow load) as if it always has one cause is the mistake most speed advice makes.

    Server

    Slow origin response time before anything else runs.

    Caching

    No page cache, no object cache, or a cache that isn’t being hit.

    Images

    Uncompressed, oversized, or lazy-loaded above the fold.

    CDN

    Missing entirely, or configured so static files never hit the edge.

    Plugins and theme

    Queries, CSS and JavaScript added to pages that don’t use the feature.

    Database

    Revisions, expired transients and orphaned metadata piling up.

    Render-blocking code

    CSS and JavaScript that delays the first paint of the page.

    Seven possible causes of a slow WordPress site: a map of possibilities, not a priority order. The order to check them in lives in “What to do about it” below.

    The order to check them in matters more than any individual tactic. Server response and caching come first, because a slow origin server undermines everything built on top of it. Images and the CDN come next, since they’re the most visible cause on a typical page. Plugin and database cleanup come last, because they take the most care to do safely. How the speed work gets scoped breaks down what a structured pass through all seven actually looks like.

    How it actually works

    Caching, images, and the CDN

    Full-page caching serves a static, pre-built copy of a page to a visitor instead of running PHP and querying the database on every request. Object caching goes a layer deeper: it stores the results of expensive database queries so the same query doesn’t run twice. Browser caching stores static assets like CSS and images directly on the visitor’s device so a repeat visit doesn’t re-download them. Each of these solves a different part of the problem, and none of them fixes a query or a page that was slow to begin with. As Jetpack puts it, caching will hide performance issues, but it will not fix the root cause.

    Images are the biggest lever most sites have, and also where the most common piece of advice backfires. Lazy loading defers loading an image until it’s about to scroll into view, which is useful for images far down the page. Applied indiscriminately, including to the image at the top of the page, it’s measurably worse: web.dev’s own A/B test found that lazy-loading above-the-fold images made archive pages 13 to 15 percent slower on both desktop and mobile. That’s specifically because the largest above-the-fold image is usually the LCP element, the one Core Web Vitals is timing, and delaying it delays the whole measurement. WordPress core now recognizes this and doesn’t lazy-load the first featured or content image on a page for that reason.

    A CDN caches static content, images, CSS, JavaScript, at edge locations closer to the visitor, so a request travels a shorter physical distance. Cloudflare’s own illustrative figures put a request from Atlanta at roughly 1,100 milliseconds and the same request from Singapore at roughly 3,000 milliseconds without a nearby edge location, a reduction of about 63 percent with one, though that’s a directional example rather than a guarantee for any specific site. What a CDN can’t do is speed up PHP execution or a slow database query. It moves static files closer to the visitor. It doesn’t touch what happens on the origin server before those files are generated.

    Verify it

    After each change, run a Core Web Vitals check rather than trusting that the change worked. A caching or CDN change that looks right in the plugin settings can still leave LCP, INP or CLS unchanged if the actual bottleneck was somewhere else.

    Plugins and the database

    Every active plugin can add its own database queries, CSS and JavaScript to a page load, whether or not that plugin’s feature is actually being used on that page. There’s no verified number for how many plugins is too many. Any specific count offered as a safe threshold isn’t backed by a real source, so treat it as noise.

    Database bloat builds up the same way: post revisions, expired transients and orphaned metadata from removed plugins accumulate in the database and slow down the queries that run on every page load. Cleaning it up means removing rows and rebuilding indexes, and a backup before either of those steps isn’t optional. Plugin and theme updates are also a common, overlooked cause of a sudden slowdown: an update can silently change caching behavior or add a heavy new dependency, which is exactly what the update process that catches a plugin-caused slowdown is built to catch before it ships to the live site.

    Verify it

    After a database cleanup or a plugin change, re-run the Core Web Vitals check and confirm the backup taken beforehand actually restores, not just that it exists.

    Why it matters for a business site

    Google’s own documentation is more measured than most speed advice suggests. Google Search Central states plainly that Core Web Vitals are used by its ranking systems, and in the same breath that Google Search always seeks to show the most relevant content, even if the page experience is sub-par. Speed is a factor. It isn’t the only one, and a faster page that’s less relevant to the search still loses to a slower, more relevant one.

    For a small, low-traffic brochure site, a caching plugin plus a free CDN tier can genuinely be enough. The honest gap a managed service closes isn’t the initial setup, it’s what happens in the months after: a plugin update that silently disables the cache, an unoptimized image uploaded straight from a phone, or database bloat that nobody’s watching build up. None of those show up the day they happen. They show up as a slow site three months later with no obvious cause.

    What good looks like

    The benchmark is Core Web Vitals, measured at the 75th percentile and split by mobile and desktop, not a single load-time number:

    Metric Threshold for “good”
    Largest Contentful Paint (LCP) 2.5 seconds or less
    Interaction to Next Paint (INP) 200 milliseconds or less
    Cumulative Layout Shift (CLS) 0.1 or less
    Thresholds are measured at the 75th percentile, split by mobile and desktop.

    An update is one of the most common causes of a site suddenly missing one of these three, which is why testing an update before it goes live, and having a rollback if it breaks something, ties directly back to speed rather than being a separate concern. The ongoing maintenance routine that speed work depends on covers more than the update itself.

    What to do about it

    Work through these in order rather than picking the one that sounds most familiar:

    1. 01Check server response time first. If the origin server itself is slow, caching and a CDN only mask the problem for cached pages and do nothing for anything dynamic.
    2. 02Add page caching. A full-page cache serves a static copy instead of rebuilding the page on every request, which is the change most likely to matter on most sites.
    3. 03Fix above-the-fold lazy loading. Make sure the first visible image, usually the LCP element, loads eagerly rather than lazily. Reserve lazy loading for images further down the page.
    4. 04Compress and correctly size images. An oversized or uncompressed image is one of the most common reasons LCP misses the 2.5 second threshold.
    5. 05Clean up database bloat, with a backup first. Remove stale revisions, expired transients and orphaned metadata, and confirm the backup restores before making any changes.

    Every NoDrama plan includes page and browser caching, image compression and conversion, and real visitor speed data each month. Every plan gets the same global CDN. What differs is backup cadence: daily on The Standard, every 12 hours on The Higher Standard, and on every change on The Highest Standard. What’s included at each plan level has the full breakdown.

    Verify it

    After working through the list, re-run the Core Web Vitals check and compare it to the thresholds above rather than to how the site feels.

    Common misconceptions

    “Lazy-load every image.”

    Wrong for the LCP element specifically. web.dev’s own test showed lazy-loading above-the-fold images made archive pages 13 to 15 percent slower. Lazy-load what’s below the fold, not what’s above it.

    “Page speed is a major ranking factor, full stop.”

    Google’s own position is narrower than that. Core Web Vitals feed the ranking systems, but Google states directly that it still favors the more relevant page even when its page experience is worse.

    “A CDN fixes a slow site.”

    A CDN moves static content closer to the visitor. It does nothing for a slow database query or an unoptimized PHP process on the origin server, so a slow origin stays slow behind a CDN.

    What this does not solve

    None of the above fixes under-provisioned hosting. If the server itself doesn’t have the resources for the site’s traffic, caching and a CDN reduce how often that limit gets hit, but they don’t raise the limit. The same goes for a badly written theme: code that runs unnecessary queries or ships excessive CSS and JavaScript stays slow no matter how well everything around it is tuned. A full care plan covers the parts of ongoing WordPress operation that sit outside performance work specifically.

    Is my WordPress site actually slow, and what’s the fix?

    A slow WordPress site is almost always more than one problem at once: server response, caching, images, the CDN, plugins, the database and render-blocking code all contribute, and there’s no single fix that covers all seven. The honest way to check is Core Web Vitals at the 75th percentile, LCP at 2.5 seconds or under, INP at 200 milliseconds or under and CLS at 0.1 or under, worked through server response and caching first, then images and the CDN, then plugin and database cleanup, verifying with a fresh Core Web Vitals check after each step.

  • The WordPress Maintenance Checklist

    The WordPress Maintenance Checklist

    Get the checklist

    Copy this into a doc, a spreadsheet or a project board. It is ordered by cadence, not by importance, because a task that runs continuously and a task that runs monthly are both required, just not on the same day.

    WordPress maintenance checklist

    • Uptime monitoringContinuous
    • BackupsDaily to weekly, scaled to activity
    • Update review, core, plugins and themesWeekly
    • Security scanning and hardeningOngoing
    • Performance checkMonthly
    • Database and log cleanupMonthly

    Each line names the task and the cadence only. The next section covers what “correctly” means for each one, because a task run on schedule but run wrong is not much better than a task skipped.

    If the list above is more than you want to track by hand, see which parts of it NoDrama’s plans cover.

    Run each task correctly

    Updates, staged and tested

    A WordPress core update is not a single event on a single day. WordPress’s 2026 release schedule runs three major releases roughly four months apart, and plugins and themes ship on their own separate schedules on top of that. WordPress’s built-in auto-update system, introduced in WordPress 5.5, checks for available plugin and theme updates twice a day by default.

    That default check is not the same as a safe default rollout. WordPress’s own documentation on plugin and theme auto-updates says plainly that you may want to make sure you can roll back to a previous version before enabling them. The correct sequence is staging first, live push second, rollback held ready as the fallback if the live push still breaks something the staging test missed.

    The update pipeline

    Staging test
    The update installs on a clone first. Key pages and forms checked there.

    →

    Live push
    Passed on staging. The same update goes to production.

    →

    Rollback if needed
    The fallback path when the live push breaks something staging missed.

    Rollback is a fallback path that depends on a recent backup existing, not an automatic or instant recovery.

    Flow diagram of a WordPress update tested on staging before it goes live, with rollback as the fallback.
    Verify it

    After any update goes live, confirm the site’s key pages and forms still load and submit correctly. A staging test that passed is not the same evidence as a live push that held.

    Backups, matched to how often the site changes

    WordPress.org’s own backup guidance sets the cadence by activity rather than by a flat weekly rule for every site: once a week for smaller sites with fewer posts, daily for high-activity sites with a lot of posts.

    A backup has to cover both halves of the site to be useful. WordPress.org is direct about this: you need both the database and the files to fully restore a typical WordPress site, not one or the other. Keep 3 to 5 recent backups stored across at least two locations, so a single storage failure does not take out the only copy.

    Verify it

    Actually restore from a backup at least once, on a staging copy, rather than trusting that the backup file exists. A backup nobody has restored is a backup nobody has tested.

    Security scanning and hardening

    A security scan checks the site’s installed core, plugins and themes against databases of known, disclosed vulnerabilities. That is useful and it is also limited: a scan catches what has already been found and published. It does not catch a zero-day, a misconfigured server, or a weak password, because none of those show up in a vulnerability database.

    Hardening is a separate layer that sits alongside scanning rather than replacing it: correct file permissions, disabling the in-dashboard file editor, and protecting wp-config.php from being read directly.

    Verify it

    Confirm the scan actually ran and produced a dated result, and confirm hardening settings held after the last update. Some updates reset file permissions or reactivate a setting the update assumed was default.

    Uptime monitoring

    Uptime monitoring answers one question continuously: is the site responding right now. It does not answer why the site is down, and it does not catch a site that returns a page but is broken in a way that does not trip a downtime alert, a checkout that loads but will not process a card, for instance.

    Verify it

    Confirm the monitoring alert path itself still works by triggering a test alert periodically, so the first real outage is not also the first time anyone finds out the alert never fires.

    Performance and database cleanup

    A monthly performance check catches drift before it becomes a pattern: the same page that loaded fine last month, loading slower this month because of an accumulation of plugins, images or database bloat. It’s the comparison against last month’s result, not a single reading, that reveals the drift.

    Database cleanup removes what accumulates in the background and nobody deletes on purpose: old post revisions, expired transients, spam comments and orphaned metadata left behind by deactivated plugins. Left alone, these slow database queries and inflate the size of every backup that follows. Take a fresh backup before running any cleanup, since a cleanup tool that deletes the wrong table row is not something you want to discover without a way back.

    Verify it

    Confirm the site still loads and functions correctly after cleanup, the same way you would after an update.

    What reviewers and auditors actually check

    Anyone reviewing whether this routine actually ran, an auditor, an insurer, a new hire taking over the site, checks for evidence rather than intent. That means:

    • What updated, and when, with a dated log rather than a memory of “we keep it current”.
    • Whether the last backup completed and whether it has ever been restored, not just whether a backup file exists.
    • What the last security scan found, and whether anything flagged was addressed.
    • Uptime over the review period, as a record rather than an impression.

    A routine that ran but left no trace is indistinguishable, to a reviewer, from a routine that never ran.

    What this checklist does not cover

    This checklist covers the recurring maintenance work. It is not a security incident response plan for something that has already gone wrong, it is not a compliance program for a specific regulatory standard, and it is not a full site rebuild. Those sit on the other side of a boundary this checklist does not try to cover.

    Where teams get this wrong

    The same three mistakes show up across sites of every size.

    A security plugin gets installed once and never checked again.

    Installing a scanner is a decision made on one day. Reading its findings is a habit, and the habit is the part that lapses.

    Auto-updates get switched on with no backup and no rollback path behind them.

    The update mechanism runs on schedule either way. Whether a bad update costs an afternoon or costs nothing depends entirely on whether a rollback exists to fall back on.

    A one-off backup gets mistaken for a routine.

    Someone took a backup before a big change six months ago, and the site has changed a dozen times since then without another one.

    NoDrama’s plans cover the core of this list on every tier: updates kept current, off-site backups daily or more often, malware scans every 12 hours, uptime checked every minute, and real visitor speed data each month. Database cleanup is not part of the plans. See what every plan includes.

    Conclusion

    A WordPress maintenance routine is six jobs on six different clocks: updates tested before they go live, backups matched to how often the site changes, security scanning paired with hardening, continuous uptime monitoring, a monthly performance check, and regular database cleanup. Running any one of them on the wrong cadence, or running them without a way to verify they held, is how a routine task turns into a surprise.

  • Is WordPress Secure? The Honest Answer

    Is WordPress Secure? The Honest Answer

    The short answer

    Core is not where the risk lives.

    Patchstack tracks WordPress vulnerabilities two ways, and the two numbers don’t match:

    • Patchstack’s live database: 20 core vulnerabilities out of 11,259 tracked in 2025. That is 0% of the total.
    • Patchstack’s 2026 whitepaper: 6 core vulnerabilities out of 11,334 tracked in 2025. The whitepaper calls these “low priority” issues.

    This guide won’t average the two or pick a winner. Either way, the core sits at roughly 0 to 0.2% of everything tracked in 2025. Both reports agree on the rest: plugins account for 91% and themes for the remaining 9%.

    The other half of “is WordPress secure” is a market-share question, not a security one.

    As of 21 August 2026, WordPress runs 40.7% of all websites. It runs 58.9% of every site with an identifiable content-management system. That is according to W3Techs, an independent source that tracks this directly. WordPress’s own security page gives a different figure: “more than 43% of the web”. That is WordPress’s self-reported number. Don’t average the two.

    Running the largest share of the web makes WordPress the largest target pool. That is arithmetic, not the same as being the least secure platform on the web. The distinction matters before you look at what hardening actually covers.

    How WordPress security actually works

    Core, plugins, and themes get patched in different ways. That difference explains most of what follows.

    How core gets patched

    WordPress 3.7 introduced automatic background updates for core. The goal was security.

    Before WordPress 5.6 (released December 2020), a new install auto-updated only minor releases and translation files by default. From 5.6 onwards, a new install auto-updates both minor and major releases by default. WordPress’s own documentation calls turning that off “strongly discouraged”.

    Who patches the core? In WordPress’s own words: “more than 50 trusted experts, including lead developers, security researchers, and key contributors to every component of WordPress.” They even backport fixes to older, unsupported versions as a courtesy. No one is obligated to keep running those fixes for you, but the team ships them anyway.

    Confirm it

    Open the site’s update settings, or ask whoever manages hosting. Check that both minor and major core updates run automatically, not just minor ones.

    Why plugins and themes are different

    Plugins and themes don’t get the same treatment as core.

    WordPress.org’s security team can force an update to a specific plugin or theme, but only “in special cases”. This happens through the WordPress.org API, when a critical vulnerability needs patching everywhere at once, no matter what the owner set up.

    Outside that rare case, keeping a plugin or theme current is the owner’s job. An abandoned plugin stops getting fixes but stays installed, active, and reachable, which is the exact gap the 2025 numbers describe above.

    What a firewall or security plugin actually catches

    A firewall or security plugin checks the perimeter. It doesn’t patch anything.

    Patchstack’s 2026 whitepaper cites two penetration-testing studies. Hosting-level defences blocked only 12% of attacks on known, already-disclosed vulnerabilities. That rate rose to 26% across a broader set of vulnerability types.

    12–26%Attacks blocked at the perimeter

    A real layer, working by matching known attack patterns at the edge. It doesn’t rewrite the vulnerable code inside a plugin.

    It also can’t catch a backdoor already planted inside a theme or plugin file. That is exactly how a pirated (“nulled”) plugin works. The backdoor ships inside the same zip file a legitimate copy would use. Nothing forced its way in, so there is no signature to catch at the door.

    What a compromise actually costs to recover from

    What decides how a compromise ends? Not the firewall. The backup.

    A tested, offsite backup lets you restore the site to a known-good point. Without one, you rebuild from nothing.

    Whatever caused the breach, a vulnerable plugin, a guessed password, or a nulled theme, matters less at that point. What matters is whether you have a short restore ahead of you or a full rebuild.

    Why it matters even if the core is well maintained

    Sites still get compromised for a simple reason: almost all the attack surface sits in plugins and in what an owner does with them, not in core.

    Core didn’t get worse. The exposure lives in the 91% of 2025’s tracked vulnerabilities that sat in plugins, plus outdated versions, abandoned installs, nulled downloads, and reused admin passwords. None of that runs through WordPress’s security team. An unpatched plugin isn’t an abstract risk score. It is a defaced homepage or a compromised checkout page, the kind of thing a customer notices before the owner does.

    The 90% figure still gets repeated as if it were current. It isn’t. It traces back to Sucuri data from 2018, reported in a March 2019 Infosecurity Magazine article, which makes it roughly seven years stale. Whatever it measured about 2018 installs, it says nothing about security today, or even then. Treating it as a live statistic repeats the exact error this guide opened with: mistaking market share for a security score.

    There is a quieter point worth stating. Leaving WordPress’s free, built-in core auto-updates on solves the smallest slice of the real risk, and it costs nothing. A site owner who does only that has correctly handled the roughly 0 to 0.2% that lives in the core, for free. It doesn’t touch the 91% sitting one layer up in plugins, which is a maintenance question, not something core patches for you.

    What good WordPress security looks like

    What actually reduces this risk is a short, concrete list, not a product:

    • Keep core, plugins, and themes current. Test every update before it goes live, not after.
    • Remove abandoned or nulled plugins and themes. Check for ones you forgot were still active.
    • Use strong, unique admin credentials. Brute-force attacks against wp-login.php are their own attack surface, separate from any software bug. A weak or reused password doesn’t need a vulnerability to succeed.
    • Run file-integrity or malware monitoring. It tells you when a file changed after installation, so it catches a compromise that already happened. It doesn’t stop the first entry; that is what the points above are for.

    What to do about it

    Start with the plugin list, not the firewall. Three actions cover most of this:

    1. 01Audit every installed plugin and theme. Remove anything unused or no longer maintained by its developer. An abandoned plugin doesn’t announce itself. It just stops getting fixed. NoDrama’s free WordPress audit tool does this scan in minutes if you would rather not do it by hand.
    2. 02Turn on core auto-updates for both minor and major releases, if they are not on already. This slice of the problem is free and already solved.
    3. 03Decide who runs tested updates, file-integrity monitoring, and backups: your team, or a retainer that does WordPress operations full-time. Either answer works. What matters is that someone actually does it. See plan pricing and what’s included to compare that against doing it yourself.
    Confirm it

    After any of the above, log the date and what changed. Use a spreadsheet or maintenance log, something that outlives whoever made the change and stays checkable later.

    Common misconceptions

    “A security plugin is a complete answer.”

    It is a perimeter check, and it needs its own updates, like anything else on the site. The pentest figures above put its real block rate at 12 to 26% against known vulnerabilities. That is a partial layer, not a substitute for patching the plugin underneath.

    “My host’s security features cover this.”

    Hosting-level defences carry the same 12 to 26% block rate described above. They are the same category of perimeter defence. They harden the server. They don’t patch the vulnerable code inside a specific plugin.

    “WordPress gets hacked constantly because it’s insecure.”

    This usually traces back to the 90% figure: 2018 data, reported in 2019. It describes market-share exposure, not a security verdict. Running the largest share of the web means showing up in the largest share of hacked-site counts. That is just arithmetic, whatever the underlying security looks like.

    What this does not solve

    None of the above patches a specific vulnerable plugin for you. It doesn’t replace the judgement call of deciding a plugin is abandoned and removing it. It doesn’t replace reading what an update changes before it goes live, especially on a site that depends on that plugin working a certain way.

    Automation and monitoring narrow where your attention needs to go. They don’t remove the need for it.

    Is WordPress actually secure?

    The software WordPress ships from wordpress.org, backed by a security team of more than 50 people and a habit of backporting fixes to old versions, is well maintained. It is not the meaningful risk.

    What determines whether a WordPress site is secure is what runs on top of core and who keeps it current: which plugins are installed, whether they are still maintained, whether the admin password would survive a guess, and whether anything watches for a change after the fact.

    That is a maintenance question about one specific site, not a verdict on the platform every site like it happens to run on.