The seemingly unlimited amount of information on the internet and the constant improvement in technologies hint at infinite abundance. When designing an app or website it can appear tempting to consider the resources needed to make the app or site work not important. But when observing it becomes clear the internet has very finite resources, and so do the two edge devices: the server, and the client device. This is a post to encourage site owners and app builders to think about bandwidth optimization from the first day and continuously from that point.
Compression is used when serving media files like video, audio or images. You can think of compression options as those that keep the quality of the media intact or reduce its quality. Lossless compression allows you shrink the file size during transport from the server to the client device, and have it de-compressed by the device at the endpoint. This takes CPU power from the device, but the advantage is that quality is completely intact on a smaller file footprint. At the time of this writing the standard for video compression is the H.264 codec, and the industry is in the process of transitioning to H.265. H.264 is convenient, supported by most programs, and a normal computer takes about 3 minutes to encode a 1 minute video. Likewise, when playing most devices can read H.264 and decode it, that is, they can play it without issue. H.265 promises much better performance for an identical file size, and is going to drive a wider use of ultra high definition content, also called 4K content. However, H.265 will take much longer to encode using today’s computers. It will take the next generation of CPUs to encode it fast enough. It will also take much faster CPUs for the computers showing the content when encoded in H.265. When compressing bandwidth optimization has to be considered together with the resources needed to encode as well as decode.
Image format and scaling
Likewise some image formats enable superior compression. JPEG has traditionally been the format allowing the most flexibility in how much quality one would like to retain for a given image size. Now the next generation of bandwidth efficient media format is WebP. This allows for much smaller images to be sent over the network for the same quality index.
Depending on the device you are serving images to, make sure you enable srcset, which serves scaled images in the right size for the device screen consuming the content. It makes sense to serve a UHD format to a UHD monitor. It makes no sense to resize a UHD image to a smartphone screen. There is a big difference between responsive design that resizes images (bad) to responsive design that scales images.
Code minification and efficiency
When writing computer code it’s a common practice for programmers to leave some spacing for clarity, and some comments in line to keep notes of which code performs that function. For example in stylesheet css files there are often comments by section to make it easy to find which fonts are used for which part of the site. The same goes for other design elements or configuration files containing credentials. That code is commented out, so that it is not executed by the computer running the program:
* Authentication Unique Keys and Salts.
* Change these to different unique phrases!
You can see that in the case of configuration files what’s commented out can represent a significant percentage of the total code. However, this is only useful to the programmer looking at the source file. It’s not useful, and for the most part not visible to the end users. So if you have a million pageviews why send code that has no use to the million of pages and end users? This is where minification comes handy. You can find plugins or programs that help you minify code on your origin server. CloudFlare’s CDN also has a feature that strips spaces and commented out code to make it lighter, therefore making your site or app faster. By stripping it to the end users, all the comments remain in the source file. It’s all benefit.
Low definition is sometimes better
We’ve gone from desktop computers to laptops, and from laptops to mobile phones. Soon we will go from mobile phones to smartwatches. Compare the size of a watch with that of a computer monitor. It makes no sense to serve the same media file to both client devices. The problem with responsive sites is that there is an important distinction between an image that is resized for a small screen, and an image that is re-scaled. When resizing an image it is still the full size that is being served. So the bandwidth cost is the same. Beware of mobile solutions that look good on the surface, until you realize your mobile phone has to download the full size media file that is then, shrunk. You want it scaled. When the image is scaled correctly the user sees no difference on a small screen. Your users do see a huge benefit in page load time.
Two more reasons to optimize for bandwidth
With cloud computing, app resources that were bundled all together before are itemized. In old-style hosting you would pay a flat fee no matter whether you used fewer or more resources. In cloud computing like Amazon AWS, Google Cloud Platform, you pay for what you use. So the more bandwidth-intensive your site or app is, the more it’s going to cost you to power the service. If your product becomes popular your bandwidth bill will go up a lot. Having done the above optimizations, you will save money while at the same time make your site faster, and your users happy.
You’ll also benefit in search rankings. When running Google PageSpeed tests you will notice that Google explicitly tells you if your images are not scaled, if you are not using compression, and your score will be a factor of these. In other words, your site will likely rank higher in search results if you optimize for bandwidth.
Leave a Reply