Performance is the first interaction a user has with the things that we create.
As frontend engineers we need to always be reminding others about performance.
Performance isn't just the responsibility of frontend engineering. Like accessibility it's invisible, technical, and the result can slip through the cracks in a project. We should always consider performance as an essential design feature.
We surveyed 3000 users about 17 key product drivers. They rated speed 2nd most important only after easy to find content. Patrick Hamann, The Guardian
Early on each project should set a maximum page weight, which forces everyone involved in the design process to make some tough, realistic decisions about what deserves to end up on the page. Useful ammunition for saying no. An example performance budget:
Reducing the number of HTTP requests in your page is the place to start. This is even more important when considering mobile, where DNS lookups over mobile networks often takes longer than downloading the file itself.
inline-image(no IE7 support).
Wherever possible, defer the loading of third party code (e.g. social sharing buttons, video players) until after
window.onload. Where this is not possible (e.g. analytics code that needs to be present as soon as possible, use the
async attribute on the
<script /> element to prevent blocking.
Once the page has downloaded, interaction performance is important as well. Anything below 60 frames per second will feel sluggish and poorly built. When dealing with user input, interactions should be less than 100ms to feel instant, and 250ms to feel fast. Some rules of thumb:
scrollevents, use throttle/debounce instead.
There are some guidelines that we tend not to follow because of known problems:
Modern browsers support more parallel downloads than old Internet Explorers. As such, the practice of domain sharding is no longer as beneficial as it once was.