Improve Storefront Performance: Updated Product Image Fetching using GraphQL Best Practices

Katie Hoesley
BigCommerce Developer Blog
4 min readApr 14, 2022

--

As you may have noticed, both GraphQL and the Stencil context have updated their default behavior surrounding requests for product images.

With this update, the BigCommerce API is now using GraphQL best practices, reducing query complexity and request time, which in turn improves performance. Now, when fetching images, only 10 will be returned by default. However, developers are able to override this new default behavior and request any number of images and specify pagination of those images if needed.

GraphQL Best Practices

Simply put, this update enables us to align with GraphQL’s best practices. A huge advantage of a GraphQL API versus a REST API is that you, the developer, are able to request specific information to be returned from an API call rather than receiving, without any sort of filtration, all relevant data.

It’s always better when using GraphQL to be explicit, rather than rely on the defaults to run. Why? Because when we’re calculating complexity, of which there is a limit, and sending a request whose return is a very large data set, your complexity score can be too high. To reduce your complexity, you can simply request more specific data, particularly if you’re requesting nested data. Being explicit safeguards you against inadvertently requesting too much data.

A great example is the description of products in the BigCommerce API. Product descriptions can be huge and extremely nested data sets, so it’s inefficient to return all of this data when you very likely do not want all of it. Instead, to align with GraphQL best practices, your request should be written to request the specific data that you need.

The biggest advantage of this update for developers is that the data being returned in your request’s response is data that you care about.

What’s Changing?

So, what exactly is the change?

The GraphQL Storefront API’s default behavior for the product.images node has been updated. It redefines this default behavior to return only 10 images, instead of returning all images associated with a product, which was the previous behavior.

Developers are able to override this new default behavior should they need to by providing the first argument explicitly with the request. Should you request larger amounts of data with increased page sizes, this will factor into the calculation of your GraphQL query complexity.

What Does This Look Like?

To illustrate this change, let’s first look at a GraphQL query request that would return the default number of responses, in this case 10 images:

graphql query that doesn’t include pagination or and override of the default number of images returned on a fetch

Now, say you need 35 images. In order to request this larger set of images, you would simply add the first argument with a value of 35. This informs the program that you will be overriding the default of 10 and will need your results paginated. So, that same request would now look like this:

graphql query that does include both pagination specification and an override of the default number of images returned on a fetch

Pagination

To implement pagination, node(id: productID) should be used to paginate the images beyond the default return quantity of 10. You would also want to get images.pageInfo element so you could use its endCursor element to update the value of the $cursor variable used in after:$cursor when hitting whatever button you instantiate to allow the user to see the next 10 available items.

Effect on the REST API

The number of images returned by the Featured Products, New Products, and Popular Products panel is changing to now return up to 10 images per product by default, instead of the previous default behavior which was to return all of the images on each product. For products in the store that have more than 10 images, this will improve storefront performance.

Should you be relying on accessing the data for a large number of images for each of these products, consider using a GraphQL query instead. GraphQL can be used to fetch additional data as frontend API calls, or can be embedded in Front matter to be utilized directly within the theme context via Handlebars.

Additional Resources

Want to learn more about GraphQL and Stencil? Find additional details and information in the BigCommerce Dev Center.

Are you using GraphQL and Stencil and see these changes in your BigCommerce store? Let us know in the comments how you’ve utilized this new capability and what you think!

--

--

Katie Hoesley
BigCommerce Developer Blog

Hi! I’m Katie - Senior Developer Advocate for BigCommerce & based in Colorado! 🤠🏔🥾👾?