Website Performance Audit: A Practical Step-by-Step Guide

A slow website quietly costs you money. Visitors leave before the page paints, Google pushes you down the rankings, and the enquiries never arrive. A website performance audit is how you find out exactly what is dragging your site down, and this guide walks through the full process: the metrics to measure, the thresholds to hit, the tools to use, and the specific fixes that move the numbers, with notes for Malaysian businesses along the way.

What a website performance audit is, and why it matters

A website performance audit is a structured review of how fast, stable, and responsive your site is for real visitors, followed by a prioritised list of what to fix. It is not a single score from one tool. It combines lab tests (a controlled run in a tool like Lighthouse), field data (what real users actually experienced), and a manual look at the things automated tools miss.

Three reasons it belongs on your schedule, not your someday list:

• It is a Google ranking factor. Core Web Vitals feed into Google’s page experience signals. Two pages with similar content and links will not rank equally if one loads in 1.8 seconds and the other struggles at 6 seconds on a mid-range Android phone.
• Speed decides whether people stay. Bounce rate climbs sharply as load time grows. Google’s own research has put the jump in bounce probability at roughly 32% as a page goes from 1 second to 3 seconds, and higher again beyond that. For a Malaysian site serving mostly mobile users on 4G, this is the difference between a lead and a lost visitor.
• It protects conversions and ad spend. If you pay for Google Ads or Meta traffic, a slow landing page burns budget twice: worse Quality Score and fewer people who wait around to convert. Faster pages lift conversion rates directly.

Performance is broader than raw speed, so a good audit also touches mobile responsiveness, accessibility, and technical SEO health. These overlap more than people expect, and we cover the connections below.

The metrics that matter, with target thresholds

You cannot fix what you do not measure, and you cannot measure well without knowing the target. The heart of any audit is Google’s Core Web Vitals, backed by a few supporting metrics. Google grades a page at the 75th percentile of real visits, meaning 75% of visits need a “good” experience for the page to pass. Aim for the good column, not the “needs work” middle.

Page weight and request thresholds are practical working targets, not official Google limits. Treat them as guardrails, not pass/fail lines.

The audit toolkit

You do not need paid software to run a solid audit. This mix of free tools covers field data, lab diagnosis, and real-device testing.

For Malaysian sites, always test from an Asian server location. A page that loads in 1.5 seconds from a US test node can take 3 seconds or more for a user in Kuala Lumpur if the server sits far away or the CDN has no regional edge. WebPageTest’s Singapore location and GTmetrix’s Hong Kong server give you a realistic picture.

The step-by-step audit process

Run the audit in this order. The point is to measure before you touch anything, so you can prove the fixes worked afterwards.

1. Set the scope and pick your test pages

You do not audit every URL. Pick your most important templates: the homepage, your top landing or service page, one blog post, and one conversion page (checkout, contact, booking). These represent the code patterns that repeat across the whole site. Note the goal for each page too, since a checkout has different priorities than a blog post.

2. Capture the baseline

For each test page, record the field data from PageSpeed Insights (LCP, INP, CLS) and the lab numbers (TTFB, FCP, TBT, page weight, requests). Do it on both the Mobile and Desktop tabs. Save the numbers in a simple sheet. This baseline is what you measure every future fix against, so screenshot or export it.

3. Pull the site-wide view from Search Console

PageSpeed Insights shows one URL at a time. The Search Console Core Web Vitals report groups your whole site into Good, Needs Improvement, and Poor buckets, so you can see whether a problem is one page or a template used on 400 pages. Fixing a shared template is where the leverage is.

4. Read the waterfall to find bottlenecks

Open GTmetrix or WebPageTest and study the waterfall chart. It shows every file in load order. Look for the long first bar (that is TTFB, a server or hosting signal), large image files, scripts that block rendering, and anything from a third-party domain that arrives late. This is where you move from “the score is bad” to “this specific thing is the cause”.

5. Diagnose each bottleneck

Match each symptom to a cause using the problem table in the next section. Slow LCP with a heavy hero image points one way; slow LCP with a fast image but a long TTFB points to hosting. High INP almost always means too much JavaScript. High CLS means elements loading without reserved space.

6. Prioritise by impact versus effort

Do not fix in the order the tool lists them. Score each issue on how much it hurts the metric and how hard it is to fix, then start with the high-impact, low-effort items. The framework for this is in the prioritisation section below.

7. Fix, then re-measure

Apply one fix (or one batch), then re-run the same tests from the same locations. Lab data updates immediately; field data in Search Console and PageSpeed Insights lags because it reflects a rolling 28-day window of real users, so give it three to four weeks before you judge the field result.

Common performance problems and their fixes

