Skip to main content
15.09

The new zenith-watches.com platform

Zenith-Watches-Paroles-d-expert

Zenith, the Swiss watchmaker founded in 1865 and today part of the LVMH group, asked us to set up their new digital e-commerce platform. With a desire to offer their online customers an innovative avant-garde experience, Zenith and WIDE collaborated on the development of this new digital showcase.

 

Going beyond a simple e-commerce website, we propose a focus on the architecture and WIDE's vision of this platform.

 

The Zenith site was previously powered by Magento1, without offering its visitors the possibility of purchasing on line. As you probably know, Magento1 has come to the end of its life cycle following the announcement that Adobe is ending its support. WIDE has thus accompanied the brand in its migration to Magento2 to enable them to achieve their new ambitions.

 

Our vision of e-commerce.

Today, constructing an e-commerce website is quite easy. Take any solution on the market, simply customise it through its back-office and you are ready to sell your products on line.

 

However, when you are an international company that is present in several countries with dedicated e-commerce teams, local marketing teams, a centralised CIO and specific market constraints, you can no longer operate in the same fashion and must envisage a platform that meets your business expectations and challenges.

 

With the evolution of the web and the never-ending innovations in the sector, WIDE has over the years proven its capacity to take into account all its clients' constraints and to respond to their needs in the most appropriate way every time.

 

An e-commerce website today is a sales channel in the same way as social media, boutiques and all the different points of contact of the brand ecosystem. Thus, it must interconnect with all the business components of the company:

 

  • PIM
  • DAM
  • CRM
  • ERP
  • Content platform
  • PSP
  • Marketing automation
  • IAM

and all the other systems...

 

Carrying this vision.

The technical architecture of the e-commerce platform must serve the brand and not the contrary. Why should you have to make functional, technical, business or editorial concessions due to your technical and technological choices?

Setting up an e-commerce site can be approached in 3 different ways:

  • An e-commerce-led platform: i.e. a classic e-commerce CMS, an all-in-one solution. Quick, efficient and robust, its set-up imposes a monolithic architecture within which any integration will be strongly linked to the chosen solution.
  • A DXP-led platform: quite similar to the previous solution, it offers you the possibility to expose your content supported by an e-commerce API. This solution enables you to power your digital brand vision via a single solution that is interconnected with the rest of your ecosystem but implies advanced knowledge of the chosen solution.
  • An API-oriented platform: interconnecting systems via a REST API, GraphQL or other while maintaining a vision oriented towards services or micro-services. This type of platform does not impose the choice of a global solution and enables you to quickly adapt your ecosystem to market evolutions.
Les-différentes-approches-des-plateformes-e-commerce

The different approaches of e-commerce platforms

 

Over the years, WIDE and its experts in the field have thus helped its clients deploy the best architecture for their needs.

 

 

Why compromise?

Zenith's image in the field of watchmaking is one of excellence and innovation. Its e-commerce platform must reflect that image.

It is by keeping this in mind that we have designed the new zenith-watches.com website.

The rules are simple:

  • An international e-commerce site that is a reference in its field
  • Rich content
  • A powerful platform that is interconnected with the brand's IT systems
  • A forward-looking platform that is open to innovation

By analysing all these points, we have opted for a decoupled architecture (API oriented), capable of fulfilling a key concept that has guided us throughout the creation of the platform: the separation of concerns.

 

The separation of concerns.

The principle of the separation of concerns is an IT concept that aims to isolate each component of the application to concentrate on the task it does best.

 

This approach enables the decompartmentalisation of the software architecture, in contrast to the monolithic architectures of the past.

 

By choosing an API-oriented approach, we guarantee an optimal platform that is capable of connecting the best solutions for Zenith according to its business needs. The e-commerce site thus becomes a rich and robust sales channel that is widely interconnected with all the systems of the brand and which responds to all issues because it remains open to the best solutions on the market.

 

The zenith-watches.com architecture  👷

 

l-architecture-découplée-pour-Zenith

 

The diagram above presents the key components of the decoupled architecture for Zenith:

 

  • An e-commerce solution: Magento2 and its API
  • A PIM, Easy Docmaker, which supplies the data produced to Magento
  • A CRM solution, Salesforce Sales Cloud, which provides boutique and customer data
  • A headless CMS: Prismic
  • A Progressive Web App (PWA): Vue Storefront
  • A CDN: Akamai

 

A DevOps approach

The production workflow used for the construction of the new Zenith website falls under WIDE's in-house quality process and the DevOps approach set up and implemented by all our technical teams:

 

