RSS
Search

Delta V Conference - Day 1!

Delta V Conference is a new two-day, single-track web performance conference in London, hosted by me, Perry Dyball and Jo Franchetti. Here's my raw notes from the fantastic content from our lovely speakers on day one.

Tim Kadlec - Redefining Web Performance

There is a lot of under-appreciated creativity in technical work. Definitions change - dictionaries are out of date as soon as they are printed - like JS frameworks.

Network Constraint - 71% of global connections are 2G or 3G, we live with a rose-tinted view of the world.

Device Constraint - new adoption is on low-end Android devices. 90th percentile JS payload is 1MB (compressed) / 7MB (uncompressed).

Performance cannot be fixed top-down (AMP / FIA / Apple News). It took the New York Times 10 years to fix their performance problem.

Speculative execution - a performance optimisation without considerations for the implications. (Spectre / Meltdown).

Access & accessibility - he keystroke-level model for user performance time with interactive systems. Performance is about the level of effort, human memory limits, task completion.

Web Performance: how quickly users can complete their task.

Sarah Dapul-Weberman - The first 10 months of a dedicated web performance team at Pinterest

Discovering the value of performance Migration of user pages to React -> 20% performance gain. Led to 10 - 20% engagement increase. Non-auth pages 30% faster -> 15% more signups, 10% increase in SEO traffic.

No ownership of performance -> started dedicated performance teams for web, Android and iOS.

Pinner Wait Time (PWT) as the key performance metric - a composite of the time to render the key image and the comments / metadata.

Get rid of vanity metrics - prove correlation with business goals or drop them. Performance is a lever to change the business metrics.

Impact Assessments - artificially delay key metrics and measure the impact on user behaviour / business metrics.

PR campaign to publicise the performance team on all-hands calls. Each critical page is tested multiple hundreds of times on every commit - the 90th percentile of PWT is taken and plotted, threshold-based alerts.

"Perf Detective" performs a binary search with performance testing (like git bisect) to find the exact commit which caused the regression.

Changes are prototyped first to provide estimated performance wins - before development starts! Once the projects are decided on they are tested in an A/B framework which has performance and engagement metrics built in! A/B test results are segmented by geography, user behaviour profiles etc.

The team beat the original goal of 14% improvement by an additional 20%! Vision: five pillars:

  1. Scalability (team) - we can’t be the only people working on performance. Enable product teams to manage performance.
  2. Ownership - each team owns their surface performance. Decentralised monitoring.
  3. Knowledge base - create a central place to document what performance looks like at Pinterest
  4. Tooling - create / purchase the tools which developers want to use
  5. Strategy - performance team will own the performance strategy - where to focus, tool management. Distribute the work.

Rhys Evans - Speeding up FT.com, without slowing down

Slides | @wheresrhys

The old FT.com site (Falcon) was slow and high-risk. One release a month!

If we ever need to start from scratch again, we've gone badly wrong

For the new site, the team insisted on control of all web content, including third-parties.

Deploy local -> production in 10 minutes using CircleCI and Heroku. Feature flags enable roll-out of features to live traffic.

~100 microservices create the FT.com back-end stack. Componentisation at the front-end using Origami.

These practices free us to release quality software quickly, with confidence

Microservices add extra latency to user requests due to dependency chains. Ft.com uses multiple caching layers to resolve that.

Preflight enables intelligent caching at the edge. But this itself is another performance bottleneck with multiple microservices! Every service is measured, medians and percentiles are used and the number of timeouts are counted and plotted too.

Code impatiently - HTTP agent keep alive to create connection pools. Pessimistic timeouts - fail fast and provide error details.

Fast releases reduced asset reuse - with no inlined CSS or shared JS bundles!

The singular focus on performance made releases harder, alienated the development team.

Performance is not a core front-end skill. It's weird, complex and optional

Performance optimisations should be discussed with the whole team, especially junior developers. Optimisations should be released early and often, tested and balanced with developer convenience.

You don't have to be perfect to get results!

Further reading!

Seren Davies & Bruce Lawson - This is for everyone

Seren

Accessibility issues are much broader than we consider, with two broad topics: permanent and temporary / situational.

Cognitive Accessibility e.g. dyslexia, ADHD and epilepsy Animations should add value and not distract.

Drunk Use high contrast colours and large text. City mapper increases the size of the "get me home" button as the evening progresses!

Touch or movement - e.g. broken arm, holding a baby.

Link areas should be larger than the text - provide large tap targets.

Sight - beyond screen-readers, including colour-blindness. Text on images is really tricky - ensure that contrast ratio is preserved for all characters.

Deaf / hard of hearing - always add connections

Bruce

4 Billion people are not on the web - including 2 billion from India and China, and 51 million in the USA!

We need to sell into growing markets. These markets are overwhelming getting online with low-powered Android devices, with limited RAM on 2G networks. The infrastructure supporting mobile networks takes decades, while new devices take months.

A standard-sized Android app will take 30 minutes to download on a 2G connection, except it's unlikely that the download will succeed during that time.

Progressive Web Apps are the solution. Flipkart lite increased returning visitors by 40% when they released their PWA.

Images still account for >50% of page weight so that's a good place to start!

This matters not to the people loading your site from Silicon Valley, it's for the people who pay per MB.

Worldreader.org

If you want to liberate a country, give it the internet

The web is for everybody.

Inian Parameshwaran - Chrome Real User Experience Report