This is the part the shallow guides skip. Below is each common bottleneck, how to spot it in your audit, and the concrete fix.

1. Oversized and unoptimised images

Images are the single most common cause of a slow LCP and heavy page weight. The symptom: a large image file at the top of the waterfall, or PageSpeed flagging “Properly size images” and “Serve images in next-gen formats”.

• Convert to WebP or AVIF. These are 25% to 50% smaller than JPEG or PNG at the same quality.
• Resize to the largest size actually displayed. Do not ship a 4000px photo into a 800px slot.
• Add loading="lazy" to below-the-fold images so they do not compete with the hero.
• Set explicit width and height attributes so the browser reserves space (this fixes CLS too).
• Preload the LCP image so the browser fetches it early.

2. Render-blocking JavaScript and CSS

The symptom: a slow FCP and a waterfall where CSS or JS files load before anything paints. The browser stops rendering until these finish.

• Minify and combine CSS and JS to cut file size and requests.
• Defer non-critical JavaScript with defer or async so it loads after the page paints.
• Inline the critical CSS needed for above-the-fold content and load the rest afterwards.
• Remove unused CSS and JS. Many WordPress sites load scripts on every page that are only needed on one.

3. No or weak caching

Caching stores files so repeat visitors and the server do not rebuild everything each time. The symptom: PageSpeed flags “Serve static assets with an efficient cache policy,” or repeat visits are as slow as the first.

• Set browser cache headers so returning visitors reuse local copies of images, CSS, and fonts.
• Enable page caching. On WordPress, WP Rocket, LiteSpeed Cache, or W3 Total Cache handle this well.
• Add object caching (Redis or Memcached) for database-heavy sites.

4. Slow hosting and high TTFB (a Malaysia priority)

The symptom: a long first bar in the waterfall before any file even starts downloading, and a TTFB above 800ms. This is a server problem, and it is common for Malaysian sites hosted on cheap shared plans or on servers physically far from local users.

• Host on a server near your audience. If your customers are in Malaysia, a Singapore or Kuala Lumpur data centre beats a US or European one on latency every time.
• Move off overcrowded shared hosting to a decent VPS or managed plan if TTFB stays high under load.
• Put a CDN in front of the site so static files serve from an edge location near the visitor. Confirm the CDN has Asian points of presence, not just US and EU.
• Upgrade PHP to the current version. On WordPress this alone can cut server response time noticeably.

5. Web fonts blocking text

The symptom: text that appears late or flashes as fonts swap in, and font files loading from a third-party domain. Custom fonts often delay text paint.

• Add font-display: swap so text shows in a fallback font immediately, then swaps.
• Self-host fonts instead of pulling from Google Fonts to remove a third-party connection.
• Preload the one or two fonts used above the fold, and subset them to the characters you need.

6. Heavy third-party scripts

The symptom: chat widgets, analytics, ad tags, and social embeds arriving late in the waterfall and inflating INP. You control your own code but not theirs, so they are often the worst offenders.

• Audit every third-party script and remove any you no longer use.
• Load non-critical tags (chat, heatmaps) after the page is interactive, or on user interaction.
• Use a tag manager to control loading order rather than hard-coding tags in the head.

7. Database bloat and too many plugins (WordPress)

The symptom: high TTFB that caching does not fully solve, and a growing database. Most Malaysian SME sites run on WordPress, so this matters.

• Deactivate and delete plugins you do not use. Each active plugin can add scripts, styles, and queries.
• Clean the database: remove post revisions, spam comments, transients, and orphaned data.
• Avoid stacking plugins that do the same job (two caching plugins, three SEO plugins).
• If plugin sprawl is the root cause, a proper website maintenance routine keeps it from creeping back.

Mobile, accessibility, and SEO overlaps

Performance does not live in a silo. The same audit should catch these related issues, because Google and your users experience them together.

Mobile and responsive checks

Malaysian web traffic skews heavily mobile, so the mobile numbers are the ones that count. Google also uses mobile-first indexing, meaning it ranks based on your mobile site, not desktop. During the audit:

• Run every test on the Mobile tab first, on a throttled 4G connection to mimic real conditions.
• Check that tap targets are large enough and spaced apart, and that text is readable without zooming.
• Confirm nothing is cut off or requires horizontal scrolling. Our notes on responsive web design and mobile-first design go deeper here.

Accessibility

Lighthouse gives an accessibility score in the same run as performance, so there is no reason to skip it. Check colour contrast, alt text on images, form labels, and keyboard navigation. Accessible sites are usually faster and cleaner, and they widen your audience. Many accessibility fixes (alt text, semantic headings) double as user experience and SEO wins.

Technical SEO