The utilisation of Docker for local team use

  • Continuous integration via Gitlab
  • Deployment pipelines for automated quality control
  • Code quality audit (code review and SonarQube)
  • Code security audit (code review, SonarQube and Detectify)
  • Unit and functional testing
  • Automated performance audit (Sitespeed)
  • Build and continuous deployment within our Kubernetes cluster
  • Deployment in production of the generated images
  • Application monitoring and error reporting (Uptime robot, Sentry)

The Zenith project fits perfectly into our working process. Its decoupled architecture enables us to optimally separate the software components developed and thus optimise their performance and quality.

 

A special effort has been made for the integration of the GKE (Google Kubernetes Engine) into our workflow. Indeed, in partnership with the Zenith hosting teams, all the application components of the solution are deployed after building in our Gitlab pipelines for Zenith environments, in GKE. This container-oriented approach thus offers us maximum security, extensibility and flexibility.

 

The other components

The Zenith ecosystem also integrates business- and marketing-oriented tools (OneTrust, GTM, Google Maps, Google RecaptchaV3, ABTasty, etc.). It natively adapts to our architecture and thus enables pertinent management of the e-commerce activity:

  • Data
  • Retailers
  • Content customisation and recommendation
  • GDPR
  • Spam
  • Emailing

 

💡 The integration of these solutions can have great impact on the performance of the site. Work hand-in-hand with the partners to analyse the impact of their solution and find the best compromise for loading their tools (implementation of asynchronous loading, incorporation of their script on your CDN, the installation of dedicated and isolated JavaScript modules, etc.).

 

The content

Editorial content is a major component of brand strategy. Zenith is no exception to the rule, and its history, positioning and richness demands the deployment of a solution that enables it to efficiently highlight this.

 

While designing the architecture of the platform, we have striven to imagine a content management solution that is robust, modular and one that fully meets their needs.

 

Content as a Service

The obvious approach when you build an internet site, whether large or small, e-commerce or not, is to say:

 

I will deploy my site, based on an e-commerce solution or a classic CMS, and use its CMS component... and I will do the same thing for every new site.

 

By adopting this strategy, you come up against several major problems:

 

  • Can an e-commerce solution correctly and easily manage my editorial strategy?
  • Can my site distribute its content to the other digital touchpoints that I plan to deploy in the future (mobile applications, internal solutions, POS, e-learning, mini-sites, etc.)?
  • If I deploy a new site tomorrow, will I be dependent on another site that has no relation to the present one for my content?

The answer is 'no'.

 

A decoupled architecture enables you to easily adopt a position that is totally different with respect to your content and steer an editorial strategy that is much more transversal and centralised.

 

I deploy a content management service, in the same way as a PIM or a DAM, which I will expose via APIs and which will enable me to centralise and capitalise on a single content base... for all my digital touchpoints.

 

Today, content is the key. It serves:

 

  • brand image
  • brand vision
  • brand editorial governance
  • brand business performance
  • brand SEO strategy
  • the user experience

 

Prismic as brand content manager

WIDE and Zenith have deployed Prismic, an SaaS content management solution that is ideal to carry this decoupled vision.

Prismic does only two things, and it does them well: manage your content and distribute it. It presents a back-office that is complete, rich and totally modular according to your needs. You will find all the features necessary for an ideal contribution experience:

 

  • multilingual
  • multi-environment
  • previsualisation
  • planned content deployment
  • content batching
  • content versioning
  • instant search
  • webhooks
  • content statuses
  • and much more...

 

The other strength of Prismic lies in its modularity. You intuitively build the structure of your content with no constraints linked to the tool.

Modélisation-de-la-structure-des-contenus-sous-Prismic

Modelling content structure with Prismic

Its editor enables us to model the atomic and component-based approach.

GIF

Component contribution from the Prismic back-office

 

'Any page of the Zenith site can be enriched by editorial content.'

 

The CMS thus positioned in our ecosystem enables us to power rich content and to distribute it easily on our site via its JSON API or GraphQL. Another key feature of Prismic, 'integration fields' establish a link between editorial content and products.

 

By thus associating editorial content and trade via an internal connector, Zenith can easily offer its visitors a rich experience for all types of content on its site.

 

Connect the content to the site

 

WIDE has thus striven to develop a JavaScript module dedicated to Vue Storefront to transcribe this modular approach to the Zenith website.

Each Vue.js component is the technical translation of a CMS Prismic component, which is totally atomic and customisable, functioning on both the client and server side.

 

 

Capitalise on content

 

