Back to Blog

By Brian Hunter · Founder, Hunter Creative Media & Design

Your website is slow. We don’t say that to be rude. We say it because statistically, it’s almost certainly true. When we audit small business websites, the majority score below 50 out of 100 on Google’s PageSpeed Insights. Many score below 30.

The frustrating part? Most of these performance problems are caused by the same five issues, over and over again. They’re hiding in plain sight, silently costing you search rankings, visitor engagement, and actual revenue. We go deeper on all of this in a full breakdown of Core Web Vitals for site owners.

Here are the five biggest performance killers we find on small business websites, how to diagnose them, and how to fix them.

1. Unoptimized Images

This is the number one offender. It’s not close.

What it is:

Images uploaded directly from a camera or phone at their original resolution and file size. We regularly see 3,000 x 4,000 pixel images being used in a section that only displays at 600 pixels wide. We see 4MB hero images on homepages. We see PNG files used for photographs (PNGs are meant for graphics with flat colors, not photos).

One site we audited had a single page with 12 images totaling over 25MB. On a mobile connection, that page took 18 seconds to load. The owner had no idea.

How to diagnose it:

  • Run your site through PageSpeed Insights. Look for the “Properly size images” and “Serve images in next-gen formats” recommendations.
  • Open Chrome DevTools (F12), go to the Network tab, filter by “Img,” and reload the page. Check the file sizes. Any image over 200KB for standard content images or over 500KB for full-width hero images needs attention.
  • Look at the dimensions. If the image file is 3000px wide but it’s displayed at 400px, you’re wasting bandwidth.

How to fix it:

  • Resize images to their display dimensions. If an image is shown at 800px wide, there’s no reason for the file to be 3000px wide. Serve a 2x version at most (1600px) for high-DPI screens.
  • Convert to WebP format. WebP typically delivers 25-35% smaller file sizes than JPEG at equivalent quality. Every modern browser supports it.
  • Compress aggressively. Most images can be compressed to 70-80% quality with no visible difference to the human eye. Tools like ShortPixel, TinyPNG, or Squoosh make this trivial.
  • Implement lazy loading. Add loading="lazy" to images below the fold. This tells the browser to only load them when the user scrolls near them, not on initial page load.
  • Use responsive images. The HTML srcset attribute lets you serve different image sizes to different screen sizes. A phone doesn’t need the same image file as a desktop monitor.

Before and after:

We worked with a local law firm whose homepage hero image was a 5.2MB JPEG at 5000px wide. After converting to WebP, resizing to 1600px, and compressing to 80% quality, the file was 148KB. Same visual quality. Page load time dropped from 6.3 seconds to 2.1 seconds. That single image change accounted for most of the improvement.

2. Render-Blocking CSS and JavaScript

What it is:

When your browser loads a page, it reads the HTML from top to bottom. When it encounters a CSS file or JavaScript file in the <head> section, it stops everything and downloads and processes that file before continuing to render the page. If you have multiple CSS and JS files loaded this way, the browser is essentially frozen, staring at each file one by one, while your visitor stares at a blank screen.

This is called “render blocking”: these resources are literally blocking the page from rendering.

How to diagnose it:

  • PageSpeed Insights will flag “Eliminate render-blocking resources” and list the specific files causing the problem.
  • In Chrome DevTools, the Performance tab shows a waterfall chart of how resources load. Look for CSS and JS files that start loading early and delay the first paint.
  • Check your page source. If there are more than 2-3 CSS files and 3-4 JavaScript files loaded in the <head> with no defer or async attributes, you have render-blocking resources.

How to fix it:

  • Defer non-critical JavaScript. Add the defer attribute to script tags that don’t need to execute immediately. This tells the browser to download them in the background and execute after the HTML is parsed.
  • Async load third-party scripts. Analytics, chat widgets, and social media embeds should almost always use the async attribute.
  • Inline critical CSS. Extract the CSS needed to render the above-the-fold content and embed it directly in the HTML. Load the rest asynchronously.
  • Combine and minify CSS files. If your site loads five separate CSS files, combine them into one and minify it (remove whitespace, comments, and unnecessary code). This reduces both the number of HTTP requests and the total file size.
  • Move scripts to the bottom of the body. If you can’t use defer, at least move script tags to just before </body> so they don’t block initial rendering.

Before and after:

