Front-end Performance – Where should we start?

In today’s web development the performance can be critical on both front-end and back-end side, but unfortunately, it is easy to forget about its importance.

In this article when we say performance, we don’t think about any severe parts but just the basics of it. This article is for those front-end developers whom a little bit neglect the efficiency of their code/site/app/product and want to start thinking a bit more critical about it, an essential and mostly gentle introduction into this vast field! At the end of the article, I hope you will know some useful info about this part of Front-end which you can build into your daily job!

Why Speed Matters on the Web?

Nowadays when the mobile devices are the most popular gadgets to access the web, so it isn’t tricky to imagine why the fastest site or app is the winner in a longer term. With mobile internet access your latency will be a lot more significant (correct that this technology evolves fast) than with a Wi-fi and to compensate this, you need a lightweight source.

Of course, the performance critical too on a simple site browsed on a desktop. We all heard Amazon’s study where they find that every second additional load time makes a notable loss in real money. To make your simply blog, shop or magazine the most competitive in this crowded market, you must spend on your speed!

The formula is straightforward; you need the lightest version of your app or site to make the most out of it, without this you start with a drawback.

We assume that Google checks the performance of our sites and also count into our ranking. Google also gives us the PageSpeed tool to review our overall performance.

Front-end, Back-end Speed, and Your Design

We have to keep in mind that the Front-end speed useless without a good back-end performance. You can have a profoundly optimized site which is weight less than 200 kb and lack of bloat, but if your server runs on a PHP 5.1, it is worthless.

I know this is an extreme example, but I’m sure you know what it meant. The performance, not a task at the end of your developing routine it is a never-ending process what is needed your all team.

And if we are here, your design team is also responsible for the performance too they make a much critical decision which has a high-performance load just like the large images in the sliders and so on.

How to Measure Your Project’s Speed?

We have a lot of great tools to check and find our end product’s performance bottlenecks; I’m mostly using the followings:

WebPagetest

WebPagetest is one of the most advanced performance analyzers which is freely available, and you can access a wide range of city, device, and browser. The territorial part is essential when your project is globally open because of your physical server place.

The report generated by it is detailed from the basic waterfall diagram to the loading phase video.

Pingdom Tools

Pingdom is a performance related company which offers this free tool to test your site. It gives back quite good results, and you can also customize the territory.

Yslow

YSlow is the most popular browser plugin for performance analyzing. It is like a swiss army knife which tells you almost everything like webpagetest.org but in your local environment.

PageSpeed Tools

This tool is made by Google and intent of it to give the site owners a view about their product’s performance. In my opinion, it is a less excellent tool for this purpose, but it can be useful.

What are my Static Resources?

The most basic optimizations are the ones which are touch your app static assets. Your end product is built by Images, Fonts, JavaScript, CSS, and HTML. These building blocks spoil your performance if you don’t pay attention to them.

The good news is that mostly you can quickly optimize them with some tooling or some third party application. The more exciting part is that a lot of developers forget that with a little effort they can make a significant impact to the performance.

Images

Usually, the most notable bloat on a web page is the various type of images this means not the pictures itself but the poorly chosen type, the wrong size and the lack of compression.

Content type comparsion on an avarage web page. Source

As you read above you can make three things:

  • Choose the correct image type. For a photo use JPG, for a simple image which contains just a few color – like an icon or an illustration – use PNG.
  • Crop your images to the correct size don’t let the browser to scale them. This part can be tricky because of the retina screens, but with the element you can handle it!
  • Compress your files as far as possible. For JPG you can merely use your graphics software export (set the compress to 60%-80%) and for PNG use a third party tool like TinyPNG!

Fonts

The web fonts not the most substantial part of a general site but it is simple to overuse and include a lot of unnecessary parts.

If you use Google Fonts, you can see that the app helps you determine the load time of your font stack. When you check more subsets ant weight or combine with other fonts, your loading time will grow.

When you choose fonts, try to include the most necessary parts. If you use icon fonts only include the ones which are needed, for this, you can use apps like Icomoon.

JavaScript

In this case, the overuse means the various plugins for your framework like jQuery. I know that in WordPress case it is hard to cut these expenses but it worth a try.

I know that when we develop the more natural path is to choose an existing solution, but we can write some own solution for a problem where it is possible. For example: for a simple modal or popup component can be written in some hours and we will be sure that there aren’t any part which is useless.

There are a lot of sites which can efficiently run on vanilla JavaScript so we can also drop our necessary frameworks.

For the end, there are two steps named concatenation and minifying. The first approach can be handy too on a site which runs on HTTP2 but the second is always necessary because the spaces and the understandable naming convention is just for us the browser doesn’t care.

CSS

In CSS case the most JS parts are valid. We should write our plugins if possible, and we should catenate and minify our files.

HTML

By the HTML I mean mostly our sites complexity. With the different Front-end frameworks like Bootstrap and Foundation we can fastly develop sites, but in a lot of case, its has a price structure complexity. Use Flexbox and Grid where it is possible!

Don’t forget that you can also minify your HTML!

Fine-tune your Back-end

Slightly this is Back-end part, but we can manage it from the Front-end part too. With a simple snippet, you can set Gzip or Deflate compression on your files and also set browser cashing headers!

Learning Material

This part is tricky! There are a lot of great expert and content which worth to follow and read! For a start I give you some:

Summary

I hope that now you can start to focus on the performance of your Front-end! Keep in mind that every project is different, so the choices always yours! This article was an elementary introduction in the future I’d like to write more accurate ones on this topic, but we need to start somewhere! 🙂