The deployment of Prismic thus falls within the CaaS (Content as a Service) vision favoured by WIDE. It perfectly integrates the decoupled architecture of the Zenith ecosystem and becomes a central point of the brand's editorial strategy.

 

In the future, the solution will feed all Zenith's digital touchpoints. It represents a major asset for the brand's governance strategy. Indeed, it applies to all types of sites or applications, all types of budget and represents a major asset for the control of your TCO (Total Cost of Ownership).

 

The Zenith website frontend

The new Zenith site is a digital project whose e-commerce solution is based on Magento2, a recognised solution with which WIDE has maintained a partnership for several years via its publisher, Adobe.

 

The Zenith decoupled architecture offers us multiple implementation solutions for the frontend component of the new site and leaves a large space for innovation.

 

Respecting brand expectations, our vision and our expertise, it was only natural that we should turn towards the Vue Storefront solution.

 

An e-commerce-oriented PWA: Vue Storefront

Vue Storefront is an open-source project based on the Vue.js frontend framework. It presents a headless and agnostic PWA (Progressive Web Application) capable of interfacing with any e-commerce backend.

 

Highly appreciated in the Magento and Vue.js community for its performance, Vue Storefront also fulfils all the functional needs related to the brand's digital e-commerce activities:

 

  • PWA (offline mode, push notifications, background synchronisation, installable on mobile devices as a mobile application, etc.)
  • an almost entire functional coverage for Magento2
  • a performance-oriented solution
  • natively managed server-side rendering (SSR)
  • a mobile-first approach
  • no limits to customisation and site design (user interface)

Behind these simple notions lies a complete solution that guarantees quality and performance for the exchange of data between the e-commerce backend and visitors. Vue Storefront is essentially based on 2 components:

 

  • a PWA application that is responsible for the site, its theme and dynamic requests to Magento (sessions, carts, stocks, etc.)
  • an API that serves as a gateway between the application, product catalogue data (via Elasticsearch) and the various external services to be interconnected.

 

Architecture-Vue-Storefront

 

Vue Storefront Architecture

 

Once the application is deployed, all that remains to be done is to devote efforts to the implementation of the Zenith theme and connectors towards the services involved in the architecture:

 

  • component-oriented implementation of the site design via Vue.js, HTML5 and CSS3
  • development of the modules for specific services (Prismic, wishlist, external checkout, store locator, ABTasty, Google RecaptchaV3, OneTrust, etc.)
  • development of specific API endpoints

Vue Storefront thus offers us a pertinent response to the problems related to frontend solutions. By offering both client-side and server-side (via VueSSR) rendering, it enables us to focus our efforts on the overall performance of the site.

 

Performance 🚀

If you ask web developers to define the notion of a powerful website, you will obtain as many answers as there are developers – the performance of a website is not limited to its technical quality.

 

Performance is the sum of its parts and that is how it must be considered when setting up a digital platform. Thanks to our global expertise, we maintain a transversal approach towards this subject. Technical performance involves SEO performance, which is in turn closely related to accessibility and environmental performance... All of which ultimately affect the performance of the Zenith business project.

 

As this is a technical presentation, we will focus here on several points of performance that have been treated in this project, especially concerning the frontend

 

Résultats-de-l-analyse-Lighthouse-sur-une-page-produit-Zenith

Results of the Lighthouse analysis of a Zenith product page

 

Key concepts

The architecture set up for the Zenith project is a decoupled architecture based on a powerful Vue.js frontend framework whose traffic depends on connected users.

Once the solution is set up, the latter enables us to work on the fundamental aspects of performance:

 

  • The rendering of HTML pages
  • Caching
  • User experience optimisation

 

Serve HTML pages quickly... very quickly.

Vue Storefront and the Zenith site are based on a universal application and thus present a number of key concepts in the search for performance:

 

 

  • You execute the JavaScript code not only on the client side but also on the server side. In this way, part of the work to generate the page is delegated to the Node JS backend, and the power of the visitor's terminal is no longer solicited for a large part of the rendering.
  • Vue.js enables us to adopt a modular and optimised component-oriented code architecture.
  • Webpack (and Yarn) are present for an optimised build: transpilation, HMR, optimisation of the generated code, Code splitting, PostCSS, etc.
  • An API gateway serves as a proxy layer between the frontend and backend of the architecture to avoid dependency on the response time of the e-commerce or other solutions while reinforcing security
  • Elasticsearch, a NoSQL database, responsible for rapidly sending static data (products, categories, attributes, reviews, etc.).
  • Redis for the optimisation and caching of the pages at the backend of the origin server.

