Why Is My Website Slow? What to Check Before You Pay

Somebody showed you a number. It might have been a developer, a cold email, or a red score you found yourself at eleven at night after a customer said the site took forever on their phone. Whoever handed it over, the number came with a suggestion attached, and the suggestion usually costs money. The awkward part is that you cannot check it. Your site opens fine on your own laptop, in your own office, on the internet connection you pay for. So, you are left deciding whether to spend on a rebuild you may not need, or to ignore something that might genuinely be turning people away. There is a way to settle that question yourself, in about twenty minutes, before anybody invoices you.

Open PageSpeed Insights, put in the exact address somebody complained about, and look at the top of the result before you look at anything else. If enough people have visited that page in Chrome recently, Google shows a panel of what those real visits were like. Underneath it sits a second set of numbers from a test run just now, on a simulated phone, on a simulated connection.

Those two things answer different questions. Google's own guidance describes the difference between lab and field data plainly: a lab test is a controlled simulation, while field data reflects the devices, networks and locations of people who really came to your site. The field numbers are also a distribution rather than one experience, reported at the 75th percentile.

That matters more than it sounds. A red lab score with a healthy field panel means the simulation struggled and your customers largely did not. A healthy lab score with a poor field panel means the opposite, and the field panel is the one describing your business.

There is a third case worth naming, because it gets misread constantly. Sometimes the field panel is absent, because not enough people have visited that page for Google to report on it. That is missing evidence. It is not a clean bill of health and it is not proof of a problem.

A lab score earns its place as a starting point. It runs on demand, it repeats, and it hands you a list of things worth investigating. What it cannot do is tell you which of those things is actually costing you anything.

Google is unusually direct about the limits here. Its page experience documentation says that Core Web Vitals are used by its ranking systems while also saying there is no single page experience signal, that strong content can still rank with a subpar experience, and that passing reports do not guarantee rankings. The Lighthouse team goes further in its own performance FAQ, noting that chasing a perfect score purely for search reasons may not be the best use of anybody's time.

So, two opposite conclusions are both wrong. "The score is 40, we need to rebuild" skips the diagnosis. "Speed does not matter, content matters" ignores a signal Google says it uses. The useful position sits between them and it is built on evidence about your own pages.

"Slow" is one word covering three complaints, and they have different causes and different fixes. Separating them is most of the diagnosis, and you can do it by describing what you saw rather than by reading a report.

The first is loading. Google's reference points, last updated in 2025, put a good largest contentful paint within 2.5 seconds. When that is the problem, the main thing on the page takes too long to appear.

The second is responsiveness. You tap a button and nothing happens for a moment. Good interaction to next paint sits under 200 milliseconds by the same guidance, and web.dev's breakdown of what makes an interaction slow splits it into input delay, processing time and presentation delay.

The third is movement. Text loads, you go to tap a link, and an image arrives above it and shoves everything down. Good cumulative layout shift is under 0.1.

Which one you are describing changes where a competent person looks first. It also changes whether "upgrade the hosting" makes any sense, because server response time is one possible cause of the first problem and has little to do with the other two.

The sequence below is diagnostic before it is prescriptive, and each step narrows the next. Somebody proposing work before step four has skipped the part that tells them what to do.

It starts with the complaint itself. Write down the address, the device, roughly where the person was, what time it happened and what they were trying to do. Test it logged out, because a consent banner, a chat bubble, a video embed or an advertising tag can behave differently for a visitor than for you.

Then the baseline. Save the reports for the page that was actually slow and for one or two other page types, mobile and desktop separately. Read the field panel first where it exists. In Search Console, look at the groups of affected addresses rather than the homepage alone.

Then the bottleneck. For a loading problem, web.dev's guide to finding what delays the main content splits the delay into server response, how late the browser discovers the important file, how long that file takes to download, and how long it takes to draw. Each part has different remedies. Chrome's own performance tools can compare a local recording against the real visitor data, which is how somebody tells a genuine pattern from a one-off.

Then the smallest reversible change that the evidence supports. A correctly sized image. An unused tag removed. A script loaded differently. A cache header corrected. Not five unrelated changes in one release, because then nobody knows which one worked.

That last group is the part nobody mentions when they sell the work. The fix can be live and correct on a Tuesday, and the evidence that customers felt it will not be complete for a month. Anybody promising you a confirmed improvement next week is describing a lab retest and calling it something else.

There is no reliable market rate for this work, and any figure presented as one deserves a question. What can be shown honestly are real published prices, dated and labelled as belonging to the company that set them.

One WordPress specialist, WPPerfOps, listed on its pricing page a one-time basic audit at $149, a standard optimisation at $399 including thirty days of support, and a premium tier at $749 with monitoring and ninety days of support. A different provider, JoeWP, publishes packages at €990 net for a basic performance package and €1,990 net for a more involved one covering server response and plugin work.

Those are two companies' own sale prices. They are not an average and they are not what your job should cost. What they do usefully show is the gap between buying an audit and buying an implementation, which are different purchases that often get quoted as if they were one.

