Network access for Shopify Functions gives your app specific control points to declare what information you want to request. Shopify handles the execution of the network operations.
This guide describes how to optimize your app for performance and resilience when configuring network access for Functions.
## Timeouts
Network requests have a maximum execution timeout. The permissible range is between 100ms and 2000ms.
You can configure the timeout value using the `HttpRequestPolicy` input of an `HttpRequest`:
Refer to [error management](#error-management) for details on how timeouts are communicated back to Functions.
## Request cache
Customers engage with Shopify multiple times throughout their checkout journey. In order to ensure a stable and efficient experience, Shopify has implemented a network cache layer.
The cache key comprises all of the HTTP request attributes (method, URL, headers, and body). Additionally, cache isolation is enforced between stores.
Successful responses are cached for up to 300 seconds. Connection errors and responses with 5xx and 429 status codes are cached for up to 30 seconds. Persistent connection errors may trigger a circuit breaker per host and port, lasting more than 20 seconds. Keep in mind that the provided values are subject to change.
Cache-Control headers are not honored.
### Increasing the cache hit rate
Because the request cache is shared across all checkout sessions within the same store, leveraging this caching mechanism can significantly enhance the checkout experience by reducing buyer wait times. Additionally, this approach helps alleviate the load on external servers, which improves server performance and optimizes resource utilization.
Requests that are broad in scope are particularly suited for this optimization strategy. We advice including only the necessary elements in the request. For example, omit customer-specific information like email addresses if they're unnecessary. Decrease the precision of data where feasible.
For example, when making external calls to retrieve pickup points based on delivery address coordinates, slightly reducing the precision of the latitude and longitude can be beneficial. This adjustment covers a broader grid area, allowing customers in close proximity to receive the same pickup points without the need for separate requests for each individual.
The following example demonstrates how to adjust the precision of latitude and longitude to three decimal places, effectively covering a substantial grid area. [Learn more](https://wiki.openstreetmap.org/wiki/Precision_of_coordinates).
This approach ensures that delivery addresses with coordinates such as `(45.4193479, -75.6965198)` and `(45.419534, -75.6967035)` generate identical requests, as demonstrated in the following example.
Consequently, customers at these locations will benefit from accessing the same cached response.
## Error management
During a network call, various issues can occur, including DNS errors, connection errors, SSL errors, gateway errors, encoding errors, and timeouts.
Shopify categorizes and repackages the various possible error paths. By design, a simplified view of the error is returned to the input query of the subsequent target.
An error is returned to the function as a `fetchResult: HttpResponse` with a `5xx` status code:
- **Encoding error**: `{ "status": 501, "body": "501 Encoding charset not supported. Use 'UTF-8' encoding." }`
- **Timeout error**: `{ "status": 504, "body": "504 Gateway Timeout" }`
- **Connection error**: `{ "status": 502, "body": "502 Bad Gateway (Connection Failed)" }`
- **SSL error**: `{ "status": 502, "body": "502 Bad Gateway (SSL Error)" }`
- **Compression error**: `{ "status": 502, "body": "502 Bad Gateway (Data Compression Error)" }`
- **Response size error**: `{ "status": 502, "body": "502 Bad Gateway (Headers and body exceed 100KB limit)" }`
You can configure the function to either apply a locally defined fallback or to throw an error, in which case the default platform fallback is applied.
## Network retry
To handle transient failures, Shopify has implemented an automated retry mechanism to manage network failures when they occur:
- If the failure is temporary and the retried call is successful, then the system recovers transparently.
- If the issue continues, then the error is [exposed to the function's subsequent target](#error-management).