In this article, I want to go over how amazon.com is optimizing their page load performance and how you can benefit from some of the strategies that they’re using.

Why amazon.com? As of writing this article, Amazon has a lighthouse score of 97 on performance. Also e-commerce websites are more sensitive to conversion and retention metrics so I thought this was a good example for other websites in the same domain.

Disclaimer: I do not work at amazon and am not aware of their internals, this is the information I gathered by auditing their website.

Why is performance important?

• Conversion and retention: Multiple studies have shown how bad page performance negatively affect conversion and retention rates. This is especially noticeable with users with older mobile phones.

• SEO: Google has started tracking Core web vitals metrics and penalizing websites that score poorly

• Caring about your users: Having a page that loads fast shows that you care about the user experience.

• Brand value: A website with a smooth experience that loads fast creates a perception of quality

• Environment: A page that loads fast consumes less resources (low energy consumption, support for older hardware, less server cost).

The methodology

I use Google Chrome dev tools for everything I’m demonstrating in this article. I’ll go over techniques to optimize for the following metrics:

• Time to first byte (TTFB)

• First contentful paint (FCP)

• Largest contentful paint (LCP)

• Cumulative Layout Shift (CLS)

Time to first byte (TTFB)

This is the time from when a user first requests a page (clicks on a link or types in the URL) to when the first byte of data returns to the browser from the server.

How to measure?

An easy way to do this is to go to the chrome network tab, click on the entry for the document (html) of the page and go to the timing tab.

Here you will see how much time was spent waiting for server response before the content started to download.

There could be other entries here as well like DNS lookup, initial connection, SSL, etc.

Strategies to reduce TTFB

Reducing TTFB is mostly a matter of getting your server to return the HTML document as fast as possible.

• Minimal amount of data calls

  For your server rendered HTML, keep the backend data calls as few as possible. You can render a skeleton of your page and fetch the rest of the data on the client side. We will dive deeper into progressive loading later

• Compression

  Use gzip or brotli for compressing your HTML so fewer bytes have to be transferred over the network. Your web server mostly supports this already, you would just have to enable this

  

  the response header of html would have Content-Encoding: gzip when compression is enabled

• Caching

  This would not apply to websites where the content changes frequently or is personalized per user. If your content remains stable for at least 10 minutes then there might be value for you in enabling caching at HTML level.

First contentful paint (FCP)

This is TTFB plus time taken until the first content (text, image, or non-white canvas or SVG) is rendered on the page. In this section we will focus on the time from TTFB until when the first content is rendered on the page.

Before we get into strategies on how to reduce FCP, it would help to familiarize ourselves on the critical rendering path. On a high level keep the following in mind:

• HTML document is processed and rendered in a streaming fashion. The content received is immediately displayed

• CSS and JS are render blocking resources (by default). When a browser encounters these, rendering is stopped until this resource is downloaded, parsed and executed.

• JS is parser blocking (by default). When a browser encounters JS, it parses and executes it and is not able to parse any other resource at the same time. Render is also blocked during this phase.

How to measure?

For this we would have to look at the Performance tab in chrome dev tools and manually look at the frames section.

1. In performance tool hit the “Record and reload” button on top.

2. Make sure you enable screenshots

3. You can open the frames section and you can select the frame you consider to be the FCP for your users

4. In the summary section at the bottom you can see the frame and the time it took to show it (in Amazon’s case it is 583ms)

Strategies to reduce FCP

• Resource hints

  Add dns-prefetch for resources on cross domain resources (css, fonts, analytics api). You can also explore other resource hints like preconnect, preload and prefetch

  

  you can see here that dns-prefetch is being used at the beginning of the document before loading resources from those domains

• Lean head tag

  The content usually would live in the <body> section of the page. The <head> section should only contain metadata, critical CSS and JS. Keep this as lean as possible. If you have a lot of CSS and JS here then it would block the rendering before content in <body> can be displayed.

• Server side rendering

  If you rely on content to be rendered only on client side then this the user will need to wait until the JS is downloaded, parsed and executed.

• Asset optimization

  By assets here I primarily mean JS and CSS. But you could also apply some of these strategies for fonts and images as well. There are a bunch of strategies here. I would just mention them at a high level without going into too much detail.

  • Leverage CDN for hosting

  • Caching your assets

  • Minification

  • Compression (gzip or brotli). In case of assets, do this at build time as opposed to runtime

  • Only loading the data you need (dead code elimination, remove unused css, etc)

How amazon uses CDN, compression and caching for its assets

• Progressive loading

  You can load a placeholder first and progressively load your page. Amazon first loads a skeleton of the page, then it progressively loads more frames.

  new

  • 

    we can see how amazon first loads a skeleton then proceeds to populate the contents of the page. (The video is taken from the frames section of the performance tab in dev tools.)

• Async and Defer attributes

  Use this to prevent non-critical javascript from blocking the rendering of the page. More details

  

Largest Contentful Paint (LCP)

LCP measures when the largest content element in the viewport becomes visible to the user. This metric is important because it represents when the main content of a page is likely visible to users, directly affecting their perception of site speed.

How to measure?

You can measure LCP in Chrome DevTools by looking at the Performance tab. The LCP is marked in the experience section, typically showing the largest image or text block on your page.

you can see how LCP < 0.58s here

Strategies to reduce LCP

• Prioritize above-the-fold content

  Ensure the largest content element (often hero images) loads as quickly as possible by optimizing and prioritizing it.

• Image optimization

  There are multiple strategies here:

  • Image size matching: display the image at its original size (so the browser doesn’t have to resize)

  • Use srcset attribute to fetch different resolutions for different devices

  • Use webp images else png since they’re more optimized for web

  • Compression: Tools like Squoosh and ImageOptim can help here

• Lazy loading

  Only load images that appear below the fold when the user scrolls down to them. Note that you should NOT lazy load LCP elements.

Cumulative Layout Shift (CLS)

This measures visual stability. It quantifies how much elements on a page unexpectedly shift during loading, which can lead to a frustrating user experience when content moves just as users try to interact with it.

How to measure?

CLS can be measured in Chrome DevTools under the Performance tab.

You can explore layout shifts in the experience section.

Strategies to reduce CLS

• Reserve space for dynamic content

  Amazon pre-allocates space for images, ads, and other dynamic elements to prevent layout shifts as these elements load.

• Use width and height attributes

  Always specify dimensions for images, videos, and other media to help the browser allocate the correct amount of space before they load.

• Avoid inserting content above existing content

  Place new elements at the bottom of the viewport instead of pushing existing content down, which creates disruptive layout shifts.

Final thoughts

Help make web leaner and better. Using the above techniques, you should strive for these targets:

• TTFB <0.8s

• FCP <1.8s

• LCP <2.5s

• CLS <0.1

I also offer a Performance Optimization service. If you’re interested you can contact me here.