Blog Post

Best practices for a fast performing banking website

Performance analysis of US Banking websites focusing on DNS response time, response time, page render time, web page response time, and more.

We recently wrote about the importance of conducting competitive web performance benchmarking to examine how your site compares to others. We identified five aspects to include in your analysis.

  • Page load time
  • Application availability
  • Webpage size and content
  • Third-party analysis
  • User engagement / transactions

We analyzed the performance of 26 firms in the US banking sector between March 1, 2017 and March 1, 2018 to see how they perform on various aspects of page load time.

Page load time is more than a single metric.   Browsers have to perform a DNS lookup, establish a TCP connection, wait for a response, parse the response and then they can start to render the page. Parsing the base HTML leads the browser to go through this some or all of this process to download the remaining elements on the page.

Let’s examine what makes a fast performing banking site.

DNS time

To begin with, let’s look at the time taken to load the base HTML page of these banking websites. Before the page loads, a DNS (Domain Name System) lookup occurs.

At Catchpoint, we believe fast DNS resolution is just as important as delivering fast content. DNS is what translates your familiar domain name (www.example.com) into an IP address your browser can use (93.184.216.34). This system is fundamental to the performance of your webpage.

Chart of DNS response times

DNS response time of the five fastest US Banking websites

The industry standard for DNS time is <=50ms. As highlighted in the above bar chart, we see good DNS time for

  • Wells Fargo (20ms)
  • Regions Bank (21ms)
  • Goldman Sachs (30ms)
  • Branch Banking & Trust (34ms)
  • Comerica Bank (52ms).

Exhibiting the slowest DNS response time:

  • Citibank (153ms)
  • TD Bank (155ms)
  • KeyBank (228ms)
  • HSBC Bank (238ms)
  • Sovereign Bank (260ms)

Outsourcing DNS to a third party is one method companies try to ensure fast, reliable DNS resolution, but it is not a guarantee. Four of the five banks with the fastest DNS resolution rely on Verisign for DNS services, while three of the five banks with the slowest resolution rely on Akamai.

Response time

At Catchpoint we compute response time as:

Response = DNS + Connect + SSL + Send + Wait + Load

For the base HTML, the industry standard for response time is <= 200 ms.

The following sites returned the fastest response times well within the industry standard:

  • Goldman Sachs (160ms)
  • Citigroup (163ms)
  • Branch Banking and Trust (172ms)
  • Comerica Bank (191ms)

Exceeding the industry standard with the slowest response times were:

  • KeyBank (758ms)
  • M and T Bank (835ms)
  • Citibank (887ms)
  • ING Bank (Voya) (984ms)
  • Wells Fargo Bank (1001ms)

When we see higher than normal response times a more in-depth analysis is needed to understand where the delays are occurring. Are there problems with the connection, SSL, or waiting for the response?

Bar chart of wait time and response time

Blue bar: Wait Time Orange bar: Response Time

For these banks, a slow wait time impacted the overall response time. Wait time is the delay between when the browser sends a request to a server and when it receives the first byte of response for the element. In this case the delay between requesting the base HTML page and receiving the response from the server.  Delays in wait time can indicate latency on the network or slowness with the back-end application and web servers.

Akamai CDN powers both the top fastest/slowest banks. In the case of the slowest brands, the slow wait time could be partly due to not enabling the base page caching. Without base page caching requests for the base page must be fetched from the origin servers rather than being delivered from the CDN.

Render start time

After receiving the first byte of data, the browser has to wait for the rest of the response to download and then parse the response to render the page.  As the browser parses the page, it identifies additional elements to download-JavaScript, style sheets, and images. Render start time shows us the time it took for the browser to draw the first visual content (in a pixel which is not black or white) on the page. Up to this point, users are staring at a blank page.

Bar chart of render start time

Render start time in ms

The recommended industry standard for render start time is 500 ms. Unfortunately, none of the banks highlighted above met the industry standard.

Among the mix, Comerica bank exhibited the fastest Render Start of 772 ms.

What made Comerica the fastest when it comes to render start time?

  • A faster response time of the base HTML page (192ms).
  • Fewer JavaScript files.
  • Fewer third-party elements.
  • Fewer elements loaded upfront during the initial page load.

The following sites all had a render start time of greater than two seconds. More than four times higher than the industry recommendation.

  • Citibank (2 secs)
  • ING Bank (Voya) (2.19 secs)
  • Sovereign Bank (2.40 secs)
  • SunTrust Bank (2.48 secs)
  • M and T Bank (3.55 secs)

What affected the render start time?

  • Slow response time of the base HTML pages.
  • A higher number of JavaScript files.
  • Latency introduced by the child requests.
  • Multiple requests loading before render start.

Document complete time

All of these metrics are useful, but what matters most to end users is when they can start interacting with the document.  Document complete is the time when the page was ready for user interaction or the time it takes from the URL request being issued to the browser triggering the “onload” event.

Bar chart of document complete response times

Document complete times in ms.

The industry standard for document complete is between two and three seconds.

The fastest performers were:

  • Comerica Bank (1.93 secs)
  • Regions Bank (2 secs)
  • Branch Banking and Trust (2.13 secs)
  • Wells Fargo Bank (2.67 secs)
  • Bank of America (2.85 secs).

What made them faster?

  • Faster response time for the base HTML page.
  • Fewer JavaScript files loaded before Document Complete.
  • Fewer items downloaded for the page.

The slowest performers were:

  • Citizens Bank (4.30 secs)
  • State Street Corp (4.32 secs)
  • TD Bank (5.13 secs)
  • Sovereign Bank (5.79 secs)

What made them slower?

  • Slower response times for the base HTML page.
  • More third party elements downloaded before document complete.
  • More JavaScript files downloaded before document complete.
  • More total items downloaded on the page.

Webpage response time

While the user may be able to interact with the page, there are still items downloading after the onload event fires. Webpage response measures the time taken by the browser to download all the elements on the page.

The industry standard for webpage response time is between three and four seconds.

The fastest performers were:

  • Branch Banking and Trust (2.27 secs)
  • Citigroup (2.62 secs)
  • Comerica Bank (3.02 secs)
  • Wells Fargo Bank (3.09 secs)

The slowest performers were:

  • PNC Financial Services (5.95 secs)
  • Citizens Bank (6.20 secs)
  • TD Bank (6.55 secs)
  • Sovereign Bank (7.50 secs)

The faster sites downloaded fewer than 60 elements. The slower sites downloaded more than 110 elements-the majority served from third parties. The more third-party hosts, the greater the number of  DNS lookups.

What does it take to be a fast performing banking site?

  • Choose the fastest DNS provider
  • Use a CDN
  • Reduce the number of third-party elements on your site
  • Reduce the number of JavaScript on your site
  • Reduce the total number of elements on your site
  • Minimize the number of JavaScript files that download before the onload event.
Synthetic Monitoring
Network Reachability
DNS
CDN
SLA Management
Financial Services
This is some text inside of a div block.

You might also like

Blog post

Traceroute InSession: A traceroute tool for modern networks

Blog post

Mastering IPM: Key Takeaways from our Best Practices Series

Blog post

DNS Security: Fortifying the Core of Internet Infrastructure