Chitra's Blog: November 2015

About four years ago, the main theme, mantra in all of "web world", including social media, blogosphere, meetups and conferences was "responsive web" which pretty soon turned into "responsible web" as web pages seemed to have had an immediate need to go on a "diet" to do well in the speed and performance aspect, more so in relation to keeping up with the responsive aspect.

Although we feel comfortable enough at this time to say that the Web industry has matured enough to understand the concept of "one-web" that works well on all platforms and devices and the term "responsive web" or "mobile web" is hopefully getting obsolete and web now inherently means "responsive web" as it was always intended to be, I am not yet sure if we have reached the point where websites are as fast and lean as they can be. Striving to be fast and lean is where the web seems to be focused right now (or needs to, if it isn't already). This was aptly represented by the focus of the An Event Apart Conference in San Francisco, Nov 2015, especially considering the fact that there were two talks exclusively focused on this topic and many others also included a heavy focus on the same topic as well.

Here's my consolidated "Cliff Notes" of sorts from:

Design Decisions through the Lens of Performance by Yesenia Perez; Desgining for Performance by Lara Hogan; Modern Layouts: Getting out of our ruts by Jen Simmons and CSS Grid Layout by Rachel Andew.

NOTE: I may have added general contextual information and resources here, which may not have been directly elaborated on, at this conference. All the resources and links included here are public resources shared by the speakers and others.

The need for faster websites

Although the need for faster websites is unequivocally established and felt (or has been made to feel, as in Facebook 2G Tuesdays), here's a bit of a refresher on the need for faster websites:

Average size of websites now — 2.16MB! Increasing every week!
Online shoppers expected pages to load in 2 seconds — and at 3 seconds, a large share abandon the site.
People will visit a Web site less often if it is slower than a close competitor by more than 250 milliseconds.
20% is the magic number that makes a web-page perceptibly faster/slower than its nearest competitor.
Visiting your website actually costs your users money! https://whatdoesmysitecost.com

Ref: "For Impatient Web Users, an Eye Blink Is Just Too Long to Wait,” New York Times, February 29, 2012"

What makes up the page weight?

Images (biggest contributor)

http://httparchive.org/interesting.php

Custom web fonts (note that iOS 9 and many others give an option to disable custom fonts make sure you don’t have any gotchas with system fonts).
Third-party scripts (tracking, marketing analysis, user analysis, heat maps and more). These tend to cause more http requests as well.
UI Interactions that mostly translate to Javascrip/jQuery scripts.
Stylesheets: Not the biggest contributor but can easily get bloated with overly complex layouts and numerous breakpoints (and frameworks if used in the 'kitchen-sink' model).

Apart from the usual Web Page Speed tests, time for first render etc. the term Page speed index was also discussed... Lower the better.
https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index

https://www.nccgroup.trust/uk/about-us/newsroom-and-events/blogs/2015/june/speed-index--how-it-works-and-what-it-means/

The best Speed Index score was 819. The average was 3,658 (median 3,106), while the poorest had a score of 8,582.

Why do we end up with bloated websites?

Slow, heavy sites are a result of…

Poor planning
Poor communication
Poor awareness

Fast sites build trust.

Yesenia made a bold statement with "Performance is a design feature. Not a technical concern." What I think she alludes to is, if there have been decisions made at the marketing, UX and Design phases of the web project that cause it to be "heavy", no amount of optimization in the later phases will help you much to make it much leaner, so make sure it is built on strong but lean foundations.

On a similar note:

"Deciding a page can’t exceed 500kB when a mock-up containing three carousels and a full-screen high-resolution background image has already been approved isn’t going to do you much good."

—Tim Kadlec

If an “approved page layout” already has a carousel/full page background image, textures, parallax scrolling, tons of web-fonts, videos, numerous JS/jQuery UI interactions and “must-have” third party tracking scripts and much more, optimization won’t help you much to get your page load faster.

How can we change this?

Create Reusable UI patterns that use common CSS; similar UI interaction patterns > common JS > Less code.
Use the same basic pattern and add minor variations for different conditions.
Simplify.
Consolidate the number of colors and font-weights in custom web-fonts.
Choose inherently smaller size images (shallow DOF, less texture, fewer details/noise).
Optimize images further https://imageoptim.com/ (has links for automation too).
Use responsive images. Thanks to Jason Grigsby's Herculean effort, we have an exhaustive 10 part essay on responsive images.
Use svg, svg sprites and icon-fonts when possible (smaller sizes).
Use CSS to create banners, backgrounds, gradients and whereever it is possible to replace images.
Remove unnecessary elements in markup ('divitis'); Clean up code; Don’t use “Kitchen sink” framework elements; drop rarely used CSS/JS libraries; Create the same effect, interactions with fewer lines of code and use plugins sparingly.
When there are no other options, lazy-load below the fold images.
Load scripts asynchronously (taking care of dependencies).
Create a performance budget http://danielmall.com/articles/how-to-make-a-performance-budget/
A Grunt task for keeping up with performance budget.
https://github.com/tkadlec/grunt-perfbudget

The above are predominantly design oriented tasks related to performance optimization as discussed in the talk and there is a lot more that can be addressed in code and on the server and this is by no means an exhaustive list. In this write-up as I am focusing more on the former.

Key takeaways from the performance talks

Prioritize performance from the beginning.
Set a performance budget and prioritize as a project goal. Retroactive doesn’t really work.
Who is responsible for performance? No more performance cops or janitors. Change Culture.
Include performance goals in project specifications and documents.

Front-end technologies we can look forward to, get excited about

Talk from Jen Simmons on "Layout should serve the content" and Rachel Andrew on CSS Grid Layout.

Notice something on the web these days...?

http://www.novolume.co.uk/blog/all-websites-look-the-same/

Summary: Web is not print, but it is OK to borrow or be inspired from print elements that were previously not possible on the web, as long as they are accessible, compatible with multiple viewports and user-friendly. Be careful of tab-orders and screen readers and don't over-do, or go overboard. Many of these technologies may not work in all the browsers just yet, but most may be conducive to be used as progressive enhancement at this time. Below are some of those, many of which we are already using in although in smaller doses.

CSS Shapes
CSS Regions
Multi-column layout
Flexbox
Dynamic Grids
CSS Grid Layout

Where are we on the browser support for these?

http://caniuse.com/#search=css%20shapes

http://caniuse.com/#search=css%20regions

http://caniuse.com/#search=CSS%20Grid%20Layout

If you are thinking... Why Did You Tell Me About All This Stuff I Totally Can’t Use Yet?!

The answer is: Do Websites Need To Look Exactly The Same in Every Browser?

Find out here ;) http://dowebsitesneedtolookexactlythesameineverybrowser.com/

To sum up in one sentence... Progressive enhancement is the key.

CSS Grid Layout

Specs are still not finalized on this, but in a better shape than flexbox. No confusion with multiple syntaxes as it happened with flexbox. Get involved and give feedback. May not be ready for prime-time/production yet, but can be used in prototyping as of now. Provides many options that aren’t available or hard to achieve currently, the most notable being separation of content and presentation and content choreography (yes, as in changing the content in different viewports without actually changing source order in the DOM). Of course a polyfill is in the works as well.