Transporting containers of goods around the planet is the primary source of revenue for Maersk’s logistics business. With the COVID-19 pandemic fuelling a change in purchasing behaviour all around the world, it is critically important to Maersk’s customers that shipping those goods to their customers is an easy and reliable process.

As demand for container logistics has increased significantly, the reliability of our booking systems has not been perfect. One of our key measures of customer experience in the booking system is the time to retrieve schedules and prices and then display them to the customer. This metric has been increasing, with search times exceeding 30 seconds on average. This is a large amount of time to wait for search results and was not providing the constant care that our customers expect, a core value of Maersk.

In 2021, Maersk’s engineering teams modernised the customer-facing booking systems. The aim was to build a more scalable platform for the booking journey, reduce response times, and bring the user interface up to the standards of the rest of Maersk.com.
The work was split into two workstreams - re-building the user interface (UI) and modernising the APIs.

The new Maersk booking application
The new Maersk booking application
The outgoing Maersk booking application
The outgoing Maersk booking application

Re-creating the web application

The UI re-build had four goals at the outset of the project:

  • Bring the UI up to the Maersk.com platform standards
  • Improve consistency in the application
  • Improve the app's performance and resilience
  • Improve the Core Web Vitals of the app

Platform Standards

Modern web standards move at a fast pace - what was modern 5 years ago feels ancient compared to today's toolset. This was the case with the outgoing booking UI which was built on BackboneJS, and had many features that were cutting edge when it was created.

Maersk has also moved with the times and standardised on VueJS and web components as the ecosystem of choice for web applications. This change allowed us to make large gains in developer efficiency by using more modern JavaScript features, a more efficient build system, and to take a test-driven approach to creating our components. This approach and many other small changes resulted in direct changes to the customer experience in terms of performance and resilience of the application.

Application Consistency

Maersk’s design capability has matured significantly since the first instant booking application was launched in 2018. This capability produced the Maersk Design System to help the different applications on the platform to feel like they are one consistent experience. The design system also solves many basic styling and user experience (UX) problems for the applications – allowing us to focus on their own web app’s UX. It also keeps the applications up to date with the latest look and feel and helps makes the experience more consistent on our other carrier brands, such as Sealand Maersk.

Booking information Sealand
Booking Information Sealand

When we started the re-build, we looked for opportunities to improve the UX. There were several improvements that could make use of the Maersk Design System to help solve those problems. For example, finding the right entity to be part of the shipment can be awkward; with different search interfaces being used in the outgoing application depending on what kind of role that you were searching for. We created and standardised a “party finder” component that allowed us to have a search that worked consistently throughout the application.

Your Booking details

For many customers, booking container logistics is done on desktop computers in offices. We have seen an increase in people searching for bookings on mobile devices, and smaller screens. The new booking UI was designed with a mobile-first approach, so that the UI performs and looks just as good on small screens as it does on large ones. Whether a customer is on the move or has just moved the booking application to the side, it will work just as well as on a large monitor.

Performance and Resilience

All the above factors contributed to improved performance and resilience of the application. Using code and standards that were tried and tested by many groups across the company gave us the confidence to build these modern interfaces using the latest tools and techniques, focusing on the code that made booking itself complex and not on the complexities of basic components. This approach helped us to reduce the size of the UI codebase to 75% of the previous size, and the JavaScript bundle from 490KB to 190KB on first load.

Our platform standards allowed us to write better tests for the application code. In total, over 3000 unit tests run on every build to help us know when our changes affect other parts of the application. These tests are fast, taking less than 60 seconds to test the entire application. This, along with 500 end-to-end tests, allow for the team to test and release code faster, getting more features and fixes to our customers.

Core Web Vitals

For its performance goals, the team aimed to improve user experience of the system for our customers, and we measured this using the Core Web Vitals metrics. These metrics are used by Google as a search engine ranking signal, and as a proxy for the overall performance of a web application. Google gathers data on users experience from the Chrome browser and makes it available as the Chrome UX Report. The charts below show these metrics, along with a marker for the 75th percentile score for the application. Green means a “good” experience, amber “need improvement” and red is considered “poor”. This gives a reasonable overview of how the applications fared in the real world.

