Delivering an ePaper might seem easy. Upload PDF, serve PDF to readers, done. While that might essentially be true, delivering a high-end reading experience isn’t as simple. We’re constantly battling a classic dilemma: Speed vs. quality.
Lately we’ve been reworking our Desktop Web Reader to ensure a flawless experience for readers. Not an easy task, as browsers are not all alike.
Background
One of the most significant features in the Visiolink platform, across all platforms, is the ability to render publications accurately and with high quality. A lot of time and effort goes into creating these publications, so we feel strongly about delivering a user experience that matches this.
Not too long ago, our main way of achieving this on desktop was using the Flash technology to render the native format SWF. This allowed us to present pages with great quality across all modern and legacy browsers.
However, at some point Flash started to become ill-favored among the browser vendors and the public in general, and the decision was made to shift to an HTML5-based platform.
While HTML5 is great for many things, cross-browser support is only slowly improving and will still make most web developers scream and curse in frustration from time to time.
The first implementation
One of our main issues when switching to the new platform was rendering the text as sharp and fast as we wanted it to be. We decided to use SVG for vector rendering. It allowed us to quickly generate pages while giving an automatic sharpness to the page, even when zoomed in. Unfortunately, when a page consists of more than 30,000 individual shapes on a page, most computers and browsers will still struggle with the shear amount of elements.Although loading would be reasonably fast in most browsers, adding the SVG to the page might be slow, and in many cases the performance after load would be choppy and unbearable.To give our users the best possible experience, a compromise had to be made, and we decided to trade a bit of that text sharpness for faster rendering times. This could be accomplished by switching to an image format instead, which has fast loading and rendering, but a blurry text.A performance test would then decide if the user’s computer specs and browser vendor would allow them to render the SVG, or if we should fall back to an image.At some point after launch we had a look at our browser demographics, and we realized that a sizeable amount of users would fall back to the image approach and not benefit from the sharp text at all. We decided to spend some time optimizing the text rendering and to explore alternative solutions.
The process
In order to make a qualified decision on which solution to choose, the first task was to establish what “good performance” actually means. Assuming that all acceptable solutions would have to be crisp and sharp in quality, we decided to focus our tests on two primary areas:
-
Time to load
-
On-screen performance after load
The first shows how long it takes to load a page and to display it on the screen. The second focuses on on-screen performance once the page has finished loading. While the first would be a simple timing test, the second was a little harder to quantify.The second task was to establish a test environment that would give us untainted and clear results in these focus areas, while still resembling a realistic environment.Over a number of weeks, several tests and prototypes were made in order to narrow down the amount of technologies to focus optimization on. Three different approaches ended up showing promise, and we decided to focus our efforts on these:
-
SVG
-
Image with the SVG as Data URI
-
HTML5 Canvas
Looking at our current user demographic, five browsers were relevant for this test, and all of them would have to pass our requirements:
-
Internet Explorer 11
-
Edge
-
Chrome
-
Firefox
-
Safari
The results
We ended up conducting two rounds of testing - one for each focus area we identified earlier.
The first round of testing focused on the time it would take a sample page to load. In all of our browsers we timed how long it took from when the page started to load to when it became visible on the screen.
Apart from a few extremes, all of the browsers performed well on SVG and Canvas loading. Much to our surprise, the aging IE11 performed extremely well with all 3 technologies. Firefox, Safari and Edge on the other hand showed some serious delays when using the image-based technology.
With those three outliers, the image-based technology was already off to a rough start.
The second round of testing focused on how well each browser performed after the page had finished loading. We tested how well the browsers were able to render the page, and if they had any serious delays or stuttering.
Three scores were given for the good (100), mediocre (66), and bad (33) performances.
The second test revealed a few really interesting points: Canvas was performing well on a majority of the browsers, and Safari was consistently scoring low on performance.
Another interesting point was that Internet Explorer 11 had one of the best performances when loading SVG files, but was one of the worst performers on the screen.
Wrapping up
At this point we had three different approaches, each with strengths and weaknesses and with extreme performance differences from browser to browser. Some browsers showed good results in the test, but performed poorly when integrated in the final product. Other browsers had great processing times, but slow on-screen performance.
Overall, the Canvas-based approach was shining through in both load time and on-screen performance, so the choice was fairly easy in the end. Our solution would be a combination of direct SVG rendering for Safari on Mac, and Canvas rendering on the other browsers.
The quest to improve performance never ends, as browsers and systems improve and new technologies emerge. We’ve come one step closer to giving our users the best possible reading experience, and hopefully one day there will be crisp text rendering and smooth performance in every browser.
