Why Your Website Is Slow: A Performance Audit Checklist
A practical checklist for diagnosing and fixing website performance issues, covering Core Web Vitals, image optimization, render-blocking resources, caching, CDN configuration, and server response time.
Eyecay Team
Hosting & Infrastructure, Cayman Islands
Listening...
0:00 / 0:00
A practical checklist for diagnosing and fixing website performance issues, covering Core Web Vitals, image optimization, render-blocking resources, caching, CDN configuration, and server response time.
A slow website is not just an inconvenience — it is a measurable business problem. Visitors leave, search rankings drop, and conversions suffer. Yet many businesses accept poor performance as normal because they do not know where to look or what to fix.
This guide is a structured audit checklist. Work through each section, test your site against the benchmarks, and address the issues you find. Most performance problems fall into a handful of categories, and most can be fixed without rebuilding your site from scratch.
Start With Measurement: Core Web Vitals
Before you fix anything, establish a baseline. Google's Core Web Vitals are the standard metrics for measuring real-world page performance. They consist of three measurements:
- Largest Contentful Paint (LCP): How long it takes for the largest visible content element — typically a hero image or heading — to fully render. Target: under 2.5 seconds.
- Interaction to Next Paint (INP): How quickly the page responds when a user interacts with it — clicking a button, tapping a link, or typing in a field. INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. Target: under 200 milliseconds.
- Cumulative Layout Shift (CLS): How much the visible content shifts unexpectedly during loading. When text jumps because an image loaded above it, or a button moves because a banner appeared, that is layout shift. Target: under 0.1.
Use PageSpeed Insights to test your pages. It provides both lab data (simulated conditions) and field data (real user measurements from the Chrome User Experience Report). Field data is what Google uses for ranking purposes. Also check your Core Web Vitals report in Google Search Console to see which pages pass and which need improvement.
Image Optimisation: The Biggest Quick Win
Images are typically the largest assets on a page and the most common cause of poor LCP scores. Many websites serve images that are far larger than necessary — both in pixel dimensions and file size. A single unoptimised photograph can be 5 to 10 megabytes. Multiply that across a page with several images, and you are asking visitors to download tens of megabytes before the page is usable.
Serve Modern Formats
WebP and AVIF are modern image formats that provide significantly better compression than JPEG and PNG. WebP is supported by all modern browsers. AVIF offers even better compression but has slightly less browser support. Serve WebP as your default format with JPEG as a fallback for older browsers. Most image CDNs (Cloudflare, Cloudinary, Imgix) can handle format negotiation automatically.
Resize to Actual Display Dimensions
Serving a 3000-pixel-wide image in a container that is 800 pixels wide wastes bandwidth and slows rendering. Resize images to match their display dimensions, and use responsive images with the srcset attribute to serve different sizes for different viewport widths. For most content images, generating sizes at 400, 800, and 1200 pixels wide covers the range of common devices.
Lazy Load Below-the-Fold Images
Images that are not visible in the initial viewport should use lazy loading — they load only when the user scrolls near them. Add loading="lazy" to image elements below the fold. Do not lazy load the hero image or any image that is the LCP element — these should load eagerly with fetchpriority="high" to render as quickly as possible.
Specify Dimensions
Every image element should have explicit width and height attributes (or equivalent CSS aspect-ratio). Without dimensions, the browser cannot reserve space for the image before it loads, causing layout shifts that hurt your CLS score.
Render-Blocking Resources
Render-blocking resources are CSS and JavaScript files that must be downloaded and processed before the browser can render the page. Every render-blocking resource delays the first paint.
Critical CSS
Inline the CSS required to render the above-the-fold content directly in the <head> of your HTML. Load the remaining CSS asynchronously. Tools like Critical (by Addy Osmani) can extract critical CSS automatically. For sites built with frameworks like Astro, critical CSS is often handled as part of the build process.
JavaScript Loading Strategy
Most JavaScript should load with the defer attribute, which downloads the script in parallel with HTML parsing but executes it only after parsing is complete. Scripts that are not needed for the initial render should use async or be loaded dynamically. Third-party scripts — analytics, chat widgets, ad platforms — are frequent offenders. Audit every third-party script on your page and remove any that are not providing measurable value.
Font Loading
Web fonts are a common source of render blocking and layout shifts. Preload your primary font files with <link rel="preload"> to prioritise their download. Use font-display: swap in your @font-face declarations so text is visible immediately with a fallback font while the web font loads. Limit the number of font weights and styles you load — each variant is a separate file that adds to load time.
Caching: Avoid Redundant Downloads
Proper caching ensures that returning visitors and subsequent page navigations do not re-download assets that have not changed. Caching operates at multiple levels:
Browser Caching
Set appropriate Cache-Control headers for your assets. Static assets like images, CSS, and JavaScript files with hashed filenames can be cached aggressively — Cache-Control: public, max-age=31536000, immutable (one year). HTML pages should use shorter cache times or no-cache to ensure visitors always get the latest content while their browser validates with the server.
Server-Side Caching
If your site runs on a CMS like WordPress, server-side caching prevents the server from regenerating the same page for every request. Page caching plugins (WP Super Cache, W3 Total Cache, WP Rocket) or server-level caching (Varnish, Nginx FastCGI Cache) can reduce server response time from seconds to milliseconds.
CDN Caching
A CDN caches your assets on edge servers around the world. When properly configured, it also caches your HTML pages, eliminating the need for requests to reach your origin server at all. Cloudflare, AWS CloudFront, and Fastly are popular CDN options. Cloudflare's free tier is sufficient for most small to medium websites.
Server Response Time (TTFB)
Time to First Byte (TTFB) measures how long it takes for the server to begin sending a response after receiving a request. A high TTFB delays everything else — the browser cannot start rendering until it receives the first byte of HTML. Google recommends a TTFB under 800 milliseconds. For optimal performance, aim for under 200 milliseconds.
Common causes of high TTFB include:
- Slow database queries: CMS-based sites often execute dozens of database queries per page load. Identify and optimise slow queries, add database indexes, and consider implementing object caching (Redis, Memcached) to reduce database load.
- Insufficient server resources: Shared hosting plans that pack hundreds of sites onto a single server cannot deliver consistent performance. If your TTFB is consistently above 600 milliseconds, your hosting infrastructure is likely the bottleneck.
- No page caching: Generating a page dynamically for every request is wasteful when the content does not change between requests. Implement page-level caching.
- Geographic distance: If your server is in London and your audience is in the Cayman Islands, every request travels across the Atlantic. Either choose a server location closer to your primary audience or use a CDN that caches your pages at edge locations.
Third-Party Scripts: The Hidden Performance Tax
Third-party scripts — analytics, advertising, social media widgets, live chat, heatmaps, A/B testing tools — are frequently the largest contributors to poor performance, yet they receive the least scrutiny because they are "just a snippet."
Each third-party script adds DNS lookups, TCP connections, and download time. Many also execute synchronously, blocking the main thread and degrading INP scores. Some load their own dependencies, cascading the impact.
Audit every third-party script on your site. For each one, ask: is the business value this provides worth the performance cost? If yes, load it asynchronously or defer it. If no, remove it. For scripts like Google Analytics, consider whether the lighter measurement alternatives or server-side tracking would serve your needs with less client-side impact.
WordPress-Specific Performance Issues
If your site runs on WordPress, several platform-specific issues commonly contribute to slow performance:
- Too many plugins: Each plugin can add its own CSS and JavaScript files to every page load, run additional database queries, and increase server processing time. Audit your plugins and remove any you are not actively using. Replace multiple single-purpose plugins with one well-coded alternative where possible.
- Unoptimised themes: Many WordPress themes are bloated with features you will never use. Every unused feature still loads its assets. Consider switching to a lightweight theme or a purpose-built theme that only includes what you need.
- No object caching: WordPress makes repeated database queries for the same data. Object caching with Redis or Memcached stores query results in memory, dramatically reducing database load and response time.
- Heartbeat API: The WordPress Heartbeat API sends AJAX requests every 15 to 60 seconds from the admin panel and post editor. On shared hosting, this can consume significant resources. Limit its frequency or disable it on pages where it is not needed.
The Performance Audit Checklist
Use this checklist to systematically audit your site. Address issues in order of impact — images and caching typically yield the largest improvements with the least effort.
- Measure: Run PageSpeed Insights on your five most important pages. Record LCP, INP, and CLS for each.
- Images: Serve WebP format. Resize to display dimensions. Lazy load below-the-fold images. Set explicit dimensions on all image elements.
- CSS: Inline critical CSS. Load non-critical CSS asynchronously. Remove unused CSS.
- JavaScript: Defer non-critical scripts. Remove unused JavaScript. Audit third-party scripts.
- Fonts: Preload primary fonts. Use font-display: swap. Limit font variants to what you actually use.
- Caching: Set Cache-Control headers on static assets. Implement server-side page caching. Configure CDN caching.
- Server: Measure TTFB. Optimise database queries. Evaluate hosting infrastructure. Implement object caching if on a CMS.
- CDN: Enable a CDN. Configure it to cache static assets and, where possible, HTML pages.
- Third-party scripts: Audit all external scripts. Remove unnecessary ones. Defer or async the rest.
- Re-measure: Run PageSpeed Insights again after changes. Compare against your baseline. Repeat.
Performance is not a one-time fix. New content, new features, and new third-party integrations can degrade performance over time. Build speed monitoring into your ongoing site maintenance process and run this checklist quarterly at minimum.
Frequently Asked Questions
Core Web Vitals are a set of three specific metrics that Google uses to measure user experience on web pages. Largest Contentful Paint (LCP) measures loading performance — how long it takes for the largest visible element to render. Interaction to Next Paint (INP) measures responsiveness — how quickly the page responds to user interactions like clicks and taps. Cumulative Layout Shift (CLS) measures visual stability — how much the page layout shifts unexpectedly during loading. Google has confirmed that Core Web Vitals are a ranking factor in search results. Pages that meet the recommended thresholds (LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1) may receive a ranking advantage over competing pages that do not.
The relationship between page speed and conversion rates has been documented extensively. Google has published research showing that as page load time increases from 1 to 3 seconds, the probability of a visitor bouncing increases by 32%. From 1 to 5 seconds, it increases by 90%. While exact conversion impact varies by industry and audience, the general pattern is consistent: faster pages retain more visitors and convert at higher rates. For e-commerce sites, even a 100-millisecond improvement in load time has been associated with measurable revenue increases by retailers who have published their findings.
If your website serves visitors from multiple geographic regions, a CDN (Content Delivery Network) will almost certainly improve your performance. A CDN caches your static assets — images, CSS, JavaScript, fonts — on servers distributed around the world, so visitors load those assets from a nearby server rather than your origin server. For businesses in the Cayman Islands serving both local and international audiences, a CDN is particularly valuable since the nearest major data centres are in Miami or other US locations. Cloudflare offers a free CDN tier that provides meaningful performance and security benefits for most websites.
Want a Faster Website?
We build high-performance websites on modern infrastructure that score 95+ on Lighthouse. If your current site is dragging, we can audit it and fix the bottlenecks — or rebuild it properly.
Get a Free Speed Audit