Starting with LCP (Largest Contentful Paint), the time taken for the largest part of a web page to be shown to the user, the new booking app is able to render larger parts of the page before some slower APIs have provided a response.

New Old booking LCP

The histogram above shows the distribution of LCP timings over a month for the new booking journey and the old booking journey. These histograms so that whilst the old journey has a grouping of very fast users (most likely bots), the largest part of its distribution is wide and has a long tail of users with slow experiences. New booking has a much narrower peak at good speeds, showing that most users receive a fast first page load.

Looking deeper into the stats, the results are excellent:

  • 47% faster LCP at the median – 1.7 seconds
  • LCP is 3.8s at the 75th percentile
  • 95th percentile LCP reduced by 6.3 seconds
  • the 95th percentile speed is faster than the old application’s 90th percentile speed

The Core Web Vitals are not just about first page load, Cumulative Layout Shift (CLS) measures how much content moves around on the page, and First Input Delay (FID) measures how quickly the application responds to user input. First, the good news, the field data on FID is excellent, showing that 98% of users have an input delay of under 100ms, and 75% of users having an input delay of 7 milliseconds.

The data on CLS is less positive. Whilst there has been an improvement compared to the outgoing booking application, layout shift is still poor for 80% of users. This is due to the page being rendered in two parts, the header and then the main application content. This single layout shift is large, though after this the page does not shift again. This produces an experience that is OK, but not great. We will continue to investigate solutions to this and aim to improve this metric over the coming releases.

These large performance gains and UX enhancements represent a step-change in booking experience for our customers. There are more optimisations to be made to the first page load time, which we are identifying as we get more data. These enhancements will be added to the application in future versions.

However, none of that would make much difference if the sailings that the customers are looking for can’t be found quickly.

A new architecture for the APIs

In parallel to the UI re-build, every API was modernised and moved out from our data centres and to the cloud. As mentioned earlier, search timing metrics had crept up to unacceptable levels and a new direction was required to enable the APIs to scale.

Maersk’s platform standards have changed in the API area as well, we have adopted a reactive, event-driven architecture. Core services generate events when something happens, such as a price is quoted, and customer-facing micro-services pick these up when they are ready and show it to the customer. This doesn’t consume resources or block the user experience whilst waiting for the events, and allows us to scale our services horizontally when under load. The diagram below shows how the user interfaces is composed as the data is delivered to the customer by different services at different times.

Select Sailing - Sealand
Diagram showing how event-driven systems orchestrate multiple services through the layers of micro-services to be reflected on the website in real-time.

This process also allowed us to re-visit when certain checks were being made in the user journey and how when they were shown to the customer. The key metric is to provide schedules and prices to the customer as soon as possible after they click on the first continue button. The team discovered a small number of requests that had been coupled in the previous APIs that could now be separated and composed in the UI, thanks to the event-driven architecture that is now in place. The video below shows the same search taking place on the outgoing and the new booking experience.

The new experience (left) takes around 11 seconds, with the old experience (right) taking almost double that amount of time.

The results in the real world are excellent – over thousands of searches the median time to show prices is down to 9.4 seconds, and searches take ~12 seconds for the 75th percentile.

This makes booking a container with Maersk a much less frustrating experience, with less time waiting for the results of a search, which means that our customers can perform more searches to find the transport that is best for them and their customer’s needs.

Maersk now has a highly scalable, resilient, and high-performing booking system that provides a better experience for our customers. This is just the beginning for the new booking platform, and we will be rolling out more features in the coming months.

A huge thank you to the technology teams at Maersk for their hard work and dedication to the project over the past year.

Learn more about software engineering at Maersk on our careers pages

Steve Workman
Steve Workman
Lead Engineer – Maersk.com

Anything you need, we’re here to help

解决方案

解决方案

我们满足从供应链一端到另一端的客户需求。
联系我们

联系我们

我们的专家团队随时为您服务。
查询价格

准备好运送货物?

查询航运及内陆运输费率。
Industry Insights

Sign up to our newsletter

To provide you with the right tools and the most relevant information for you to best manage your supply chain, please sign-up to our bi-weekly newsletter on global logistics.