These different key points have enabled us to build an application that is intrinsically optimised, but performance does not stop there.

 

Caching

If you are capable of rapidly generating dynamic pages, it is even more optimal to avoid regenerating what has already been done: the fastest request is one that does not solicit your server, whether for static assets or HTML pages.

 

The Zenith e-commerce site is an international website that must offer the same user experience worldwide.

 

 

There is where Akamai comes in…

Most websites use Akamai (or the other solutions on the market) as a CDN (Content Delivery Network) to cache their static asset files (images, videos, documents). It is good practice to adopt an aggressive cache policy for these files.

 

If you are capable of bringing static assets as close as possible to the visitor via the platform's server network, why not do the same for the HTML pages generated?

 

Configuring Akamai 'behaviours' for each user request enables you to dramatically accelerate the Time To First Byte of our application, regardless of the visitor's location in the world (on average, TTFB is 10 times lower with Akamai enabled). By caching the HTML pages on the CDN, the origin server is no longer loaded at each visit and your site is accelerated accordingly.

 

At the backend, all that remains to be done is to configure and sync the purge of this cache when updating content (e-commerce and editorial) via the installation of webhooks on Magento2 and Prismic.

 

Akamai thus enables you to approach your visitors by offering them the fastest server according to the http request. It also allows the management of HTTP redirects directly via its infrastructure (without a return trip to the origin server) and provides a range of instructions for the optimisation of rendering time.

 

The user experience

Once the content has been cached, the final stage in the performance optimisation strategy lies with the display strategy and the loading of the UI on the visitor side.

 

 

Performance metrics...

It is during this stage that we strive to follow the best practices taken into account in all performance benchmark tools (Lighthouse, PageSpeed, Dareboost, GTMetrix, Webpage Test, etc.).

 

At WIDE, the analysis phase is automated via our continuous integration tools. Gitlab enables us to build the Zenith project and systematically launch the analysis of the various environments deployed via a Sitespeed.io instance that enables us to carry out the real-time analysis of the results and to rapidly correct any problems.

 

Exemple-de-rapport-Sitespeed-pour-Zenith

Example of a Sitespeed report for Zenith

 

💡 Don't limit yourself to a single tool to understand the blocking points. Multiply the metrics, both on desktop and mobile devices to ensure greater clarity for the results.

 

... and optimise the experience

Building the Zenith site around a frontend framework like Vue.js offers you numerous opportunities for optimisation, in addition to classic optimisations. A selection:

 

Compression

A basic element of optimisation, Akamai enables us to compress the resources loaded by the visitor via Gzip. More specifically, the resource requested is compressed on the server side, transits through the network and is then decompressed on the client side, which considerably reduces the quantity of data to be loaded.

 

Minification of CSS and JavaScript files

When building in production, Webpack, the module bundler used in the project, enables us to execute 2 plugins in particular: TerserPlugin and Optimize CSS Assets Webpack Plugin. These recover the CSS and JavaScript resources generated and carry out a series of operations to reduce the quantity of code generated:

 

  • Grouping of CSS properties
  • Removal of useless spaces
  • Removal of comments in the code
  • Removal of console messages (console.log())

 

Lazy loading and code splitting of JavaScript components

As your application grows, the quantity of code generated increases and impacts the quantity of data that transits via the network.

 

This is where the concept of code splitting comes in. Thanks again to Webpack and modern frameworks (here Vue.js), you can split your code into several 'pieces' that you load according to their necessity for the page requested.

 

- Do you need to load the JavaScript code for the Store Locator page while you are on the home page?

- No! 😥

 

You can thus dramatically reduce the quantity of code necessary for the operation of your site and load on the fly the modules necessary to display your content, and this using Vue.js (it also works with the other frontend frameworks).

 

You can manage it at the application routing level but also at the component level:

 

💡 Use Chrome Devtool and its code coverage metrics module to understand and optimise the way that your JavaScript code is used and analyse your results with the Webpack Bundle Analyzer plugin.

Rapport-du-build-projet-réalisé-avec-le-plugin-Bundle-Analyzer

A project build report made using the Bundle Analyzer plugin

 

HTTP2, preconnect and preload resources

If you apply all these recommendations, you will have more files to load. Due to this, they will have to be loaded rapidly to avoid penalising the measured loading time for your application.

 

This is where HTTP2 comes to the rescue!

HTTP2 and the preconnect and preload instructions enable you to solve the DNS, establish TCP connections and terminate the TLS negotiation more quickly in the loading cascade of your page and its resources.

 

  • The preconnect attribute enables you to inform the browser that, if it has time between two priority loadings, it will be good to load the requested resource because it may be used later:

