Audit My Site Get Started

Tag: Diagnosing

  • Core Web Vitals for WordPress: LCP, INP and CLS

    Core Web Vitals for WordPress: LCP, INP and CLS

    Contents

    1. 01
      Work out which metric is failing

      The short answerHow it actually worksWhy it mattersWhat good looks like

    2. 02
      Fix the one that is actually failingWhat to do about it
    3. 03
      Avoid the traps

      Common misconceptionsWhat this does not solve

    The short answer

    Three metrics make up Core Web Vitals, and each has its own threshold:

    LCP · Loading

    How long the biggest visible element takes to render.

    INP · Interactivity

    How long the browser takes to respond, start to finish, to anything a visitor clicks, taps or types into.

    CLS · Visual stability

    Whether content jumps around while the page is still loading.

    Not Core Web Vitals

    Time to First Byte, First Contentful Paint and Total Blocking Time show up in the same reports and get talked about in the same breath, but none of the three is a Core Web Vital. They are diagnostic metrics that help explain why LCP, INP or CLS is failing. Treat them as supporting evidence, not as a fourth or fifth vital to chase.

    How it actually works

    Largest Contentful Paint

    The LCP element is whichever single thing on the page is biggest by rendered area: usually a hero image, a video poster frame, a CSS background image or a large block of text. Google’s own measurement includes any redirect delay, connection time and server response time before that element can even start rendering, which is why a slow WordPress LCP is usually a hosting and Time to First Byte problem before it is an image-weight problem. Fix the server response first, or the image work does very little.

    A common WordPress misconfiguration works against the reader here directly: lazy-loading the LCP element itself. Lazy-loading defers an image until it is about to enter the viewport, and a hero image is in the viewport from the first paint, so telling it to lazy-load delays the exact element the metric is timing. Preload it instead.

    See the usual reasons a WordPress site loads slowly for the fuller list of causes behind a slow server response.

    Verify

    Confirm which element PageSpeed Insights or Search Console names as the LCP element for the page, then check whether it is set to lazy-load. If it is, that alone can explain a poor score with no other cause present.

    Interaction to Next Paint

    Interaction to Next Paint replaced First Input Delay on 12 March 2024. The two measure different things.

    Before 12 March 2024

    First Input Delay

    Only timed the delay before the browser started processing the very first interaction.

    Current

    Interaction to Next Paint

    Times the full latency, start to finish, of the browser’s response to every interaction on the page, and reports the worst one observed.

    On WordPress, that number is driven almost entirely by the cumulative JavaScript weight of the plugin stack: page builders, sliders, chat widgets, analytics tags and ad scripts all queue work on the same main thread a click has to wait behind.

    Verify

    Check whether a site that passed comfortably under First Input Delay now fails under Interaction to Next Paint with no code change at all. That gap is the clearest sign the two metrics measure different things, not that the site got slower.

    Cumulative Layout Shift

    The scoring formula is impact times distance: how much of the visible screen moved, multiplied by how far it moved. Two small, unrelated shifts add up the same way one big one does.

    On WordPress, the usual causes are missing width and height on images, a web font swap that resizes text after the page has already rendered, and ads, cookie banners or other content injected late into the page.

    Verify

    Reload the page and watch the first two seconds for anything visibly jumping, a button moving as an ad loads in above it, or text reflowing as a font swaps in.

    Why it matters for a WordPress site

    Google Search Central’s own wording on this is worth quoting directly rather than summarizing:

    “Google Search always seeks to show the most relevant content, even if the page experience is sub-par… Having a great page experience can contribute to success in Search, in such cases.”

    “Beyond Core Web Vitals, other page experience aspects don’t directly help your website rank higher in search results.”

    Source: Google Search Central, page experience

    Read plainly, that makes Core Web Vitals a contributing signal among many, not a dominant one. Relevant content that scores poorly on Core Web Vitals can still outrank thin content that scores well.

    What good looks like

    The same three thresholds, restated as the number that gets checked: LCP at 2.5 seconds or less, CLS at 0.1 or less, and INP at 200 milliseconds or less. Google scores each one at the 75th percentile of real visits, segmented separately for mobile and desktop, so a site can pass on desktop and fail on mobile with nothing else different.

    Two different reports can disagree, and it helps to know why before trusting either one on its own.

    Field data

    Chrome User Experience Report

    The data Search Console’s Core Web Vitals report is built on. Reflects real visits from real devices and connections over a rolling window.

    Lab test

    Lighthouse in PageSpeed Insights

    One simulated visit, on one simulated connection, at one moment.

    A site can score well in that single lab run and still fail in the field report, because the field data carries the slow connections and low-end phones the lab test never simulates.

    Server response time also depends on infrastructure the reader is already paying for.

    What to do about it

    A core web vitals fix starts with the diagnosis above, not with a plugin. Each metric has its own fix, and none of the three overlaps much with the others.

    For LCP

    Check Time to First Byte first. Managed WordPress hosting and an edge cache (a Cloudflare-style integration in front of the site) address server response time directly. Once that is solid, move to the hero image itself: serve it in a modern format such as WebP, and preload it rather than lazy-loading it.

    For INP

    Audit the plugin stack for scripts running on every page load that only need to run on one or two. A slider script loading on a page with no slider, or a chat widget loading before anyone has scrolled near it, are common candidates.

    For CLS

    Set an explicit width and height on every image and embed, and reserve space in the layout for anything that loads in late, ads and cookie banners included.

    See the full speed checklist, one item at a time for the complete list beyond these three, and have someone check which metric is actually failing before spending time on a fix that targets the wrong one.

    See how this is held on the retainer.

    NoDrama’s speed optimization work checks Core Web Vitals against the site on an ongoing basis, not as a one-time fix.

    See Speed Work

    Common misconceptions

    “A caching plugin fixes Core Web Vitals.”

    It improves Time to First Byte and repeat-visit LCP. It does nothing for INP, which is client-side JavaScript running after the page has already loaded, and nothing for CLS, which is a markup and layout problem.

    “The padlock and a CDN mean performance is handled.”

    A CDN helps LCP through Time to First Byte and faster asset delivery. It has no effect on the JavaScript execution behind INP or the missing dimensions behind CLS.

    “Core Web Vitals is a major ranking factor.”

    Google’s own wording, quoted above, treats it as a contributing signal that can help when content is otherwise comparably relevant, not a dominant one that overrides relevance.

    What this does not solve

    Core Web Vitals measure loading, interactivity and visual stability. They say nothing about uptime, security or content quality, and a site can pass all three metrics while having an outdated plugin or no backup in place.

    Conclusion

    Core Web Vitals are three separate metrics with three separate causes: LCP traces to hosting and image handling, INP traces to plugin JavaScript, CLS traces to unreserved layout space. Check Search Console to see which one is actually failing before changing anything, because a fix aimed at the wrong metric leaves the score exactly where it started.

  • How Do You Check If Your Website Is Secure?

    How Do You Check If Your Website Is Secure?

    Contents

    1. 01
      Understand what each check actually tells you

      The short answerHow it actually works

    2. 02
      Run the checks

      What good looks likeWhat to do about it

    3. 03
      Know what still isn’t covered

      Common misconceptionsWhat this does not solve

    The short answer

    Checking whether a website is secure means running four separate signals, not one. Each covers a different layer, and a clean result on any one of them is not a clean bill of health for the other three.

    Signal What it checks What it misses
    Google Safe Browsing status
    		Whether Google’s crawler classified the URL as malware, phishing, unwanted software or deceptive content on a recent pass Anything injected since that pass, or anything on a page the crawler never reached
    Blacklist (DNSBL) check
    		Whether the domain or IP has been reported to a third-party list such as Spamhaus or Barracuda A fresh compromise nobody has reported yet
    Certificate validity (the padlock)
    		That the connection is encrypted and that whoever requested the certificate controlled the server at issuance Patched software, server-side validation, or malware already on the site
    File-level malware and vulnerability scan
    		The actual files and database for injected code, plus installed versions against known disclosures Nothing, but it is the one check none of the URL-only tools can run
    The four checks that make up a website security check, and what each one covers.

    How it actually works

    Google Safe Browsing

    Google’s Safe Browsing technology scans its own web index daily. As Google puts it, “Our Safe Browsing technology scans our web index on a daily basis to identify unsafe websites.” A URL that turns up gets classified as malware, phishing, unwanted software or deceptive content. Malware detection works by scanning sections of the index and testing pages in a virtual machine to see if it gets infected. Phishing detection runs on statistical models instead.

    Once a site is flagged, the warning is added within minutes of detection, and it takes about half an hour on average to show up externally. That speed cuts both ways.

    Catches

    A site that was actively serving bad content at its last crawl.

    Misses

    Anything injected after that crawl, anything on a page the crawler never reached (behind a login, or blocked by robots.txt), and a vulnerable plugin sitting on the site that nobody has exploited yet.

    Run the lookup directly at Google’s Safe Browsing site-status tool, and read how the scan actually works in Google’s Safe Browsing transparency FAQ. For the fuller process this single check feeds into, see the fuller checklist this feeds into.

    Blacklist and DNSBL checks

    A blacklist check is a DNS lookup, cross-referenced against third-party lists such as Spamhaus, Barracuda or SORBS. Each list sets its own listing criteria. A clean result here means the domain or IP has not been reported yet, not that the underlying code is clean. It also misses a site that was compromised recently and hasn’t been reported, and it can produce a false positive on shared hosting, where one bad neighbor gets an entire IP block listed.

    The padlock and certificate

    A valid certificate confirms two things only: the connection between browser and server is encrypted, and whoever requested the certificate had administrative access to the server at the moment it was issued. It does not confirm the software behind that connection is patched, that server-side validation is sound, or that the site is free of malware.

    Free certificate issuance changed what the padlock actually signals. A phishing site can get the same valid HTTPS certificate a legitimate business gets, and vendor reporting on phishing incidents has noted that most reported phishing sites now carry a valid certificate too.

    Read the padlock correctly

    Treat the padlock as confirmation of encryption, never as confirmation of safety.

    Malware and vulnerability scanning

    This is the layer the first three checks cannot touch, because it requires looking at the site’s own files rather than at how the outside world sees the domain. A malware scan inspects the files and database for injected code, unexpected admin accounts and altered core files. A vulnerability check compares the installed versions of core, themes and plugins against public disclosure databases such as WPScan’s.

    Both require server-side access or a direct look at the codebase. A URL-only checker run from outside the site cannot do either.

    Where the free checks stop

    External reputation
    • Safe Browsing
    • Blacklist
    • Certificate

    Requires file-system access

    Requires file-system access

    On the server
    • Malware scan
    • Vulnerability check

    A diagram showing the boundary between external reputation checks and a file-level security scan.

    External reputation and file-level access are two different zones. Safe Browsing, blacklist status and the certificate all judge the site from outside. A malware scan and a vulnerability check are the only ones that look at what is actually sitting on the server.

    What good looks like

    A genuinely clean result means all four signals come back clear at once:

    No Safe Browsing flag
    No blacklist listing
    A valid certificate with no mixed-content warnings
    A file-level scan that turns up no injected code and no versions matching a known disclosure

    One green result out of four is a start, not a finish. It tells you one layer looks fine today. It says nothing about the other three.

    What to do about it

    1. 01

      Run the Google Safe Browsing site-status lookup directly against the domain.

    2. 02

      Run a blacklist (DNSBL) checker against the domain to see if it appears on Spamhaus, Barracuda or a similar list.

    3. 03

      Check the certificate’s validity in the browser, and look in the browser console for mixed-content warnings on pages that should be fully encrypted.

    4. 04

      Run a malware and vulnerability scan, either through a security plugin with file-system access or through a fuller audit.

    Each of these is a snapshot, not a standing guarantee, so the useful habit is running all four again after any change to the site, not just once after a scare.

    Get the layer those four checks can’t see.

    NoDrama’s free website audit checks the site’s actual files and versions, no pitch attached.

    Audit My Site

    Common misconceptions

    “HTTPS means the site is safe.”

    It confirms encryption in transit and that someone controlled the server when the certificate was issued. That’s all it confirms.

    “A clean Safe Browsing result means nothing is wrong.”

    It reflects only what Google’s crawler has seen so far, and that can lag behind a fresh infection by hours or days.

    “A security plugin covers all of this.”

    A plugin scans what it has file-system access to. Reputation flags such as Safe Browsing and blacklist status are external judgments, and a local plugin cannot see or clear them.

    What this does not solve

    None of the four checks above replace an ongoing, operated security practice: updates tested before they go live, monitoring that runs continuously rather than once, and a documented process someone actually follows. A clean result across all four today answers only “as of today.” For how the security work is scoped, see how the security work is scoped, and for who actually watches this after today, see who actually watches this after today.

    Conclusion

    Checking whether a website is secure is four separate signals, not one: Google Safe Browsing status, blacklist status, certificate validity, and a file-level malware and vulnerability scan. Each one is narrow, each one misses what the other three catch, and the only honest answer to “is my site secure” comes from running all four rather than trusting whichever one came back clean first.

  • How Do I Know If My WordPress Site Is Hacked?

    How Do I Know If My WordPress Site Is Hacked?

    Contents

    1. 01
      Work out what you’re looking atWhat a hacked site looks like
    2. 02
      Check the five signs

      The five signsHack vs. broken

    3. 03
      Act, and stop it recurring

      What to do once you’re sureTroubleshootingStop it happening againWhat this doesn’t solveIs your site hacked?

    What does a hacked WordPress site look like?

    Google’s own definition: “This is any content placed on your site without your permission because of security vulnerabilities in your site.” Three common ways in: a vulnerable plugin, weak credentials, or an outdated core file with write access.

    The usual motive is SEO spam or redirects, via cloaking: the real site loads for a logged-in admin, and a different, injected page loads for Googlebot or a search visitor. “It looks fine to me” is not a clean bill of health, since that’s exactly what this hack is built to show.

    See whether WordPress itself is the weak point for that separate question.

    How to confirm the site is compromised (the five signs of a compromised website)

    Five signs checklistAny one of these holding is enough to act on
    1. 01 Google or browser warning
    2. 02 Pages you never published in search
    3. 03 Redirects to another site
    4. 04 Unknown admin users or files
    5. 05 Host suspension or abuse notice
    Five signs a WordPress site has been hacked, shown as a checklist.

    Each sign has its own cause and check; none needs developer skill.

    1. Google or your browser warns people away

    Google’s Search Console help: “Pages or sites affected by a security issue can appear with a warning label in search results or an interstitial warning page in the browser when a user tries to visit them.” This shows as “This site may be hacked” in search, or a warning in Chrome, under Hacked Content, Malware and Unwanted Software, or Social Engineering.

    Verify it

    Open Security Issues in Search Console (site must be verified there). Green “no issues” clears this; anything listed does not. See Google’s Security Issues help.

    Google’s Security Issues help

    2. Search results show pages you never published

    Injected spam: pharmacy, gambling or foreign-language pages, often served only to Googlebot.

    Verify it

    Search site:yourdomain.com in a logged-out incognito window and scan titles and snippets for anything that matches nothing in your CMS.

    3. Visitors get sent to another site

    Injected JavaScript, or a modified .htaccess or functions.php file, often triggers only on referrer or device, so a direct visit looks fine. Wordfence documented a 2019 campaign exploiting vulnerable plugins to inject this code.

    Verify it

    Visit the site logged out, in incognito, arriving from search rather than typed, and once more from a phone on a different network.

    Wordfence’s 2019 write-up

    4. Admin users or files appear that nobody created

    This sign is the foothold: a new admin account, an extra file in wp-content or plugins, or an edited core file lets an attacker return after cleanup. wordpress.org’s checklist includes unauthorised new users.

    Verify it

    Open Users, filter by Administrator, and match every account to a named person. Ask a developer to check file-modification dates in wp-content and core.

    wordpress.org’s FAQ on a hacked site

    5. Your host suspends the site or reports abuse

    Hosts run their own malware and abuse scanners, independent of Google. A suspension, or a report the site is sending spam or attacking others, can arrive before, or without, a Google flag.

    Verify it

    Check host email and the control panel for a suspension notice or an abuse report.

    When it looks like a hack but isn’t

    A broken plugin update, an expired SSL certificate, a stale cached page, or a host outage can look alarming and match none of the five signs above. If Security Issues is clean, admin accounts belong to the team, and the host hasn’t flagged anything, the read is broken, not hacked: roll back, renew, or contact the host. An SSL warning or outage doesn’t need a forensic audit.

    What you see Points to a hack Points to broken
    Search Console Security Issues An issue is listed Green “no issues”
    Unknown admin users An account nobody can name Every account belongs to the team
    Host abuse notice Suspension or abuse report received Host hasn’t flagged anything
    SSL warning only — Expired certificate: renew it
    Error after an update — Broken plugin update: roll back
    Stale cached page — Cache serving an old version
    Table comparing signs of a compromised website with ordinary WordPress failures.

    See how tested updates and rollback are handled.

    What to do once you’re sure

    wordpress.org’s first steps: stay calm, document what you found, and scan.

    Option 1Recommended

    Easiest: tell your host and follow wordpress.org’s first steps

    Your host runs its own scanners and may already know. Follow wordpress.org’s guidance from there.

    Option 2

    Done for you: hand it to whoever runs security for the site

    A retainer with monitoring and backups already running means some of these signs can be caught before you notice them.

    Option 3

    Manual: restore from a clean backup and close the foothold

    Restore to a known-clean point before the first sign appeared: the older the sign, the further back. Remove admin accounts nobody can name, and have a developer compare files against a clean copy. See how off-site backups and restores work.

    Verify it

    Re-run all five checks: Security Issues clean, site: search clean, incognito visit from search and mobile clean, Users list matches named people, no host notice.

    Troubleshooting

    “Google says this site may be hacked, but Search Console shows no security problems”

    Cloaking can explain the mismatch: the spam goes to Googlebot and search visitors, not you. Run the site: search and incognito check rather than trusting either alone.

    “My security plugin says everything is clean”

    A scanner reports what it was configured to catch; silence isn’t proof of more. Cross-check against the signs above.

    How to stop it happening again

    Turn the causes above into a routine: tested updates, admin accounts reviewed, monitoring and scanning running, and off-site backups you could restore from tomorrow. The monthly check is the five-sign list. See the site’s state now with NoDrama’s free WordPress audit.

    See what a security retainer covers.

    NoDrama’s WordPress security retainer runs security monitoring and malware scanning on every plan, which can catch some of these signs before you do, and keeps off-site backups to restore from if one turns up.

    See Security Work

    What this guide does not solve

    It doesn’t cover a full malware cleanup, a forensic investigation, or how a specific attacker got in. A site handling payments or client data also has obligations this guide doesn’t cover.

    So, is your WordPress site hacked?

    Five signs settle it: a Google or browser warning, unpublished pages in search, a redirect elsewhere, an unrecognised admin account or file, or a host suspension. None depend on how the dashboard looks while logged in; the checks happen outside it. If none hold, the read is broken, not hacked, or fine.

  • Why Is My WordPress Site So Slow?

    Why Is My WordPress Site So Slow?

    Contents

    1. 01Work out which layer is slow. What “slow” actually means, and confirming where the time is going.
    2. 02Fix the layer that is actually slow. The three ways to fix it, from easiest to most manual.
    3. 03Confirm it is held and stop it from recurring. Verify the fix, troubleshoot the remaining edge cases, and keep it from coming back.

    What “slow” actually means for a WordPress site

    Slow is a number, not a feeling. Two numbers, in fact: time to first byte, the gap between the browser asking for the page and the server sending back the first byte of a response, and render time, how long the browser then takes to paint and settle the page a visitor actually sees.

    Google measures both through Core Web Vitals, assessed at the 75th percentile of real visits so one fast or slow load does not skew the picture. Largest Contentful Paint (LCP), the render time of the largest image or text block in the viewport, is good at 2,500 milliseconds or under. Interaction to Next Paint (INP), how quickly the page responds to a visitor’s interactions across the whole visit, is good at 200 milliseconds or under. Cumulative Layout Shift (CLS), the sum of unexpected layout shifts as the page loads, is good at 0.1 or under.

    Server response (TTFB)

    Hosting, plugins running on every request, and database queries.

    Above ~600 to 800ms flags a server-side problem

    Page weight

    Full-size images and the theme’s full CSS and JavaScript bundle.

    LCP good at 2,500ms or under

    Browser rendering

    Render-blocking scripts, stylesheets, and third-party embeds.

    INP good at 200ms or under, CLS at 0.1 or under

    All three vitals are measured at the 75th percentile of real visits. These are Google’s general Core Web Vitals thresholds, not WordPress-specific ones.

    A slow WordPress site usually comes from one of three places:

    Server-side load.

    The hosting environment, an overloaded database, or plugins that run heavier queries than they need to.

    Unoptimized front-end weight.

    Full-size images, render-blocking scripts and stylesheets, or a theme that loads its entire CSS and JS bundle regardless of what the page uses.

    No caching layer.

    Every visit reprocesses the same PHP and database work from scratch instead of serving a version already built.

    Which one applies to your site is not a guess. It is the next step.

    Confirm where the time is actually going

    Run a PageSpeed Insights check, or look at the field-data Core Web Vitals for the page, before you change anything. That gives you a TTFB number and a render-time picture to compare against once you have made a change.

    If TTFB alone is high, roughly above 600 to 800 milliseconds before any content starts, the problem is server-side: the hosting environment, the plugins running on every request, or the database being asked the same questions too many times.

    If TTFB looks fine but the page still finishes rendering slowly, the problem sits in the front end: images, render-blocking CSS or JavaScript, or third-party scripts like chat widgets, ad tags or web fonts loading synchronously.

    Verify it

    Write down the specific number, TTFB, and the Core Web Vitals reading before you touch anything. That is the only way to confirm a fix actually moved it rather than assuming it did.

    Fix it

    Option 1, easiest, recommended: page caching plus image compression

    A page cache stores the fully rendered HTML after the first PHP and database cycle runs, then serves that stored copy on repeat requests instead of running PHP and the database again. Paired with image compression, this catches the two most common causes on a typical site: repeat-visit server load and oversized static assets.

    What it misses matters as much as what it catches. A page cache does not cover logged-in visitors, cart or account pages, or any URL with a query string, all excluded from caching by design because that content is meant to be dynamic. If your slow pages are the ones a logged-in user or a shopper sees, caching alone will not touch them.

    This is also the baseline a maintenance plan should already be checking as part of ongoing upkeep, not a one-time install and forget.

    Verify it

    Re-check the TTFB and Core Web Vitals numbers from the section above, on the same page, after the cache has had time to build.

    Option 2, done for you: a CDN plus performance work as part of a managed plan

    A content delivery network (CDN) serves cacheable static assets, images, CSS, JavaScript, from an edge node physically closer to the visitor, and keeps a pre-warmed connection open to the origin server. The first request for a given asset is an origin pull, fetched from your server and cached at the edge. Every request after that is served from the edge until the cache expires.

    What a CDN cannot do is speed up PHP execution, database queries, or anything generated dynamically at the origin server on every request. If the slowness is server-side, a CDN sits on top of the problem without reaching it.

    Caching plugin CDN
    Logged-in pages Not cached Not cached
    Cart or account pages Not cached Not cached
    Static assets (images, CSS, JS) Cached at origin Cached at edge, closer to visitor
    Dynamic HTML (PHP, database output) Not touched Not touched
    Table comparing what a caching plugin and a CDN each cover, showing both miss logged-in pages and cart pages, and neither speeds up dynamic HTML.

    See how the CDN and performance work is scoped as part of a managed plan, since CDN allocation and the performance work around it are handled as ongoing configuration rather than a one-time setting.

    Verify it

    Confirm the origin pull happened (the first load of an asset after a change) and that the second load of the same asset comes from the edge, then re-check TTFB against the number you noted earlier.

    Option 3, manual: clean the database and audit plugins one at a time

    Post revisions, spam comments, expired transients, and orphaned tables accumulate in the WordPress database over time and are not purged automatically. Every uncached query against a bloated database takes measurably longer than the same query against a clean one.

    Deactivating plugins one at a time is a reasonable way to find an obvious offender, a single plugin running an expensive query on every page load. It is the longest path of the three, and it will still miss the cumulative database bloat, image weight, and theme bloat that no single plugin caused on its own.

    Verify it

    After cleaning the database or deactivating a plugin, re-run the same TTFB check and confirm the number moved before assuming the change worked.

    Verify the fix actually worked

    Re-run the same check you used to note the original number on the same page, cold. Not immediately after clearing a cache, since the first load after a cache clear rebuilds the cache and will look artificially slow. Compare the new TTFB and Core Web Vitals reading against the number you wrote down at the start. If it has not moved, the fix touched the wrong layer.

    Troubleshoot

    The site is fast on desktop but slow on mobile.

    Mobile and desktop Core Web Vitals are measured and reported separately. A fix that improves desktop LCP or INP does not automatically carry over to mobile field data. Check the mobile-specific numbers directly rather than assuming a desktop result applies.

    I installed a CDN, and nothing changed.

    This is the direct symptom of a server-side bottleneck a CDN cannot reach. A CDN only speeds up cacheable static assets served from the edge. If TTFB was already the problem, adding a CDN leaves it untouched. Re-check TTFB specifically rather than the overall load time.

    It’s fast for me but slow for everyone else.

    You are likely viewing a warmed, cached, or logged-in version of the page that a first-time or logged-out visitor does not get. Check the page from a logged-out session, ideally on a different network, before concluding the fix worked for everyone.

    Prevent it recurring

    Run the same diagnostic monthly, not just after a complaint. A monthly health report that tracks TTFB and Core Web Vitals over time catches drift before it becomes a complaint, which is what a monthly health report actually tracks as part of ongoing maintenance.

    Not sure which layer is slowing your site down?

    Send NoDrama your URL and get a free website audit, no pitch attached.

    Audit My Site

    What this does not solve

    The diagnostic above finds and addresses the common causes: server load, page weight and missing caching. It does not replace hosting that is genuinely undersized for a high-traffic site, where the fix is a hosting change, not a configuration one. It also does not audit custom code written specifically for your site, since that requires a developer familiar with the codebase, not a maintenance diagnostic.

    Google has publicly confirmed that page speed is a ranking signal. This piece does not quote a specific figure for how much it weighs, because no verifiable figure exists to quote.

    Unmaintained plugins that slow a site down are often the same plugins carrying real security exposure, so a speed audit and a security review usually turn up the same list.

    So, why is your WordPress site actually slow?

    It comes down to one of three layers: server response time, page weight, or browser rendering, and the fix depends on which one the diagnostic points to. Check TTFB first. A high number means the problem is server-side. A fine TTFB with a slow finish means the problem is in what the browser has to load and render. Fix the layer the numbers point to, not the layer that is easiest to buy a plugin for, and re-check the same numbers afterward to confirm it held.

  • 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.

  • 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.