Post on 04-Jul-2015
description
Building Faster (& Be!er) Sites
Holger Bartel | @foobartel | FFCPH 8/11/2014
Performance is a thing.
Nobody likes to wait. Also not for your site to load.
Slow is Bad!
Users expect sites to load in ~2-3 seconds…
Expectations
Users expect sites to load in ~2-3 seconds…
That’s the definition of ‘fast’
We’re even aiming to deliver something in even less
Expectations
50% of people say they'll abandon a page that takes longer than 4 seconds to load
Expectations
Depending on location and what the user is used to this might be slightly longer
More than 6 seconds for sure is pushing it and people will leave
Expectations
Faster is Be!er!
Faster is Be!er! Why?
The Real World (and why you should care)
40% of surveyed online shoppers will abandon a page that takes more than 3
seconds to load.— Akamai (2009)
Speeding up a fundraising site by 60% increased donations by 14%.
— Kyle Rush, Obama Campaign (2012)
Adding half a second to a search results page can decrease traffic and ad
revenues by 20 percent — Google
Every additional 100 milliseconds of load time decreased sales by 1 percent.
— Amazon
Global Network Speed
http://www.netindex.com
Global Broadband Download: 21.3Mbps
Global Mobile: Download: 10.9Mbps
PhilippinesDownload: 3.49Mbps (Mobile roughly the same)
IndonesiaDownload: 5.27Mbps (Mobile 2.67Mbps)
USADownload: 31.3Mbps (Mobile 13.33Mbps)
November 2014
http://www.netindex.com
Too good to be true…?
3G, Edge, GPRS
http://en.wikipedia.org/wiki/Intercity-Express#mediaviewer/File:SiemensVelaroD-InnoTrans2010.jpg
3G, Edge, GPRS, offline…
Faster is Be!er!
Progressive Enhancement
Because before thinking about making your site fast, we want to make sure it loads in the
first place.
The idea of one web for everyone is one of our main goals.
We just have to figure out how to best do it, so eventually it will work well for everybody.
(Responsive) Web Design
Working with the unknowns
(Try to) Make the best assumptions
RWD Lessons
We tried media queries & viewport sizes
But: You could be mobile on Wifi or with a laptop tethering EDGE in the jungle
How do we find out what our users want in their current environment?
Assumptions
Faster is Be!er!
Just like we did with pixel-perfect design, we have to let go of the idea of the same experience for all
browsers and all users.
Le!ing go…
Progressive Enhancement rather is about making core functionality available to everyone.
Everything on top of that is the ‘enhancement’ part.
…to progress
http://en.wikipedia.org/wiki/Tightrope_walking
Every website is responsive from the start.
Everything else on top of it, is how we brake the base feature.
It’s easy!
It’s all here already.
Start simple and look at the bigger picture.
Give users a great experience in its simplest form.
Then progressively enhance to deliver be"er experiences.
Performance is Design
Performance is Design
Design is Performance
Performance is Design
Design is Performance
Design directs Performance
— Ian Feather
“Performance is a compromise between design and performance.
You can only be as fast as the design allows.”
Collaboration & communication between designers and developers nowadays is essential and more
important than ever before.
Breaking Silos
Get designs into the browser as soon as possible, so you, your team and your client can
get a be"er feel for what it will be like in the real world.
Ask yourself:
What's the gain?
What do you want to achieve?
A carousel with 7 images - is it really worth the load time or just pre"y to look
at?
Whereas it's questionable if images 3-7 will be seen
in the first place.
— Jake Archibald
“If images would be render blocking we'd probably think
twice about them.”
Performance Budgets
http://timkadlec.com/2013/01/setting-a-performance-budget/
Building for Performance
Rendering Pages
Waiting for DOM and CSSOM to build the render tree.
Render tree contains nodes to render the page.
Layout computes the exact position and size.
Paint turns the render tree into pixels on screen.
Render-Tree Construction, Layout & Paint
Waiting for CSS
Avoids “Flash of Unstyled Content” (FOUC)
Render Blocking CSS
The parser has to stop for scripts before continuing to parse HTML.
JavaScript can query and modify DOM and CSSOM.
JavaScript blocks DOM construction unless explicitly declared as async.
Render Blocking JavaScript
Every request fetched inside of HEAD, will postpone the rendering of the page
Loading JavaScript
Every request takes roughly ~200ms
Avoid unnecessary redirects
Limit HTTP Requests
Critical Resource
Critical Path Length
Critical Bytes
Critical Rendering Path
Optimizing the dependency graph between HTML, CSS, and JavaScript.
Optimising the Critical Rendering
Path
https://developers.google.com/web/fundamentals/
Optimising the Critical Rendering
Path
=Ge!ing stuff on the
screen fast
domLoading: this is the starting timestamp of the entire process - start parsing the first received bytes of the HTML
document
domContentLoaded: marks the point when both the DOM is ready and there are no stylesheets that are blocking
JavaScript execution
loadEvent: as a final step in every page load the browser fires an “onload” event
Navigation Timing API
Without CSS & JS
https://developers.google.com/web/fundamentals/
With CSS & JS
https://developers.google.com/web/fundamentals/
To get stuff on the screen fast…
Minimize the number of critical resources.
Minimize the number of critical bytes.
Minimize the critical path length.
A critical resource is a resource that can block initial rendering of a page.
Analyze and characterize: number of resources, bytes, length.
Minimize number of critical resources.
Optimize order of remaining critical resources being loaded: download critical assets as
early as possible.
Optimize the number of critical bytes to reduce the download time (number of
roundtrips).
Put your JavaScript files at the bo"om Optimize your images
Concatenate files Minimize files
Far future expires headers for caching
Google Page Speed YSlow
The low hanging fruit
Fastclick
Polyfill to remove click delays on browsers with touch UIs
Perceived Performance
Taming Framework Overhead
Frameworks
B
It’s so easy to choose a framework like Bootstrap & plug in a li"le jQuery…
Kill The Lazy Developer In You
Do you really need all that stuff?
No?
Do something about it then!
Don’t trade Performance for a Framework
CSS Spring CleaningCSS SPRING CLEANING
Just Like With Other Stuff
Too Much Overhead: 15.689 CSS rules
Built with Foundation 5 as an MVP Uses jQuery, jQuery UI, Vanilla JS
& various Grunt tasks
Missedin-HKG.com
CSS File Size: 88Kb JS File Size: 213Kb
Development
CSS File Size: 3.8Kb JS File Size: 54.3Kb
Production
Tools
Standards for developing flexible, durable, and sustainable HTML and CSS.
Code Guide
http://mdo.github.io/code-guide/
VirtualBox
Modern.ie
Browserstack.com
Sauce Labs
Cross-Browser Testing
Adobe Edge Inspect
Ghostlab
BrowserSync!
Device Testing
6 Weeks
428 Different Devices
=
http://opensignal.com/reports/2014/android-fragmentation/
Testing on Real Devices
opendevicelab.com
Photo: @viljamis http://devicelab.fi
http://tools.pingdom.com/fpt/
https://developers.google.com/speed/pagespeed/
https://developer.yahoo.com/yslow/
Performance Testing
Chrome Dev Tools
With achieving fast page load time, people can quickly use your site and
accomplish what they want.
People will appreciate it and end up being happier users.
Happier users mean be!er conversion rates.
Be!er conversion rates can be increased revenue, more signups,
returning visits, or downloads.
Faster is Be!er!So…
Thanks!
Holger Bartel | @foobartel | FFCPH 8/11/2014