Why your site takes
four seconds to load

Speed is a conversion problem before it is a ranking problem

Page speed is a ranking signal, but a modest one. The reason to care is that every channel you pay for lands on this page. A slow site raises the cost of your ads, weakens your SEO, and wastes the map pack visibility you worked for. It is a tax on everything else.

For reference, the page you are reading transfers about 50KB and paints in roughly a second on a normal connection. That is not an achievement — it is what happens when you do not add the four things below.

1. Images nobody compressed

The most common single cause, by a wide margin. A hero photograph exported straight from a camera or a stock site can be three to six megabytes. Displayed at 1600 pixels wide, it needs to be a small fraction of that.

Three fixes, in order of effect. Resize to the largest size actually displayed — a 6000-pixel image in a 1200-pixel slot is five-sixths waste. Convert to WebP or AVIF, which typically saves 30–50% over JPEG at the same visual quality. Then lazy-load everything below the first screen, so the browser fetches it only when it is needed.

Leave the image at the top of the page eagerly loaded, though. Lazy-loading your hero delays the very thing the visitor is waiting to see.

2. Fonts, in quantity

Each font family and weight is a separate file the browser must fetch before it can paint text properly. Sites commonly load two or three families at four to six weights each — a dozen files, often from a third-party domain that needs its own DNS lookup and connection.

Most designs use three or four weights in practice. Audit what is genuinely on the page, drop the rest, and set font-display: swap so text renders immediately in a fallback rather than leaving a blank space while the file arrives.

3. A page builder doing far more than the page requires

Visual builders are wonderful for people who need to edit their own site, and the trade is real: they ship the machinery for every feature, whether or not your page uses it. A simple page can end up carrying several hundred kilobytes of JavaScript and CSS for sliders, popups, animation libraries and grid systems that are not on the screen.

You do not need to abandon the builder. You do need to turn off the modules you are not using, most of which are individually switchable, and stop stacking plugins that each load their own copy of the same library.

4. Third-party scripts, one at a time, forever

Analytics, a heatmap tool, a chat widget, a review carousel, two remarketing pixels, a booking embed. None is unreasonable. Together they routinely exceed the weight of the actual page, and many of them block rendering while they load.

Audit them annually and ask, honestly, when you last used the data. The heatmap tool installed during a redesign two years ago is usually still loading on every page view for nobody.

How to see which one is yours

Run your page through PageSpeed Insights and read the network waterfall rather than obsessing over the score. The largest bar is almost always the problem, and it is usually an image. Then check the number of requests: a straightforward service page needs perhaps twenty, not ninety.

Test on a phone on mobile data, not on your desktop on office wifi. That is the experience your customers in Irving or Carrollton are actually having.

What good looks like

Under two seconds to first contentful paint on a mid-range phone. Under 500KB total for a content page. Twenty to thirty requests. No layout shift as images and fonts arrive — which means declaring width and height on every image, a one-line fix almost nobody does.

Hitting that on an existing site is usually a day of work, not a rebuild. If it turns out to need a rebuild, that is worth knowing before you spend another month of ad budget landing traffic on it — which is where our web design work usually starts.