Why video buffers on YouTube — where the bottleneck is and how to check it yourself

The clip stops halfway, the wheel spins, the picture turns to soap all by itself — while the speed test in the next tab shows tens of megabits. Or like this: in the evening the video stands still, in the morning the very same one plays as if nothing had happened. Or the most galling case of all: it buffers even with the tunnel switched on. Below — why video is built so that “fast internet” guarantees it nothing, how to work out in five minutes whose half of the way the bottleneck is on, and what a private network changes here — and what it does not.

Why video is a special case

A page either opened or it did not, and an extra second there is barely noticed. Video works differently: it arrives continuously, and the player keeps deciding for you what quality you can carry right now.

It decides by the first seconds. While you are watching the intro, the player has already judged how fast the first chunk arrived — and picked the quality for the whole stretch ahead from that judgement. Judge too high and you get the spinning wheel: the buffer ran out before the next piece arrived. Judge too low and the picture is soap, but it never stops. And here is the galling part: having dropped the quality, the player climbs back reluctantly. It needs to be sure the margin holds rather than merely flickered, and that caution costs you several minutes of soap — long after the network came back to its senses.

And the clip does not come “from YouTube”. The site itself is a page, buttons and a list; the video is handed out by separate machines spread across the network in many places, and your player is given the address of one of them — the one judged suitable for your network in that minute. So “the internet is fast but the video is slow” is not a contradiction but the norm: the road to the site and to the speed-test machine can be fast while the road to that particular serving machine is something else entirely. They are different roads, and the choice can change in the middle of a clip.

How many megabits are actually needed. YouTube publishes this itself — here is its table of recommended speeds, which we checked on 20 September 2026:

The source is YouTube’s own help page, the part about approximate speeds recommended for playing each video format; checked on 20 September 2026.

Now compare that with the number from your own speed test. If it shows tens of megabits while 1080p buffers, the width of the channel has nothing to do with it: there is several times more of it than the picture asks for. So the question is not “how many megabits do I have” but “how far do they reach, and in which minute”. That is exactly why a speed test and a clip so often disagree: they measure different roads. Why even two consecutive runs of the same test give different numbers is taken apart separately.

A five-minute check: whose half of the way is it

The point of the check is one thing: to separate “bad at my end” from “bad on the way to this clip”. No terminal is needed — only the phone or the computer in your hands and five minutes. Go in order and remember the answers.

1. Switch the quality to 360p by hand, in the clip’s own settings. If 360p plays smoothly while 1080p spins the wheel, the channel is alive — simply less is reaching you than the larger quality asks for.
2. Open any other video — not on this service but anywhere else: in a messenger, in a feed, in an online cinema. This is the fork in the road: everything stutters — the trouble is at your end; only this one does — the trouble is on the road to that serving machine.
3. Change the network. From Wi-Fi to mobile data and back, on the same clip and in the same minute. A different answer in two networks means neither the phone nor the service is to blame: it is that particular network.
4. Come back to the same clip at another hour. Evening is when networks are busiest; if in the morning the same link plays smoothly, you are running into the rush hour, not into a fault.
5. Run a speed test alongside — and read it carefully. It measures the road to its own nearest machine, not to the one your clip is coming from; we once took apart a case where the instrument measured quite a different path.

If the check pointed at your side, the way on leads to neighbouring write-ups rather than to this one: if it is the home network, why Wi-Fi and mobile data come out differently; if it is the mobile one, operators each behave in their own way.

What a private network changes, and what it does not

This is the easiest place to be disappointed, so we will say it straight away. A tunnel changes the path, not the width of the channel. Your traffic goes to our server and out into the network from there — that is, the second half of the road becomes ours, and we answer for it. The first half — from your device to us — stays entirely yours: the Wi-Fi in the far room, the evening load at your provider, the elderly router and the busy phone do not go away, and no tunnel cures them.

For our own half, though, we can answer in numbers. Here is our measurement of 20 September 2026: from our working machine a real tunnel was raised to each line, and a 50 MB chunk was pulled through it — from Google’s file storage and from Cloudflare’s speed endpoint.

The last row matters more than all the others, and without it the table lies. The same machine at the same time, with no tunnel at all, takes 67.9 and 68.4 Mbit/s — that is its own ceiling. Which makes the numbers above a floor rather than a limit: that much reached our test machine, having run into that machine’s own channel. How much the line would have given to a fatter machine this measurement does not know, and we are not going to invent it.

