Most Milwaukee small business websites are slow, and it’s not because of hosting, Google, or “the internet.”
They’re slow because of how they were built.
In almost every performance audit I run, performance issues can be traced back to decisions made early on: who built the site, what tools they used, and whether speed was ever considered at all.
The result is a website that technically works, but loads far slower than it needs to, costing leads, rankings, and credibility.
Here’s why this happens so often.
DIY Websites Built by Business Owners
Many business owners build their own websites at first. That’s understandable. Tools promise fast results, no coding, and total control. Domain registrars like GoDaddy even build a generic site for you!
The problem is that these platforms are designed to help you publish, not to help you build a fast, efficient website.
Most DIY sites share the same issues:
- Heavy themes loaded with features you’ll never use
- Oversized images uploaded directly from phones
- Fonts, scripts, and animations added without understanding their impact
- No concept of technical debt
Performance usually isn’t even on the radar. Most business owners don’t realize speed is a problem until the site stops generating leads or until Google quietly stops rewarding it.
Instead of using Page Speed Insights, I recommend using DebugBear for testing your page speed. Page Speed Insights simulates a slow network, which can produce inaccurate metrics, while DebugBear measures performance on a real throttled connection.
Agencies Using Bloated Page Builders as a Foundation
This is where things really go sideways.
Many agencies don’t actually build websites. They assemble them using page builders and pre-packaged themes, often handing the work to junior designers whose job is to make the site “look good.”
Under the hood, these sites are anything but efficient.
Inexperienced web designers who use themes that come pre-configured with page builders like WPBakery, Elementor, or BeTheme are notorious for loading massive CSS and JavaScript files globally, even when most of their features aren’t being used.
That means:
- Every page loads unnecessary code
- Performance problems are baked into the foundation
- Optimization becomes damage control instead of proper engineering
These page builders aren’t bad necessarily, but they are targeted at inexperienced web designers who don’t have the first clue about semantic HTML structure and even basic CSS.
Styling at the ID level
But before I go further, we have to talk about website styling. Styling a website is essentially what gives a site it’s colors, it’s spacing, the way the buttons and links look, it’s overall feel and design.
These types of page builders rely on workflows that end up with “web designers” styling elements at the ID level, which is the absolute worst practice in web design.
Why is this typical agency practice bad?
Using unique, page-specific IDs instead of reusable classes makes every section a one-off, which quickly leads to bloated code, inconsistent design, and slower load times as the site grows.
It also makes future changes harder and more expensive because nothing is built to be reused or maintained cleanly.
Imagine asking your agency web developer (that you went with instead of me), to go in and change the color of the buttons on your website.
Because the “web designer” you hired styled all of your 40 buttons at the ID level, they have to go and find all 40 instances of buttons across your entire site and manually change the color on each one.
The agency could end up billing you for eight of hours of painstaking work for something that would take me five seconds.
If you have a contracted web designer currently, ask them if they understand the difference between class-level styling and ID-level styling. If their answer is “I don’t know,” then you have a problem.
What I do differently
In my workflow, I scope your website colors to variables. For this example, I would need to update my variable var(--primary) to your new branding color. Not only will your buttons reflect the new color, but any element that uses your brand’s primary color will also be updated in seconds.
By using simple, reusable CSS styles and components, my sites are faster, cleaner, and easier to manage long-term.
If another developer comes along in the future and needs to decode what I did, they’ll also have a much better time with my build than dealing what many big agencies do.
Plugin Bloat
Plugins are another major contributor to slow sites.
A plugin might get installed to solve a small problem: a form, a button, a layout tweak. But most plugins don’t do just one thing.
They ship entire feature sets, and WordPress loads that baggage whether you need it or not.
A good example is block libraries like Stackable. I regularly see sites where this type of plugin is installed just to use a single button style, yet it loads styles for dozens of other elements across the entire site.
That’s wildly inefficient.
If you’re using a Gutenberg block plugin, you may be able to disable blocks or patterns that you are not using, ridding your site of additional CSS bloat.
Sometimes a client does need specific functionality from a larger plugin. In those cases, the solution isn’t always removal.
Using tools like Perfmatters, I can manually inspect which scripts and styles are actually required, then prevent everything else from loading. That means:
- Unused CSS is disabled
- Unnecessary JavaScript is blocked
- Only the exact elements needed remain active
The result is a faster site without breaking functionality.
To round out the topic of design in general, most local business websites don’t need flashy animations, heavy effects, or complex interactions.
They need to look professional, load fast, and convert visitors into leads. That’s it. When I do use flashy animations and effects, they’re done properly.
I am of the belief that you should only use plugins that you absolutely need.
Old Databases, Legacy Code, and Visual-Only Redesigns
Another common issue is building on top of old sites.
Many “redesigns” only change what you see on the surface. Underneath, years of legacy data remain:
- Orphaned database tables
- Deprecated features
- Old scripts and settings from previous themes or plugins
You can’t fix structural problems by stacking new design on top of old code.
This is especially common with long-established businesses that have gone through multiple agencies over the years. In those cases, a clean rebuild is often the smarter move:
- Fresh database
- Clean permalink structure
- No legacy baggage slowing things down
If a site is relatively new, building on top of it can make sense. If it’s been around for years, starting clean is usually faster, and cheaper long-term.
For these types of builds, I will take a backup of your current site, export all posts and content, take note of the site architecture, and essentially rebuild the skeleton of the site in a fresh environment before starting the build.
Tools like Perfmatters and WP Rocket can automatically clean your WordPress database for you. You can schedule deletion of post revisions, auto-drafts, trashed posts, and spam comments on a daily, weekly, or monthly basis.
Hosting Is Usually the Least of the Problem
Hosting gets blamed more than anything else, and most of the time, it’s not the issue.
For the majority of local business websites:
- Shared hosting is perfectly fine
- You don’t need a VPS or dedicated server unless you’re pulling massive traffic
No hosting plan can fix:
- Bloated CSS
- Excessive JavaScript
- Poor site architecture
Better hosting might shave off a few milliseconds off your time to first byte metric, but it won’t save a poorly built website. Performance has to be addressed at the code level first.
What Actually Makes a Website Fast
Fast websites aren’t a mystery. They’re the result of intentional decisions from the start. I always opt for a lightweight foundation using industry-leading tools like BricksBuilder and EtchWP.
I don’t use “all-in-one” plugins to solve my problems. In the case where we need scripts, I make sure they only run in places they need to run. Keeping the database clean is important, as well.
In practice, that means:
- Writing custom CSS instead of relying on bloated frameworks
- Avoiding unnecessary block libraries and page builders
- Cleaning and optimizing sites monthly
- Replacing abandoned plugins with clean, coded solutions when needed
Speed Is a Choice
Slow websites aren’t inevitable. They’re the result of shortcuts, innexperience, convenient tools, and decisions made without considering long-term performance.
Fast websites don’t happen by accident. They’re designed that way from the start.
If your site feels slow, it probably isn’t your fault.
But it is fixable.
