Why site speed matters
Site speed matters, but not for the reason it is usually sold: its effect on Google rankings is small and conditional, and its effect on the person waiting in front of the page is large and immediate. This lesson draws the line between those two using Google own documentation and our own measurements.
- Lesson 1 of 10
- Beginner
- Free, no signup
Being slow lands on four things, not one
These four are ordered from the largest effect to the smallest and, contrary to what the market says, ranking is the third, not the first.
- The person waiting
- Contact and purchase
- Rank in search
- Server cost
The size of each of these four belongs to your own site. This picture shows the order and not the amount; there is no number for the effect of speed on sales on this page, because we have none we could prove.
Last checked: Facts and tool names in this lesson are re-checked against their sources on this date.
What being slow actually takes from you
Being slow does not have one cost, it has four, and they are of very different sizes. The largest is the one that gets measured least: the person who opened the page and still sees nothing. They do not wait for you to prove your content is good; they go back and take the next result, and you never learn that they were there.
The second cost follows directly. Someone who did not stay does not fill in the form and does not buy. Here one thing has to be said honestly, because almost no other Persian page says it: we do not have a precise number for how many percent more sales this is worth, and any number you see about it has most likely come from a study of another company site in another market and has nothing to do with yours. The direction of the effect is clear, its size belongs to your own site, and it only comes out of your own measurement.
The third cost is ranking, and it is the smallest of the four. The next section deals with that alone, because that is where most of the talk and most of the exaggeration sits.
The fourth cost is invisible until the bill arrives: a heavy page is also more expensive on the server. Every request PHP has to rebuild from scratch wants processor time, and on a server holding several sites together that time is shared. A slow site is not only slow for its visitor; it is slow for its neighbours.
What Google itself wrote about speed
The good news is that you do not have to take anybody word for it. Google has a page called understanding page experience in Google Search results, and on that page, in the FAQ, it says four things with a directness you do not often see. We quote all four here, because half of them almost always get quoted alone.
First: asked whether there is a single page experience signal, the answer is that there is no single signal. Second: asked which aspects are used in ranking, the answer is that Core Web Vitals are used by our ranking systems. So far this is exactly what speed sellers quote, and it is correct.
The third is quoted less: getting good results in the Core Web Vitals reports does not guarantee that your pages will rank at the top of Google Search results. And the fourth is, in our view, the most important sentence on the whole page and one that is quoted essentially nowhere in Persian: trying to get a perfect score just for SEO reasons may not be the best use of your time. That is not us saying it. Google wrote it in its own official documentation.
And at the end of that page, where they ask how important page experience is to ranking success, the answer is the most precise and the most useful of the lot: Google Search always seeks to show the most relevant content, even if the page experience is sub-par; but for many queries there is lots of helpful content available, and in those cases a great page experience can contribute to success.
That one sentence closes the whole argument. Speed helps your ranking when ten other pages have also answered the question and Google is looking for a reason to order them. If you are the only one with the right answer, being slow does not push you out of position one. And if your content is weak, a score of one hundred does not carry it in.
What Google wrote, and what gets sold
In Google own documentation
- there is no single page experience signal
- Core Web Vitals are used by the ranking systems
- a good score does not guarantee a top position
- a perfect score just for SEO may not be the best use of your time
In the marketing of speed work
- speed is one of the biggest ranking factors
- a green score will lift your position
- a specific sales uplift figure, without your site ever being measured
- a score of one hundred is the goal
The right pan is not a lie, it is an inflation. Every sentence in the left pan is in that same Google FAQ page, and its link is at the foot of this lesson.
So why is the effect of speed on ranking exaggerated this much
Because speed is the only thing in SEO that has a number, and that number arrives in two minutes. Ranking takes months, content quality cannot be scored, link building is slow and vague; but a speed score can be taken right now, put in a screenshot and shown to a client. Whatever is easy to measure gets sold beyond its share. That rule is not specific to speed, but speed is its clearest example.
There is a second reason that is said less often: a large part of these claims comes from studies by companies that themselves sell a speed tool or service. Those numbers are not necessarily false, but they were taken on sites that are not like yours, in a market that is not yours. We sell speed work too, and that is exactly why this page carries no number about increased sales.
We have seen the practical result of this inversion often enough on client sites: someone spends months moving a score from good to very good, while the real problem with their site is that it has no page at all for the phrase they want. Which layer to fix first is laid out in the technical SEO lesson, and speed is the last layer there too, not the first.
Where speed is not your problem at all
There are four situations in which working on speed, however well it is done, changes nothing. If your site is in one of those four, read this path but spend the money elsewhere.
The first is a page that is not indexed. A page that is not in Google index gets zero visits with a score of one hundred, because it is not in the race at all. The second is a phrase nobody searches for. The fastest page in the world brings no visits for a question that is not asked.
The third is subtler and happens more often than the rest: a site whose speed is fine and which believes it is bad. That usually happens when someone mistakes the lab score of a tool for the real experience of their users. The difference between those two is the subject of the third and fourth lessons in this path, where it is opened up with Google own thresholds.
The fourth is one that fewer people tell a client: a site that is fast and whose offer is weak. If visitors arrive, the page opens instantly and still nobody gets in touch, the problem is not in the seconds. It is in the price, in trust, or in the fact that it is not clear what they are supposed to do. Speed does not fix that, and you will hear no claim from us that it does.
And one borderline case worth stating: sites whose audience is on mobile and on a weak network stand somewhere else on this spectrum. There slowness is no longer an irritation, it is a closed door, and even the four situations above stop applying sooner.
The question to answer before spending
If the page opened instantly, would anything change?
Speed genuinely is your problem
- you have visitors and a large share of them are on mobile
- you know which page earns for you
- start on that page rather than on the whole site
The problem is somewhere else
- the page is not indexed, or you have no page for that phrase at all
- visitors arrive but the offer or the price is not doing its job
- keep speed for when those two are solved
The right branch means leave speed for later, not that it does not matter. A site with no visitors today asks this same question next year once it has them, and by then the answer has changed.
Decide where speed sits in your own priorities
One simple way to get out of the argument and reach a decision: instead of asking whether speed matters, ask what exactly changes if your page opens instantly, and for whom. The answer for a shop with mobile traffic is not the answer for a company site that takes ten calls a month.
In practice three things settle the order. First, whether you have visitors at all; if you do not, speed is your last job. Second, where your visitors come from and on what device; if most of them are on mobile over a cellular network, page weight is money directly. Third, which page earns for you; speed work is worth it on that one, not across the whole site.
If after those three questions you conclude that speed genuinely is your problem, the next lesson is the right place to start: until you know what the browser does, every piece of advice you hear is a prescription you cannot repeat. The lesson on how a browser builds a page opens exactly that, and the rest of the site speed path rides on it.
The fast path, with AI
The ordinary way to decide about speed is to open a testing tool, look at the score and start fixing from the top of its list. The flaw is that the list is not ordered by your site, it is ordered by what the tool can measure. The fast way is to put your own field data next to the business role of your pages before any repair, and let the model say which page is genuinely held back by speed. It takes ten minutes and usually deletes half the jobs on that list.
- Take your own field data, not a lab score. The Core Web Vitals report in Search Console is exactly that: it is based on your real users and separates mobile from desktop. If a page has too little data there, note that fact and do not invent it.
- Write down the five to ten pages that matter to you, and next to each its business role: this one brings sales, this one brings calls, this one only informs. Do not take the order from traffic; a page with high traffic and no role is the page that eats your time.
- Hand both lists over together with the recipe below, not separately. The whole value is in that juxtaposition: a number that looks bad on its own stops being a problem once it turns out to belong to a page with no role. This needs a strong model, because it is judgment rather than bulk processing; the current pick in each class is kept in our AI reference.
- Turn the answer into a decision rather than a report. The right output here is one sentence: this month we work on this one page, for this reason. If the answer comes back as a list of ten jobs, ask again and force it to pick one.
Copy-ready recipe
You are a senior web performance consultant and today your job is prioritising, not repairing. Judge only from the two lists below.
List 1, field data from Search Console (for each page: address, mobile status, desktop status, or "not enough data"):
{the pages and their status}
List 2, the business role of those same pages:
{address} = {brings sales | brings calls | informs only | has no role}
Write four things:
1. Put the pages in three groups: speed is a real constraint here, speed is present here but is not the constraint, speed is not the subject here at all. Give your reason for each group in one sentence.
2. Pick the one page where working on speed is worth most, and say why that one and not the others.
3. Say which pages should not be touched now despite bad numbers, and what has to be solved about them first.
4. Write down which data you do not have that would change your answer if you did.
Rules: do not estimate any figure for increased sales or conversion, even if asked; no such number comes out of this data. Do not add any page that is not in the list. If a page has too little data, write that and draw no conclusion from it. If both lists show that speed is not this site main problem, say so plainly; "none of them, fix something else first" is an acceptable answer.Before you trust the output: One thing the model does not know and you do: why that page matters to you. It reads the business role from a list you wrote yourself, so if you fill that list optimistically the answer comes back optimistic. And a rule to keep yourself even if the answer says otherwise: accept no sales uplift number from this exercise. The relationship between speed and sales on your site comes only from changing something and measuring before and after, not from reasoning over Core Web Vitals data, and a model that hands you such a number is guessing.
AI in this kind of work
There is one question you should not ask a model here and one you should. The bad question is whether site speed matters for SEO; the answer is the marketing consensus, which is exactly what this lesson is correcting with Google own documentation. The good question is to put your own field data in front of it and ask which page is genuinely held back by speed. In the second case the model works on your data and is useful; in the first it recites from memory and takes you exactly where you should not go.
Tools that actually help
- Claude Suited to the job in the fast path: it takes both lists together and, instead of listing tasks, picks one priority and states its reason. Iran is not on Anthropic list of supported countries, so there is no official route to sign up or pay.
- Gemini If your data came out of Search Console and is bulky, it handles reading large tables well. Iran is not among the regions where this service is available.
- NotebookLM This is the right way to ask about Google own position: upload that page experience documentation page and ask the question inside the document. The answer comes from Google own text rather than from the model memory, and that difference is the whole argument of this lesson. It runs on a Google account, and Iran is not among the available regions.
Where it backfires
Two risks, and the first is precisely the subject of this lesson. A language model was trained on what the internet wrote about speed, and that text has been repeating the same inflation for years; so if you ask without data you will most likely hear what the sellers say rather than what is written in Google own FAQ. Here the model gives you consensus rather than the document, and on this subject the consensus is wrong. The second risk is more expensive: ask how much your sales will rise and you will get a number. That number does not come out of your data, it comes out of the pattern of sentences the model has seen, and Anthropic itself calls stating something unsupported with confidence hallucination in its documentation. Our position: the model is allowed only to organise data you took from Search Console yourself; any sentence about the effect of speed on ranking has to be read off Google documentation page, and any number about the effect of speed on sales has to come from measuring before and after on your own site.
Sources: Google: understanding page experience in Search results Anthropic: reduce hallucinations Anthropic: supported countries Google: where Gemini Apps are available
Where this advice stops
This lesson makes no page faster; it only helps you decide whether to go there at all. It has two other boundaries. First, its position rests on a text Google publishes today, and that text can change; the checked date is at the top of this page, and if a lot of time has passed since then, open the source link yourself once. Second, our observation comes from the sites we have worked with, meaning small and mid sized Iranian businesses; for a large international shop with millions of visits, where a fraction of a second really is measured in money, the order of those four costs is different, and at that scale we have no first hand experience to sell you.
From our own work
The simplest way to tell whether an agency actually acts on what it says about speed is to open the source of its front page. We measured the front page of this site on 7 September 2026: zero link rel=stylesheet tags, zero scripts in head, and zero img tags on the whole page. Everything on this site that looks like an infographic is drawn with HTML and CSS rather than an image file. The whole theme CSS is inlined into the response itself, so for the first paint the browser waits on no file from the network. And in the site main stylesheet exactly one animation is left, the waiting spinner; the rest of the animations and transitions were deliberately removed. You can check all of this right now by viewing the page source. Now the part that actually cost something: these decisions constrain what the site can look like, and inlining the CSS means those same bytes are sent again in every response. We accepted that because the HTML of this site is cached at the edge, and it is the second lesson that puts you in a position to judge such a trade yourself instead of taking it from us.
Real follow-up questions
So does site speed affect SEO or not?
It does, and Google itself wrote that Core Web Vitals are used by its ranking systems. But in the same place it wrote that a good score does not guarantee a top position and that chasing a perfect score just for SEO may not be the best use of your time. So the effect is real and small, and it mostly shows itself when several other pages have also answered well.
My speed testing tool gives a low score. Does that mean my site is slow?
Not necessarily. That score comes from a simulated run on one device and one assumed network, and your real users may have a completely different experience. What you should look at is field data, meaning the report built from your own visitors. The difference between the two is opened up with Google own thresholds in the third and fourth lessons of this path.
Should I fix speed first or content first?
If you have no page for the phrase you want, or your page does not answer the question, content comes first and it is not even close. Speed gets its turn once the right page exists, is indexed and receives visitors. The only exception is when the page is so slow that a mobile user leaves before seeing anything; there good content does not get seen either.