@jonoalderson

@jonoalderson@jonoalderson

@jonoalderson

There’s a lot of much-needed focus on (mobile)

performance at the moment

@jonoalderson

@jonoalderson@jonoalderson

@jonoalderson

On AMP, briefly...

@jonoalderson6

Just the tip of the iceberg...

@jonoalderson

@jonoalderson

http://bit.ly/badams-amp

@jonoalderson

Risky? Dangerous? Subversive, even?

@jonoalderson

@jonoalderson

Are you actively managing your AMP cache?

https://developers.google.com/amp/cache/update-ping

@jonoalderson

@jonoalderson

You don’t need AMP.

You can do this yourself.

@jonoalderson

Anyone can (theoretically) create an AMP cache.

https://github.com/ampproject/amphtml/blob/master/spec/amp-cache-guidelines.md

@jonoalderson

@jonoalderson

@jonoalderson

http://bit.ly/ampJSWhat if you could

de-couple AMP?

@jonoalderson

To clarify, I’m not saying that you shouldn’t adopt AMP.

@jonoalderson

So, what’s the broader performance toolkit look like?

@jonoalderson

Infrastructure & network optimisation

@jonoalderson

HTTP2 Implications

@jonoalderson

@jonoalderson

HTTPS isn’t a binary thing!

@jonoalderson

SSL Chain LengthOn certificate length...

@jonoalderson

HSTS● Become compliant by adding extra HTTPS checks

● Register for the HSTS preload list (hstspreload.org)

● Skip the HTTP/HTTPS redirect when people type example.com

@jonoalderson

online.marketing/guide/https

More here...

@jonoalderson

Let’s go faster.

@jonoalderson@jonoalderson

@jonoalderson

bit.ly/http2-ilya

@jonoalderson

@jonoalderson

We need to go smarter, not faster

@jonoalderson@jonoalderson

@jonoalderson@jonoalderson

@jonoalderson

Connection & data transfer

@jonoalderson

With HTTP2, you don’t need to worry as much about round trips...

...but you should still consider what you’re transferring,

and how.

@jonoalderson

@jonoalderson

For devices...● Detect early, and adapt. Responsive = expensive!

● Make CSS mobile-first (build up from min-width); typically reduces sizes.

○ Conditionally layer on / load more for larger devices.

3131

@jonoalderson

@jonoalderson

For media/images…Test CSS3 vs images vs sprites vs encoding vs inlining

@jonoalderson

http://bit.ly/srcsetstuff

SRCSET is the only solution for managing image sizes/resolutions.

@jonoalderson

...And you can also use <picture> to support multiple formats

@jonoalderson

base64-image.de

You can also base64() encode images...

@jonoalderson

base64-image.de

@jonoalderson

@jonoalderson

Sprite sheets are might still be a thing!

@jonoalderson

https://developers.google.com/speed/webp/

WebP > JPG & PNG

@jonoalderson

Error management for common request headaches

Manage your robots, favicons, and other irritations.

@jonoalderson

@jonoalderson

apple-touch-icon.png (and variants)

favicon.ico (and variants)

browserconfig.xml

Feeds (/rss/, /feed/, etc)

Invalid page/date ranges

Broken internal links (and missing http links)

Alternate sitemap and metadata urls

Breaking parameters (especially on images, from search engines)

@jonoalderson

Measurement

@jonoalderson

Which metrics matter?● There’s no such thing as ‘speed’. What are we measuring?

● Numbers from Google Pagespeed Insights, Pingdom,

WebPageTest, GA, etc, are all nonsense

● User satisfaction metrics > any technical speed metrics

@jonoalderson

developers.google.com/speed/pagespeed/insights/

@jonoalderson

@jonoalderson

The Waterfall in Chrome

@jonoalderson

@jonoalderson

http://bit.ly/newchrometoys

Brand New Chrome Dev Toys!

@jonoalderson

Which metrics matter?● Don’t ignore, or get fixated on time ‘til first byte.

● You need to fix the front end and the back end.

@jonoalderson

webpagetest.org

@jonoalderson

@jonoalderson

Other Tools

