Transfer Size vs. Resource Size
It's important to be clear on two key ways to measure size: Transfer Size and Resource Size.
In this tip, we'll discuss each and their respective impact on performance.
Web applications are designed to retrieve remote resources from the network and load them into the end-user's browser at runtime.
The Transfer Size of a resource represents the total number of bytes required for transfer across the network. This is also sometimes referred to as bytes over the wire. This size considers the transferred payload and any request / response headers.
In general, the larger a resource's Transfer Size, the longer it will take to transfer across the network.
There are a variety of techniques that exist to optimize Transfer Size.
Each technique is designed to reduce the amount of time that is required to transfer a network resource.
Transfer Size can be greatly reduced by utilizing standard resource compression algorithms like gzip and brotli.
This usually works by having a server or build process compress a resource before transferring it to the end-user:
In this example, the Transfer Size for this resource is 24 kB, because 24 kB is transferred over the network.
A resource, once delivered, must be decompressed by the end-user's browser before further processing:
By compressing resources before sending them across the network, web applications optimize delivery of assets to their end-users.
In general, most web applications utilize some form of Browser Cache to persist resources on the end-user's device.
When a resource is persisted in a Browser Cache, it does not have to transfer any bytes over the wire.
This is why caching is such a popular optimization for improving Transfer Size -- if a resource is loaded from the end-user's browser cache, it has a network Transfer Size of 0 bytes!
Unlike Transfer Size, Resource Size is completely independent of any notion of the network; it simply represents the total number of bytes that comprise a resource, regardless of any caching or compression applied.
There's a common misconception among web developers that a resource, if optimally delivered or cached, does not hold the potential to degrade a web applications performance.
This couldn't be further from the truth!
Once a resource is delivered to the end-user's browser (or loaded from cache), we start to see its impact on an end-user's CPU.
In general, the larger a resource's Resource Size, the longer it takes to process on an end-user's CPU.
Note: End users typically have slower CPUs and hardware than developers. Slow hardware further compounds the overhead of large Resource Size.
For more details on this, read about my tip on why your cached JS is still slow.
Images require decoding on the end-user's device before they can be displayed on screen. This cost is irrespective of if the image was transferred quickly or loaded from browser cache:
There are various techniques that exist to optimize resource size. The goal of each is to fundamentally reduce the size of the resource and its impact on the end-user's CPU.
Some of these techniques include:
- Optimizing Image Formats
- Lazy Loading resources
By reducing the size of a resource, you directly minimize its overhead on the end-user's CPU.
When optimizing Resource Size, you are also directly optimizing Transfer Size!
Since Transfer Size is typically a compressed result of a resource, a smaller resource produces an even smaller compressed resource!
Compressing a 10kB resource produces about 4kB of Transfer Size, which can be delivered across the network much faster than a compressed 80kB resource at around 24kB of Transfer Size!
You can also utilize Performance Resource Timings to collect size metadata and timings from your users at runtime.
That's all for this tip! Thanks for reading! Discover more similar tips matching Network.