Website performance and security audit: what it finds and costs

Your site loads slowly, a plugin warning or an unknown name in your user list has made you uneasy, and you want one team to look at all of it, fix it and stay. That team exists. The first thing it should give you is a website performance and security audit: one written review that covers speed and risk together, ranks what to fix and prices the work.

This article shows who can do that job, what the audit checks and what usually goes wrong on WordPress, Webflow, Shopify and Next.js. It also covers what fixing costs, how to confirm the fix worked and how to keep the gains.

You do not need to read code to follow it. You need a goal (more enquiries, fewer abandoned carts, no incident) and an honest view of where the site stands today.

Who can run a website performance and security audit#

You need one accountable team that audits the site, fixes what it finds and keeps it running afterwards. When those jobs sit with different vendors, the gaps between them become your job. That is where slow, exposed sites tend to stay that way.

Three kinds of provider you will meet#

Most buyers meet three kinds of provider. A security-only vendor scans for malware and known vulnerabilities, then sends a report. A speed-only specialist tunes images, caching and scripts. A single team handles the audit, the fixes and the upkeep.

The first two have a place. A one-time malware cleanup suits a security vendor, and a single campaign page suits a speed specialist. They fall short when the cause is shared. A speed specialist who removes a heavy plugin may never learn it was also the one with a known flaw.

Why one audit covers speed and security#

Slow and exposed sites often share causes. A plugin nobody updated is heavier than its current version and is also a common way in. A tracking script added by marketing delays the first screen and runs code nobody on your team reviewed. A budget hosting plan with no caching rules often has no firewall and no tested backup either.

When one team reads all of that in one pass, it finds each cause once and fixes it once. You get one report, one priority list and one person to call. That is usually cheaper and clearer than two projects that undo each other's work.

What to ask before you hire#

Ask these questions in the first call. The answers tell you more than a price list does.

• Will I get a written report, with findings ranked by risk and effort?
• Is speed measured on real visitors or only in a lab test?
• Do you work on my platform every week, or once a year?
• Who touches the site after the audit, and how fast do they reply?
• How will we prove together that the fix worked?
• What happens if an update breaks something?

If you are also deciding between a freelancer and an agency for the upkeep, freelancer vs agency for website maintenance compares both on risk and continuity.

What a website performance and security audit checks#

A website performance and security audit is a structured review of how fast your site answers real visitors and how exposed it is to the problems that usually cause incidents. You receive a report that lists each finding, why it matters to your business, how much effort it takes and in what order to act. It covers six areas, grouped below into four parts.

Core Web Vitals on real visitors#

Core Web Vitals are Google's measures of how a page feels to a visitor. LCP is how fast the main content appears. INP is how fast the page answers a tap or a click. CLS is how much the layout jumps while loading. web.dev explains each metric, and Google describes how they fit into page experience.

The audit reads field data, meaning measurements from real visitors on real phones, and compares it with the thresholds below.

A lab test helps find causes, while field data tells you whether visitors feel the problem. For the metric detail, read mastering Core Web Vitals for B2B websites.

Plugin, theme and dependency inventory#

The auditor lists everything your site runs: plugins, theme, apps, embedded scripts and code libraries. Each gets a version, a last update date and a purpose. Anything unused, outdated or abandoned is flagged.

This is the quickest source of both speed gains and lower risk. The OWASP Top 10 names vulnerable and outdated components as one of its main risk categories, and every unused plugin also adds weight to your pages.

Server, headers and certificates#

Next the audit reviews the hosting setup: the PHP or Node version, caching, compression, the certificate and the CDN (a network that serves files from a location near the visitor). It also reads the response headers your site sends. Strict-Transport-Security keeps browsers on the secure version of your site, and Content-Security-Policy limits which scripts may run on your pages.

Missing headers and default settings fall under security misconfiguration, another general OWASP category. They are common findings and often a fast fix.

Backups and access#

The last area decides how bad a bad day gets. The audit checks how often backups run, where they are stored (a copy on the same server does not count) and when one was last restored. It then lists who has admin access, whether former staff or agencies still do, and whether two-factor sign-in is on.

