Business requires fast software delivery. This sometimes leads to a situation in which developers are focused less on performance and more on business requirements. The problem is that badly designed architecture can unable to fix performance in the future. Many times I have explained that page with a total weight of about 2 MB is too large. I  have explained that server side has a limited bandwidth. For 1Gb/s connection speed at server side you can handle about 50 concurrent users in the same time to show them full content in 1 second. I also tell my colleagues that we have to reduce number of requests. Each request not only consumes browser connection pool limit, but also server resources. When clients are located far from our server, pages can load very slowly. When I was on Galapagos I realized (again) how slow can a network connection be and how important wise web design is.

Let’s see how it worked on Galapagos. In a hostel in which I stayed, internet was based on satellites connections or something similar (its my deduction based on ping response time and connection speed). Keep in mind that Galapagos is located about 1000 km from the South America continent. Ping responses oscillated around from about 500 milliseconds up to 2 seconds. Download speed oscillated about 16 KB per second. It was faster than the first modem connection I had 19 years ago, but it is too slow to load modern pages efficiently.

Ping response time

Let’s focus on ping response time first. The simplest scenario: single HTML page, JavaScript and CSS files. Browser needs 500 ms to receive an HTML file. Now in parallel it can ask about CSS and JS. One second is required to wait for that content only. I am still not focused on bandwidth. Now, let’s be honest how many pages on production are not using bundling? If you have 6 to 10 Java Script files (frameworks plus custom libraries), you have to wait a few seconds for these files only. If you have switched off caching or you have set up server side cache only, it means that the browser actually waits for nothing. Remember that HTTP response 304 requires about 500 ms anyway to ask server, because the browser has to ask about content modification, so it is similar like ping response time (on Galapagos). Browser is waiting because of light speed limit plus extra “tax” for electronic devices delay.

Too many requests

Do you bundle your images? If you are not using fonts or sprites, browser wastes again many seconds to ask for all images. Remember that a request to a server with response 304 still requires 500 ms each. Even with parallelism you are waiting. One of the internet banks I am using generated more than 70 independent requests for the logon page! Modern browsers are using about 6 connections in parallel. It means that this page wasted about 12 seconds waiting for response (first bytes of response 😉 ) – and nobody can give me back this wasted time.


Now let’s focus on throughput (on Galapagos 16KB/s). If e.g. a logon page loads all not currently required Java Scripts, you are wasting next seconds for your initial page. Frameworks’ weights are about 300KB up to 2MB. Simple maths and you have from 18 seconds up to 2 minutes before your page is fully loaded. It means that user cannot use this page at all.


If you design a web application that should be used around world, you have to remember that sometimes your client can be in a region with very slow internet connection (like me 😉 ) or maybe some of your clients are located on the opposite side of the world. Remember that light requires about 1/7 second to go around the earth. Client should always have as good experience as possible using your application. You cannot accelerate the speed of light, but you can design your application so as it loads resources in smart way.

  • Logon or first loaded page should not load everything (e.g. all Java Scripts). Try to show first page as quickly as possible and then in the background load remaining resources. It enhances the user experience.
  • Try to attach image ‘loading’ in initial page using base64 content. It allows you to save ping response time.
  • Use browser cache for static content. As a static content I mean CSS, Java Script and Images. If your Java Scripts or images are modified just introduce versioning. Trust me, browser cache speeds up your page loading a lot.
  • Analyze what is required and where it is required. Create bundles to be loaded independently. Send small parts with the first page to show something to the client ASAP.

I was disappointed when I had to wait about 2 minutes for bank logon page to appear. Next time you start a new web project, keep in mind that your client may not always be as close to the server as you are.

This is also a hint for the SQA team. You should measure number of requests and sent data size just to create some metrics for well designed applications.