Client Side Performance

Today is an era of web (www: World Wide Web) where everything is available on web.  Today every organisation uses web not only to provide services to their client but also running their own business functions online.  These days web is in very high demand due to its hassle free availability. The users are really concerned about responsive time of the websites. If any page takes more than 3 sec to load, it is regarded as slow and leads to a large impact on business.

When we say client side, it means it involves every thing involving client side activity. That means, when we do performance testing of an application based on its client activity, that is client side performance testing. Example : if you consider an web application, client side performance will include the time of server execution and client side browser rendering, JS/AJAX calling, socket responses, service data population etc.

Poorly optimized websites are plagued with a variety of issues including slow loading times, being non-mobile ready, browser incompatibilities, and so on. Ultimately all of these do account for customer satisfaction and product performance.

We need to optimize the web performance for our application .

What is web performance optimization?

Web performance optimization occurs by monitoring and analyzing the performance of your web application and identifying ways to improve it.

Web applications are a mixture of server-side and client-side code. Your application can have performance problems on either side and both need to be optimized.

The client side relates to performance as seen within the web browser. This includes initial page load time, downloading all of the resources, JavaScript that runs in the browser, and more.

The server side relates to how long it takes to run on the server to execute requests. Optimizing the performance on the server generally revolves around optimizing things like database queries and other application dependencies.

Optimizing client performance

Client performance typically revolves around reducing the overall size of web pages. This includes the size of the files and perhaps more importantly, the number of them.
Some of the best practices mentioned below can help us provide a better performing product to our customers and end users.

Content Delivery:

  1. We need to use CDN for assets on top of S3 – If there are any export control limitations i.e. security concern for the client data being available outside a region – We can restrict based on Geography and on specific path combinations.
  2. Once we have setup the CDN, we can go for at least 2 CDNs, depending on the number of resources being loaded from CDN.
  3. The assets uploaded in S3 bucket need to be configured with appropriate attributes during upload process. (I can provide a simple utility on those lines.)
  4. We need to ensure the S3 buckets mimic the assets structure in web application for the resources being part of web application. Any other resources can continue to reside in the existing structure.
  5. We need to implement CDN fallback mechanism while implementing CDN usage.
  6. The CDN paths need to be obtained from the configuration file to keep it dynamic and appended dynamically to the resources.
  7. Regarding CDN provider, we can use Amazon Cloudfront or Azure CDN.

JavaScript Usage:

  1. Try to load the JavaScript asynchronously wherever possible. You can use Async/Defer attributes for the same. This ensures that the HTML rendering is not blocked.
  2. As a suggestion, use async if your script is modular in nature and doesn’t rely on any other script(s).
  3. Use defer if the script relies upon another script or is relied upon by another one.
  4. Try to minimize the library dependencies to the maximum possible extent.
  5. Try to use CSS classes instead of JavaScript for any DOM animation.
  6. Add fallbacks for any scripts being used from 3rd party CDNs.

Compression Methodologies:

  1. We need to enable the compression methodologies like GZIP/Deflate on the server end. Most of the resources coming from CDN would be handled at the CDN end itself.
  2. For the content rendering directly from the server, the compression needs to be enabled at the server end.

Minification & Bundling:

  1. We need to ensure that we have bundled the multiple JS/CSS files. We should also create an image sprite for multiple small images.
  2. We can use WebPack or Gulp for the same which makes it little easier.
  3. We should also ensure that all the CSS/JS scripts are minified for lower load on the network.

Enabling Prefetch/Prerender/Preload:

  1. We should try and utilize the browser hints like prefetch, prerender, pre-resolve (DNS), preload, subresource to improve the performance and provide a much faster experience to end user.
  2. These browser hints should be leveraged as per the application scope. They tell the browser to load the resources/assets that are going to be used in future.

Image Optimization:

  1. We need to ensure that images are optimized without compromising on the quality of the images. We can use the free tools like tinypng or compresspng.
  2. Try to use SVG images or fonts instead of JPEG/PNG since they can be compressed using compression methodologies and scale well at large resolution.

