Skip to content
Adobe Commerce Storefront Logo Adobe Commerce Storefront

Search is only available in production builds. Try building and previewing the site to test it out locally.
Production

Content requests overview

A content request is a page or data file your storefront delivers through Adobe Experience Manager (AEM). Adobe measures storefront usage in content requests, not page views. These counting rules apply to traffic through the Adobe-managed CDN.

Page views vs. content requests

Section titled “Page views vs. content requests”

When a shopper opens a page, the browser requests the page and supporting files. Only some of these requests count:

  • Page HTML: 1 content request.
  • Counted JSON data files: 0.2 each. These files can include an enrichment index, which lists additional content for product and category pages.

A product page on the aemshop.net demo storefront loads one HTML page and one JSON index file that counts, for a total of 1.2 content requests:

One product page view loads several requests. Two count toward content requests, the page HTML, 1 request that counts as 1 content request, and a JSON index file, 1 request divided by 5 for 0.2 content requests. They add up to 1.2 content requests. Four don't use your allowance and total 0 content requests, 4 HTML fragments ending in .plain.html, 6 placeholder JSON files, 6 Commerce API calls, and static assets such as images, CSS, and scripts.

How one view of the example product page adds up to about 1.2 content requests. HTML fragments, placeholder files, Commerce API calls, and static assets don't count.

Which requests count?

Section titled “Which requests count?”

Your storefront delivers pages through Edge Delivery Services, part of AEM, so AEM’s counting rules apply. These rules cover traffic through the Adobe-managed content delivery network (CDN).

Storefront visits arrive through the Adobe-managed CDN, and AEM checks each one. Six kinds of visits count. Shoppers count 1 per page, even with analytics blocked. Prerendered pages count 1 per page, once, whether or not the shopper opens them. Spreadsheets and indexes, such as banners, store lists, and blogs, count 0.2 per file. Unrecognized bots, such as AI agents and scripts, count 1 per page. Uptime monitors that send GET requests count 1 per check. Apps and feeds that read your data files count 0.2 per file. Four kinds don't count and use 0 of your allowance. Images, styles, and scripts, plus the navigation and footer. Well-known search, social, and AI crawlers. Health checks from monitors that send HEAD requests. Redirects and errors, such as 301 or 404.

AEM checks each storefront visit. Only the visits in the Counts column use your content request allowance.

Shopping actions and Commerce API calls

Section titled “Shopping actions and Commerce API calls”

Shopping actions that only send Commerce API calls don’t count. Examples include filtering products on a search or category page, adding to the cart on a product page, and placing an order on the checkout page. They send calls to Adobe Commerce, not AEM, and don’t load a new page. Any action that opens a new page counts, such as going from the cart to checkout. Hovering over a link can count too, if it prerenders the linked page.

A shopper visits four pages in order, a category page, a product page, the cart page, and the checkout page. Opening each page counts as a page view. On each page, the shopper then takes an action that uses 0 content requests, filtering products, adding to the cart, updating the cart, and placing an order. These actions send Commerce API calls to Adobe Commerce, which use 0 content requests.

Opening each page, including the cart and checkout pages, counts as a page view. Shopping actions on each page send Commerce API calls to Adobe Commerce, which don't count.

Prerendered pages

Section titled “Prerendered pages”

A prerendered page is one that is loaded in advance, before the shopper actually opens it. This technique improves perceived performance when navigating between pages, because the content is ready the moment it’s requested. To make that possible, the storefront asks browsers to load linked pages ahead of time, for example, when the pointer rests on a product link.

Calculating prerendered content requests

Section titled “Calculating prerendered content requests”

A shopper opens a category page, hovers over products A and B, and then opens B. Both prerenders finish, and each uses 1.2 content requests. Opening B uses its prerendered copy, so only A adds content requests.

A four-step shopper journey. Step 1, the shopper opens a category page, a regular page view. Step 2, the shopper hovers over product A, which is prerendered, never opened, and uses 1.2 content requests. Step 3, the shopper hovers over product B, which is prerendered and uses 1.2. Step 4, the shopper opens product B, and the browser uses the prerendered copy, which adds 0. Product B totals 1.2 plus 0, which equals 1.2, the same as a normal page view. Product A's prerender adds 1.2 extra content requests.

Prerendering product B costs the same as a normal page view of B. Product A's unopened prerender is the extra cost.
  • Counted once: Product B was prerendered and then opened, so it costs the same as a normal page view.
  • Extra cost: Product A was never seen, but its prerender adds 1.2 content requests.
  • Not a forecast: This short example shows the counting rule. To estimate your storefront’s average, measure unopened prerendered pages.

Next steps

Section titled “Next steps”