Full speed ahead for Maersk booking

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.

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.

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.

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.

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.

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 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