What follows for video is simple arithmetic. The smallest number in the table, 40.1 Mbit/s, is eight times the 5 Mbit/s YouTube asks for at 1080p, and twice the 20 Mbit/s recommended for 4K. But it has to be read strictly: what was measured is our stretch, from the test machine onward, on one evening, over four lines. Your stretch — the one up to us — takes no part in these numbers at all, and they do not turn into a promise of a smooth picture at your place.

Separately we measured something closer to the question itself: how fast one and the same chunk of one and the same clip downloads straight from the serving machine — from each of our nodes, in Russia, the Netherlands, Poland and Germany. That measurement answers “does the node itself have a good road to the video?”, and it no longer depends on our own home channel.

The second run on the Polish machine is missing from the table: by then the serving address had expired and the server answered with a redirect. That is the instrument failing, not a speed of zero, and we say so.

The important column here is the first one, and it is the same everywhere. The clip arrives at about 3 Mbit/s from anywhere: from Russia, from Amsterdam, from Warsaw, from Frankfurt — while the clip’s own bitrate is 3,248 kbit/s. In other words, the serving machine hands out video at the pace of the video itself, not as fast as the pipe allows: exactly as much as is needed to watch it.

That the pipe is in fact wide is visible in the next column. The same machine, the same minute, servers of the same company — an ordinary file downloads tens of times faster: from 146 to 582 Mbit/s. The starkest case is the Russian machine: 506 Mbit/s on a file and 3 Mbit/s on the clip — a hundred and sixty times apart.

Hence the conclusion this measurement was made for: a speed test and a video measure different things. Chasing megabits for the sake of video is pointless — there are already ten times more of them than the clip needs. What matters is whether that modest 3 Mbit/s lane holds steadily, without dropouts lasting a few seconds. A dropout is exactly the spinner on your screen.

And an honest caveat, without which the table reads wrong. The Russian machine lost 20 % of the probe packets to the serving machine, the other three lost none — and the download speed came out the same for all of them. So echo loss alone is not something to judge by: a server may answer those probes every other time, and that need have nothing to do with losing data. We report it as it is and draw no conclusion from it. One more: all four machines sit in data centres rather than at home on an ordinary line — this is one evening and our half of the way, not a portrait of yours.

And one more thing a tunnel does not do: it does not save traffic, it adds a little — how much exactly, we counted separately. If your traffic is metered, that surcharge is worth keeping in mind — it does nothing to the smoothness of the picture either way.

It buffers even with the tunnel on

The most unpleasant case, and it has three explanations. They are different, and they are checked in turn.

1. The player has already dropped the quality and is holding on to it. If you switched the tunnel on in the middle of a clip, or right after a bad patch, the player’s judgement is the old one — and it will honestly keep serving soap although the road is already different. The cure is crude and reliable: restart the clip, better still the app, and let the player judge the network afresh.

2. The path has become longer — and that is true. Traffic goes not straight but through our server in the country you chose, and the latency grows accordingly. Here is our measurement from the same evening: 20 service packets each, in pairs — first straight, then immediately through the tunnel.

The tunnel added between 13 and 65 ms — precisely because the road got longer. For video that hardly matters: the player keeps a buffer seconds ahead, and an extra tenth of a second hides in it whole. Where it does show is elsewhere — in games, where every action leaves and comes back at once; there we measured it in detail. The caveat is the same as in that write-up: we measured from a working machine whose provider carries traffic to Europe the long way round, so these hundreds of milliseconds say nothing in themselves — what speaks is the difference between two roads taken in the same minute.

3. The bottleneck is on your stretch — a tunnel does not cure that. If little reaches us in the first place, how good our half is no longer matters. This is exactly the case the five steps above were written for: another network, another hour, another video — three answers, and the culprit becomes visible.

And separately: if with the tunnel on nothing loads at all, that is not about speed but about the connection. “Connected, but nothing loads” is taken apart by cause, and that is where to start. And if you want to be sure the protection came on at all, four checks, step by step, are in a neighbouring article.

What we do not promise

In plain words, so that nothing extra can be read out of the sections above.

• That video will be faster for you. We promise no speed for any particular service to anyone — it depends on your network, your hour and which serving machine you are given. That can only be promised in words, and we try to work in numbers.
• That “it will become 4K”. The quality is chosen by the player, not by us, and it chooses by how the first seconds arrived along the WHOLE way — your half included.
• That a tunnel always adds speed. The opposite happens too: a longer path, a higher latency — it is visible in the table above, and we are not hiding it.
• That our numbers are your result. 40–57 Mbit/s is what reached our test machine on one evening; it is a floor for our stretch, not a forecast for yours.

