Slow Server and HTTP/1.1 Findings: What to Ask Your Host

Short answer: Two findings in the speed area of a Site AI Audit report point at your hosting. “The server takes N s to respond” is a warning that appears when the first response takes longer than 1.5 seconds. “The server uses the old HTTP/1.1 protocol” is a notice that appears when the server has not enabled HTTP/2 or HTTP/3. Neither needs a redesign. Both are fixed by caching, a better hosting setup or a setting that you can ask your host to change.

Why the server matters before anything else

Every page load starts with a wait. The browser sends a request, the server prepares the page and sends the first byte back. Until that first byte arrives, nothing on the screen can happen: no text, no images, no layout. A slow server delays everything that follows, and no amount of image compression can win that time back. That is why the audit measures it separately, during the first step of the check when it asks “how fast does the server answer?”

The audit’s explanation for the finding is short: a slow first response delays everything else on the page. The advice is to enable page caching, upgrade hosting or use a CDN. That list is also a good order of attack, from cheapest to most expensive.

The slow server finding in detail

The finding reads “The server takes N s to respond” with the measured time, and it is a warning when the response time is above 1.5 seconds. For comparison, a well-configured site answers in a fraction of a second. The measurement comes from the audit’s own request to your site, so it reflects what a visitor from outside your network would see for an uncached request.

Occasional slowness is normal. A single measurement can be affected by a busy moment on the server or a cold cache. If the finding appears once and not in the next check, you probably saw a spike. If it appears every time, you have a real problem. A good rule: run the check twice on different days before you decide to change your hosting.

What usually causes a slow response

No page caching. Dynamic sites such as WordPress build each page from the database on every visit. Caching stores the finished page and serves it instantly.
Overloaded shared hosting. Hundreds of sites on one machine compete for the same processor and database.
Old PHP. Newer PHP versions are much faster; the audit also warns when the visible PHP version is below 8.2.
Heavy plugins or slow database queries. A plugin that runs expensive queries on every request slows the first byte.
Distance. A server on another continent adds delay to every request, which a CDN can reduce.
A slow DNS lookup or a long redirect chain before the page, which adds time that is not the server’s fault.

What to try, in order

Turn on page caching. For WordPress, a caching plugin or the cache offered by your host is the biggest single improvement. The article on choosing a WordPress caching plugin helps you pick one that matches your hosting.
Update PHP. Ask your host to move to a current version, after checking that your plugins support it. See why upgrading PHP makes a site faster.
Remove what you do not use. Deactivate and delete plugins that you do not need; the guide on finding slow WordPress plugins shows how to identify the heavy ones.
Add a CDN if your visitors are far from the server; the article on whether you need a CDN explains when it helps.
Change hosting. If nothing works, the plan may simply be too small. The comparison of shared hosting and VPS shows what a step up can bring.

The most detailed explanation of the underlying measurement is in how to reduce server response time.

What to ask your hosting provider

Many site owners do not control the server, and the most effective action is a clear message to support. A good message contains the measured value and a few specific questions:

“My site takes about N seconds to give the first response. Can you check whether my account is being throttled or the server is overloaded?”
“Is server-side page caching available on my plan, and can you turn it on?”
“Which PHP version am I running, and can you switch me to a current one?”
“Is HTTP/2 or HTTP/3 enabled on my site?”
“Is there a slow-query log or a resource usage report you can share?”

Concrete questions get concrete answers. A vague “my site is slow” often gets a generic reply.

The HTTP/1.1 finding in detail

The notice reads “The server uses the old HTTP/1.1 protocol”. HTTP is the language that the browser and the server use to exchange files. The old version, HTTP/1.1, handles files one after another on each connection, so the browser has to open several connections and wait. HTTP/2 and HTTP/3 send many files in parallel over a single connection and compress the headers. The audit’s explanation is that this loads many files in parallel and is noticeably faster, and the advice is to enable HTTP/2 on the server or the CDN.

In most cases this is a setting that your host can switch on or that is already available on a newer plan. The article on HTTP/2 and HTTP/3 explains what each version changes. It is a notice and not a warning because the effect depends on the page: a page with few files gains little, and a page with dozens of scripts, styles and images gains more.

Checking the result

After a change, clear the cache and run the check again. The slow server finding should disappear when the response time drops below 1.5 seconds, and the HTTP finding disappears when the server answers with HTTP/2 or HTTP/3. Remember that the audit measures your server from the outside, so a CDN in front of your site may show a better protocol than your own server offers, which is fine: your visitors see the same thing.

Why a faster server helps other findings

Server speed is the base of the speed area, and improving it often lifts other numbers at once. A faster first response moves the main content earlier, which helps the Largest Contentful Paint finding. A cached page needs less work from the processor, which can reduce slow pages in the crawl. A newer PHP version and caching lower the load, which helps when many visitors arrive together. When you fix the server first, you may find that several other speed findings shrink or disappear without any separate action.

When the measurement is misleading

A few cases can make the response time look worse than it is. A site that redirects through several addresses before the final page adds delay. A page that checks a login or a location on the first request can be slow only for that request. A security plugin that scans every new visitor may add a pause. If the number looks too high for what you expect, test the same address in your browser’s network panel and look at the waiting time for the first request. If both show the same, the problem is real.

Reading the numbers with a sense of proportion

It is easy to chase a number. A response time of 1.4 seconds does not trigger the finding while 1.6 seconds does, but the difference for a visitor is small. Treat the threshold as a signal that the server is slower than it should be, and focus on the clear wins, such as caching, rather than on shaving a tenth of a second. If your response time is already well below the threshold, the better use of your hour is probably another finding, such as an oversized image or a missing compression setting.

A worked example

A florist runs a WordPress shop on a budget shared hosting plan. The audit shows two speed findings: the server takes 2.8 seconds to respond and the site uses HTTP/1.1. She writes to the host with the five questions above. Support replies that page caching is available but off, that her PHP version is old and that HTTP/2 is enabled only for newer plans. She turns on caching and PHP 8.3, and the host moves her to a newer plan at the same price. The next check shows a response time of 0.6 seconds and no HTTP finding. Her mobile score has also moved up, although she changed nothing in the design of the site.

To measure your own server, check your website with Site AI Audit. The check needs a free account; the plans unlock the full report so you can see the findings and fixes.

The bottom line

A slow first response and an old protocol are both hosting findings. Turn on caching, update PHP and ask your host the specific questions in this article. Then run the check again to see the response time and the protocol that your visitors get.

BUJ

How fast should the server respond?

The audit warns above 1.5 seconds. A well-set-up site answers much faster, often in well under a second.

Will a CDN fix a slow server?

A CDN can serve cached pages from locations close to visitors, which helps. It does not fix a slow database or an overloaded plan behind it.

Is HTTP/1.1 really a problem?

It is a notice, not a warning. HTTP/2 or HTTP/3 loads many files in parallel and is noticeably faster, especially on pages with many files.

Can I enable HTTP/2 myself?

On many hosts it is a setting or comes with a newer plan. If you do not control the server, ask your host or enable it in your CDN.

Why does the response time differ between checks?

Server load, caching and the distance to the test server all vary. Judge a pattern across several checks, not a single number.