Transfer Size vs. Resource Size<!-- --> | <!-- -->Web Performance Tips

Transfer Size vs. Resource Size

The size of the resources (images, JavaScript files, CSS files, etc.) web applications deliver to end-users directly impacts performance.

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.

Transfer Size

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.

A diagram highlighting network transfer for a browser

In general, the larger a resource's Transfer Size, the longer it will take to transfer across the network.

Optimizing Transfer Size

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.

Resource Compression

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:

A diagram highlighting compression as an optimization

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:

A diagram highlighting decompression

By compressing resources before sending them across the network, web applications optimize delivery of assets to their end-users.

Resource Caching

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.

A diagram highlighting browser caching as an optimization

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!

Resource Size

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.

In this example below, the JavaScript file's Resource Size is 80 kB, although the Transfer Size is 24 kB:

A diagram highlighting compression

Resource Size Overhead

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.

Example: JavaScript Overhead

For example, if we load a decompressed 80 kB JavaScript file into the user's browser, that means that 80 kB file must be Parsed, Compiled, and Executed on the end-user's device. This cost is irrespective of how fast the resource transferred, or if it was loaded from browser cache.

A diagram highlighting JS CPU Cost

For more details on this, read about my tip on why your cached JS is still slow.

Example: Image Overhead

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:

A diagram highlighting Image CPU Cost

Optimizing Resource Size

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:

By reducing the size of a resource, you directly minimize its overhead on the end-user's CPU.

For example, it will take the browser less time to Parse and Compile a 10kB JavaScript file vs. an 80kB JavaScript file:

A diagram highlighting JS CPU Cost

With this knowledge, be extra weary when importing a new JavaScript library (or other dependency) into your web application! When a library claims to only consume "N bytes", be sure to clarify if this is N Compressed bytes or N Resource bytes.

Optimizing Resource Size Helps Transfer Size

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!

For example, if you optimized and trimmed an 80kB Resource Size JavaScript payload down to 10kB of Resource Size, this is a huge improvement for the end-user's CPU utilization. It also is a huge improvement for Transfer Size.

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!

A diagram highlighting how Resource Size optimizations help with Transfer Size

Measuring Resource and Transfer Size

For measuring Resource and Transfer Size locally, I recommend utilizing the Chromium Network Tab and the the Chromium F12 Profiler Network Pane.

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.