Page speed matters.

Anyone dealing with the Internet should have heard the term page speed in one way or another. But what is meant by that and why does it matter?

OpenHPI
8 min readNov 15, 2017

There is no clear definition of the term page speed but it can usually be understood as the time from sending the request to the server until the website is fully displayed on the client. This time includes two phases. After the server receives the request the back-end has to build the requested webpage. The next phase starts when the client receives the first byte (Time To First Byte). Only then the client browser can start rendering the front-end in all its HTML, CSS and JavaScript glory.

Sample page load statistics before optimization created by webpagetest.org based on location Sydney and a cable connection (5Mb/s). The page is interactive accessible and visible for the user behind the rose bar on 6.5 seconds. All images are loaded in 10 seconds.

So, in just a little bit more detail: as soon as the browser received the HTML document from the server it can start parsing and building the Document Object Model (DOM). Every occurrence of a script, link or style tag, that is not inline, can halt the parsing process to fetch and execute the corresponding resource. The browser tries to minimize the effect by opening a new thread, which speculatively downloads external resources, like images, scripts and CSS files. For the stylesheets it will also create a CSSOM, which in combination with the JavaScript and DOM, will enable the browser to recursively layout the page and finally paint it. All these steps might also be executed, while the user interacts with the web page.

Various online tools allow to analyze the pagespeed of a website. They not only allow to test the speed of the website from different locations on the globe, but also list recommendations on how to improve the performance of the front-end. Generally this includes minifying your code, using compression algorithms, deferring JavaScript, setting correct caching parameters, the use of a CDN for static files and optimizing the size of images.

  • www.webpagetest.org was our recommended testing tool for comparing worldwide connection tests and image analysis. The tool supports first- and second view comparison to control caching of a site.
  • gtmetrix.com can enhance having a performance overview over longer time periods.
  • with tools.keycdn.com you can check http/2 support of our webpage and find other tests for checking ssl encryption or performance.

Importance for customer satisfaction

Studies from Radware, a load balancing and cybersecurity service provider, looked in 2015 at the page speed of online shops and pointed out the importance for sales. More than half of the customers expect a load time of less than two seconds, otherwise they buy at a different shop. But only 14% of the shops delivered the content in less than three seconds. This shows a divergence between the expectations of the consumers and the web pages which are often quite complex and therefore take longer to load. Also, while the customers expect a fast performance the median time to interact is quite low with only 5.2 seconds from the 100 tested retail sites.

On the other hand the industry has already discovered that page speed is an important business factor. Providers like eBay or Walmart reduced the time to interact on their websites to less than three seconds, while in 2014 users had to wait more than five seconds before they could interact with their website.

One important reason for slow page speed is that over 40% of the tested pages do not use any kind of image optimization. Delivering huge image files over the internet increases the loading time significantly. Only 10% use good compression techniques, which allow the reduction of the size without degrading the quality of the image to an unacceptable level.

The patience of mobile users is limited. Studies from Gomez.com and Akamai.com say that in e-commerce one second longer of loading time leads to a decrease in sales of up to 7%. The majority is willing to wait 6 to 10 seconds for a website to load, after that they would close it. Only 16% of the participants of the study are expecting results in less than 5 seconds. This is based on the expectation that mobile load times are as fast as on the desktop or a little bit slower, which more than 40% of the participants were expecting.

The two studies show clearly that users expect fast responding websites. If a website is too slow, users abort it in the loading process and switch to another one to buy their products. A faster time to interact not only increases the satisfaction of the consumers but also increases the sales.

Importance of page speed for SEO

Since 2010 Google analyses the page speed as part of the providing of search results. In 2017 Google announced that for mobile rankings they use the speed of the mobile page to offer better results. Those two additions from Google put a spotlight on page load optimization. To allow users to improve the load times of their websites and optimize them for better usability Google published PageSpeed Tools which gives insights into possible problems.

Not only the ranking is influenced but also how often the page is crawled by Google. According to John Mueller, who works as webmaster at Google, pages with more than two seconds load time will be crawled less frequently.