Leverage Browser Cache:

  1. We need to ensure that we are leveraging the browser cache in an effective manner. The cache-control header’s max-age directive should be set on the static resources with appropriate time-range.
  2. Use no-cache and no-store effectively to ensure that the no stale data is being served to the clients for non-static resources.

HTTP/2 Protocol:

  1. We should ensure that we are able to leverage the benefits offered by HTTP/2 protocol. Have a look at the demo of performance comparison.
  2. Most of the CDNs by default are serving the content over HTTP/2 protocol.
     

https://developer.mozilla.org/en-US/docs/Web/API/PerformanceTiming

Client side performance metrics

We can measure different performance metrics :

Page Load Time

This metric indicates when the page was completely loaded and started to be interactive. It is fired when a resource and its dependent resources have finished loading.

Page Weight

This metric, also called “total requests.” is an accrual of all a site’s resource weights, measured in kilobytes or megabytes, including the HTML of the page itself. It’s useful for setting weight budgets on a site, which are easy to pass to developers and designers. It doesn’t always tell the whole story of performance, as performance often depends on how a page loads those requests.

Ref: https://mobiforge.com/research-analysis/understanding-web-page-weight

Speed Index

Speed index is a score for the visual completeness of the page above the fold (what’s visible to the user) over time. It uses video capture to calculate this score. Created by WebPagetest, it’s a score from 0 to infinity that maps approximately to milliseconds of time before the page is completely visible to the user. A lower score is better.

Ref: https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index

Time to First Byte

Time to first byte (TTFB) is a measurement used as an indication of the responsiveness of a web server or other network resource. TTFB measures the duration from the user or client making an HTTP request to the first byte of the page being received by the client’s browser.

Ref: https://www.maxcdn.com/one/visual-glossary/time-to-first-byte/

First Paint

This is the point at which pixels are first drawn on the scene. This metric excludes the default background paint, but does include any user-defined background paint.

First Contentful Paint

First Contentful Paint is triggered when any content (an object defined in the Document Object Model) is painted. This could be text, an image or canvas render.

First Meaningful Paint

First meaningful paint is a browser-supplied metric that measures how long it takes for the most meaningful content to be fully rendered on the site. It is equivalent to first-contentful-paint, and describes the duration until the browser first rendered any text, image (including background images), non-white canvas or SVG. This includes text with pending web fonts. This is the first moment when users could start consuming page content.

Ref: https://developers.google.com/web/tools/lighthouse/audits/first-meaningful-paint

Time to Interactive

The number of seconds from the time the navigation started until the layout is stabilized, web fonts are visible, and the page is responsive to user input. The page is stabilized if there was no task blocking for at least 50ms.

Ref: https://docs.google.com/document/d/1GGiI9-7KeY3TPqS3YT271upUVimo-XiL5mwWorDUD4c/edit#

DOM Content Loaded

The DOMContentLoaded event is fired when the initial HTML document has been completely loaded and parsed, without waiting for stylesheets, images, and subframes to finish loading. A very different event load should be used only to detect a fully-loaded page. It is a popular mistake to use load time as a performance metric, where DOMContentLoaded would be much more appropriate.

Ref: https://developer.mozilla.org/en-US/docs/Web/Events/DOMContentLoaded

Client Side Performance Tools

References:

https://www.altexsoft.com/blog/engineering/12-techniques-of-website-speed-optimization-performance-testing-and-improvement-practices/

https://devonblog.com/test-automation/client-side-performance-testing/

https://github.com/thedaviddias/Front-End-Performance-Checklist/blob/master/README.md

https://developers.google.com/web/fundamentals/performance/rail

https://www.w3.org/TR/navigation-timing/

https://www.slideshare.net/nicjansma/measuring-the-performance-of-single-page-applications

https://developer.mozilla.org/en-US/docs/Web/API/Navigation_timing_API

https://developer.mozilla.org/en-US/docs/Web/API/PerformanceTiming