Special design of software product

You need to spend a lot of time studying technology, even plunge into mathematics somewhere. Library Three.js is an excellent tool that allows you to abstract most of the low—level operations of working with WebGL.

You can use this technology for any project where you want to show objects in volume, complex animation, give the user the opportunity to interact with 3D or make an interesting behavior of a 3D model depending on what is happening on the site.

Special product special design

In relation to this site, there are three features that greatly influenced the timing of the project. By the way, if you’re interested, we made a video in which we revealed the five principles of creating websites not like everyone else. These are the main postulates of our studio, which we rely on when developing the design. There will be a link at the end of the article.

Non-standard layout

We create an individual grid for each project, which makes the sites look more interesting. This approach allows us to better take into account the features of the customer’s content and make the perception of information more effective.

In this case, the layout of objects is different on all pages, for this reason, the layout time has noticeably increased.

Lots of graphics plus video as a preloader

There are a little more images on the site than very much — I had to spend a lot of time optimizing them so that the site loaded in a more or less tolerable time. Regarding the video as a preloader: when the idea came to link the video to the loading state of the site, it seemed interesting and unusual, but at the implementation stage we realized that everything was not so simple here.

The video should be small in weight (it’s a preloader, after all), and should be played smoothly — after all, the user’s attention is focused on it when assets are loaded.

3D models

The most interesting part. We decided to make not just static images of products, but volumetric, more realistic bottles that respond to user actions. At this stage, a lot of time was spent studying the experience of other developers using GLTF models on the web, as well as optimizing them. 3D content is usually the most “heavy” part of the site for the browser (both in terms of loading and in terms of performance in runtime).

What difficulties did you face and how did you overcome them

We met the main difficulties on the layout of the site. Pavel Mazhuga, the front-end developer of the project, will tell you what was the matter.

1. “Heavy” bottles. When a designer hands you a model with a size of 25 megabytes (on average), the first reaction is horror. There should be 4 different models on the main page, not to mention smooth scrolling, lottie animations (svg animations exported from Adobe After Effects), and so on. 100 megabytes of 3D objects only? Not an option.

Chocolate, cinnamon, masala, vanilla. What flavor will you choose?

I was familiar with Google’s Draco 3D data compression/decompression technology, so my first thought was to use it. Due to it, I was able to reduce the volume of the model from 25 megabytes to 1.5 megabytes, which is very cool. But it wasn’t enough.

A little later I realized that the geometry of the model can be reused, and the materials of meshes (solid ready—made label objects) can be changed in JS. After removing textures from the model and implementing their loading in runtime, the loading speed has increased significantly and there is more flexibility — now you can create bottles with any labels without sacrificing performance.

The final size of the bottle now is 156 KB for a large bottle and 306 KB for a small one, plus the texture of the label. It turned out strangely that after compression, a small bottle came out heavier than a large one. Apparently, in the world of bottles, size does not matter…

Unfortunately, in the mobile version, we had to abandon 3D and replace models with pictures, since phones cheaper than forty thousand rubles began to “boil” when launching the site.

2. Storytelling on the main page. When scrolling through the pages on the site, something is constantly happening, and this “something” is tied to the scroll position. If the implementation is incorrect, guaranteed lags (because there are a lot of redraws in the browser). I decided to use a ready-made solution to implement this functionality.

At first everything was great, but then I came across the library’s flaws, and I struggled with them more than I took advantage of its advantages. As a result, I was able to contact the developers of the library, and they were able to finalize it. It was already possible to do more or less something with this, but in the future I will try not to use ready-made solutions.

3. Using lottie animations on the site. The fewer of them, the better if you want to maintain the performance of the site. When scrolling, the page is terribly frizily. When such animations worked, fps sank to 20. In order to maintain an adequate performance when scrolling the site, lottie animations are paused, and when scrolling ends, they are played again.

In order not to waste browser resources, animations that are outside the browser’s viewport (which are not currently visible to the user) are not played.