The things that move a job up the range are visible in those listings: more page templates, an online shop or logged-in areas, server or database work, custom code, third-party integrations, no access to the source or the hosting, and any ongoing monitoring or support. Separate the one-off fee from the recurring ones for hosting, image processing, monitoring and plugin licences, then ask which of them are inside the number you were quoted. The same discipline applies to what a website costs you every month, where the recurring charges are the ones that quietly accumulate.

Everything in this group is safe, free and useful whether or not you hire anybody. Save the PageSpeed result for the page somebody complained about, on mobile and on desktop. Note whether a field panel appeared at all. Run the same test on two or three different page types rather than the homepage alone. Write down the complaint with the device and the time.

Then take stock of what is loaded onto the site: plugins, tracking tags, embedded video, chat widgets, consent tools, and anything added in the last few months. Make sure you personally hold administrator access to the domain, the hosting, the content system, analytics and Search Console, which matters here and matters much more when you need to know who owns your website. Take a backup you know how to restore.

One content change is usually safe: swapping an enormous uploaded photograph for a properly sized version, keeping the original file somewhere. Google's guidance on choosing an image format covers the options. Look at the page afterwards to confirm it still looks right.

The line is an untested change in production to caching, DNS, redirects, a booking or payment flow, server configuration, code, the database or third-party scripts. Deleting a plugin because it looks unused can quietly remove a live form, a security function or a payment step. And do not hand anybody the only administrator account, or move the domain, to fix a speed report.

There is no Arlington rule about website speed, no city benchmark, and no local testing programme for small business sites. If somebody tells you otherwise, ask to see it. What is real locally is ordinary business infrastructure: the Greater Arlington Chamber of Commerce reports more than a thousand members, and the Downtown Arlington Business Improvement District, which began through a property owner petition in 2010 and had its funding renewed in 2025, does marketing and economic development work.

Two pieces of Texas law do touch this, though neither sets a speed standard. Claims made while selling you the work fall under the state's rules on false, misleading or deceptive practices in trade or commerce, which is worth remembering when somebody guarantees a ranking or a score. Separately, if a performance change alters your analytics, consent tools or advertising tags, it may affect how personal data is handled, and the state's data privacy statute sets obligations for the organisations it applies to, with its own small business provisions. None of this is legal advice, and the ownership and liability terms in any agreement are worth a Texas lawyer's eyes.

Prevention here is a habit rather than a project. Pick a small set of pages that matter, including the one people actually land on, and record where they stand today. Check them again after any real change to the site.

The moment things slip is almost always the moment something gets added: a new theme, a plugin, a tracking pixel, a chat tool, an embedded video, or a batch of photographs uploaded straight off a phone. Putting a quick check into the approval path for those is worth more than any monthly report.

You will know a change worked when the retest improves, the page and its forms still do what they are supposed to do, the field data improves as the 28-day window turns over, and Search Console stops reporting the issue after validation. Not one of those on its own. Certainly not a ranking movement, which has too many other causes to prove anything here.

It looks fast on my computer. Is it actually slow?

Your laptop, your connection and your location are one experience out of many. It is a real observation and it is not a measurement of your customers. The field panel is the thing that speaks for them.

Why is my website slow on mobile but fine on desktop?

Phones have less processing power and often a worse connection, so anything heavy shows up there first. It is also why the mobile and desktop reports are kept separate.

Will upgrading my hosting solve it?

Sometimes. Server response time is one cause of slow loading, and it has little to do with a page that will not respond to a tap or one that jumps around. Find out which problem you have before you move.

Do too many plugins make a site slow?

They can, because each one may add code the browser has to fetch and run. The number matters less than what each one does. Removing them blind can take a working form or payment step with it.

How much does a slow site actually cost me?

The honest answer is that it depends on your own traffic. There is a widely quoted figure that 53% of mobile visits were abandoned when pages took longer than three seconds, from research Google published with SOASTA in 2017. It is real, it is old, and it is a global average rather than a number about your business. Work yours out from your own analytics instead.

How do I check my website speed without a tool?

Open the page on a phone, on mobile data rather than your office network, having not visited it recently. That is closer to a customer's experience than any test you run on the machine you built it on.

A speed score is a prompt to look, not a verdict and not a quote. The distinction that settles most of these conversations is the one between a simulation run on demand and a record of what your actual visitors met, and both sit on the same screen for free. From there the questions are which page, which of the three faults, and what evidence points at the cause.

Getting that far costs you twenty minutes and no money at all. It also changes the conversation with whoever suggested the work, because you arrive with the affected page, the device, the field panel and a specific question instead of a screenshot somebody else chose.

If you would rather somebody else ran that diagnosis and showed you the working, Arlington Website Designer builds and looks after sites for businesses around Arlington, TX, and a speed question is usually the cheapest place to start because it so often ends in a small fix rather than a rebuild. Send us the address and what your customer described, through the contact page, and you will get back the page we tested, what the field data showed, and whether we think it is worth spending anything on at all.