Congratulations, you have decided to go headless! You may have already read our Headless Commerce 101 Guide and are ready to get to work, but let's be sure you are fully prepared before you dive in.
Here at Nacelle, we’ve seen firsthand how impactful going headless can be—for example, our merchants see a 20% to 30% improvement in conversion rates on average. With that said, there are a number of things that, when overlooked, can become major pitfalls for your store.
We’ve compiled a list of the top five things we’ve seen cause issues for brands making the move to headless. Read on, and avoid these five mistakes as you embark on your headless journey.
1. Don’t put your store’s fate in the wrong hands
Web development is a very wide-ranging field. Not everyone who carries the title of “developer” has the same skillset or background. It’s important that you properly vet your development team for your build.
Doing headless commerce well requires some specific skills and experiences, enough time in the industry to have learned from one’s own trial-and-error, and gained knowledge from a breadth of projects that have been battle-tested in production. Here are some considerations that should help you find the right people for the job.
What is their level of frontend development experience? A good candidate should be an expert in your front-end framework of choice. You want to go in with your eyes wide open—it’s a lot of work to build an eCommerce store and you want to make sure your team has the right experience to achieve your vision and business goals for the build and beyond.
Do they have proven examples of past work? Ask for project examples (of live sites) and understand the candidate’s involvement in the finished product.
How do they work cross-functionally? A good developer will provide your team with a standardized approach to product and content editing that eliminates the need for them to be involved in every change. Your content editors should be able to make changes to your site without developer intervention.
Here’s the deal—third-party JavaScript is EVERYWHERE. If you are migrating to headless from an eCommerce platform, it's almost guaranteed that you are coming with 10 to 20 third-party apps in tow, in the form of script tags that are installed on your eCommerce site.
The benefit of these scripts is that they provide functionality quickly with very little development time. But they can come at a high cost to your customers—JavaScript file download time to get the scripts to load, and the execution time required to get them to run.
Most third-party JavaScript vendors will assure you that their code will not slow your site down. That may be true in isolation, but that’s not how your site works. Let’s use an analogy to explain this in greater detail.
Imagine your store is a backpack and every third-party script you load is a ten-pound brick. “Not too heavy,” says the brick manufacturer. One or two is doable. But ten? That’s 100 pounds. You can see how “not too heavy” becomes just too much for you (and your browser) to bear.
How can we solve this problem? The answer is two-fold. First, identify which vendors provide direct API access, and work with your development team to build direct integrations. This will bypass the need to load any extra JavaScript for that vendor, and opens up more possibilities for a much more cohesive experience for your customers as well.
Secondly, using a server-side event tracking system like Segment will allow you to send data to trackers like Facebook or Google Analytics without having to add vendor JavaScript for each tracker.
3. Don’t allow JavaScript bloat
Jamstack architecture is becoming more and more prevalent and we fully support the movement. The many benefits of static site generation are indisputable. However, using frameworks like Next and Nuxt still require JavaScript to run on your customer’s devices to enable the level of interactivity customers expect.
When your development team adds new features to your store, they may use publicly available packages from a platform such as Node Package Manager (NPM) to speed up development and avoid reinventing the wheel for certain aspects of the feature.
During the build process, your frontend framework will take all of the packages referenced in the store and will create a number of files, called “bundles.” The bundles will be referenced in your store’s code so it has access to them when customers visit. Just like with third-party scripts, package vendors vary in size, and the more you add, the more your customers’ devices will have to work to download all the files and run the code.
With that said, it is a good practice to establish a bundle-size budget and integrate tooling into your deployment process to enforce the budget. This article from web.dev explains this concept in more detail. Establishing a budget will help your team to be more mindful of the dependencies they add to the store, and may encourage them to find alternatives that are smaller but achieve the same outcome.
If there truly are no alternatives, one way to avoid heavy packages from slowing down your site is to create a small API via a serverless function to handle that specific functionality. This prevents the JavaScript from being loaded onto the customer’s device at all. You can read more about serverless functions on Netlify and Vercel.
4. Don’t use unoptimized images
It may not be obvious from all of the recommendations around improving JavaScript performance, but images far outweigh JavaScript in terms of sheer file size. A single unoptimized image asset, straight from the product photographer can be upwards of 5 megabytes in size. Whereas image loading may not necessarily block the browser from loading other parts of the page, slow image loading can drastically harm the perception of good performance of your site, especially if you use a lot of images in your design.
Thankfully all three of the most popular JavaScript frameworks commonly used for eCommerce store development (Gatsby, Next, and Nuxt) provide image optimization components. They vary in specifics but each component serves similar functions: controlling image dimensions and quality between screen sizes, and loading assets at the best possible time.
When it comes to the dimensions of images used, it is wasteful to serve a 2000-pixel image where a 300-pixel image would appear as the same “rendered size” due to CSS rules or device size. These image optimization components allow you to specify the exact dimensions, file format, and pixel density needed to serve the best image for a given device.
Both “nuxt/image” and “next/image” provide an additional benefit of initially loading your images from one source and hosting them on another (such as Netlify or Vercel’s CDNs).
Using one of these components will drastically improve the overall perception of performance for your eCommerce site, and we highly recommend using “nuxt/image,” “next/image” or “gatsby-plugin-image” depending on your framework of choice.
Google Lighthouse and Page Speed Insights are helpful tools for understanding your store’s performance on desktop and mobile. However, running them incorrectly can produce wildly different results.
According to Google, internet speed, the processing power of your device, Chrome extensions, and antivirus software can all adversely affect the accuracy of your testing. Read more in this great article on web.dev.
To get the most accurate results, use a service like SpeedCurve, or the Lighthouse plugins on Netlify and Vercel.
Go headless with Nacelle
At Nacelle, we’ve helped brands like Barefoot Dreams, Flex, and Lola go headless the right way. Our APIs, SDKs, and starter kits are built to create a headless foundation for your store that enables your team to grow and delight your customers for years to come.
Ready to see Nacelle in action? See a demo today.