The exact importance of loading time on the ranking in the search results is not clearly specified by Google. They consider it as one part of 200 factors which gives importance to load time improvement not as primary factor but as a baseline of search engine optimization.

Emerging markets

As Africa is a focal point for the openWHO platform, its peculiarities have a main importance. Because of the infrastructure, the digital revolution in Africa happens on mobile phones. In fact there are more people with a mobile phone than access to electricity. And with the ever decreasing cost of smartphones the internet is mainly accessed via mobile networks. These devices are also used for tasks that one would do on stationary desktops or laptops connected to a landline in developed regions like West Europe or North America.

In the first quarter of 2017 the penetration of mobile subscriptions already reached 81% of the population and mobile broadband subscriptions are expected to grow almost 3-fold between 2016 and 2022. As a result the larger part of the population will be connected via WCDMA/HSPA and LTE in the next 5 years according to Ericsson Mobility. Despite these promising numbers the majority currently has an EDGE/GSM connection, which equals to a maximum bandwidth of 220 kbit/s.

Therefore the main objective is to make services available and useable in these countries. Optimizing the page speed, by reducing the transmitted data and delivering static files via a Content Delivery Network is crucial to reach this goal.

Testing Scenario

For our platform openWHO we implemented some optimizations to improve the loading times worldwide to increase the first user experience. The optimizations are separated into two different steps: Images optimization and the use of a content delivery network (CDN).

Page analysis have shown that the page consists of two huge parts of data: images (969 KB) and javascript assets (660 KB).

As described in our article about our pichasso image crop and compression service we tested the use of media queries with correctly cropped images and stronger image compression. The simple result for the openWHO landing page returned that all images could be compressed with loosing a minimum of quality to ¾ of origin size to 255 KB over all images on the landing page. The resulting image data amount was finally reduced from 49% to only 20% of all asset data.

For pages with international interest we highly recommend the use of a CDN. We have executed tests from different locations around the world using webpagetest.org to compare loading times. Let’s go to the single steps until a page is displayed to a user and can answer user interactions:

  1. Connections establishment consists of resolving dns name, connection setup and in our case the ssl handshake. After that the initially requested html file has to be downloaded. But for that the file needs to be generated on server side. When the initial download starts we have reached the time to first byte (TTFB).
  2. A short TTFB and download time allows the browser to scan the downloaded file for further resources like javascript and css resources.
  3. Completing that the page can be rendered. Until that time the user will only see a white browser page. When the browser completes rendering the page, it will be possible to click onto links or start scrolling.
  4. Further resources like images will be loaded after rendering while the page content is already visible. Huge images may rearrange the displayed content if there are no size properties defined.
Results from Sydney after optimization: 2 seconds faster initial page load (first view). Assets are delivered using a Microsoft Azure CDN based on Akami. This supports HTTP/2 and delivers better compressed images. The whole site is getting loaded around 50% faster.

Our main system is running in Berlin, Germany. For our test setup we decided to take a more detailed look on our platform from the following locations:

  • Amsterdam, as a very close location
  • Sydney, as far away as possible
  • Los Angeles, far away too

The different locations show us very good, for which files the use of a CDN will improve loading times and reduce local traffic.

What can we read from the measurements? The index html page loading time will not change, because it’s not delivered through the CDN. But the loading time raises with higher physical distance.

The delivery time of assets depends on the location between the next CDN endpoint to our own resource server. While nothing changes if the closest CDN endpoint or the main resource server is used from Amsterdam, the physical distance to Sydney shows that a closer CDN endpoint can reduce loading time to less than 50% (for all assets).

While the parsing and execution time will not change either, we see finally the reduction of image data for approximately ¾ is reducing the loading time drastically, supported by the CDN use and compression applied as well.

Further optimizations could involve the reduction of javascript and moving the index html page to the CDN as well to reduce the initial procedure mentioned above in step 1 that finally only one connection is used for index html page, assets, and images.

We have seen that the initial page load time depends as most on the establishment of the connection. Secondly it is very important to get the page rendered as fast as possible and reduce the initially required assets for that. This time can be drastically improved if there is a close CDN endpoint available.

--

--