A local dentist’s website loaded 8 CSS files and 11 JavaScript files in the head, none deferred. First Contentful Paint was 4.7 seconds, nearly 5 seconds of white screen. After deferring non-critical JS, combining CSS files, and inlining critical styles, First Contentful Paint dropped to 1.3 seconds. The page visually appeared almost instantly.

The fastest sites ship less to the browser, not more.
The fastest sites ship less to the browser, not more.

3. Too Many Plugins and Third-Party Scripts

What it is:

This is especially rampant on WordPress sites, but it applies to any platform. Every plugin you install and every third-party script you embed adds weight to your page. Each one comes with its own CSS files, JavaScript files, and often external HTTP requests.

We’ve audited WordPress sites running 30-40+ active plugins. Some of those plugins load their assets on every single page, even if they’re only used on one page. A contact form plugin loading its CSS and JS on your About page. A gallery plugin loading its scripts on your blog posts. An SEO plugin, a caching plugin, a security plugin, a slider plugin, two analytics tools, three social media widgets, a chat tool, a cookie consent banner, all loading simultaneously.

How to diagnose it:

  • Install the Query Monitor plugin (WordPress) to see exactly which plugins load which assets on each page.
  • Check Chrome DevTools Network tab. Filter by JS and CSS. Count the number of external requests. If you’re over 30 total HTTP requests on a simple page, you have a problem.
  • Look at the waterfall chart. Third-party scripts (identified by different domains) often add significant latency because your browser has to establish new connections to each external server.
  • Use WebPageTest.org for a detailed breakdown of every resource loaded.

How to fix it:

  • Audit every plugin and script. Make a list of every active plugin and every third-party script on your site. For each one, ask: “Is this providing measurable value?” If the answer is no or you’re not sure, deactivate it and test.
  • Eliminate redundancy. We frequently find sites running two analytics tools, or a caching plugin alongside a performance plugin that also does caching, or multiple SEO-related plugins doing overlapping things.
  • Replace heavy plugins with lightweight alternatives. That animated slider plugin loading 300KB of JavaScript? Replace it with a static hero image or a CSS-only solution. That social sharing plugin with 15 buttons? Use lightweight share links that don’t require any JavaScript.
  • Conditionally load assets. Use a plugin like Asset CleanUp or Perfmatters (WordPress) to prevent plugins from loading their assets on pages where they’re not needed.
  • Self-host critical third-party scripts. If you must use Google Fonts, download them and host them locally instead of loading them from Google’s servers. Same for Font Awesome icons: only include the icons you actually use.

Before and after:

A real estate agent’s WordPress site had 38 active plugins. After a thorough audit, we deactivated 16 that were either unused, redundant, or replaceable with lighter alternatives. Total page weight dropped from 4.8MB to 1.6MB. HTTP requests dropped from 87 to 34. Load time went from 7.2 seconds to 2.8 seconds, and the site looked and functioned identically.

4. No Caching Strategy

What it is:

Without caching, every single time someone visits your site, their browser downloads every file from scratch: HTML, CSS, JavaScript, images, fonts, all of it. Even if they visited five minutes ago and nothing has changed.

There are two types of caching that matter:

  • Browser caching tells the visitor’s browser to store certain files locally so they don’t need to be re-downloaded on subsequent visits or page navigations.
  • Server-side caching stores pre-built versions of your pages on the server so it doesn’t have to dynamically generate them for every request. This is especially important for WordPress and other CMS-driven sites where pages are built from database queries on every load.

How to diagnose it:

  • PageSpeed Insights flags “Serve static assets with an efficient cache policy” if your browser caching headers are missing or too short.
  • Visit your site, then reload the page. Open the Network tab in DevTools. If the “Size” column shows files being fully downloaded again (not served “from cache” or “from disk cache”), browser caching isn’t working.
  • For server-side caching on WordPress: if your Time to First Byte (TTFB) is over 600ms, you likely don’t have effective server-side caching.

How to fix it:

  • Set browser cache headers. Configure your server to send appropriate Cache-Control headers for static assets. CSS, JavaScript, images, and fonts should typically be cached for at least 30 days (ideally a year, using cache-busting filenames when assets change).
  • Implement server-side caching. For WordPress, use a quality caching plugin like WP Rocket, W3 Total Cache, or WP Super Cache. These generate static HTML files so your server isn’t running PHP and database queries for every visitor.
  • Use a CDN with caching. A content delivery network like Cloudflare not only serves files from servers closer to your visitors but also caches them at the edge, dramatically reducing load on your origin server.
  • Enable GZIP or Brotli compression. This compresses files during transfer, reducing the amount of data sent over the network. Most modern hosting providers support Brotli, which offers 15-20% better compression than GZIP.

