Accelerated Mobile - Beyond AMP

Editor's Notes

• #4: No Fili! Lots of little tips; I’ve included links, but you can Google everything in here. I know you’re not web developers… but this is going to get techy.
• #5: 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!
• #6: 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.
• #8: 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).
• #9: Why is AMP not a magic bullet? Ad networks, 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?
• #10: Have to ping to manage versions
• #11: But no guarantees; flakey!
• #13: 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
• #14: 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.
• #15: 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.
• #18: 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
• #20: 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
• #21: 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.
• #22: 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?
• #23: Parallelised/individual resources & require.js, etc Enables keep-alive by default No more hostname sharding (or, maybe - to support some browsers [esp older mobile]; serve from same IP [cached hostnames]) Itemised SASS/LESS/JS outputs - only load the bits you need
• #26: A lot of the page speed tools misreport on this. Combine your javascript! Distribute your resources!
• #27: Still bottlenecks based on the number of assets you’re loading, the size of those, where they’re hosted, etc.
• #29: 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
• #30: Base64 encode fonts and icons, and SVGs!
• #31: Doesn’t need an extra request, which still carries overhead
• #32: 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
• #33: Up to 40% smaller! Better compression, shared headers, etc.
• #35: 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.
• #36: 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.
• #40: 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
• #42: 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!
• #54: VPS, Heart?
• #55: Email, FTP, SQL, PHPmyadmin. Start to see behind the curtain.
• #56: Gzip RAM allocation Gzip variablles!
• #57: PHP versions, addons, etc
• #61: 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.
• #63: Edge caching assets easy; html less so. Uncommon. More complex setups; distributed servers/etc.
• #71: Homepage icon Online/offline hybridisation; control local caching, etc Need URL-based nav (which you already need for app indexing) Precursor to sideloaded APKs
• #72: 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.