Broken access control sits among the top OWASP categories, and in small teams it often looks simple: an old account nobody closed. The report turns all four parts into a ranked list. It is the start of a loop, because findings are fixed in order, then watched, then read again in the next audit.

Audit loop

1. 01AuditVitals, inventory, server, backups and access
2. 02PrioritiseRank by risk and effort
3. 03FixQuick wins, then structural work
4. 04KeepMonitoring and monthly report

Next audit

Four-stage loop showing audit, prioritise, fix and keep, with monitoring feeding the next audit

Common causes of slow and insecure sites by platform#

The platform shapes where problems hide. On Webflow and Shopify the vendor looks after hosting and the core, so trouble comes mostly from what you add. On WordPress and custom apps your team owns more of the stack, so updates and hosting settings matter more.

WordPress and WooCommerce#

Plugin count and age are the usual story. Each plugin may load scripts and styles on every page, and each is code someone must keep updated. WooCommerce stores add cart and checkout queries, which need caching rules that respect logged-in shoppers and a host sized for the traffic.

Webflow#

Hosting and the CDN are managed, so slowdowns tend to come from large images, many fonts and custom code embeds for chat, tracking and forms. Security risk sits in that embedded third-party code, in who holds Editor and Designer access, and in forms that pass data to other tools.

Shopify#

Apps add scripts to the theme, and some leave code behind after you uninstall them. Heavy theme sections, unsized images and many tracking pixels slow the product page. Shopify runs the checkout, so the audit focuses on staff accounts with full permissions, apps with wide data access and the theme code.

Next.js and custom apps#

Speed problems come from too much JavaScript sent to the browser and data requests that nothing caches. Risk comes from outdated dependencies, API routes that skip checks on who is asking, secrets stored in the wrong place and missing headers at the hosting layer. Custom code gives you the most freedom and needs the most regular care.

How to order fixes: quick wins first#

Work in this order: contain risk first, then take the speed gains that cost the fewest hours, then do structural work. The site stays safe while it improves, and you see visible results early.

Week one: contain the risk#

These steps are small, cheap and protect you most. Test each on a staging copy (a private duplicate of the site) before it touches the live one.

1. Take a fresh backup and store a copy away from the server.
2. Remove admin accounts of people who left and turn on two-factor sign-in.
3. Update components with known vulnerabilities.
4. Delete plugins, apps and scripts nobody uses.
5. Confirm HTTPS works on every page and the certificate renews itself.

Quick wins that move the metrics#

Most speed gains come from a short list. Resize images and serve them in a modern format, loading those below the first screen later. Turn on caching and compression. Defer or remove third-party scripts that do not earn their weight. Set width and height on images and embeds so the layout stops jumping.

A few of these often shift LCP and CLS within days, because they target what the visitor waits for first. Heavier work, such as slow database queries or theme code, comes after.

When a rebuild makes more sense#

Patching has a limit. A rebuild is the honest answer when the theme or codebase is no longer maintained, when each fix breaks something else, or when the platform cannot do what the business now needs. It also fits when a year of patching would cost close to a new build.

Most sites do not reach that point, and a good audit says so with the numbers beside it. If it does, you at least decide with evidence rather than frustration.

What a website performance and security audit costs#

Cost follows effort, and effort follows how much your site has accumulated. Treat any figure here as a starting point for your own quote, because size, platform and condition change it.

What drives the price up or down#

Six things move the price most:

• Size: pages, products, languages and integrations to review.
• Components: how many plugins, apps and dependencies, and how old.
• Hosting: whether the site must move to a better setup.
• Custom code: theme or app code that needs reading and changing.
• Condition: a clean site costs less than one already infected.
• Testing: a staging copy and checkout tests add time and prevent surprises.

A worked example, clearly illustrative#

Take a B2B WordPress site with about 40 pages. Suppose it runs 22 plugins, six of them outdated and three unused, has no security headers, keeps backups only on the same server and still lists two former staff as admins. Mobile LCP in field data sits above the 2.5 second target.

The ranges below are illustrative for a typical site of this size and are not a quote. Your written estimate comes from the audit itself.

For this example, the audit plus quick wins would sit around the lower half of those two rows. Structural work only appears if the report shows the quick wins are not enough.

