Studio Job preview

02


Studio Job is an art and design collective with a unique style. Their request was a one of kind e-commerce platform that encapsulates their style.

Build in Amsterdam
2018

[02.01]

Because of de modularity of the design a server side rendered platform would not be able work. This is because users have access to five filters at the same time. This could get very heavy the server and very expensive for hosting.

For this reason we went with a universal React application. This gave us the strength to do the filtering of the items on the frontend and still get the SEO benefits from SSR(server side rendering) that you need in an e-commerce platform.

This combined with the fact that we use a custom API gateway, that caches our JSON responses from the CMS, makes for a super smooth experience even when a lot of visitors are using the platform.


[02.02]

Scroll,
Scroll,
Scroll

The homepage is an endless page where the visitor can browse through all the work Studio Job has ever made. Each block in the grid has their own interactions, styling and animations. For this to be able to work we need to manage the resources that we have carefully. This means not rendering the blocks that are out of sight and more importantly pausing the scripts that are attached to these blocks

By grouping the blocks in layouts a css grid could be constructed for the blocks to fit in. And when a layout is out if view with a certain margin we can destroy all the children without losing the dimensions of the grid itself.


[02.03]

This website features more assets then I can count. The dynamic content the client can fill offers them a wide selection of themes that they can use that come with default svg, fonts and colours. On top of this they can upload their own images to display their content. This gave for a bit of an issue on how the content should be maintained and handled.

The solution for the fonts and most svg was to synchronize them to a CDN directly from the repository. These can be optimized before the sync and they won’t change that often. The images from the client go through a bit more complexity. We generate a bunch of size and optimise each of these by stripping down the meta data and converting them to the webp format.

In the browser we only load an asset when it’s about to be in view. This gives the browser time to fetch in and the asset should be there when it actually comes in view. For browsers that support it there is a webp version and for Safari there is the jpg/png.