Performance is everything, but many people only do the basics. AMP is just the beginning. Want to go further, faster?
Brace yourself for a whirlwind of speed techniques and opportunities - from HTTP2 to PWAs and beyond!
21. @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
30. @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
31. @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.
31
31
@jonoalderson
42. @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
46. @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
57. @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).
58. @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
68. @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
69. @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.
71. @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
72. @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
73. @jonoalderson
CSS specificity = slow paint
● .container > nav > ul > li > a { color: red; }
● .main-nav-link { color: red; }
74. @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!
75. @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?
Why is performance important?
Everybody seen the Amazon studies (and all of the others?)
Why is it only going to get more important? Instantaneous is the new 2 seconds is the new 5 seconds!
This session is for anybody who wants to go faster (either with AMP, or without), but doesn’t know where to start; front end, back end, and everything inbetween.
The AMP project in particular has pushed performance forward (not without politics)...
(AND, there may be good reasons why you don’t want to use AMP, but still want the benefits).
Not a magic bullet.
Walled gardens and dependency on Google, poor implementation.
Yet another language/framework to maintain (for them, and for us).
Deprecation? Invalid code? Security? Pinging, caching.
Pros and cons? Control! Ownership!
Are there alternatives?
Have to ping to manage versions
But no guarantees; flakey!
Other people are getting involved.
But is it enough?...AND… their implementation is a little… odd…
not easy to do your own amp cache, as you need to host and maintain your own version of the amp library#
no guarantees your amp cache is used by third parties such as search engines
What’s your motivation for adopting AMP; the performance, or access to the sandpit?
You can have all the performance advantages without having to be in the cache, etc.
But it’s a choice, with implications.
And there are other options.
But it’s also the tip of the iceberg; if your goal is performance, there are a million other things you can do.
HTTPS is mandatory. Security. Performance. Acceptance.
This thinking assumes that you’re already compliant, or are about to be.
No reason not to (ad platforms, etc)
“HTTPS is slower!” - the myth of secure handshake bottlenecks
Not binary!
Cheap certs often = long chains!
Cloudflare = shared/cheap
Let’s Encrypt; install in/on server. Also, cPanel now DIY’s, too.
Better certs = closer to trusted sources, and also better liabilities
Still bottlenecks based on the number of assets you’re loading, the size of those, where they’re hosted, etc.
Still bottlenecks based on the number of assets you’re loading, the size of those, where they’re hosted, etc.
Apache config, or automate via Cloudflare (etc)
Cloudflare - also, upgrade insecure resources, force https, free sll certs, etc.
At some point you have to sort all of this out, so it should probably be now.
Parallelised/individual resources; no waiting!
Enables keep-alive by default
A FAST, wired connection from east coast to west coast USA might take ~60-100ms.
A 4g connection to a remote server might take up to ~200ms (‘sluggish’)!
HTTP services do round-trips to get resources; HTTP2 services run in parallel.
What goes into your first few packets?
CSS3 is often faster than using images
...Though processing and rendering are your bottlenecks
SVGs > JPG/PNG is a good general rule. WebP even better, but challenges.
Although… inlining resources makes them harder to cache, and may not be optimal in terms of prioritsation
Conditional media queries still (can) load all the assets
Mechanisms which use display:none still load the image
Mechanisms which replace the image src attribute to lazy-load probably aren’t great for accessibility or SEO
Conditional media queries still (can) load all the assets
Mechanisms which use display:none still load the image
Mechanisms which replace the image src attribute to lazy-load probably aren’t great for accessibility or SEO
Base64 encode fonts and icons, and SVGs!
Doesn’t need an extra request, which still carries overhead
Up to 40% smaller!
Better compression, shared headers, etc.
Most systems don’t cache 404s (or other errors)
Some scenarios mean that requests to errors redirect, download subsequent resources, etc. Cost-intensive.
Robots.txt, favicons, app icons, msapplication policies, requests to old URLs, security probes.
Most systems don’t cache 404s (or other errors)
Some scenarios mean that requests to errors redirect, download subsequent resources, etc. Cost-intensive.
Robots.txt, favicons, app icons, msapplication policies, requests to old URLs, security probes.
Your best tool is your brain, and your experience.
Use the Chrome waterfall, look for slow request/respond/paint processes.
Click on them, and read! It’ll give you tips.
Diagnosing bottlenecks
Longest single wait is often connect + receive*
Nothing else can happen until this is done.
More time processing, or more time delivering?
Don’t ignore, and don’t get obsessed!
CDNs; later!
HTTP/2 will automatically coalesce connections if the host resolves to the same IP and the TLS certificate is valid on both
Itemised SASS/LESS/JS outputs - only load the bits you need
Different expirey and caching methodologies for different assets and types?
VPS, Heart?
Email, FTP, SQL, PHPmyadmin. Start to see behind the curtain.
Gzip
RAM allocation
Gzip variablles!
PHP versions, addons, etc
Be careful about accidentally consuming CPU/GPU, wasting bandwidth, triggering JS, etc
https://www.w3.org/TR/page-visibility/ - page visibility API is generally supported, and lets you check if a tab is active/visible.
Edge caching assets easy; html less so. Uncommon.
More complex setups; distributed servers/etc.
Homepage icon prompt
Online/offline hybridisation; control local caching, etc
Need URL-based nav (which you already need for app indexing)
Precursor to sideloaded APKs!
Consider that maybe a separate app isn’t the future
...That Google want to push for seamless search>content transition (albeit with monetisation)
The app store disrupts this; and Google Now scraping apps isn’t a good enough fix.
AMP and PWA pages are increasingly gaining access to mobile hardware; seamless transition into apps, and even into VR.