{"id":16055,"date":"2018-09-17T12:49:53","date_gmt":"2018-09-17T11:49:53","guid":{"rendered":"https:\/\/marvel7077.wpengine.com\/?p=16055"},"modified":"2020-11-12T12:48:33","modified_gmt":"2020-11-12T12:48:33","slug":"how-we-optimised-prototype-image-loading","status":"publish","type":"post","link":"https:\/\/marvelapp.com\/blog\/how-we-optimised-prototype-image-loading\/","title":{"rendered":"How We Optimised Prototype Image Loading"},"content":{"rendered":"

To build prototypes in Marvel<\/a>, all you need to do is import your designs. Whether they're low-fi wireframes you drew on paper or hi-fi prototypes you built in Sketch, you can add these as static images to a project and make them interactive by adding hotspots. These hotspots link together your designs to create a flow which in the end will feel like a real life website or app mock up. <\/p>\n

Historically, our prototype player used to load all images upfront, which works well with small prototypes, but worsens the user experience the bigger a prototype gets. Loading this way meant that despite opening a prototype and only going through the first few screens, all of the images would get downloaded at once, regardless of how many screens they viewed. <\/p>\n

We recently decided it's about time we optimised our image loading in the prototype viewer and rethink our current approach. In this blog post we'll explain how we've improved image loading since.<\/p>\n

Why loading all images upfront is not a great idea<\/h2>\n

There's a number of reasons why this doesn't work well. From a business perspective, the more images we need to serve to the browser, the more our bandwidth costs increase. But our pockets aren't the only ones getting hurt, downloading all the images is also costly for users. Accessing Marvel via mobile connection, having limited data, and having to download a few MBs of images every time you view a prototype adds up very quickly and is simply wasteful.<\/p>\n

And it's not just downloading images that gets costly, every image needs to be decoded and rendered by the browser, which can lead to wasted system resources.<\/p>\n

Along with those reasons to find a new solution, there is another bonus of optimising our image loading. In the past if you clicked a hotspot taking you to a new screen that is not close to the previous one, there is a good chance that the image would not have loaded yet. With our new approach, all of the images you might need in the immediate future get downloaded first.<\/p>\n

Graph to the rescue<\/h2>\n

All of our screens are stored as a graph, which we can use to our advantage. But what does that mean exactly? <\/p>\n

A graph is a data structure that represents relationships between the stored items.<\/span><\/p>\n

Graphs can be directed or undirected. Facebook relationships are a good example of undirected graph. You send a friend request to someone and once they accept, you become friends and it's both ways. Instagram on the other hand is an example of a directed graph. You can follow someone on there, but they don't have to follow you back for you to be able to see their posts.<\/p>\n

How does this apply to our screens?<\/h2>\n

In order to improve image loading, we decided to utilise a concept called breadth-first-search. Breadth-first-search can be simply illustrated by different approaches to acquiring new skills - some people learn as much as they can about a certain subject before they move on to another, whereas others like to cover as broad spectrum of different skills going on at the same time as possible. The latter approach is an analogy for breadth-first-search. <\/p>\n

In context of loading our screens, this works as follows:<\/p>\n