Checkout performance

Many shipping rate apps aggregate rates for multiple shipping carriers so they can offer users rate shopping functionality. To increase performance, you should limit or eliminate external calls to carriers to retrieve these rates.

If carrier retail rates are stable, then you can store them internally to avoid external calls. For carrier rates that are dynamic or user-specific, consider caching.

For carrier rates that are dynamic or user-specific, consider building a caching layer for carrier rates.

While not every call to a given carrier will result in the same response, you can identify common response patterns and, based on the pattern, define a cache key.

For example, if a carrier responds with identical shipping rates for a specific origin postal code, destination postal code, and total weight, you can create a matching cache pattern and key:

Your implementation might look like the following:

1. Analyze external call response data, and identify any patterns across various use cases.
2. Store responses for similar requests in a memory database, such as Redis, so that the cache can be retrieved quickly when new requests come in.
3. When requests hit the cache, consider making an external request in the background to validate the accuracy of the cache, and update it with new information if required.
4. Analyze your cache hit and miss ratio, and the frequency of response changes for the same requests.

If calls to external systems such as carriers can't be avoided, and you're fetching rates from multiple external systems, then you should make calls to external systems in parallel to reduce the overall response time.

When you parallelize calls, your app’s response time will be at least as long as the slowest response time. To avoid a timeout, and to avoid blocking the Shopify checkout, you should set an internal timeout that cancels your request to the external system if it fails to respond. You can then return a subset of shipping rates to Shopify so the customer can proceed with checkout.

Part of your overall response time is latency between your app server and Shopify servers.

The impact of latency varies between regions. Shopify servers are hosted on Google Cloud. Different levels of latency apply by region. To learn more, refer to the Google Cloud inter-region latency matrix.

You can use cURL to calculate your request and response time and understand the impact of hosting:

1. Create new file called curl-format.txt with the following content:

2. In a terminal, run the following command, where http://url/ is the address of one of the Shopify stores your application is installed on. The command returns timings for your request:

   Repeat this step with stores that are located in different regions.

If your connection time is significantly higher than the Google Cloud inter-region latency, then consider the following actions:

• Change your hosting provider to Google Cloud to take advantage of an optimized infrastructure.
• Move your application to a region closer to the majority of Shopify stores using your application.

To avoid blocking the checkout when a call to an external system times out or otherwise fails, you should implement backup rates for your shipping rate app. You should store these rates somewhere they can be quickly fetched when needed. These backup rates can act as an alternative to Shopify backup rates, when a user has them enabled. Implementing backup rates specific to your app leads to a better app user and customer experience, as rates are closer to those returned by your app.

Backup rates don't need to match external carrier rates exactly, but should be close enough to avoid significantly impacting profitability and conversion. To make your backup rates as accurate as possible, you can base them on historic rates that you've received from carriers.

You can implement backup rates using the following steps:

1. Define logic for your backup rates. For example, you might store one expensive and fast and one cheap and slow shipping rate for a given city or country, for a given weight range, or for a given size range.
2. Analyze the response data from external systems to determine the backup rates for each logical grouping.
3. Store the backup rates in an easily accessible datastore. The datastore should be able to return the rates quickly.

The following is an example set of backup rates for domestic orders in Canada. Rates differ based on order weight only.