Copy a large folder to an external drive and the speed may begin high, fall sharply, recover, and then change again. Sometimes the progress window even shows a speed that looks impossible for the device involved. This can make a healthy drive seem unreliable or a fast connection seem slower than expected.
The key is that a file copy is not one continuous action at one fixed rate. Data passes through several stages, and the operating system may temporarily hold some of it in fast memory before slower storage finishes the work. The source, destination, connection, file sizes, and other activity on the device can all become the limiting factor at different moments.
Once you see a transfer as a pipeline rather than a single speed test, changing copy speeds become much easier to understand.
Think of a file copy as a pipeline
For a normal copy between two storage locations, the system has to read data from the source and write equivalent data to the destination. Between those two steps, data also passes through memory and the software that manages the file system and storage device.
A simple mental model is:
source storage → memory → connection → destination storage
The exact path varies. An internal drive may use a direct high-speed connection, while an external drive may sit behind USB or another interface. A network copy adds network hardware and protocols to the path. But the same principle applies: the overall transfer cannot keep outrunning its slowest necessary stage indefinitely.
Suppose the source can supply data faster than the destination can permanently store it. The computer may accept data quickly for a while, but eventually the destination becomes the bottleneck. The visible transfer rate can then fall toward a speed that the whole pipeline can sustain.
This is why the fastest number shown during a copy is not necessarily the speed you should expect for the entire transfer.
Caches can make the beginning look unusually fast
Computers and storage devices use caches, which are temporary areas for data that is likely to be needed soon or that is waiting for slower work to finish. Main memory, often called RAM, can be used for caching, and storage devices may have their own forms of fast temporary storage.
During a write, the operating system may be able to place some incoming data into memory quickly and let the storage system finish writing it afterward. From the application’s point of view, part of the work has progressed even though every byte may not yet have reached its final physical location.
Some solid-state storage also uses a portion of its flash in a faster operating mode as a write cache. The details and size of such caches depend on the device and its current state.
The practical effect is similar in both cases: a transfer can run quickly while fast temporary capacity is available. If the incoming data continues for long enough, that temporary space can fill or become busy. The rate then drops because the system has to wait more directly for the slower underlying storage work.
This does not mean the first speed was fake. It measured real progress at that stage of the pipeline. It simply did not represent a rate that every stage could sustain for an unlimited amount of data.
One large file and thousands of small files are different workloads
A 20 GB video and a folder containing 200,000 small files can contain the same total amount of data but take very different amounts of time to copy.
With one large file, the system can usually spend much of its time moving long runs of data. With many small files, it repeatedly has to create or open files, update file-system information, handle names and directories, and close files. Those operations add work that is not captured by the total number of gigabytes alone.
This is why a transfer can slow down when it reaches a directory full of small documents, thumbnails, application files, or other tiny items, then speed up again when it reaches a few large files.
The speed display can also jump around more because each short operation contributes differently to the average being shown.
When comparing two transfers, compare both the amount of data and the kind of files. Total size alone does not describe the workload.
The source and destination can take turns being the bottleneck
People often focus on the advertised speed of the cable or port, but a connection is only one part of the transfer.
If you copy from a slow source to a fast destination, the destination spends time waiting for data. Reverse the direction and the limiting factor may change. A fast external SSD connected through a capable interface can still copy slowly if the source is a slower drive, if the source is busy with another task, or if the workload consists of many small files.
The destination can also become slower during a long write because of its own internal work. Flash-based storage, for example, has to manage where data is placed and how reusable space is prepared. Exact behaviour varies by controller, flash type, free space, workload, and device design.
Mechanical hard drives have different constraints. Their read and write performance depends partly on physical head movement and where data is located on the disk. A workload involving many scattered files can therefore behave differently from a long sequential transfer.
There is no single rule that says the source or destination is always responsible for a slowdown. The useful question is: which required stage cannot currently keep up?
Other activity can change the speed while you watch
Storage devices are shared resources. If another application starts reading or writing heavily, your copy operation may have to compete for time on the same device.
Background tasks can have a similar effect. An operating system or application may be installing an update, creating thumbnails, indexing files for search, synchronising data, or performing other storage work. Some of these tasks are intermittent, so the copy rate may fall and later recover without anything being wrong with the drive.
Temperature can matter too. Some storage devices and controllers reduce performance when they become hot enough to require thermal management. Whether this happens, and at what point, depends on the hardware and its cooling. A slowdown during a long transfer is therefore not by itself proof of thermal throttling, but temperature is one possible factor when performance consistently falls under sustained load.
The displayed speed is an estimate, not a laboratory measurement
A file manager normally calculates transfer speed from how much progress has occurred over some recent period. The exact method varies by operating system and application.
That creates two important effects.
First, the number can lag behind a real change. If a drive suddenly slows down, the displayed average may take time to catch up.
Second, short bursts can produce impressive numbers that do not describe the full transfer. A cache may absorb data rapidly, or the progress calculation may cover a brief interval. What matters for a large copy is the average time required to finish the complete workload.
The remaining-time estimate has the same problem. If software assumes that the recent rate will continue, an estimate of two minutes can become five minutes when the transfer reaches slower files or a cache stops absorbing writes as quickly.
Treat both figures as useful live estimates, not promises.
Why a fast port does not guarantee the same file-copy speed
Connection specifications describe what an interface can support under defined conditions. They do not guarantee that files will move at that rate.
A real transfer includes protocol overhead and storage work, and the devices at either end may be slower than the connection. The workload matters as well. A link that has plenty of capacity for one large sequential file does not remove the per-file work involved in copying a huge collection of small files.
This distinction helps when troubleshooting. If a transfer is slower than the headline capability of a port, that fact alone does not show that the port or cable is defective.
A more useful comparison is whether the same source, destination, connection, and type of workload behave consistently across repeated tests.
How to judge a transfer more usefully
When you want to understand whether copy performance is normal, look beyond the highest or lowest instantaneous number.
For a large transfer, note the total data size and the total time. That gives you an average rate for the workload as a whole. If you compare devices or connections, use the same files in the same direction where practical. A test with one large video is not directly comparable with a test using thousands of tiny files.
Also check which storage device is reading and which is writing. If both source and destination are on the same physical device, that device may have to handle both sides of the operation. If an external device is involved, confirm that it is connected in the intended way rather than through an unexpectedly limited hub or adapter.
If performance starts high and then settles at a lower rate during every long copy, that pattern can be consistent with caching or sustained-write limits. If speed changes only when other applications are active, shared storage activity may be more important. If a device repeatedly disconnects, reports errors, or corrupts files, that is a different problem and should not be dismissed as normal speed variation.
Changing speed is often normal
A file transfer does not have one inherent speed. It is a sequence of reads, temporary buffering, communication, file-system work, and writes. Different stages can limit the transfer at different times.
Caches explain why short bursts can be much faster than sustained writes. File size and file count explain why two folders with the same total size can take different amounts of time. Source and destination performance, connection limits, background activity, and hardware behaviour can all move the bottleneck while the copy is running.
The practical lesson is to judge a transfer by its complete workload and sustained behaviour, not by one momentary number in the progress window. A speed that rises and falls is often the visible result of the computer balancing several kinds of work, not evidence that something has failed.