@jonoalderson

@jonoalderson

@jonoalderson

@jonoalderson

@jonoalderson

Undoing bad habits

@jonoalderson

Hostname sharding

https://blog.stackpath.com/glossary/domain-sharding/

@jonoalderson

Resource combination

@jonoalderson

(I’m not going to talk about)

Back-end optimisation

@jonoalderson

Options for handling angular/react sites...1. Hope for the best

2. Serve static HTML versions, then let the framework pick up

the heavy lifting (using something like or PhantomJS)

3. Use something like Prerender.io (paid, or self-hosted).

@jonoalderson

● There comes a point where you outgrow a single server.

● If you’ve finite RAM and CPU, consider separating servers and

databases. Latency, however!

● Consider caching, varnish, load-balancers

Server Ecosystems

@jonoalderson

Server Ecosystems

Varnish (static page cache) < Apache/Nginx < PHP/Python

(memcache) < MySQL/NoSQL (request cache)

vs

@jonoalderson

SCARY?Learn by doing

DIY time

@jonoalderson

@jonoalderson

@jonoalderson

@jonoalderson

@jonoalderson

@jonoalderson

(I’m going to skim over)

Front-end optimisation

@jonoalderson

Caching Policies● Set your expiry times (appropriately!)

● Use 304 “Not Modified” header

● Use ETags

@jonoalderson

Resource Hints● Preload, preconnect, prefetch, dns-prefetch, prerender, and subresource.

○ <link rel="dns-prefetch" href="//example.com">

○ <link rel="prefetch" href="image.png"> (when idle)

○ <link rel="subresource" href="styles.css"> (prioritises)

○ <link rel="preload" href="/styles/other.css" as="style"> (prioritises)

● Pass as tags, headers, or via js

● NB: Rel next/previous automatically triggers prefetch in Chrome+Firefox

@jonoalderson

CDNs are still important● Localisation is important!

● Latency is a bottleneck more often than you’d think.

● Cookieless subdomains reduce header sizes!

● Use resource CDNs (eg., cdnjs.cloudflare.com) for things like jQuery.

● Your first line of defense.

@jonoalderson

@jonoalderson

Above the fold (critical path) rendering

● Reduces waiting time for the

browser to download assets

● ...but can’t be (easily) cached!

● loadCSS is your friend (async loading and js support)https://github.com/filamentgroup/loadCSS

● Takes advantage of rel preload

http://bit.ly/criticalpathcss

@jonoalderson

(Re)paint & (Re)flow● Consider how the page is constructed

and how it behaves

● Minimise unknowns to reduce tearing

and reflow in particular

● Small technical gains, big perception

gains

https://developers.google.com/speed/articles/reflow

@jonoalderson

CSS specificity = slow paint● .container > nav > ul > li > a { color: red; }

● .main-nav-link { color: red; }

@jonoalderson

Animation & FPS● jQuery, scrolling and changing elements costs GPU and CPU

● Consider the user’s physical hardware

● To maintain 60fps, you frame animations need to execute in less than 14ms.

● Transformation and opacity are the only ‘free’ animations.

● Measure with Chrome, and kick your devs!

@jonoalderson

Deferring / async resources● Do you need to load everything immediately?

● Do you need to load everything in the <head>?

● Do you need to load everything on every page?

● Do you understand the dependencies?

● What can you defer, load asynchronously, or load conditionally?

@jonoalderson

(You should go learn about)

PWAs

@jonoalderson

https://developers.google.com/web/progressive-web-apps/

@jonoalderson

“Twitter Lite and High Performance React Progressive Web Apps at Scale”

http://bit.ly/twitterpwa

@jonoalderson

@jonoalderson

Key takeaways...

@jonoalderson

@jonoalderson

You have a million opportunities to improve

performance ...and every byte matters to users.

@jonoalderson

Ignore all of the scores the tools give you, and

just make things faster.

@jonoalderson

Don’t neglect your infrastructure and back-

end opportunities

@jonoalderson

The landscape is changingDon’t get caught up in today’s hype

@jonoalderson

AMP is not the end.(but this is)

GO OUT AND WIN