Skip to main content

Checkout performance guidelines

This chapter contains guidelines for improving the performance of the checkout process.

Taxes recalculation with custom taxes apps​

When taxes app is used to calculate taxes (CHECKOUT_CALCULATE_TAXES AND ORDER_CALCULATE_TAXES subscriptions are being used), the app is called every time taxes need to be recalculated.

You may see mutations like checkoutLineAdd or checkoutShippingMethodUpdate being slow, just like the queries that require prices affected by taxes (see TaxedMoney).

To improve checkout (or order - it can be used in the same way) performance, you can optimize your storefront to avoid recalculating taxes when possible.

Example patterns:

  • When calling checkoutLineAdd do not require entire checkout in the response. Check for errors and assume mutation succeeds if there are none.
  • If storefront doesn't show gross prices (they are calculated after shipping is provided), do not require gross price. Use net prices or catalog prices instead.

Optimistic UI​

For operations like changing line quantity, you may want to assume that the operation will succeed and update the UI immediately. You can leverage strategy called "optimistic updates" for that.

In the nutshell, storefront can calculate new price locally and update the UI immediately, while the real response will apply with a delay in the background.

Lazy vs eager recalculations​

Some mutations require price recalculations - such as changing lines quantity or adding a voucher. However, not every mutation behaves the same way.

With performance considerations, there are two strategies how mutations recalculate prices:

  • Eager: Mutation will call CHECKOUT_CALCULATE_TAXES / ORDER_CALCULATE_TAXES event during the mutation execution. That means mutation will run slower and the returned value will have latest updates prices values.
  • Lazy: Mutation will mark internal prices to be "dirty", but not call the webhook immediately. Webhook will be called once the value is requested afterward.

Eager mutations​

Following Order mutations are eager:

In case of Checkout mutations and not mentioned Order mutations - all of them are lazy.

Fields that cause taxes recalculations​

For lazy operations, only requesting certain fields will trigger prices recalculation (including synchronous webhook calls).

It takes at least one field to trigger recalculation.

These fields are (for Checkout & Order in Draft or Unconfirmed status)

  • total, subtotal & undiscountedTotal
  • undiscountedShippingPrice, shippingPrice & shippingTaxRate
  • discounts
  • lines total & undiscountedTotalPrice
  • lines unitPrice & undiscountedUnitPrice
  • lines taxRate
  • lines unitDiscount, unitDiscountValue, unitDiscountType