How Timing and Performance Affect Users on the Web

As a web user, you may or may not be surprised that fractions of a second play a large role in your next interaction with a website. The differences can be as drastic as staying on the site versus leaving or even developing a positive versus negative attitude towards the website’s brand.

Imagine visiting a site that you haven’t been to before. You arrive from a Google search, and as the first page loads three or four seconds go by. It’s enough to notice, but maybe not enough for you to leave the site. The next move you make is clicking on a call to action that loads more information. The information animates into place, but it is choppy and at a slower pace than you’d prefer. That’s it… you’ve had enough, returning to your search engine results. Does this sound familiar? Users have a pretty short fuse when it comes to interacting with websites and why should they not? There are usually dozens of other websites to go to for the same information or service. It’s better to attack timing and performance issues head on before they greatly affect user experience, or even worse, your brand.

Let’s go into detail with some specific examples of situations on our site where we put effort giving timing and performance special consideration. This will help you get the idea of functionality on your site that you may need to give a second look to.

Homepage “snapping”

From the beginning, our interactive team favored short, digestible snippets of information on our website. We also wanted to control everything that the user would see, when first loading the page, with the intention of focusing the user’s gaze on our main headline. Then opting for a somewhat non-traditional route we went with the user still having control of their mouse for vertical “snapping” sections compared to a more common horizontal carousel with arrows. We researched this functionality by viewing other websites and how they achieved a similar effect, but something was off on those we looked at. They were often slow and clunky or there was a moment after a new section snapped into place where your ability to immediately change to the next section was disabled. We had ideas of how to make the animation smoother, but were a little confused of the intentional delay put into place. Because of this, the next step was deciding to build this feature from the ground up rather than try and utilize another gallery library.

As development progressed, we figured out why others had a delay. Without getting too technical, the problem had to do with the inherited inertia from touch pads, touch screens or mice that support swiping and how it eases into place after you swipe. Think of swiping with your finger on your phone, and how the page keeps scrolling after you swipe, and then it eases out until it stops. Placing a delay prevents your code from picking up on this continuous movement and thinking it should change slides again. We didn’t feel that settling for this delayed functionality would be successful in not frustrating our users, so we began to test solutions to get around the issue.

This was the first time I could think of that I ran into issues on the web that had to do directly with operating system settings, but our team was still convinced we could overcome it. In the end we added logic to our code that could tell whether it was an intentional user initiated scroll compared to a consistently easing out scroll after swiping. The end result was then allowing a user to quickly slide through our homepage slides without experiencing a delay or lag. Compare it to the gallery library link above.

Main menu animation

Another example of an element from our site that we dedicated extra time to getting the timing and performance right was the main menu. This was already a highly debated feature of the site between team members since we opted for traditional mobile navigation across all devices and screen sizes. While hiding the navigation was controversial, there was no discussion needed in understanding that the menu had to be easy to use and had to feel right when users navigated from page to page. Performance was the first thing we acknowledged. For any developers reading this, we went with using an animation engine called Velocity.js which has similar syntax to jQuery, but is much more efficient. This drastically helped the performance of the menu itself. We also spent some time testing different easing and timing settings to make sure it felt right to the user. Lastly, we wanted to create a subtle animation for the main menu icon to then indicate you click it again in order to close the menu. It had to be elegant, but subtle, since the user may see it several times in one visit. Not much is worse than a long, overdone animation that repeats itself multiple times and prevents you from quickly accessing content. After all of these considerations our team felt good about the experience the user would have, even with the navigation hidden. Click on our navigation above, if you haven’t already, to see the final result.

Conclusion

These are just a couple of examples of how small variations in timing and performance can affect a site. We strongly feel that if the thought and effort wasn’t put into these seemingly minor details, we would lose users to frustration when interacting with common pieces of our site. In relation, there are a lot more examples out there that get into data and testing, compared to insights from our process.