Akamai Diversity

The Akamai Blog

Top Five Web Performance Pitfalls: How to prevent them

Every web site is unique, and each presents its own set of performance challenges and opportunities. These challenges can be exacerbated by perfectly reasonable business goals and site features, which can negatively affect the overall end-user experience. Business requirements (more features/ads), analytics (data beacons), time to market (we want it now), resources and cost constraints are all considerations that should be balanced with their effect on delivering a web experience that meets end-user expectations.
Akamai has experience helping thousands of customers make their web sites faster in order to help meet user expectations while helping companies meet their business objectives. We've identified some key performance recommendations, which have strong 'ROI', measured by the positive user experience impact balanced with effort and risk to implement.

To promote the industry's best practices, we strive in this post to educate the readers so they can take appropriate actions to avoid these issues altogether before a web site is launched in production.

Note: all screenshots below taken from www.webpagetest.org and the Akamai Luna Control Center.

Large image downloads

We've observed that for many devices, in particular devices with smaller display areas; many downloaded images can be significantly reduced in size without impacting the perceived quality. Additionally, some of them do not even show in the initial viewport, or 'above the fold'.

Pierre Blog Post  729 - Pic 1.png
To address this:

  • Use image size according to the device resolution and display size
  • On initial download, only fetch 'above the fold' images, getting other images thru 'lazy-loading' techniques
Long origin 'time to first byte'

Pierre Blog Post  729 - Pic 2.png
If the base html takes a long time to arrive at the browser, there is little your front-end team can do to make the application very responsive! While not always trivial to implement, the items below provide the best ROI to address this pitfall:

  • Apply caching at the application and database layers
  • Partition content and fetch likely-to-be-delayed pieces thru ajax from the client
  • Implement short timeouts for pieces of content fetched in the back end thru API to assemble the page. If timeouts are not met, substitute pieces with static content placeholders
Non-cached high traffic pages

Pierre Blog Post  729 - Pic 3.png
Pages are not cached when they (1) cannot be shared between users, (2) when they cannot be served with any staleness, or (3) when the request must hit the origin for tracking/business reasons, like page visibility.

  • To address the first reason, do not bake user specific information into the html, and fetch the user-specific information through ajax calls or by reading cookies thru js
  • For the second one, keep in mind that caching a page for even a few seconds/minutes can make user experience much better and reduce the origin offload
  • Tracking/business reasons can be addressed with 0 TTL or client beaconing
See more detailed information in this Akamai blog.

Third party content and blocking JavaScript

Third party content encompasses resources coming from third party hostnames, and includes analytics beacons, advertising images/videos and social scripts.

Collectively, they tend to slow down the page significantly, especially if they are not served through Akamai. Since you don't typically control their performance, you must ensure they provide valuable ROI to your organization, support some SLA and if they were to fail, would not jeopardize the entire rendering of your web pages (also known as "single point of failure" or SPOF).

Of particular concern is the third party JavaScript, as by default its execution blocks the fetching and rendering of subsequent resources.

Pierre Blog Post  729 - Pic 4.png
We recommend the following mitigations, broken down by use cases (they would also apply to first-party JS):

  • "Must have early on" type tags, like privacy notice or critical ads.
    • Make them 'async'. Note that onload event will not trigger until they are downloaded
  • "Not required for proper navigation" type tags, although they may need to be triggered independently from the onload event, to make sure all user behaviors are captured (e.g. analytics/tracking beacons)
    • Use 'async' with dedicated handling to prevent onload blocking
  • "Non essential for proper function" and not "analytics/tracking" type tags. E.g. Facebook and Twitter widgets, or any ad below the fold:
    • Place them at the bottom of the html body, or even better
    • Defer to after the onload event triggers, using a dedicated onload function

Client and Edge caching of static resources

While caching is a well-known and mature technology, our experience indicates that not all web sites fully maximize the caching opportunities offered by both the client (e.g. browser) or the CDN (e.g. edge server). Akamai provides guidelines in this 2-part blog.

Mobile specifics

The performance pitfalls mentioned above are applicable to all web clients. For mobile devices however, additional care must be taken to:

  • Limit the number of redirects (e.g. from www to mdot site), as the latency to establish every new connection can be high (up to 300 ms for 3G)
  • Minimize the amount of data to be processed on the client (js, images), as a limited processing power will degrade the speed at which the downloaded content is actually rendered on screen

To conclude, we hope that the advice above will help the readers maximize their application development resources to improve their sites' user experience.

I invite you to reach out to Akamai Professional Services if you have particular situations not addressed here, or if you'd like to understand how our web performance product offering can improve your websites.