<link rel="preconnect" href="https://example.net/">

  • The preload attribute informs the browser of the fact that it must absolutely load the resource in priority:

<link rel="preload" href="user-later.js" as="script">

These preloading techniques enable the acceleration of page rendering time and fluidify future browsing experiences on the Zenith site.

 

As the site is based on a universal application, setting up these prioritisation rules was possible on the server side via Vue SSR and its rendering loop. The concept is simple:

 

  • I intercept the assets loaded (fonts, separate JavaScript files, separate CSS files, images, etc.)
  • I decide whether to preload them or not depending on my application configuration
  • I inject them into the <head/> tag of my pages

This is what is involved:

 

initial

and the result: 

resultat

Responsive images and lazy loading (image and video)

Your client's editorial team will ask you:

 

'Can you give me ALL the image sizes of ALL the components for ALL the pages that we have to contribute!'

 

The answer is simple:

'No !'

 

The perfect answer 😎 :

'Contribute the largest visuals possible, we'll take care of the rest!'

 

With the multiplication of terminals (mobile devices, tablets, desktop), resolutions, pixel densities and responsive design, it is not humanly possible to give the right answer...

 

However, solutions do exist today and this is where Akamai Image Manager comes into the scene. It intelligently optimises images and video by associating the most adapted quality, format and size for each terminal and browser.

 

What does that mean? Akamai is capable of providing you with a resized image on the fly, at a precise resolution, in the most optimised format for your browser, cache it and distribute it via its CDN… notably thanks to IMQuery.

A small example:

  • Suppose we take the following image, with a file size of 4MB because it is high resolution https://zenith-watches.com/img/defy.png
  • If I need to display it with a resolution of 800 pixels by 600 pixels, I can, thanks to Akamai IMQuery, generate it this way:

 

illustration

The image will be resized on demand, optimised for the best format accepted by the browser... and I can chain the transformations.

 

Once the image resizing on the fly feature is in place, two intimately related concepts come into play: 'responsive' images and ' lazy-loading'.

 

'The fastest image to load is the one you don't load.'

 

Thus, thanks to the two concepts mentioned above, JavaScript and HTML enable you to:

 

Provide the browser with data concerning the various dimensions of an image (srcset attribute)

Provide the browser with data concerning the size of the image depending on the screen dimensions (size attribute)

Inject the data only when the image must be visible on the visitor's screen (API Intersection Observer in JavaScript)

 

The implementation of a 'LazyImage' Vue.js component enables us to systematise this behaviour on the Zenith site and to further reduce the page loading time.

 

Here is an example of code generated when the image is visible on the user's screen:

 

 💡  For better SEO compatibility, do not leave the src attribute for your images empty, generate a low-quality image that is ultra-fast to load.

 

💡  You can apply the same concepts for videos (which is what we did), as the mechanism is the same. 😃

 

We have looked at several rendering optimisation 'techniques' used on the Zenith site. I have voluntarily not lingered on all of the points we worked on. I could have mentioned many others that we have given and will give special attention to:

 

  • font display
  • layout shifting
  • asynchronous loading of external scripts
  • WebGL script optimisation
  • CSS purging
  • environmental performance and GreenIT
  • and many more...

I have focused on the technical performance by presenting several important notions that have an impact on the quality of web developments today.

 

The subjects of accessibility and environmental performance of web applications are other fields that lie at the heart of our developments at WIDE today. These will be the subject of a specific focus very shortly. 😉

 

Conclusion… 😓

Setting up a decoupled architecture in the context of e-commerce projects has become standard today.

 

Once reserved for small sites, it has today become sufficiently mature and robust to be deployed within complex information systems.

 

The publishers of web solutions (Adobe, Salesforce, Acquia, Sitecore, etc.) have understood this and encourage brands to deploy themselves in this way.

 

Thanks to its service-oriented approach, it enables you as a brand to focus on the choice of the solution that suits you best without neglecting any department within your company and does not limit you to a costly all-in-one solution that is difficult to sustain over time.

 

As a global digital agency, it enables us to focus on the global performance of the ecosystems we deploy, whether it be from a business or technical point of view and opens even wider the doors towards innovation.

 

The Zenith site is a perfect illustration of this. What WIDE has deployed in close collaboration with the brand is simply a robust base that will enable us in the coming years to accompany the brand in its objectives of quality and innovation.

 

Find out more:

 

🚨 Go to the Zenith site for even more new features in the coming weeks.

We Create Continuous Relationship Experiences ! 

Let's meet up!