Before the overhaul, we had a long page that was vertically scroll heavy. We liked this approach because it gives users a unique look across all of our projects and their aesthetic. As the portfolio grew in scope, the page got longer… and longer… and longer. We could opt to limit the number of entries but that solution didn’t satisfy our desire to put our best foot forward. As the page got longer so did the loading time given the vast number of images that were being served to the browser. We actively cache the website and use a CDN but that only goes so far in helping with load distribution.
Solution #1 – optimizing images
We tried a few takes on scaling back the quality of the images to reduce their file size. Adjusting the quality downwards did reduce the file size considerably, but we didn’t think that solution was an option because the quality of the image spoke to the quality of our work. So we dug a little deeper.
Solution #2 – pagination
Pagination is simple in its approach and does exactly what we were looking for it to do. We would display a set of portfolio pieces and offer links to go to the next page of portfolio pieces. This would achieve the goal of lessening the server load of the initial view of our portfolio. However, we would have to ask the user to take action to see more of our work. As any website owner knows, a click is never guaranteed. Pagination was quickly ruled out as we wanted a large, photographic spread of all of our work. That lead us to solution #3 which still required action from the user, but the action was much more passive.
Solution #3 – lazy loading
Lazy loading is a popular technique being used across the Internet right now. The concept is simple – don’t load an image until a viewer “requests” it. Requesting doesn’t necessarily mean direct action on the user’s end. A request could be as simple as a scroll into view. We loaded a very small sample image with a tiny file size to fill the images until the user scrolled to where that image was put within the user’s viewport. This solution was a decent approach.
However, we were battling a few usability issues. As you scrolled down, the images would take a second or two to load which would cause a sort of “pop in and pop out” effect. Since some of the images on the portfolio were larger than others, the images would load when the files were downloaded. The effect that created wasn’t optimal. Plus, the page was saddled with unnecessary markup – and we didn’t like that as development purists.
Solution #4 – asynchronous calls with infinite scrolling
Using asynchronous calls to the server took the benefits of solutions #1 – #3 and lessened their drawbacks.
Using this method, we could essentially have a portfolio page of a thousand pieces without the server load of requesting a thousand pieces at a time. We would only load images when the user requested them. This employs the pagination technique from solution #2 while making the user do little more than scroll down – which they would presumably be doing while viewing our pieces. This method also uses a modified lazy loading technique as we’re not sending requests to download a file from the server unless the user is passively requesting them. We were also a little less constrained with optimizing image files given we were only loading a few chunks at a time.
Mobile Usability Issues
A benefit to using asynchronous calls in conjunction with an infinite scroll setup is that it had no drawback to mobile usability. It in fact helped. Since we relaunched the site employing responsive web design, we were cautious of using any technique that would not perform well on mobile platforms. File size is a magnified issue within mobile usability. It is a safe assumption that a mobile device may be on a cellular network when viewing a website. These networks are often slower, and sometimes incredibly slower, than traditional wifi connections. Before the overhaul, we were requiring cellular networks to download a complete list of the portfolio creating quite a bit of waiting on the user’s behalf. Now, we’re only loading 3 at a time – a manageable amount even by cellular network standards.
With solution #4 in hand, we went a little further and added another layer of usability to the portfolio. We established a tagging system where we would categorize each portfolio piece as a certain type. For example, some sites contain e-commerce capability, others are corporate, others were for non-profits. We added 8 tags to begin with although that list can dynamically expand using the power of WordPress. Clicking any of the tags on the portfolio page serves an asynchronous call to the server for pieces that match that tag. It is then put on the same infinite scroll setup allowing a user to easily and seamlessly drill down to content they wanted to view.
We added Google Analytics Event Tracking to each of the buttons. An event is fired each time a user clicks one of those buttons and is logged within Google Analytics. This allows us to have dynamic information coming in about which portfolio categories were viewed most often and by who. Perhaps this stat is ultimately meaningless, but that information does give us a small glimpse into the minds of our users and the market as a whole.
Website owners should actively examine their most important properties on their website. Important can mean a few different things. They could be important to your users determined by the percentage of which they view certain pages over others. They could be important to your sales process – checkout screens for example. You should examine each of your important properties a few times a year at a minimum to be sure that the usability is there to successfully convert anonymous traffic into customers or followers.