Image for post
Image for post

Readymag Under the Hood: Faster Vertical Viewer Implementation

In December 2017 Readymag launched Faster Vertical Viewer, which enables smoother viewing experience for projects with fixed widgets and heavy animations. In this article Readymag Product Designer Eugene Petrov describes how we did it and what we achieved.

It all was easy first

In 2013 Readymag started out with a single Horizontal Viewer. A project utilizing this type of viewer presents a set of vertical pages between which the reader switches using navigation arrows on the left and on the right of the page. In a horizontal viewer project, each single page could also be scrolled vertically from top to bottom if it doesn’t fit the screen.

Image for post
Image for post
Pages in Horizontal Viewer

Then we introduced Fixed Widgets — they stick to a certain position in the browser window and do not move when the page is being scrolled. But when you move to another page, fixed widgets get out of view together with the previous page where they belong. For two-dimensional scrolling, it was enough to use widely supported ‘position: fixed’ CSS property.

Fixed Widget in Horizontal Viewer

Beyond the Horizontal Viewer

Problems arose when we started stacking pages on top of each other to present them in new Vertical Viewer.

Image for post
Image for post
Pages in Vertical Viewer

In this case, Fixed Widgets need to stay on screen while their page is being scrolled. But, they should get out of view when a new page appears — not from the side like in horizontal scroll projects, but from the bottom of the screen. The ‘position: fixed’ property couldn’t solve that task: elements are no longer unconditionally fixed along the height of the page (vertical axis) but have to check if there’s a new page coming and change their state accordingly from being fixed to being static.

To solve this issue we had to emulate ‘position: sticky’ with our own javascript implementation. The code moves pages vertically when the reader scrolls through them and moves Fixed Widgets together with their container.

Fixed Widget in Horizontal Viewer

The drawbacks inevitably surfaced with the recent updates in browsers. Since we implemented our own scroll behavior with javascript browsers were unable to predict the positioning of the elements and optimize the rendering process. Each content movement caused full window repaint: the process that demands higher memory and significantly increases CPU and GPU loads. In its turn, animations sometimes lagged during scroll because browsers didn’t fire the ‘onscroll’ event on every movement. It looked like skipped frames in an animation movie. Of all browsers, Safari was a total disaster: with each update, Apple made it less energy-consuming by severely limiting the available resources.

‘Position: sticky’ comes to light

Everything changed in March 2017 when all major desktop and mobile browsers finally added support for ‘position:sticky’ CSS property. Chrome was the last one to introduce it in version 61 on September 5, 2017. Since then the task to remove fixed elements from view along with their container became trivial.

Native support for ‘position:sticky’ means that developers no longer have to emulate this behavior via slow javascript. Browsers know best what content to request depending on the direction in which the page is being scrolled. Or unload from memory those page elements that are no longer visible on a screen. That especially makes value for mobile browsers: resources are scarce so this is the only way for them to be able to respond to commands even when the reader is viewing very long pages. And since Chrome 61 update most of the latest Android devices can not only display but also natively support our Vertical Viewer.

Faster Vertical Viewer: the principal changes

We saw this challenge as an opportunity to fundamentally rethink the implementation of the Viewer. The result is our new Faster Scroll Viewer — when switched on, the browser interprets the sequence of pages of which the project consists as a naturally tall HTML page body (as if pages follow the ‘flow’ in which all HTML elements appear on a page). This way our project with all its complicated logic looks as a conventional long web page like any other website.

This update enabled faster and smoother viewing performance, especially on pages with animated and fixed widgets.

Yet, there are a couple of minor cons. Firstly, when switched on, the Faster Scroll does not support the Slide-in transition. We left this option in the settings, but have to warn you that it uses the old implementation of the Viewer with all its drawbacks.

Secondly, ‘on scroll’ animated widgets — that move as visitors scroll — could lag in some browsers. That’s due to the reason we’ve described earlier: surprisingly, browsers cannot fire the ‘onscroll’ event simultaneously with the scroll. That essentially means that we can’t run the script that moves animates widgets on every scroll movement. It especially hurts when you are using ‘on scroll’ animations to lock a widget on a screen while the rest of the content is being scrolled. Luckily, there is a workaround: make your animated elements fixed. In this case, everything will look perfect.

Readymag has always strived to give the most advanced web technology in the hands of designers. You might get a sense it’s a tough approach (and it is indeed!) but creative freedom will always be our #1 priority.

Written by

The most elegant, simple and powerful web-tool for designing websites, presentations, portfolios and all kinds of digital publications.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store