One-off fix or monthly plan#

A fix is a project, and upkeep is a rhythm. Plugins release updates every week, certificates expire and new scripts get added, so a repaired site drifts back without someone watching it. Choose a one-off project (Small, Medium, Large or Custom) for the fix, and a monthly Care plan or Retainer for what follows.

The engagement options show how each one works. A monthly plan usually costs less than recovering from one incident, and it makes your budget predictable.

How to verify the fix worked#

You should not have to take anyone's word for it. Each area of the audit has a check you can run or ask to see.

Speed: compare field data before and after#

Save your Core Web Vitals report before any work starts. Field data builds over a rolling period of about four weeks, so give it time to reflect the changes. Then compare LCP, INP and CLS against the thresholds, looking at mobile first.

If a metric improved in the lab but not in field data, the fix reached the test and not your visitors. Ask the team to explain what is still slow.

Security: OWASP basics to confirm#

Use the OWASP Top 10 as a plain-language checklist. For access: can a visitor reach an admin page or another customer's data, and are old accounts gone? For configuration: are the security headers present, debug mode off and default accounts removed? For components: does the inventory show no known vulnerable versions?

Ask for evidence, such as a header scan and the component list with versions. For the wider picture, web application cybersecurity: OWASP and what B2B teams must prioritize goes deeper.

Recovery: restore a backup once#

A backup you have never restored is a hope. Ask the team to restore the latest one to a staging copy, then check that login, forms and checkout work, and note how long it took. That time is your real recovery time after an incident.

When you have run all the checks, tick them off one by one.

• Field data for LCP, INP and CLS improved against the saved baseline
• Security headers such as Strict-Transport-Security and Content-Security-Policy are present
• The component list shows no known vulnerable versions
• Admin accounts were reviewed and former users removed
• A backup was restored once on a staging copy
• Monitoring alerts were tested and reach the right person

How to keep your site fast and safe#

A fixed site decays slowly. New plugin versions, new marketing scripts and new staff all change it. The habit that protects your result is small and regular: monitor, update, review and read a report.

What monitoring should watch#

Monitoring should tell you about a problem before a customer does. It needs to watch five things:

• Uptime and response time of key pages, such as the home page and checkout.
• Certificate expiry dates.
• Backup success each day.
• Core Web Vitals trend over time.
• Unusual sign-in activity and unexpected file changes.

An alert is only useful if a named person receives it and knows what to do. Test that once, as the checklist says.

What a care plan covers#

A care plan turns the rhythm below into work somebody owns. It is the monthly alternative to waiting for the next emergency. For a deeper look at WordPress upkeep, including who fixes updates that break the site, read WordPress maintenance service: who fixes broken updates.

1. Daily

   Backups and uptime checks

   Automatic backups run and key pages are checked, with alerts to a named person.

2. Weekly

   Updates on a staging copy

   Plugins, themes and dependencies are updated, tested and then released.

3. Monthly

   Written report

   You receive findings, work done and the Core Web Vitals trend.

4. Quarterly

   Access and plugin review

   Accounts, permissions and unused components are checked again.

How to read a monthly report#

A good report answers four questions in plain words. What changed on the site this month? Did speed hold against the thresholds? Was anything blocked or repaired? What does the team recommend next, and what will it cost?

If a report lists tasks and never mentions your goal, ask for it to be tied to enquiries, sales or bookings. The numbers are only useful when they point to a decision.

Where to start this week#

You can take the first step in an afternoon, with no vendor involved. Open the Core Web Vitals report in Google Search Console, or run your key pages through PageSpeed Insights and read the field data section, and save a screenshot as your baseline. Then write down everyone who has admin access to the site, hosting and domain, and mark anyone who has left.

Those two lists are most of what an auditor needs to start. Bring them, tell werun.dev your goal (more enquiries, fewer lost sales, no incident) and we will build the way there: an audit, a ranked fix plan and the upkeep that keeps it working. We reply in under 2 hours on business days, and you can compare a one-off project with a Care plan or Retainer on the engagements page. When you are ready, tell us about your site.

Frequently asked questions#