Measuring speed - Synthetic & RUM HTTP Archive is the archive for synthetic tests, CrUX is the archive for RUM data.

Rather than absolute values, CrUX stores histograms. Inian defines Site Experience Benchmark (SEB) as the fraction of users whose time to first contentful paint is under one second.

SEB reduces by 36% on average between desktop and mobile.

On average, SEB is 225% better on non-framework sites compared with those using a single-page app frameworks. This grows to 486% when isolating to mobile traffic.

Using RUM data gives a much wider perspective on geography and device diversity than synthetic testing, so you can use it to help inform technology choices. E.g. React server-side rendering improves SEB by 47%, 69% on mobile.

google.com is 40% faster than google.com.cn for visitors in China. 🤨

Lack of information on the number of data points in CrUX makes it hard to do cross-site analysis.

Laura Sheridan & Nick Webb - Web performance at N Brown, it's a business affair

N Brown are a fashion brand group that focuses on under-served groups - those that are larger and / or older.

First online store in 1999 as a small IT project. Now 75% online sales, 76% of traffic is smartphone. 4 million sessions per week!

After getting inspired at Velocity Berlin 2011, N Brown launched a project to remove duplicate scripts, set a weight budget for the homepage and purchased a StrangeLoop on-premise FEO solution.

Making the business understand performance - using RUM data to correlate page load time with bounce rate. Then created department-specific metrics, e.g. total image weight for the design team.

Laura held roadshows to share performance data for each of the 14 brand websites, with tips on how to improve. They also developed a web performance action plan - including scheduled work on specific operating systems, device types and page types.

To ensure performance does not regress, a weekly report is produced for each brand, device and page group combination. This is used to encourage internal competition and provide insight into regressions.

RUM data allows N Brown to modify their development plans between brands, based on the user profiles of the brand customers and their web environment.

Tag mapping for identification of what's on the site, as well as analysis for GDPR compliance. This led to a tag governance process.

The right visualisation can do our job for us

48/52 split between iOS and Android traffic, but sales are much lower on Android. To help fix the issue, rules were added to deliver the mobile version of the site to Android tablets with display sizes under ten inches.

As N Brown re-platform, there are weekly team lead meetings to discuss performance and a UX Director to ensure the performance of the new sites.

Uve - Making a Progressive Web Application

This was a live coding demo - here's a relevant blog post!

Ian Feather - Frontend Resilience

Resilience is function in a hostile environment.

We don't ship compiled products - there are many components we have to ship over the network to create a functional product.

We tend to develop in the ideal environment for a great user experience, but we can't guarantee that. We need to guarantee the most basic level of acceptable UX.

How systems can fail

HTTPS is a must-have to protect you from malicious interference. Third-party scripts are a nightmare.

Pick your third-parties and trust them well.

13 million JavaScript requests fail per month (1%) - that's a greater proportion of page views than IE11. 9% of visitors use content blockers, and 4% of users don't load web fonts - 40 million page views per month with no fonts.

Know what's broken before Twitter does

How we can design for failure

Have a working user experience in the first request. I.e. know what the critical part of your user experience is and ensure that it can be usable with the first HTML response.

Tell your developers when things break, but don't tell your users unless you have to. If you have to tell your users - give them an informative message and reassurance.

How we can mitigate failures

Lock your dependencies - use sub-resource integrity (SRI) for all third-party assets. But this then requires a well defined update process between you and your third-parties.

Build in redundancy - have two of everything, and use a proxy where possible to create an active / active asset delivery system.

Buzzfeed has Plan Z - a static copy of buzzfeed.com hosted both on AWS S3 and Google Cloud Platform and updated every few minutes. If everything is on fire, the DNS is updated to point at a static backup!

Serve stale content - use cache control headers to enable the CDN to continue to deliver assets when origin is unavailable.

How we can learn from our failures

Run blameless postmortems religiously to ensure that knowledge is gained from every failure. Consider how incidents were handled as a team and how it can be prevented from happening in the future.

Run fire drills and chaos testing to give the team practice on responding to incidents.

Ada Rose Cannon - New web technology

This one is best viewed the way Ada presented it, don't forget to view-source.

Denys Mishunov - debugger; for developers

Perfectionism

There are two types of perfectionism: healthy and unhealthy.

Steve Jobs was not satisfied with any of the 2,000 shades of beige given as options for the first Apple computer. This is perfectionism paralysis.

Perfectionists tend to pick small details to work on, where there is a guarantee that they can achieve the perfect result.

Unnecessary tasks (the cherry on top). Near the end of the project you might think of a small feature that would bring the project a little closer to perfect.

We cannot force perfectionists to stop being perfectionists, but we can help to turn negative productivity into positive.

### Imposter Syndrome

2 out of 5 successful people suffer from imposter syndrome, and 70% of the general population have experienced it at some point in the career.

You think that your success is due to luck, others might discover that you are not as intelligent as they think you are or that everyone is better than you.

True frauds rarely experience imposter syndrome.

The trouble with the world is that the stupid area cocksure and the intelligent are full of doubt

Feeling like an imposter is a symptom of gaining expertise.

Measure yourself against you, not others. Communicate your fears and feelings.

Long Hours

One of the most common death-bed regrets is working too much.

There are two types of long hours: temporary and permanent. Temporary long hours are associated with hard-working people, while permanent long hours indicates workaholics.

Stress and burnout are eventually harmful to productivity, even if there is a temporary increase at the beginning.

Every year Guolaosi costs China 1,600 people per day due to overwork.