3 front-end performance problems in current websites


"The future is ours to make—friendly.", says the Future Friendly manifesto, which points to the current and possible future state of the web and the quantity and diversity of connected devices. Of course, we are not able to test our websites on all possible devices, but we have workflows and techniques that help us to create future-friendlier websites.

Over the past several days, I have been reviewing tons of web projects and assessing their quality from a front-end implementation point of view. I was surprised by how frequently I found the same performance problems across all these web projects. In this article I would like to point out the most serious of them.

1. Carousels everywhere

I understand the need to attract a visitor's attention to great products or the company's strengths, but choosing carousels every time is a web design mistake.

This is because:

  • Users may not have time to read carousel slide content and having to switching between them requires interaction. Both may cause confusion or frustration.
  • Users are not getting all of your most important content if it's hidden in later carousels.
  • Carousels are JavaScript libraries; some requiring jQuery or other libraries to work properly, increasing the size of data needed to be downloaded and number of page requests.
  • Carousels almost always contain heavy images, also increasing the size of data to download and number of page requests.
  • Carousels are often not ready for use on mobile devices and usually don’t support touch gestures and responsive images, and even when they do, developers don't implement this functionality.

I’m not trying to get rid of carousels completely—do use them if you are sure it's the most suitable design for your project—but out of the reviewed websites I saw, two thirds had a carousel on their homepage… something’s not right about that.

2. Tons of data and page requests

I'm excited about the constant increase in the number of websites implementing responsive design. However it seems that developers only focus on fluid layouts and forget about data.

In many cases ensuring a fluid layout is done by simply setting display: none to html elements that are not to be displayed on small screens. But developers are forgetting data downloaded behind the curtain. I'm used to websites downloading several megabytes in 100’s of requests, whether for desktop or mobile device. This is despite the fact that websites displayed on mobile devices often have half the content of those displayed on desktops.

The solution for this problem is called "Conditional loading" in which you can request data from the server according to a particular condition e.g. screen size or technology supported by the device.

A real world example could be:
You don’t want the carousel on your homepage to display on small screens. To ensure this, you set up a JavaScript condition to ask the requesting device about its screen width. According to the answer, you can download the carousel JavaScript libraries and images or not.

You can also use the more complex solution; Modernizr and YepNope. Read more about conditional loading in Jeremy Keith's article.

The example below shows an implementation of the screen size condition for downloading a variety of images. It consists of a JavaSript function called in a Kentico CMS repeater transformation.

JS function:

function displayImg(imgSelector, mobileUrl, tabletUrl, desktopUrl) { var screenWidth = jQuery(window).width(); if (mobileUrl !== '' && screenWidth <= 480) { jQuery(imgSelector).attr('src', mobileUrl); } else if(tabletUrl !== '' && ((screenWidth < 768 && screenWidth > 480) || (mobileUrl === '' && screenWidth <= 480))) { jQuery(imgSelector).attr('src', tabletUrl); } else { jQuery(imgSelector).attr('src', desktopUrl); } }

Function call:

<img src="" id="image" /> <script type="text/javascript"> //<![CDATA[ displayImg('#image', <%# IfEmpty(Eval("mobileUrl"), "\'\'", "'"+ GetFileUrl("mobileUrl") +"'") %>, <%# IfEmpty(Eval("tabletUrl"), "\'\'", "'"+ GetFileUrl("tabletUrl") +"'") %>, <%# IfEmpty(Eval("desktopUrl"), "\'\'", "'"+ GetFileUrl("desktopUrl") +"'") %>); //]]> </script>

3. No minified or concatenated code

The third problem is the excessive use of JavaScript and CSS libraries linked to the website's head section. This again increases the size of data to download and number of page requests. If you want to use multiple libraries, I recommend you minify and concatenate them. This will reduce data and page requests and will serve your content faster.

Of course, you should consider which parts of your code are suitable for concatenation, as some should be left in separate files e.g. if part of your code is loaded conditionally. It may even be better to load it from a CDN. I’d recommend Grunt for this kind of task.

This article focuses on performance problems found in current websites that result in slow page load. With these simple tricks, we can reduce page load time, making ourselves, our clients and our users happier—success in the making.

Czech version of this article/Česká verze článku

Share this article on   LinkedIn Google+

Milan Kačurák

My intention is to give you practical information about web site development in Kentico. <a href="http://kacurak.com/">Find more information about me on my personal web site</a>.