Service · Performance
A slow site costs you rankings, customers, and revenue — here's how to fix it
Google measures how fast your site loads and uses it as a ranking signal. Slow sites rank lower, lose visitors before they read a word, and convert fewer of the ones who stay. ArdinGate audits your site, identifies exactly what's slowing it down, fixes it, and hands you a written before-and-after report with documented scores. Fixed price, one-time engagement. Starting at $600.
What a site speed engagement covers
Most sites are slow for the same handful of fixable reasons: images that are too large, fonts that make text invisible during load, styling files that delay the page from appearing, and behind-the-scenes code that runs at the worst possible moment. The fix isn't a rebuild. It's precise, documented work. Audit first, fix in order of impact, verify each change, report everything. Here's what that looks like in practice.
Baseline measurement before anything changes
The first step is measuring exactly where your site stands before any work begins. Every part of Google's page-speed health checks gets recorded: how fast your main photo or headline shows up on screen, how quickly the page responds when a visitor taps or clicks something, and whether the layout stays stable as it loads or jumps around. These scores are captured using Google's own free speed-testing tool, which shows both a controlled lab test and, for busier sites, real numbers from actual visitors who came to your site in the last month. The audit also pinpoints the specific culprits: which photo is taking the longest to show up, which things are delaying the page from appearing, and which elements are causing the page to jump around. You can't fix what you haven't measured, and the audit decides the order fixes get applied in so the biggest wins come first.
Getting the visible page to appear without waiting on extra files
When a visitor's device loads your page, it works through it from top to bottom. Every time it hits a separate file it has to go fetch (the styling that controls how the page looks, a font, a piece of interactive code) it often stops and waits for that file to arrive before showing anything. On a site that pulls in several of these files plus a font request, that wait can add half a second to a full second before your visitor sees anything at all. The fix is to take just the bit of styling needed for the part of the page that's visible before scrolling and build it right into the page, so it can start appearing immediately. Everything else loads quietly in the background without holding up what the visitor sees. This single change is one of the biggest wins available for making your page feel instant.
Fixing fonts so text is never blank during load
Custom fonts arrive separately from the rest of the page, which means the page often shows up first and the font gets dropped in a moment later. In the gap between those two events, the text on your page is invisible. Your headline isn't there. Your service description isn't there. The visitor sees a layout with blank white spaces where your words should be. On a slower phone connection, that blank stretch can last two to three seconds. Two fixes address this: the font is told to start loading earlier so it arrives sooner, and the page is set to show your text in a standard backup font right away, then quietly swap to your custom font once it's ready, instead of hiding the words entirely. The result is that text is visible the instant the page appears.
Images: smaller files, right size for each device, no jumping around
Images cause more slow-load problems than anything else on most sites, and three things need to be right for them not to hurt you. First, file size: photos saved in older formats are bigger than they need to be. A modern image format delivers the same quality at 30-50% smaller file sizes. A main photo that was 400KB becomes around 120KB in a modern format, which is a proportionally faster download on every connection. Second, the right size for the device: a phone doesn't need the same huge image a desktop monitor does. Serving each device a right-sized version means phones download a small file and big monitors get a sharp one. Third, holding the space: if the page doesn't know how tall a photo is before it loads, it leaves no room for it. When the photo finally arrives, everything below it gets shoved down. That shoving, which the visitor sees as the page jumping around, is exactly what one of Google's health checks penalizes, and telling the page each image's size in advance gets rid of it completely.
Interactive features run after the page is visible, not before
The behind-the-scenes code that powers things like contact forms, visitor tracking, chat bubbles, and pop-out menus can delay the page from appearing if it runs at the wrong moment. By default, the device stops, fetches each of these, runs it, and only then carries on loading the rest of the page. On a site that loads visitor tracking, a chat bubble, a form checker, and an embedded map up top, that's four stops before anything shows up. The fix is to set the non-essential features to load after the page is already on screen for the visitor. This doesn't break anything: tracking still works, the chat bubble still loads, but the visitor sees the page right away instead of waiting for all of that to finish first. It also makes the page respond faster to taps and clicks, which is another of Google's health checks.
How fast your site starts responding, assessed where it's a bottleneck
Before any of the above work matters, the company hosting your site has to actually start sending the page out. If that takes more than half a second, the delay piles on top of every other speed problem you have. Common causes: the page is built from scratch on every single visit, or your site is on cheap shared hosting that buckles when traffic picks up. The fix is to have a ready-made copy of the page kept on hand and handed out instantly instead of rebuilt every time, which can cut that start-up delay from nearly a second down to a fraction of one. If the real problem is the hosting itself being too slow to fix this way, that gets flagged clearly in the audit so you know the realistic ceiling before any work begins.
Your main photo starts loading first, before everything else
Google measures how long it takes for the main thing on your page to show up: the headline, the main photo, the first thing a visitor actually sees. For most sites, that's a large image at the top of the page. The problem is that a visitor's device doesn't know to go get that photo until it's read most of the way down the page and finally bumps into it. By then, fonts, styling, and other files have all jumped ahead of it in line. The fix is a note right at the top of the page that tells the device to start fetching your main photo immediately, before it even reaches the spot where the photo normally appears. For sites where the big background image is the main visual, this is the only way to move it earlier in line. This one change commonly shaves a noticeable fraction of a second off how fast your main photo shows up on screen, on sites where that photo is the holdup.
What a slow site communicates before a visitor reads a single word
Speed is framed as a technical problem. It's also a first-impression problem. Understanding how visitors experience a slow site explains why fixing it has such a direct effect on inquiries and sales.
A visitor clicks your link in Google. The browser spinner runs. Two seconds. Three. Four. Nothing useful has appeared yet. Most visitors don't consciously think "this site is slow." They feel something closer to "this doesn't seem right" and hit the back button before they've seen your business name. Google's own research on mobile behavior puts the abandonment rate at 53% for pages that take more than 3 seconds to load. That's not impatience — it's a learned pattern. Slow pages have been associated with untrustworthy or low-quality sources long enough that the back-button reflex is now automatic for a large portion of mobile users.
The page-jumping problem is different but equally damaging. When a page loads and the content jumps around while images and other elements finish arriving, the experience feels broken even if the design is excellent. A visitor who reaches for a button and has it move out from under their finger is frustrated in a way that's immediate and physical. They don't think of it as a technical glitch, just your site feeling unreliable. That impression carries forward into every other judgment they make about your business.
The invisible text experience (where the page structure loads but text is blank for a beat because the font hasn't arrived yet) is subtler but has the same effect. The visitor sees a skeleton page with white spaces where your headline and service description should be. Even visitors who don't consciously notice it register that the site felt incomplete or broken during load. On a slow mobile connection, that blank period can last two to three seconds.
The compounding factor is that all of this feeds back into your Google rankings. Visitors who hit the back button because your page was slow return to the search results and click a competitor. Google tracks that pattern. A page that repeatedly sends visitors back to search results is signaling that it didn't deliver what the visitor needed. Over enough data points, that signal pulls rankings down. The speed problem and the ranking problem are the same problem — one is just the cause and the other is the consequence.
What distinguishes speed optimization from most other web work is that the results are completely measurable. There's no debating whether the new copy is better or whether the redesign improved trust. The scores are numbers. Your main photo showed up in 5.2 seconds before, 1.8 seconds after. Your page went from jumping around badly (a failing grade) to rock-steady (a passing one). Every change is documented with its specific contribution. That kind of before-and-after clarity is rare in web work.
Where site speed fits in the search-to-customer funnel
Speed doesn't just affect whether the page loads. It affects every stage of the process from Google ranking to getting someone to contact you. The ways it breaks things at each stage are different enough to be worth understanding separately.
Rankings. Google uses site speed as a ranking factor, and the effect is most visible in competitive local searches where two businesses are similar in every other way. When the content quality, the business reviews, and the number of other sites linking to you are roughly equal, the faster site ranks higher. For the kinds of searches where most small business customers come from — "dentist near me," "web designer for restaurants," "HVAC repair [city]" — the difference between position 2 and position 5 is the difference between getting most of the clicks and getting almost none of them.
Landing. Once someone clicks your result, the first impression is the load time. Not your headline, not your logo, not your offer — the load time. Visitors who leave because the page is slow never see any of the content you've worked to build. The ones who stay are self-selected for higher patience or more urgent need, but the total pool of potential customers has already shrunk before a single word was read.
Reading and deciding. A page that loads instantly and doesn't jump around creates a smooth reading experience. Your visitor can scan your services, read your about section, and evaluate whether you're the right fit without being pulled out of that evaluation by technical friction. A page that delivers content in jerky pieces — layout first, then fonts, then images that push the text down — creates micro-irritations that accumulate across a session. A visitor who encountered no friction is easier to convert than one who spent twenty seconds getting mildly annoyed before deciding to reach out.
Taking action. Slow scripts don't just affect load time. They also make the page sluggish to respond after it's loaded. When a visitor who's already decided to contact you clicks the inquiry button or starts filling out a form, a page that lags in responding creates immediate doubt. "Did it register? Should I click again?" That moment of uncertainty has a measurable effect on how many people complete the form versus abandoning it. Pages that respond instantly to every tap and click don't create that doubt.
The bottom line: fixing site speed removes friction at every stage of the funnel, and the improvements don't wear off. They're structural changes that keep paying dividends. Full explanation of the three speed signals Google measures →
Why a plugin or a generic speed tool doesn't solve the same problem
There are WordPress plugins that promise to fix your speed scores in one click. Some of them work reasonably well for straightforward problems. Install an image compression plugin, enable a caching plugin, add a script deferral plugin — your scores will improve. That part is real.
The problem is that these tools apply the same fixes to every site regardless of what is causing the failing scores on yours. A plugin that tries to pull out just the styling needed for the top of your page doesn't actually know what's at the top of your specific pages. It guesses based on patterns it's seen across thousands of other sites, and that guess is wrong often enough that a botched job here is one of the most common ways speed plugins visibly break a site: buttons that vanish on load, fonts that switch sizes, images that disappear until the rest of the page finishes loading. Every major plugin in this space has a whole help section on working around this for a reason.
The deeper problem: plugins treat the symptom, not the cause. An Elementor page built with thirty design widgets and five font weights is doing significantly more work on every page load than an image compression plugin and a caching layer can fully offset. You can reduce a 6-second load time to 3.5 seconds with the right plugin stack. Getting below 2.5 seconds — past the threshold where Google's ranking signal kicks in — requires the page itself to be doing less work, not just doing the same work with better wrappers around it.
Custom-coded sites don't have this ceiling. A hand-built page sends exactly what's needed for the page being viewed: the content, the styling for what's visible right away, the one font it actually uses. No page builder piling on extra hidden clutter, no plugin loading its own styling for features the page doesn't even use, no heavy machinery spinning up before a single button appears. When optimization work is done on a hand-built site, the improvements hold cleanly because nothing is working against them. Custom PHP vs. WordPress: what the difference means for speed →
For WordPress and Elementor sites, speed optimization is still absolutely worth doing. The improvements are real and meaningful. But the ceiling is lower, and they need more maintenance as plugins update. For sites where the platform overhead is the primary bottleneck, the long-term answer is a migration to something leaner. How to migrate off WordPress →
Pricing
Site speed optimization is a fixed-price, one-time engagement running $600–$2,000 total. The price is confirmed before any work begins — no surprises mid-project, no retainer, no monthly fee after the engagement closes.
Single-template sites start at $600. A single-template site is one where every page — the homepage, the service pages, the about page, the contact page — shares the same general layout and code structure. The optimization work done for one page type applies across the whole site because they're all built the same way.
Multi-template sites with distinctly different page designs run up to $2,000 depending on how many separate templates exist. A site with a custom-designed homepage, separate interior page layouts, a blog section with its own structure, and purpose-built landing pages has multiple templates that each need their own audit and optimization work. The number of templates — not pages — determines the scope.
Both tiers include the full audit, all optimization work, and the written before-and-after report with documented scores. Full pricing breakdown →
Not sure which tier fits your site? Share the URL when you reach out and I'll assess the template count as part of the initial conversation. Get a quote →
Site speed optimization questions
How much does site speed optimization cost?
Site speed optimization is a fixed-price, one-time engagement running $600–$2,000 total. Single-template sites — where every page on the site shares the same general layout and code structure — start at $600. Multi-template sites with distinctly different page designs (a custom homepage, separate interior pages, a blog section, and unique landing pages) run up to $2,000 depending on how many separate templates need their own work.
The price is confirmed before any optimization begins. The audit happens first, confirms the template count and the specific issues to fix, and locks the price. Both tiers include the full before-and-after report with documented scores. No retainer, no monthly fee after the engagement closes.
Will a faster site help me rank higher on Google?
Yes. Google has used site speed as a ranking factor since 2021, specifically measuring three signals: how fast your main content loads, how quickly the page responds to taps and clicks, and whether the layout stays stable during load. Failing any of these acts as a ceiling on how high you can rank, regardless of how good the rest of your site is.
The effect is most visible in competitive searches where two businesses are closely matched on everything else — content quality, reviews, how many other sites link to them. That's where the faster site wins. Fixing your speed scores also keeps more visitors on the page (because they don't bounce back to Google out of frustration), and Google factors that behavioral signal into rankings over time as well. What the three speed signals actually measure →
How much faster will my site get?
It depends on what's causing the current problem. Sites with large uncompressed images, slow-loading fonts, and no setup to show the top of the page first commonly go from a 4-6 second load to under 2 seconds — moving from a failing score to a passing one. Sites with one specific issue (a layout that jumps around, or text that goes blank on load) see targeted improvement in that area.
The audit at the start identifies exactly what's causing your specific scores and forecasts what each fix is expected to contribute. If the primary bottleneck is the hosting server itself — a shared host that responds slowly regardless of any code changes — that gets flagged clearly before any work begins, so you know the realistic ceiling upfront rather than at the end.
What exactly does the optimization work include?
Everything starts with a baseline measurement of your site's speed scores before anything changes. Then the fixes go in order of impact:
- Getting the part of the page visible before scrolling to appear without waiting on extra files
- Fixing fonts so text appears immediately instead of going blank during load
- Converting images to smaller modern formats and making sure each device downloads the right size
- Reserving space for images so the page doesn't jump around as they load
- Setting non-essential features to run after the page is visible instead of before it
- Telling each visitor's device to start downloading your main photo as early as possible
- Assessing and fixing how fast your site starts responding, where that's a bottleneck
The engagement closes with a written before-and-after report documenting each of Google's three speed signals before and after, with a plain-English explanation of what each change did and a maintenance checklist for going forward.
What is not included?
This is a technical optimization engagement, not a redesign or content project. New pages, copy changes, design revisions, new features, and content marketing are all out of scope. The work focuses on how the existing site loads — not what it says, not what it looks like.
If your hosting server is so slow that no amount of code optimization can fix the underlying problem, that gets surfaced in the audit and communicated clearly before any work begins. You won't pay for optimization work that can't actually move the needle. That situation is uncommon — most sites have meaningful room for improvement regardless of platform — but it happens, and it gets caught early rather than at the end of an engagement.
My site is on WordPress or Elementor. Can you still speed it up?
Yes. WordPress and Elementor sites have meaningful room for improvement through image compression, caching configuration, removing unnecessary scripts, and correct font loading. A well-optimized WordPress site can absolutely reach passing speed scores.
The ceiling is lower than a hand-coded site because the platform itself carries overhead that can't be fully eliminated — Elementor loads its own files on every page regardless of what the page actually uses. Getting from a failing score to a passing one is achievable on most WordPress sites. Getting into the same territory as a purpose-built custom site is often not. Plugin updates and WordPress core updates can also reintroduce problems that were fixed, which is why the final report includes a maintenance checklist covering what to watch after updates. For sites where the platform overhead is the primary bottleneck, migrating to a custom build is the right long-term answer. How to migrate off WordPress →
How do you prove the site got faster?
Every engagement includes a written before-and-after report using Google's own PageSpeed Insights tool — the same tool Google uses to evaluate your site. Scores are captured before any changes, after each batch of fixes, and at completion, so you can see exactly what each individual change contributed. This isn't a single before-and-after snapshot; it's a change-by-change log of what moved the needle and by how much.
The report documents all three speed signals Google uses as ranking factors — how fast the main content loads, how quickly the page responds to taps and clicks, and whether the layout stays stable during load — with specific scores at each checkpoint. Where your site has enough real-user traffic, the report also includes data from actual visitors, not just lab measurements. The report is yours to keep, reference, and share with any developer or agency you work with in the future. It's a permanent record of what was done and why.
How long does the optimization take?
A single-template site generally wraps up in three to five business days from the audit through the final report. The audit itself takes one to two days to measure, trace the causes of each failing score, and map out the fix sequence. Optimization work and verification follow, with each batch of changes verified before the next begins so the contribution of each fix is documented cleanly.
Multi-template sites with several distinct page designs run five to ten business days depending on how many templates exist and how many issues each one has. WordPress sites that need changes tested on a staging copy before going live add a day or two for that deployment step. If you have a deadline, mention it when you reach out — rush availability is possible in some cases and gets assessed as part of the initial conversation. Get a quote →
Will the speed improvements last, or will the site slow back down?
For hand-coded sites, the improvements are permanent unless someone deliberately adds new slow elements: large uncompressed images, extra features set to load at the wrong time, or styling files that delay the page from appearing. The changes are structural, not plugin-dependent, and they don't erode on their own. The final maintenance checklist covers what to watch if you or a developer make future changes to the site.
For WordPress and similar platforms, improvements can erode after plugin updates, theme updates, or when new images are uploaded without compression. The most common regression patterns are a WordPress update wiping out the ready-made-copy setup, a plugin update switching a feature back to loading at the wrong time, or new images getting uploaded without being compressed first. The maintenance checklist in the final report specifically covers these patterns for your setup. It's not a guarantee that scores stay stable forever — WordPress is a moving target — but it gives you a practical guide to the specific things most likely to cause problems and how to catch them early.
Does this help with mobile search rankings specifically?
Yes, and this is where speed optimization has the most direct ranking impact. Google evaluates the mobile version of your site when determining rankings — for both mobile and desktop searches. That means your mobile speed scores affect how you rank even for people searching on a laptop.
Mobile speed scores are almost always lower than desktop scores because phones are on slower connections and have less processing power. The same optimization work that brings a site from failing to passing on desktop provides proportionally larger gains on mobile, because mobile has less margin to absorb the same problems. The optimization work targets mobile performance specifically and documents mobile and desktop scores separately in the final report. Improving your mobile scores improves how you rank for everyone. How mobile-first design and speed connect →
What is the difference between a PageSpeed score and the speed signals Google uses for rankings?
Your PageSpeed score (0-100) is a general composite grade based on a range of speed measurements. It's useful as a rough sense of where your site stands, but it's not the measurement Google uses as a ranking factor. It's a summary — like a letter grade — not the underlying signal.
Google's ranking system uses three specific health checks, each with a hard pass-or-fail line: how fast your main photo or headline shows up (passing means under two and a half seconds), how quickly your page reacts when someone taps or clicks (passing means fast enough that it feels instant), and whether your layout stays put while it loads or jumps around (passing means it barely moves at all). You can have a decent overall grade and still be failing one of the three that matters for rankings. You can have a low overall grade and be passing all three. The optimization work targets these three specifically, not the overall grade. Full breakdown of the three speed signals →
Can you optimize a site you didn't build?
Yes. Most optimization engagements are for sites built by a previous developer, a web design agency, a template shop, or a DIY website builder the owner is now running on their own. The audit process is the same regardless of who built the site — the speed measurement tools surface the same issues, and the fixes follow from the issues rather than from familiarity with how the site was originally constructed.
What matters is access. For hand-coded PHP and HTML sites, access to the code files is needed to make changes. For WordPress, admin access to install or configure plugins. For hosted platforms like Wix or Squarespace, the plan you're on determines how much can be changed — some plans allow custom code additions sufficient for meaningful optimization, others don't allow it at all. If you're not sure whether your setup allows the required access, share the URL and the platform when you reach out and it gets assessed as part of the initial conversation before any commitment is made. Site speed self-diagnostic guide →
Related: Core Web Vitals explained · how to speed up your website · mobile-first web design · custom PHP vs. WordPress · Elementor vs. custom · SEO setup
Share your URL and find out exactly what's holding your scores back
The audit comes first. I'll measure what's failing, identify the root causes, and confirm what's achievable for your specific site before any work begins.
Get a quote