What we can actually do is answer for our half of the way, measure it and show it as it is, together with what the measurement does not say. And let you check for free, because on your own network the answer will be your own anyway.

What we checked

• How much each line delivers — with a live tunnel, not from a description. On 20 September 2026, around half past eight in the evening, from our working machine: a real tunnel to each of the four lines and a 50 MB chunk pulled from Google’s file storage and from Cloudflare’s speed endpoint. The result is in the table above.
• The ceiling of the test machine itself — same instrument, same time, no tunnel: 67.9 Mbit/s from Google’s storage and 68.4 from Cloudflare. That is why the line numbers are called a floor and not a limit: 40–57 against a ceiling of 68 means we ran into our own channel. Without that check the same table would read as “this is all we are capable of”.
• Latency — in pairs, within one minute. 20 service packets each to the video serving machine and to the YouTube site, first straight and then immediately through the tunnel, over the Netherlands and Poland lines. The pairing is there so that we compare two measurements of one minute rather than today’s against yesterday’s.
• The clip itself — paired with an ordinary file, on every machine. The same chunk of the same clip was downloaded straight from the serving machine on four of our machines, two runs each, and right after that, on the same machine, an ordinary file from Google storage. The pair is essential here: without it “3 Mbit/s” would read as “a narrow channel”, while the neighbouring 146–582 Mbit/s shows the channel is wide. Steadiness we did NOT measure: an average over two minutes cannot see a three-second dropout, and the spinner on the screen is exactly that dropout.
• The table of requirements — at the source. The numbers 20, 5, 2.5, 1.1 and 0.7 Mbit/s were taken neither from memory nor from someone else’s article but from YouTube’s own help page; checked on 20 September 2026, the link is under the table.
• The player’s behaviour is not our measurement but the general mechanics of streaming video, and we call it exactly that. We have no measurement of our own for how many seconds it takes a player to climb back up.

What we do not know

It is more honest to list this than to pass over it: the measurement was a one-off, and exactly as much can be concluded from it as is in it.

• How this looks from a home connection in Russia. We measured from our own working machine, not from a subscriber’s flat: neither your provider nor your Wi-Fi is in these numbers.
• How this looks in other regions. One measuring point — one route. We do not count speed by city or operator and draw no “where it is faster” maps.
• How televisions and set-top boxes behave. They were not part of this measurement at all.
• What happens at another hour. The measurement was an evening one and a single one; in the morning and at a weekday noon the numbers will be different, and we do not know by how much.
• Why one line gave less to one target than its neighbour did. A spread of 40–57 Mbit/s against a machine ceiling of about 68 can mean a difference of routes or simply the evening load. One measurement cannot tell those apart, and we do not invent explanations.
• Which serving machine you personally will be given. The service picks that itself, and the choice is neither visible to us nor ours to control.

Short answers

Will a VPN help if video buffers? Not necessarily. An app of that kind changes the path, not the width of the channel: if the bottleneck is on your stretch — the Wi-Fi, the router, the evening load at your provider — a tunnel will not remove it. If the trouble is further along the road, another path may turn out luckier. Which of the two it is takes five minutes to find out.

Why does 360p play and 1080p not? Because they ask for different speeds: 0.7 Mbit/s against 5, by YouTube’s own table. What reaches you in that minute is somewhere in between.

Why is it worse in the evening and fine in the morning? Evening is rush hour for everyone at once: the home provider, the mobile operator, the road further along. The check is simple — open the same clip in the morning.

Is the phone to blame? Sometimes it is: no free storage, a hot case, battery saving, a dozen apps open. The sign is that on another device in the same network the same clip plays smoothly.

It buffers even with the tunnel on — what do I do? First restart the clip and the app: the player may have dropped the quality earlier and be holding on to it. Then — the three causes in turn, taken apart above.

How many megabits are needed to watch in peace? By YouTube’s table: 5 Mbit/s for 1080p, 2.5 for 720p, 20 for 4K. Anything beyond that no longer improves the picture — it only gives a margin for the dips.

What about a television or a set-top box? They were not in this measurement, and the numbers above say nothing about them. What works on a big screen at all, and what does not, is in a separate article.

Will the tunnel eat extra traffic? It adds a small surcharge — how much exactly, we measured the same way: one and the same file with the tunnel and without. The quality of the picture itself eats incomparably more than that surcharge.