A performance audit naturally surfaces technical SEO problems: broken links, missing meta tags, no HTTPS, poor crawlability, and missing structured data. These affect rankings independently of speed. Pair this audit with our technical SEO guide and the complete SEO checklist, and design with SEO-friendly principles from the start so you audit less often.

How to prioritise what you found

An audit that produces 40 issues and no order of attack is useless. Score each finding on two axes: impact on the metric and effort to fix. Then work the quadrants.

A useful rule: fix anything that moves a Core Web Vital from Poor to Good before you touch anything that only improves an already-passing metric. Passing the threshold is what changes the ranking signal.

How often should you audit?

• Quarterly for a full audit on a stable site.
• Monthly glance at the Search Console Core Web Vitals report to catch regressions early.
• After every major change: a redesign, a new plugin, a marketing campaign that adds tracking scripts, or a big content push. New code is where performance quietly breaks.

The website performance audit checklist

Copy this into your own doc and work top to bottom. It mirrors the process above.

Baseline and scope

• Chosen 4 to 5 representative pages (home, service, blog, conversion)
• Recorded field data (LCP, INP, CLS) for each, mobile and desktop
• Recorded lab data (TTFB, FCP, TBT, page weight, requests)
• Pulled the site-wide Core Web Vitals report from Search Console

Speed and Core Web Vitals

• LCP under 2.5s on mobile
• INP under 200ms
• CLS under 0.1
• TTFB under 800ms
• Images in WebP/AVIF, sized correctly, lazy-loaded below the fold
• CSS and JS minified, non-critical JS deferred
• Page and browser caching enabled
• CDN active with Asian edge locations
• Fonts using font-display: swap, preloaded and subset
• Third-party scripts audited, unused ones removed

Mobile, accessibility, SEO

• Tested on throttled mobile 4G from an Asian server location
• Tap targets, readable text, no horizontal scroll
• Lighthouse accessibility score reviewed, alt text and contrast checked
• HTTPS enforced, no broken links, meta tags present
• Structured data valid

Prioritise and re-measure

• Issues scored by impact vs effort
• High-impact, low-effort items fixed first
• Re-tested lab data after each fix
• Diarised a 3 to 4 week field-data check in Search Console

Turn the checklist into results

Finding the problems is half the job. Fixing render-blocking code, migrating hosting, and rebuilding slow templates is where a specialist team pays for itself. We handle web design and development, SEO, and conversion rate optimisation for Malaysian businesses, and we start with a free one-time performance and health check worth RM300.

Request a Quote

Frequently asked questions

What is a website performance audit?

It is a structured review of how fast, stable, and responsive your website is for real visitors, combining lab tests, real-user field data, and manual checks, ending in a prioritised list of fixes. It covers speed, Core Web Vitals, mobile, accessibility, and technical SEO.

How long does a performance audit take?

A focused audit of your key page templates takes a few hours to a day. A full site audit with a written fix plan usually takes one to three days depending on site size. The fixing takes longer than the auditing.

What are good Core Web Vitals scores?

LCP at or under 2.5 seconds, INP at or under 200 milliseconds, and CLS at or under 0.1, measured at the 75th percentile of real mobile visits. Hitting all three moves you into Google’s “good” band.

Which tool should I start with?

Google PageSpeed Insights. It is free, shows both real-user field data and lab data in one place, and lists specific diagnostics per metric. Add Search Console for the site-wide view and WebPageTest for detailed real-device testing.

What is TTFB and why does it matter for Malaysian sites?

Time to First Byte is how long the server takes to send the first byte of a response. High TTFB usually means slow hosting or a server far from your users. For a Malaysian audience, hosting in Singapore or Malaysia and using a CDN with Asian edge locations keeps TTFB low.

Does site speed actually affect Google rankings?

Yes. Core Web Vitals are part of Google’s page experience signals. Speed rarely outranks great content on its own, but between two similar pages the faster one wins, and slow pages lose visitors before they ever convert.

Why is my PageSpeed score different every time I test?

The lab score comes from a single simulated run and varies with network and server load. That is why you should judge real performance on field data, which averages 28 days of actual Chrome users, and use the lab run only for diagnosis.

How often should I run a performance audit?

A full audit quarterly, a quick Search Console check monthly, and an extra audit after any major change: a redesign, new plugins, or a campaign that adds tracking scripts.

Can I improve performance without rebuilding my site?

Often, yes. Image compression, caching, deferring scripts, cleaning up plugins, and better hosting fix most sites without a rebuild. A rebuild is only warranted when a bloated theme or template is the root cause and no amount of tuning gets you into the good band.

Is a performance audit the same as an SEO audit?

No, but they overlap. A performance audit focuses on speed and Core Web Vitals, while an SEO audit covers content, keywords, links, and indexing. Both check technical health, so it is efficient to run them together.