Web performance: how Swish.com got 40% faster
Users do not like to wait. Study by study demonstrates that the speed of the site significantly affects visitors: for slow sites, visits are shorter, users browse pages less and even less often make purchases on slow sites. Every site owner should take its productivity seriously, as it significantly affects business results.
We are pleased to announce that it has become easier to test the performance of sites, thanks to the new F12 tools designed to find and fix related problems. In this case, we used the Modern.ie scanner and the UI profiler from the new F12 set in IE11. We showed these tools to the developers at the swish.com team to find out how a popular site can use them to optimize the performance of typical usage scenarios. The result - the site loading has become 2 seconds faster: a 40% increase in productivity thanks to several simple changes in the code.
')
It is important to note that the performance problems of the site, in most cases, manifested themselves in the same way in all browsers. Almost all modern browsers performed the same operations. Good tools for web developers just help find bottlenecks and improve overall performance. These improvements will help speed up the site in all browsers, not only in Internet Explorer.
Swish.com collects the most interesting pre-order items from Kickstarter, Indiegogo, Amazon, Outgrow.me, Dragon Innovation, and Crowd Supply, giving you the opportunity to see the most impressive technical innovations in one place.
Like many similar sites, swish.com uses both static elements and content downloaded via AJAX queries from the database. The result is displayed in a grid with large images of products.
The performance of swish.com at the start of the project was satisfactory, but we noticed a significant delay in the initial loading of the site. Our task was to find simple ways to optimize the site code, which would allow users to quickly move to search for products.
We started testing with the “User Interface Response” tab in the F12 tools of Internet Explorer 11. Below is the result we got before starting the optimization:
The “User Interface Response” tab is a new tool in the F12 suite, and it definitely deserves attention. The graphics in the upper part of the window shows all the activities that occur during the page loading. Color coding shows which tasks the CPU was used for: blue — file downloads, red — JavaScript, etc. The same colors are used in the diagram below.
You can select any part of the graph with the mouse to see which events took place at that moment. The selected area is highlighted in white, with the details displayed in the diagram below. The panel on the right serves to display additional information for each selected event.
From the graph it can be understood that when loading the site there are periods of very low activity (white gaps between the colored columns). This means that the page is waiting for content to arrive from the server. There are also some moments when the page is actively executing JavaScript and can not do anything other than that. We will try to use the knowledge of these two facts to optimize the page.
Many optimization options are associated with changing the order of loading files. See which files the page loads and in what order in the “Network” tab:
Typically, Internet Explorer caches files locally and tries to avoid wasting time requesting files from the server. For optimization purposes, of course, we need to simulate the situation when a user visits the site for the first time, and there are no files in the cache yet. To do this, click the “always update from server” button at the top of the window before you start recording. After that, you need to click on the "enable collection of network traffic" and refresh the page.
Tasks in the received network activity graph are also color coded: red - the time between creating a request and actually sending it, yellow - waiting from the moment the request is sent until the first byte of the result is received, and blue means the time to load the result.
Large white spans that are not occupied by any activities (for example, a space after loading load_templates.js) mean moments when the network is not actually used. They coincide with the spaces we saw above in the “User Interface Response” tab. Approaching these areas, we can understand exactly where optimization is possible.
The information we received from the IE11 developer tools is enough to create a site load optimization plan. What we saw on swish.com is also easy to find on many other sites, so the tips below can be widely used for optimization.
Most browsers, when loading a page, perform “speculative downloading” - the procedure for scanning HMTL code and searching for items that you can go to download immediately in order to maximize the connection capacity. The correct order of different file types, especially scripts and CSS, is extremely important to maximize download speeds. A good tip is to load external CSS files as early as possible, because the browser will not be able to correctly display the page without CSS. Javascript can wait.
In this case, the “Network” tab shows that on swish.com JavaScript is requested before CSS, before the scripts are needed to display the page. The request for the jquery.min.js and url.js files can be moved down to the closing tag. In the extreme case, external scripts can be at the end of the head section, but always after all the CSS.
Using Gzip to compress files containing mostly text (HTML, CSS, JavaScript) can significantly reduce their size and, therefore, speed up the download. If we select the HTML page and look in the “Details” tab of the “Network” tab, we will see that Gzip compression is not used (a page using compression will have a corresponding header). It turned out that Gzip compression was used earlier when the site was on a different server, but was not turned on after the move.
CSS styles can load other external CSS files using the @ ‍import directive. These nested style embeddings can dramatically decrease performance because they interfere with the browser’s ability to preload (prefetch) content. If the external style is specified directly in HTML, the browser can immediately send a request to download it, which will reduce the overall page load time. If the external style has the nested @ import directive, the browser cannot start loading it until the style itself is loaded and processed.
In our case, bootstrap.min.css has a nested @ ‍import directive that loads some fonts. In the record of network activity, we see that @ ‍import starts only after bootstrap.min.css is loaded, which causes a significant delay.
In this case, the @ ‍import directives were required solely for loading special fonts, so we decided to use built-in fonts instead. In the general case, the correct solution would be to transfer the link to the files directly into HTML or include the content directly into CSS.
In the footer template, we found a link to the script. The F12 tools make this easy to notice, as they show the sources of all requests in the network activity report. The source of this jquery-cookie.js request is XMLHttpRequest, which is unusual and significantly reduces performance.
We do not recommend using scripts in HTML templates. When jQuery processes scripts inside HTML, the scripts are executed immediately before control returns to the HTML insert script. In case the script is external, this results in a significant delay caused by waiting for the script to be received from the server. The situation is very similar to the problem with @ ‍import for CSS, described above, where additional levels of nesting lead to a delay in getting the content.
Solving the problem is also similar to the @ ‍import situation described above. Scripts must be inserted directly into the HTML file, so that the browser can preload them. If possible, you should also combine them and use compression to save network connection resources.
Third-party widgets and counters caused a significant part of the delays in downloading and executing the swish.com code. However, they are not required by the user at the initial stage of working with the site: it is unlikely that someone will want to share something on facebook or twitter - at least a few seconds should be required to read the page. The JavaScript profiler in IE11 showed that it was third-party code that was the main cause of CPU utilization, which delayed the entire page.
In the “Network” tab you can see that the Facebook and Google analytics scripts load even earlier than the page header and footer. We recommended downloading these scripts after a timeout of a few seconds after the main elements of the page are loaded.
Graphics can be a significant part of downloadable content, especially for a visually rich site like swish.com. Available online tools such as modern.ie or webpagetest.org help determine which images can be compressed. You can use tools similar to kraken.io in order to minimize the weight of images, without significant loss of quality. Before optimization, swish.com received images directly from the original source, and these images were not always optimized. Using optimized images from their own server, they were able to achieve much faster loading of the site.
The good news is that these problems were very easy to solve - almost all of them were fixed. Here is the record of network activity after optimization:
There are several ways to estimate page loading speed. Due to the complexity of modern websites, simple measurements, such as time to window.onload, can no longer be an objective indicator. The performance optimization guru, Steve Souders, explained the reasons and suggested more relevant metrics for measurement on his blog www.stevesouders.com/blog/2013/05/13/moving-beyond-window-onload
The website webpagetest.org allows you to see the storyboard video download site, which shows how the user sees it. We tried this tool to visually assess the download speed of swish.com before and after optimization.
Below is a storyboard of loading the page with a breakdown of 0.5 seconds. It is seen that the appearance of the skeleton of the page occurs after 3 seconds, and the whole page becomes visible only after 5.5 seconds of loading.
Our site optimization work, made using the Internet Explorer 11 developer tools, allows you to see the entire site and start using it in 3.5 seconds:
The updated developer tools in Internet Explorer 11 and the modern.ie scanner allow you to quickly and easily find and eliminate the bottlenecks that prevent the site from loading quickly. New analytic tools, such as the “ User Interface Response ” tab, allow you to see which particular aspects of performance have the most effect on page load and save time on their search. We managed to achieve a faster loading of the site for two seconds, and give users a faster interface right after entering the site.
We are pleased to announce that it has become easier to test the performance of sites, thanks to the new F12 tools designed to find and fix related problems. In this case, we used the Modern.ie scanner and the UI profiler from the new F12 set in IE11. We showed these tools to the developers at the swish.com team to find out how a popular site can use them to optimize the performance of typical usage scenarios. The result - the site loading has become 2 seconds faster: a 40% increase in productivity thanks to several simple changes in the code.
')
It is important to note that the performance problems of the site, in most cases, manifested themselves in the same way in all browsers. Almost all modern browsers performed the same operations. Good tools for web developers just help find bottlenecks and improve overall performance. These improvements will help speed up the site in all browsers, not only in Internet Explorer.
Here's how we did it.
Swish.com Analysis
Swish.com collects the most interesting pre-order items from Kickstarter, Indiegogo, Amazon, Outgrow.me, Dragon Innovation, and Crowd Supply, giving you the opportunity to see the most impressive technical innovations in one place.
Like many similar sites, swish.com uses both static elements and content downloaded via AJAX queries from the database. The result is displayed in a grid with large images of products.
The performance of swish.com at the start of the project was satisfactory, but we noticed a significant delay in the initial loading of the site. Our task was to find simple ways to optimize the site code, which would allow users to quickly move to search for products.
We look at the tab “User Interface Response”
We started testing with the “User Interface Response” tab in the F12 tools of Internet Explorer 11. Below is the result we got before starting the optimization:
The “User Interface Response” tab is a new tool in the F12 suite, and it definitely deserves attention. The graphics in the upper part of the window shows all the activities that occur during the page loading. Color coding shows which tasks the CPU was used for: blue — file downloads, red — JavaScript, etc. The same colors are used in the diagram below.
You can select any part of the graph with the mouse to see which events took place at that moment. The selected area is highlighted in white, with the details displayed in the diagram below. The panel on the right serves to display additional information for each selected event.
From the graph it can be understood that when loading the site there are periods of very low activity (white gaps between the colored columns). This means that the page is waiting for content to arrive from the server. There are also some moments when the page is actively executing JavaScript and can not do anything other than that. We will try to use the knowledge of these two facts to optimize the page.
Let's dig deeper: Network tab
Many optimization options are associated with changing the order of loading files. See which files the page loads and in what order in the “Network” tab:
Typically, Internet Explorer caches files locally and tries to avoid wasting time requesting files from the server. For optimization purposes, of course, we need to simulate the situation when a user visits the site for the first time, and there are no files in the cache yet. To do this, click the “always update from server” button at the top of the window before you start recording. After that, you need to click on the "enable collection of network traffic" and refresh the page.
Tasks in the received network activity graph are also color coded: red - the time between creating a request and actually sending it, yellow - waiting from the moment the request is sent until the first byte of the result is received, and blue means the time to load the result.
Large white spans that are not occupied by any activities (for example, a space after loading load_templates.js) mean moments when the network is not actually used. They coincide with the spaces we saw above in the “User Interface Response” tab. Approaching these areas, we can understand exactly where optimization is possible.
First results
The information we received from the IE11 developer tools is enough to create a site load optimization plan. What we saw on swish.com is also easy to find on many other sites, so the tips below can be widely used for optimization.
Download CSS first, then JavaScript
Most browsers, when loading a page, perform “speculative downloading” - the procedure for scanning HMTL code and searching for items that you can go to download immediately in order to maximize the connection capacity. The correct order of different file types, especially scripts and CSS, is extremely important to maximize download speeds. A good tip is to load external CSS files as early as possible, because the browser will not be able to correctly display the page without CSS. Javascript can wait.
In this case, the “Network” tab shows that on swish.com JavaScript is requested before CSS, before the scripts are needed to display the page. The request for the jquery.min.js and url.js files can be moved down to the closing tag. In the extreme case, external scripts can be at the end of the head section, but always after all the CSS.
Use Gzip to compress files.
Using Gzip to compress files containing mostly text (HTML, CSS, JavaScript) can significantly reduce their size and, therefore, speed up the download. If we select the HTML page and look in the “Details” tab of the “Network” tab, we will see that Gzip compression is not used (a page using compression will have a corresponding header). It turned out that Gzip compression was used earlier when the site was on a different server, but was not turned on after the move.
Consider using embedded fonts.
CSS styles can load other external CSS files using the @ ‍import directive. These nested style embeddings can dramatically decrease performance because they interfere with the browser’s ability to preload (prefetch) content. If the external style is specified directly in HTML, the browser can immediately send a request to download it, which will reduce the overall page load time. If the external style has the nested @ import directive, the browser cannot start loading it until the style itself is loaded and processed.
In our case, bootstrap.min.css has a nested @ ‍import directive that loads some fonts. In the record of network activity, we see that @ ‍import starts only after bootstrap.min.css is loaded, which causes a significant delay.
In this case, the @ ‍import directives were required solely for loading special fonts, so we decided to use built-in fonts instead. In the general case, the correct solution would be to transfer the link to the files directly into HTML or include the content directly into CSS.
Avoid scripts in templates
In the footer template, we found a link to the script. The F12 tools make this easy to notice, as they show the sources of all requests in the network activity report. The source of this jquery-cookie.js request is XMLHttpRequest, which is unusual and significantly reduces performance.
We do not recommend using scripts in HTML templates. When jQuery processes scripts inside HTML, the scripts are executed immediately before control returns to the HTML insert script. In case the script is external, this results in a significant delay caused by waiting for the script to be received from the server. The situation is very similar to the problem with @ ‍import for CSS, described above, where additional levels of nesting lead to a delay in getting the content.
Solving the problem is also similar to the @ ‍import situation described above. Scripts must be inserted directly into the HTML file, so that the browser can preload them. If possible, you should also combine them and use compression to save network connection resources.
Do not rush to download third-party code
Third-party widgets and counters caused a significant part of the delays in downloading and executing the swish.com code. However, they are not required by the user at the initial stage of working with the site: it is unlikely that someone will want to share something on facebook or twitter - at least a few seconds should be required to read the page. The JavaScript profiler in IE11 showed that it was third-party code that was the main cause of CPU utilization, which delayed the entire page.
In the “Network” tab you can see that the Facebook and Google analytics scripts load even earlier than the page header and footer. We recommended downloading these scripts after a timeout of a few seconds after the main elements of the page are loaded.
Squeeze pictures
Graphics can be a significant part of downloadable content, especially for a visually rich site like swish.com. Available online tools such as modern.ie or webpagetest.org help determine which images can be compressed. You can use tools similar to kraken.io in order to minimize the weight of images, without significant loss of quality. Before optimization, swish.com received images directly from the original source, and these images were not always optimized. Using optimized images from their own server, they were able to achieve much faster loading of the site.
The good news is that these problems were very easy to solve - almost all of them were fixed. Here is the record of network activity after optimization:
Before and after: what we won
There are several ways to estimate page loading speed. Due to the complexity of modern websites, simple measurements, such as time to window.onload, can no longer be an objective indicator. The performance optimization guru, Steve Souders, explained the reasons and suggested more relevant metrics for measurement on his blog www.stevesouders.com/blog/2013/05/13/moving-beyond-window-onload
The website webpagetest.org allows you to see the storyboard video download site, which shows how the user sees it. We tried this tool to visually assess the download speed of swish.com before and after optimization.
Below is a storyboard of loading the page with a breakdown of 0.5 seconds. It is seen that the appearance of the skeleton of the page occurs after 3 seconds, and the whole page becomes visible only after 5.5 seconds of loading.
Our site optimization work, made using the Internet Explorer 11 developer tools, allows you to see the entire site and start using it in 3.5 seconds:
Happy end
The updated developer tools in Internet Explorer 11 and the modern.ie scanner allow you to quickly and easily find and eliminate the bottlenecks that prevent the site from loading quickly. New analytic tools, such as the “ User Interface Response ” tab, allow you to see which particular aspects of performance have the most effect on page load and save time on their search. We managed to achieve a faster loading of the site for two seconds, and give users a faster interface right after entering the site.
Source: https://habr.com/ru/post/201108/
All Articles