Find your performance threshold early on
Continuing from the previous technique’s theme, it’s worth stressing that the advice in this
chapter is especially relevant for mobile devices, many of which are slow relative to
desktop computers. Unfortunately, we, as developers, often fail to consider this in our
workflows: we routinely create websites within the pristine operating environments of our
high-end desktops, which are likely running the latest-generation hardware and software
available. This type of environment is divorced from the real-world environments of users,
who are often not only using outdated hardware and software, but tend to have many apps
and browser tabs running simultaneously. In other words, most of us work in development
environments that are non-representationally high-performance! The side effect of this
oversight is that your app may actually be noticeably laggy for a significant portion of
your users. By the time you asking what frustrates them, they may have already lost
interest in using it.
The correct approach for a performance-minded developer is to determine the
performance threshold early on in the development cycle. While developing your app,
check its performance frequently on reference devices, which might include a last-
generation mobile device plus a virtual machine running Internet Explorer 9. If you set a
performance goal early on of being performant on your reference devices, then you can
sleep soundly knowing that all newer devices will deliver even better performance for
your users.
TipIf you’re a Mac user, visit Microsoft’s Modern.ie website for information on
how to run free virtual copies of old Internet Explorer versions.If you find that a reference device is too weak to power the motion design that you
insist your app has, follow the advice from the previous technique: gracefully degrade
animations on that reference device, and choose a faster device as your new (non-
degraded) reference.
For each testing device, remember to open several apps and tabs at once so you
simulate users’ operating environments. Never test in a vacuum in which the only app
running is your own.
Keep in mind that remote browser testing (through services such as BrowserStack.com
and SauceLabs.com) is not the same as live reference device testing. Remote testing
services are appropriate for testing for bugs and UI responsiveness—not for animation
performance. After all, the test devices running in the cloud aren’t using real hardware—
they’re emulated versions of devices. Consequently, their performance is typically
different than that of their real-world counterparts. Further, the lag time between what
occurs on the virtual machine and what’s displayed on your browser window is too
significant to get a meaningful gauge of UI animation performance.
In short, you’ll need to go out and buy real devices for performance testing. Even if
you’re a cash-strapped developer, don’t skimp on this. The few hundred dollars you spend