Before and after:

A local restaurant’s WordPress site had no caching of any kind. TTFB was 1.8 seconds, before any content even started loading. After implementing WP Rocket for server-side caching, setting proper browser cache headers, and enabling Cloudflare’s CDN, TTFB dropped to 180ms. Repeat visitors experienced near-instant page loads because most assets were served from their local browser cache.

5. Bloated Page Builders

What it is:

Visual page builders like Elementor, Divi, WPBakery, and Beaver Builder are popular because they let non-developers create complex layouts with drag-and-drop interfaces. The tradeoff is that they generate an enormous amount of extra HTML, CSS, and JavaScript to make that visual editing work.

A simple section with a heading, paragraph, and button that should be about 20 lines of clean HTML becomes 150+ lines of nested divs with inline styles and data attributes when built with a page builder. Multiply that by every section on every page, and you get websites with HTML documents that are 5-10x larger than they need to be.

Beyond the bloated HTML, page builders typically load their entire framework, including CSS and JS for widgets and features you’re not even using on that page.

How to diagnose it:

  • View your page source (Ctrl+U in Chrome). If it’s thousands of lines of nested <div> elements with classes like elementor-widget-wrap or et_pb_section, you’re seeing page builder bloat.
  • Check the total page size in DevTools Network tab. If a simple 5-section homepage exceeds 3MB, the page builder is likely a major contributor.
  • Look at the CSS files. Page builders often load 300-500KB+ of CSS, most of which styles widgets that aren’t on the current page.
  • Run Lighthouse and check the “Reduce unused CSS” and “Reduce unused JavaScript” recommendations. Page builders typically show significant unused code.

How to fix it:

  • If staying with the page builder: Disable unused widgets and features in the builder’s settings. Elementor, for example, lets you disable widgets you don’t use, which reduces the CSS and JS payload. Enable the builder’s built-in performance optimizations if available.
  • Use the builder’s performance features. Newer versions of popular builders have added options for CSS print method (external file vs. inline), reduced DOM output, and lazy loading of assets. Enable all of them.
  • Consider a lighter alternative. If performance is critical (and it should be), consider Bricks Builder, Breakdance, or even switching to a block-based theme that uses WordPress’s native Gutenberg editor. The performance difference can be dramatic.
  • For maximum performance, go custom. A hand-coded theme or a headless approach will always outperform a page builder. For businesses where every second of load time translates to revenue, this is the right investment.

Before and after:

A local service company’s homepage built with a popular page builder loaded 487KB of CSS (72% unused on that page) and 623KB of JavaScript (68% unused). Total page weight was 5.4MB. We rebuilt the same design as a custom theme with clean, semantic HTML and only the CSS and JS needed for each page. Total page weight dropped to 890KB. PageSpeed score went from 28 to 94.

The Compound Effect of Fixing All Five

Each of these issues is significant on its own. But they don’t exist in isolation. They stack. A site with unoptimized images AND render-blocking scripts AND too many plugins AND no caching AND page builder bloat isn’t just slow. It’s unusable on anything other than a fast desktop connection.

The good news: fixing these issues compounds too. Each fix amplifies the others. When you optimize images, reduce scripts, implement caching, and clean up your code, the cumulative effect is often dramatic: sites that scored in the 20s routinely jump to the 80s and 90s.

And the payoff isn’t just a prettier number on a speed test. It’s:

  • Higher Google rankings (Core Web Vitals are a ranking factor)
  • Lower bounce rates (visitors stay instead of leaving)
  • Higher conversion rates (faster sites convert more visitors into customers)
  • Better user experience (which builds trust and repeat visits)

Keep Reading

We hunt these killers down on every project we take on. See what a clean bill of health looks like in our Dr. Samiya Hashmi case study.

About the Author

Brian Hunter is the founder of Hunter Creative Media & Design, an Aurora, IL studio building hand-coded websites and custom web applications for small businesses across Chicago’s western suburbs. He writes about web performance, local SEO, and the software that runs small businesses. Get in touch.