DEV Community: Rick Viscomi

Querying parsed HTML in BigQuery

Rick Viscomi — Fri, 26 May 2023 16:05:19 +0000

A longstanding problem in the HTTP Archive dataset has been extracting insights from blobs of HTML in BigQuery. For example, take the source code of example.com:

<!doctype html>
<html>
<head>
    <title>Example Domain</title>

    <meta charset="utf-8" />
    <meta http-equiv="Content-type" content="text/html; charset=utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <style type="text/css">...</style>    
</head>

<body>
<div>
    <h1>Example Domain</h1>
    <p>This domain is for use in illustrative examples in documents. You may use this
    domain in literature without prior coordination or asking for permission.</p>
    <p><a href="https://www.iana.org/domains/example">More information...</a></p>
</div>
</body>
</html>

If you wanted to extract the link text in the last paragraph, you could do something relatively straightforward like this:

// 'More information...'
document.querySelector('p:last-child a').textContent;

But in BigQuery, we don't have the luxury of the document object, querySelector, or textContent.

Instead, we've had to resort to unwieldy regular expressions like this:

# 'More information...'
SELECT
  REGEXP_EXTRACT(html, r'<p><a[^>]*>([^<]*)</a></p>') AS link_text
FROM
  body

It looks like it works, but it's brittle.

What if there's text or whitespace between the elements?
What if there are attributes on the paragraph?
What if there's another p>a element pair earlier in the page?
What if the page uses uppercase tag names?

It goes on and on.

Using regular expressions for parsing HTML seems like a good idea at first, but it becomes a nightmare as you need to ramp it up to increasingly unpredictable inputs.

To avoid this headache in HTTP Archive analyses, we've resorted to custom metrics. These are executed on each page at runtime, and it's been really effective. It enables us to analyze both the fully rendered page as well as the static HTML. But one big limitation with custom metrics is that they only work at runtime. So if we want to change the code or analyze an older dataset, we're out of luck.

Cheerio

While looking for a way to implement capo.js in BigQuery to understand how pages in HTTP Archive are ordered, I came across the Cheerio library, which is a jQuery-like interface over an HTML parser.

It works beautifully.

To be able to use Cheerio in BigQuery, I first needed to build a JavaScript binary that I could load into a UDF. The post How To Use NPM Library in Google BigQuery UDF was a big help. I installed the Cheerio library locally and built it into a script with an exposed cheerio global variable using Webpack.

I uploaded the script to HTTP Archive's Google Cloud Storage bucket. Then in BigQuery, I was able to side-load the script into the UDF with OPTIONS:

OPTIONS (library = 'gs://httparchive/lib/cheerio.js')

From there, the UDF was able to reference the cheerio object to parse the HTML input and generate the results. You can see it in action at capo.sql.

Querying HTML in BigQuery

Here's a full demo of the example.com link text solution in action:

DECLARE example_html STRING;
SET example_html = '''
<!doctype html>
<html>
<head>
    <title>Example Domain</title>

    <meta charset="utf-8" />
    <meta http-equiv="Content-type" content="text/html; charset=utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <style type="text/css">...</style>    
</head>

<body>
<div>
    <h1>Example Domain</h1>
    <p>This domain is for use in illustrative examples in documents. You may use this
    domain in literature without prior coordination or asking for permission.</p>
    <p><a href="https://www.iana.org/domains/example">More information...</a></p>
</div>
</body>
</html>
''';

CREATE TEMP FUNCTION getLinkText(html STRING)
RETURNS STRING LANGUAGE js
OPTIONS (library = 'gs://httparchive/lib/cheerio.js') AS '''
try {
  const $ = cheerio.load(html);
  return $('p:last-child a').text();
} catch (e) {
  return null;
}
''';

SELECT getLinkText(example_html) AS link_text

🔗 Try it on BigQuery

The results show it working as expected:

Limitations

Cheerio is marketed as fast and efficient.

If you try to parse every HTML response body in HTTP Archive, the query will fail.

Fully built, the library is 331 KB. And due to the need for storing the HTML in memory to parse it, it consumes a lot of memory for large blobs.

To minimize the chances of OOM errors and speed up the query, one thing you can do is pare down the HTML to the area of interest using only the most basic regular expressions. Since the capo script is only concerned with the <head> element, I grabbed everything up to the closing </head> tag:

httparchive.fn.CAPO(
  REGEXP_EXTRACT(
    response_body,
    r'(?i)(.*</head>)'
  )
)

If there are no natural "breakpoints" in the document for your use case, you could also consider restricting the input to a certain character length like WHERE LENGTH(response_body) < 1000. The query will work and it'll run more quickly, but the results will be biased towards smaller pages.

Also, some documents may not be able to be parsed at all, resulting in exceptions. I added try/catch blocks to the UDF to intercept any exceptions and return null instead.

That also means that your query needs to be able to handle null values instead. For example, to get the first <head> element from the results, I needed to use SAFE_OFFSET instead of plain old OFFSET to avoid breaking the query on null values: elements[SAFE_OFFSET(0)].

Wrapping up

Cheerio is a really powerful new tool in the HTTP Archive toolbox. It unlocks new types of analysis that used to be prohibitively complex. In the capo.sql use case, I was able to extract insights about pages' <head> elements that would have only been possible with custom metrics on future datasets.

I'm really interested to see what new insights are possible with this approach. Let me know your thoughts in the comments and how you plan to use it.

Simulating real users in the lab to debug CLS issues

Rick Viscomi — Fri, 16 Jul 2021 16:46:29 +0000

A developer on Stack Overflow posted this question and it went something like this:

Search Console is telling me that one of my pages has poor Cumulative Layout Shift (CLS). When I visit PageSpeed Insights to debug the issue, the lab data from Lighthouse is reporting a perfect CLS score of 0.0. I'm frustrated. What do I do?

Here was my response.

CLS can be a difficult metric to debug using lab tools like Lighthouse because they only evaluate the initial viewport by default. In other words, they don't behave like a real user. When a real user lands on a page, they scroll around and click on things.

So when trying to debug Core Web Vitals issues, especially for CLS, I'd recommend visiting the page yourself with a diagnostic tool like the Web Vitals extension for Chrome enabled.

I visited the page and after just a second of using it I was able to incur a substantial layout shift (0.484) by scrolling the page down:

It seems like what's happening is that the ad below "category : humour" is injected into the page, and all of the contents below it shift down.

To reproduce this, I used WebPageTest to simulate the real-user behavior of scrolling the page down.

Go to webpagetest.org
Enter your URL
Go to the "Advanced" tab of the Advanced Settings section

Under "Inject Script", enter this code to scroll the page by 500px:

window.addEventListener('DOMContentLoaded', function() {
  window.scrollBy(0, 500);
});

Start the test

You can see the results here.

The filmstrip view above and video demonstrate the problem. After the page partially loads and is scrolled down at the 8 second mark, we can see that the ad asynchronously loads and pushes the content below it down, incurring a layout shift with a score of 0.409, enough to cause the page experience to be evaluated as "poor".

If most of your users behave like this by scrolling down shortly after the page loads, that could be why your 75th percentile CLS score is in the "poor" category.

To fix these kinds of layout shifts caused by ads, refer to the suggestions at https://web.dev/optimize-cls/#ads-embeds-and-iframes-without-dimensions:

Ads are one of the largest contributors to layout shifts on the web. Ad networks and publishers often support dynamic ad sizes. Ad sizes increase performance/revenue due to higher click rates and more ads competing in the auction. Unfortunately, this can lead to a suboptimal user experience due to ads pushing visible content you're viewing down the page.

Introducing the Core Web Vitals Technology Report

Rick Viscomi — Thu, 24 Jun 2021 16:02:56 +0000

The technologies you use to build your website can have an effect on your ability to deliver good user experiences. Good UX is key to performing well with Core Web Vitals (CWV), a topic which is probably top of mind for you, as it is for many other web developers now that these metrics play a role in Google Search ranking. While web developers have had tools like Search Console and PageSpeed Insights to get data on how their sites are performing, the web community has been lacking a tool that has operated at the macro level, giving us something more like WebSpeed Insights. By combining the powers of real-user experiences in the Chrome UX Report (CrUX) dataset with web technology detections in HTTP Archive, we can get a glimpse into how architectural decisions like choices of CMS platform or JavaScript framework play a role in sites' CWV performance. The merger of these datasets is a dashboard called the Core Web Vitals Technology Report.

This dashboard was developed for the web community to have a shared source of truth for the way websites are both built and experienced. For example, the CWV Technology Report can tell you what percentage of websites built with WordPress pass the CWV assessment. While a number like this on its own is interesting, what's more useful is the ability to track this over time and compare it to other CMSs. And that's exactly what the dashboard offers; it's an interactive way to view how websites perform, broken down by nearly 2,000 technologies.

This post is a show-and-tell. First I'd like to walk you through the dashboard and show you how to use it, then I'll tell you more about the data methodology behind it.

Using the dashboard

There are three pages in the dashboard:

Technology drilldown
Technology comparison
Settings

The drilldown page lets you see how desktop and mobile experiences change over time for a single technology. The default metric is the percent of origins having good CWV, and it also supports individual CWV metrics (see the "Optional metrics" section below).

The comparison page lets you compare desktop OR mobile experiences for any number of technologies over time. Similar to the drilldown page, you can select overall CWV compliance or individual CWV metrics. Additionally, this page supports visualizing the number of origins per technology.

The settings page is where you can configure report-level preferences. There are currently two settings: categories and number of origins. Refer to Wappalyzer for the list of possible categories. Use this setting to limit the related technologies in the dropdown list. You can also restrict the technologies to those with a minimum level of adoption, for example those used by at least 100 websites. This can be helpful to reduce noisiness.

By default, the CWV Technology Report is configured to drill down into WordPress performance and compare WordPress, Wix, and Squarespace. This is to demonstrate the kinds of insights that are possible out-of-the-box without having to know how to configure the dashboard yourself. The full URL for the vanilla version of the dashboard is https://datastudio.google.com/reporting/55bc8fad-44c2-4280-aa0b-5f3f0cd3d2be/page/M6ZPC.

Optional metrics

You can also use the "optional metrics" feature of Data Studio to customize the dashboard and select specific CWV stats in the charts/tables as needed. The icon that looks like a chart with a gear icon is the button to select optional metrics. In the timeseries chart, you can toggle between the percent of origins having good CWV overall or specifically those with good LCP, FID, or CLS. On the table views, you can use this feature to add or remove columns, for example to see all CWV metrics separately or to focus on just one.

Data Studio also enables you to share deep links into the dashboard for specific configurations. For example, here's a leaderboard of the top 10 most popular CMSs ordered by CWV performance as of May 2021:

Date	Technology	Origins	Percent good CWV
May 2021	1C-Bitrix	35,385	56.30%
May 2021	TYPO3 CMS	24,060	54.39%
May 2021	Drupal	115,280	45.11%
May 2021	Zendesk	34,713	43.26%
May 2021	Weebly	15,920	33.35%
May 2021	Squarespace	60,316	33.32%
May 2021	Joomla	44,459	32.19%
May 2021	Wix	54,604	31.52%
May 2021	Adobe Experience Manager	15,276	27.65%
May 2021	WordPress	1,731,010	24.53%

Here are some other configurations to help you explore the data:

Feature roadmap

There are two features missing from the dashboard that I would love to add in the near future: segmenting by CrUX rank magnitude and comparing Lighthouse audit compliance. Origin popularity would be a really interesting way to slice the data and the rank magnitude dimension would enable us to see how technology adoption and CWV performance change at the head, torso, and tail of the web. Adding data from Lighthouse would enable us to get some clues into why a particular technology may be better or worse with CWV. For example, if a group of websites tend to have poor LCP performance, it'd be interesting to see what loading performance audits they also tend to fail. Of course there are so many variables at play and we can't determine cause and effect, but these results could give us something to think about for further exploration.

Methodology

The CWV Technology Report is a combination of two data sources: CrUX and HTTP Archive. They are similar datasets in that they measure millions of websites, but they have their own strengths and weaknesses worth exploring.

CrUX is a field tool, meaning that it measures real-user experiences. It's also a public dataset, so you could see how users experience any one of over 8 million websites. This is really cool, to put it loosely, because we (as a community) have visibility into how the web as a whole is being experienced.

The CrUX dataset is powered by Chrome users who enable usage statistics reporting. Their experiences on publicly discoverable websites are aggregated together over 28-day windows and the results are published in queryable monthly data dumps on BigQuery and via the CrUX API, updated daily. CrUX measures users' experiences for each of the CWV metrics: LCP, FID, and CLS. Using this data, we can evaluate whether the website passes the CWV assessment if 75 percent of experiences for each metric are at least as good as thresholds set by the Web Vitals program.

HTTP Archive is a lab tool, meaning that it measures how individual web pages are built. Like CrUX, it's a public dataset, and it's actually based on the same websites in the CrUX corpus, so we have perfect parity when combining the two sources together. HTTP Archive is powered by WebPageTest, which integrates with other lab tools like Lighthouse and Wappalyzer to extract fine-grained data about the page. Lighthouse runs audits against the page to determine how well-optimized it is, for example if it takes advantage of web performance best practices. Wappalyzer is an open-source tool that detects the use of technologies like an entire CMS, a specific JavaScript library, and even what programming languages are probably used on the backend. These detections are what we use in the CWV Technology Report to segment the real-user experience data from CrUX.

Confession time! This isn't the first tool to look at CrUX data through the lens of how websites are built. Perf Track is a report built by Houssein Djirdeh that slices CrUX data by JavaScript frameworks. The annual CMS chapter of the Web Almanac slices CrUX data by (you guessed it) CMSs. What makes the CWV Technology Dashboard different is that it facilitates exploration of the data by making all 1,950 technologies across 71 categories discoverable in a single, browseable UI. You can choose your own adventure by filtering technologies to a single category, like Ecommerce, and comparing platforms head-to-head to see which has more websites passing the CWV assessment.

The CrUX dataset on BigQuery is aggregated at the origin level. An origin is a way to identify an entire website. For example, https://httparchive.org is the origin for the HTTP Archive website and it's different from https://almanac.httparchive.org, which is a separate origin for the Web Almanac website.

HTTP Archive measures individual web pages, not entire websites. And due to capacity limitations, HTTP Archive is limited to testing one page per website. The most natural page to test for a given website is its home page, or the root page of the origin. For example, the home/root page of the HTTP Archive website is https://httparchive.org/ (note the trailing slash). This introduces an important assumption that we make in the CWV Technology Dashboard: an entire website's real-user experiences are attributed to the technologies detected only on its home page. It's entirely possible that many websites we test use different technologies on their interior pages, and some technologies may even be more or less likely to be used on home pages. These biases are worth acknowledging in the methodology for full transparency, but to be honest there's not a lot we at HTTP Archive can do to mitigate them without becoming a full-blown web crawler!

Core Web Vitals

There may be different approaches to measure how well a website or group of websites performs with CWV. The approach used by this dashboard is designed to most closely match the CWV assessment in PageSpeed Insights. CWV metrics and thresholds may change annually, but we'll do our best to keep the dashboard in sync with the state of the art.

Each individual CWV metric has a threshold below which user experiences are considered "good". For example, LCP experiences under 2.5 seconds are good. A website must have at least 75% of its LCP experiences in the "good" category to be considered as having good LCP overall. If all of the CWV metrics are good, the website is said to pass the CWV assessment. Refer to the official CWV documentation for the latest guidance on the set of metrics and thresholds.

FID is an exception worth mentioning. Because it relies on user input to be measured, it doesn't occur on as many page loads as metrics like LCP and CLS. That makes it less likely to have sufficient data for pages that may not have many interactive UI elements or websites with low popularity. So the CWV Technology Dashboard replicates the behavior in PageSpeed Insights and assesses a website's CWV, even in the absence of FID data. In that case, if LCP and CLS are good, the website passes, otherwise it doesn't. In the rare case that a website is missing LCP or CLS data, it's not eligible to be assessed at all.

When evaluating a group of origins, like those in the dashboard that all use the same technology, we quantify them in terms of the percentage of origins that pass the CWV assessment. This is not to be confused with the percentage of users or the percentage of experiences. Origins are aggregated in CrUX in a way that doesn't make it meaningful to combine their distributions together. So instead, we count origins as a unit: those that use jQuery, pass the CWV assessment, have sufficient FID data, have good LCP, etc.

The CrUX dataset includes a form_factor dimension representing the type of device the user was on. We segment all of the data in the dashboard by this dimension and call it the "Client", with values of either desktop or mobile.

Querying the raw data

The dashboard is implemented in Data Studio with a BigQuery connector to power all of the technology and CWV insights. The underlying table on BigQuery is made publicly available at httparchive.core_web_vitals.technologies. Feel free to query this table directly to extract information about specific technology trends, or even to build your own custom dashboards or visualizations.

For reference, this is the query that generated the core_web_vitals.technologies table:

CREATE TEMP FUNCTION IS_GOOD(good FLOAT64, needs_improvement FLOAT64, poor FLOAT64) RETURNS BOOL AS (
  good / (good + needs_improvement + poor) >= 0.75
);

CREATE TEMP FUNCTION IS_NON_ZERO(good FLOAT64, needs_improvement FLOAT64, poor FLOAT64) RETURNS BOOL AS (
  good + needs_improvement + poor > 0
);

WITH unique_categories AS (
SELECT
  ARRAY_AGG(DISTINCT LOWER(category)) AS categories
FROM
  `httparchive.technologies.2021_05_01_mobile`
)

SELECT
  date,
  ARRAY_TO_STRING(ARRAY_AGG(DISTINCT category IGNORE NULLS ORDER BY category), ', ') AS categories,
  app,
  client,
  COUNT(DISTINCT url) AS origins,
  COUNT(DISTINCT IF(good_fid, url, NULL)) AS origins_with_good_fid,
  COUNT(DISTINCT IF(good_cls, url, NULL)) AS origins_with_good_cls,
  COUNT(DISTINCT IF(good_lcp, url, NULL)) AS origins_with_good_lcp,
  COUNT(DISTINCT IF(any_fid, url, NULL)) AS origins_with_any_fid,
  COUNT(DISTINCT IF(any_cls, url, NULL)) AS origins_with_any_cls,
  COUNT(DISTINCT IF(any_lcp, url, NULL)) AS origins_with_any_lcp,
  COUNT(DISTINCT IF(good_cwv, url, NULL)) AS origins_with_good_cwv,
  COUNT(DISTINCT IF(any_lcp AND any_cls, url, NULL)) AS origins_eligible_for_cwv,
  SAFE_DIVIDE(COUNTIF(good_cwv), COUNTIF(any_lcp AND any_cls)) AS pct_eligible_origins_with_good_cwv
FROM (
  SELECT
    date,
    CONCAT(origin, '/') AS url,
    IF(device = 'desktop', 'desktop', 'mobile') AS client,
    IS_NON_ZERO(fast_fid, avg_fid, slow_fid) AS any_fid,
    IS_GOOD(fast_fid, avg_fid, slow_fid) AS good_fid,
    IS_NON_ZERO(small_cls, medium_cls, large_cls) AS any_cls,
    IS_GOOD(small_cls, medium_cls, large_cls) AS good_cls,
    IS_NON_ZERO(fast_lcp, avg_lcp, slow_lcp) AS any_lcp,
    IS_GOOD(fast_lcp, avg_lcp, slow_lcp) AS good_lcp,
    (IS_GOOD(fast_fid, avg_fid, slow_fid) OR fast_fid IS NULL) AND
    IS_GOOD(small_cls, medium_cls, large_cls) AND
    IS_GOOD(fast_lcp, avg_lcp, slow_lcp) AS good_cwv
  FROM
    `chrome-ux-report.materialized.device_summary`
  WHERE
    date >= '2020-01-01'
) JOIN (
  SELECT DISTINCT
    CAST(REGEXP_REPLACE(_TABLE_SUFFIX, r'(\d)_(\d{2})_(\d{2}).*', r'202\1-\2-\3') AS DATE) AS date,
    IF(category != '' AND LOWER(category) IN UNNEST((SELECT categories FROM unique_categories)), category, NULL) AS category,
    app,
    IF(ENDS_WITH(_TABLE_SUFFIX, 'desktop'), 'desktop', 'mobile') AS client,
    url
  FROM
    `httparchive.technologies.202*`
  WHERE
    app IS NOT NULL AND
    app != ''
) USING (date, url, client)
GROUP BY
  date,
  app,
  client

The most idealistic goal for this dashboard is to empower influencers in the web community to make improvements to swaths of websites at scale. Web transparency projects like this one are meant to inform and inspire, whether that's instilling a sense of competitiveness with other related technologies to climb the leaderboard or giving them actionable data to make meaningful improvements to technologies under their control. Please leave a comment if you have any suggestions to help make the CWV Technology Report better!

Introducing the second annual Web Almanac!

Rick Viscomi — Tue, 22 Dec 2020 15:23:49 +0000

The 2020 Web Almanac is a free, open-source, community-made ebook whose mission is to annually track the state of the web. This report is for everyone who's ever wondered how big a typical web page is nowadays, or what the most common CSS breakpoints are, or the most popular CMS. Those questions and many more are answered in this comprehensive, data-driven research project sourced from over 7 million websites.

Experts in over 20 web disciplines researched and wrote chapters covering the components web pages are made of, how users experience them, how developers publish them, and how they're delivered. The 2020 report is out and I'm excited to share it with you all! (Read the 2019 announcement on dev.to.)

This year over 100 contributors have collaborated on the report: analyzing data, authoring chapters, peer-reviewing, editing, translating, and maintaining the website. This project was only made possible through the hard work by all of the contributors collectively. The result is a free 500+ page ebook that you can read on our website, as a PDF (22 MB), or on Google Play or Google Books. Translations are in progress in nine languages, and the 2019 edition is completely translated into Japanese with its own ebook!

This is a community effort and we're a friendly, inclusive group, so if you'd like to be a part of the 2019-2020 translation effort or help write the 2021 edition, we'd love for you to join us! Please fill out this interest form to let us know how you'd like to contribute, and we'll reach out to you when it's time to start planning in mid-2021.

Give it a read and let us know what you find most interesting or surprising! Here's what's inside:

Part I. Page Content

Part II. User Experience

Part III. Content Publishing

Part IV. Content Distribution

Appendices

(Chapters 5 and 16, Media and Ecommerce, are coming soon!)

The mythical "fast" web page

Rick Viscomi — Tue, 01 Dec 2020 19:04:34 +0000

Web performance can mean a lot of different things to a lot of different people. Fundamentally, it's a question of how fast a web page is. But fast to whom?

When this page loaded moments ago, was it fast? If so, congratulations, you had a fast experience. So ask yourself, does that make this a fast page? Not so fast! Just because you had a fast experience doesn't mean everyone else does too. You might even revisit this page and have yourself a slow experience.

Let's say that you and everyone else who load this page all have fast experiences. Surely that makes it a fast page, right? Most people would agree. Hypothetically, what if everyone's internet speeds get 100x slower overnight? Now, all experiences on this page are suddenly slow. Is this page, which is byte-for-byte identical as it was yesterday, still fast?

Fast is a concept that exists in the minds of users as they browse the web. It's not that the page is fast—the experience is fast.

Ok, that's enough philosophy. Why does it matter? Because there's a difference between a page that's built for speed and a page that feels fast. A svelte page could feel slow to someone having network issues. A heavily unoptimized page could feel fast to someone on high-end hardware. The proportions of those types of users can determine how fast a page is experienced in aggregate, even more so than how well-optimized it actually is.

How you approach measuring a web page's performance can tell you whether it's built for speed or whether it feels fast. We call them lab and field tools. Lab tools are the microscopes that inspect a page for all possible points of friction. Field tools are the binoculars that give you an overview of how users are experiencing the page.

A lab tool like WebPageTest or Lighthouse can tell you thousands of facts about how the page was built and how quickly the page loaded from its perspective. This makes lab tools irreplaceable for inspecting and diagnosing performance issues. You can visualize every step of the page load and drill down into what's holding it up. Lab tools can even make informed recommendations for things they think you should fix, saving you the investigative time and effort. But despite their advantages, lab tools can lead you astray in subtle ways.

Similar to the problem of your fast experience not necessarily reflecting everyone else's, your lab test might not be configured like most users in two important ways: access and behavior. A lab tool accesses a web page from a specific hardware and network configuration, which can greatly affect the page's loading performance. A lab tool might not behave in ways that mimic real users either, for example the test might not be logged in, scroll the page after it loads, nor click on buttons.

This problem is becoming more and more apparent as developers rightly focus on user-centric metrics. Core Web Vitals represent a few distinct aspects of a good user experience: loading performance, input responsiveness, and layout stability. These are measured by Largest Contentful Paint (LCP), First Input Delay (FID), and Cumulative Layout Shift (CLS) respectively. So what could go wrong with measuring these metrics in the lab?

LCP is the time that the biggest content loaded on screen. The times at which things load can be highly dependent on how fast the network is, so the lab configuration can produce wildly different LCP values based on its bandwidth and latency settings. Large content like images may also be cached and immediately available for some users, but lab tests tend to run with empty caches, necessitating another trip over the network.

FID is the delay from first interacting with the page, like a click, to the time that the browser is ready to respond to it. The main thread could be so busy with script execution or DOM construction that the event handler has to wait its turn. The obvious limitation with testing a page in the lab is that there aren't any users to interact with it! There are diagnostic metrics for interactivity in the lab, like Total Blocking Time (TBT), but these don't actually measure the user experience. We can fake FID and simulate a user's click, but the questions of what to click and when to click it can be very subjective.

CLS is roughly the proportion of the viewport that shifted as a result of layout instability. A layout could have a moment of instability when elements are suddenly added or removed and the positions of neighboring contents shift. Because the layout shift score is a proportion of the viewport, CLS can be very different between phones and desktops. The type of device used or emulated in the lab directly affects how CLS is calculated. There's another issue having to do with user behavior: when to stop measuring. Lab tools tend to stop when the page is loaded, but real users are just getting started interacting with the page and potentially incurring many more layout shifts. Real users scroll and click and trigger new sorts of conditions that contribute to layout instability. Simulating these behaviors in the lab would be closer to reality but it has similar challenges to FID.

This is why field data is the ground truth for how a page is experienced. At best we can only simulate user experiences in the lab, and we'd still be hypothesizing how a user would access a page and how they'd behave once they get there.

But wait! What if we calibrate our lab configurations based on real-user data from the field? This isn't a new idea; developers have been calibrating access factors like geographic location, browser, and network speed based on field data for years. But now it's more important than ever to calibrate behavior as well. For example, we can use analytics to see what users tend to click on first and when they click on it.

Some lab tools like WebPageTest are advanced enough to be able to script that behavior into the test. But a popular tool like PageSpeed Insights (PSI) has no configurability beyond plugging in the URL you want to test, so you need to take its lab results with a grain of salt. Keep in mind that performance is a distribution, and one lab test is just a single contrived data point.

Fear not, even unrealistic lab tests can still be useful. One practical application of this is to test for worst case scenarios. You may not be able to say with certainty that anyone who visits your page will have a fast experience, but if you can make it seem fast under even the slowest conditions, that goes a long way. Stress testing your page's performance by using (or emulating) low-end hardware over strained network speeds is a great way to magnify the power of the microscope to bring more performance problems into focus. This is an opportunity to fix issues before users may even experience them.

What if users aren't experiencing this slow performance because they're conditioned not to? An experience can be so poor that the user abandons it before it gets any worse. They may never come back to the site at all, in which case your field data has survivorship bias where only the bearably slow experiences are measured. How many unbearably slow experiences aren't you measuring? And you thought we were done with the philosophical questions!

Let's stop here and recap:

Individual experiences are just data points along a distribution. What feels fast depends on the conditions under which it was experienced. Everyone's conditions are different.
Lab tests may not be configured to be representative of the most common experiences on the curve, or any experience on the curve for that matter.
User-centric metrics require extra care to ensure that behaviors are emulated faithfully in the lab.

As a web development community, we need to change more than just our mindset about "fast" web pages. It's not enough to be aware of the pitfalls that can lead us astray: to avoid them requires a concerted effort between the makers and users of performance testing tools.

Lab tools must be configurable to access and behave like real users. There is no one-size-fits-all lab configuration that represents how users experience all pages. Developers need to be active participants in the configuration process—not necessarily down to the Mbps of bandwidth, but they should make high-level decisions about what type of user they're simulating in the lab. This could be a manual guessing game, but at least developers are made more conscious of the relevance of the results.

An even better solution would be to build stronger data bridges between field and lab tools, so that the lab tool itself can make informed recommendations about the most realistic user profiles to simulate.

We're at an exciting inflection point in the power of developer tooling. As newer metrics focus on how pages are experienced from users' perspectives, we have an opportunity to rethink and reshape the ways our tools help us to measure and optimize them. By instrumenting lab tools with the behavioral characteristics of real users, we can unlock new opportunities to improve experiences beyond the page load.

Making a custom CrUX Dash shortcut in Chrome

Rick Viscomi — Tue, 22 Sep 2020 15:11:18 +0000

The CrUX Dashboard is a really easy way to see how real users experience the web, with data available for millions of websites. For developers who want to quickly jump into the CrUX Dashboard for a website, I made the CrUX Dash Launcher, a tiny web app that takes an origin and redirects you to its dashboard, by taking advantage of URL parameters.

Now there's an even easier way to launch into a customized CrUX Dashboard, using Chrome search shortcuts. Setting it up is almost as easy, as I've done here in under a minute:

Here's how to set it up yourself:

Go to chrome://settings/searchEngines

Click Add and enter the following URL:

https://datastudio.google.com/c/u/0/reporting/bbc5698d-57bb-4969-9e07-68810b9fa348/page/keDQB?params=%7B%22origin%22:%22%s%22%7D

Set the search engine to CrUX Dashboard and the keyword to something unique and easy to type like cruxdash

Now you can start typing cruxdash in the URL bar, and after pressing the <Space> key, it should prompt you to "Search CrUX Dashboard". Enter any website's origin (scheme, subdomain, and domain), eg https://dev.to, and press enter to be taken directly to a custom CrUX Dashboard for that website. Voila!

The 2019 Web Almanac is now available as a free ebook!

Rick Viscomi — Sat, 23 May 2020 22:02:41 +0000

Last year 29 subject matter experts from the web community came together in a massive effort to document the state of the web, called the Web Almanac. They wrote about 20 topics in the areas of page content, user experience, content publishing, and distribution. Chapters include JavaScript, CSS, Performance, SEO, Ecommerce, CMS, CDN, HTTP/2, and many more.

Now you can download an ebook of the entire 2019 edition (for free). It's 421 pages and 18 MB of solid research and analysis from trusted web experts packaged up for ergonomic e-reading. We've also translated the entire contents into Japanese. Or if you'd prefer to browse the content on the web, you can always visit almanac.httparchive.org.

The mission of the Web Almanac project is to document and raise awareness of the state of the web using the huge amounts of data from millions of websites in the HTTP Archive. This project is invaluable to understanding how the web is trending and the areas in which we need to be doing better. I hope you check it out!

YEStifications: Exploring how users engage with notification prompts in the Chrome UX Report

Rick Viscomi — Tue, 11 Feb 2020 23:02:58 +0000

📢 example.com wants to show notifications

Notifications can be an effective way to keep users engaged, but many websites are unable to get users past the permission prompt. A common problem is prompting out of context, as soon as the page loads or without an explanation of how they will be used. So how do users tend to engage with these permission prompts? CrUX to the rescue.

The Chrome UX Report (CrUX) now includes data from 30,000 websites on users' engagement with notification prompts. The data is made available in a public BigQuery repository, which we'll explore in this post to see how users engage with prompts across the web. Let's dive in!

The state of notification permissions

For starters, let's get a feel for the number of websites we're working with in this dataset.

SELECT
  COUNT(DISTINCT origin)
FROM
  `chrome-ux-report.all.202001`
WHERE
  experimental.permission.notifications IS NOT NULL

The results show that there are 31,515 origins with permission data. An origin is the top-level address of a website, everything before the first "/" of the path, like https://www.example.com. User experience data from pages on the same website are all rolled up at the origin level.

Now let's look at the permission data for a single website, for example Slack.

SELECT
  SUM(experimental.permission.notifications.accept) AS accept,
  SUM(experimental.permission.notifications.dismiss) AS dismiss,
  SUM(experimental.permission.notifications.deny) AS deny,
  SUM(experimental.permission.notifications.ignore) AS `ignore`
FROM
  `chrome-ux-report.all.202001`
WHERE
  origin = 'https://app.slack.com'

Accept	Dismiss	Deny	Ignore
92.10%	5.67%	1.96%	0.28%

As you can see, the Slack app has a very good permission acceptance rate for their notification prompts at 92%. In other words, 92% of users who get the prompt end up granting Slack permission to show them notifications. About 6% of users close the prompt without explicitly deciding one way or the other, 2% of users explicitly disallow Slack from showing them notifications, and ~0% of users leave the prompt entirely untouched.

But how representative is Slack of the experience across the web? Let's zoom out and see how all 30,000 websites stack up.

SELECT
  origin,
  SUM(experimental.permission.notifications.accept) AS accept,
  SUM(experimental.permission.notifications.dismiss) AS dismiss,
  SUM(experimental.permission.notifications.deny) AS deny,
  SUM(experimental.permission.notifications.ignore) AS `ignore`
FROM
  `chrome-ux-report.all.202001`
WHERE
  experimental.permission.notifications IS NOT NULL
GROUP BY
  origin
ORDER BY
  `ignore` ASC,
  accept DESC

What are we looking at here? The curved gray area on the top right of the chart shows the distribution of ignores across all websites with permission data. Next, the red area taking up the most space in the middle of the chart represents the proportion of user engagements that reject the permission prompt. The green area that curves down from the left edge of the chart represents the proportion of user engagements that accept the prompt. And the remaining yellow area between accept and deny is the dismissal rate.

We can draw a couple of insights from this visualization:

Most glaringly, there's a lot of red and not a lot of green in this chart. Users are highly likely to be denying notification permission prompts rather than accepting them. Slack is an extreme example of an outlier website with a high acceptance rate.
There seems to be an inverse correlation between deny and ignore rates. As sites have smaller deny rates, their ignore rates increase. We could interpret the lack of prompt interaction as an implicit rejection of permission.

So if Slack is such an outlier, what does a typical website look like?

SELECT
  AVG(accept / total) AS accept,
  AVG(dismiss / total) AS dismiss,
  AVG(deny / total) AS deny,
  AVG(`ignore` / total) AS `ignore`
FROM (
  SELECT
    SUM(experimental.permission.notifications.accept) AS accept,
    SUM(experimental.permission.notifications.deny) AS deny,
    SUM(experimental.permission.notifications.ignore) AS `ignore`,
    SUM(experimental.permission.notifications.dismiss) AS dismiss,
    SUM(experimental.permission.notifications.accept +
        experimental.permission.notifications.deny +
        experimental.permission.notifications.ignore +
        experimental.permission.notifications.dismiss) AS total
  FROM
    `chrome-ux-report.all.202001`
  WHERE
    experimental.permission.notifications IS NOT NULL)

Accept	Dismiss	Deny	Ignore
16.71%	23.84%	40.74%	18.71%

This is a more realistic view of the state of notification permissions. Keep in mind that we're averaging the UX for many websites together, even if they have drastically different numbers of users. So this is showing us that the average website has a notification prompt acceptance rate of 17%, 24% dismissal, 41% rejection, and 19% ignore.

What else can we learn about user behavior from this dataset? We could also slice this average distribution by users' device form factor.

SELECT
  device,
  AVG(accept / total) AS accept,
  AVG(dismiss / total) AS dismiss,
  AVG(deny / total) AS deny,
  AVG(`ignore` / total) AS `ignore`
FROM (
  SELECT
    form_factor.name AS device,
    SUM(experimental.permission.notifications.accept) AS accept,
    SUM(experimental.permission.notifications.deny) AS deny,
    SUM(experimental.permission.notifications.ignore) AS `ignore`,
    SUM(experimental.permission.notifications.dismiss) AS dismiss,
    SUM(experimental.permission.notifications.accept +
        experimental.permission.notifications.deny +
        experimental.permission.notifications.ignore +
        experimental.permission.notifications.dismiss) AS total
  FROM
    `chrome-ux-report.all.202001`
  WHERE
    experimental.permission.notifications IS NOT NULL
  GROUP BY
    device)
GROUP BY
  device
ORDER BY
  accept DESC

Device	Accept	Dismiss	Deny	Ignore
phone	22.76%	18.03%	57.33%	1.88%
tablet	18.75%	20.24%	58.34%	2.67%
desktop	6.11%	34.01%	11.61%	48.27%

Ok this is significant. There is a huge difference in engagement between phones and desktops. Phone users are very unlikely to ignore the prompt, whereas desktop users ignore the prompt about half the time on average. The simplest explanation is screen size; it's a lot harder to ignore a prompt when it's taking up a larger portion of your screen. Interestingly, despite the 57% rejection rate, phone users are the most likely to accept permission prompts, at 23%, compared to just 6% on desktop. One explanation may be that a phone is a much more natural and convenient form factor on which to receive notifications because it goes where you go.

Where we go from here

Users have been feeling the frustration of intrusive notification prompts and developers have only anecdotally heard about and experienced this frustration. Now we have actionable data to shed light on the quality of experience across the web. And it's clear from the CrUX data that relatively few websites are effectively enrolling users in notifications.

The Chrome team has announced that it is rolling out changes to how prompts are shown to users to minimize frustration, saying "sites with very low acceptance rates will be automatically enrolled in quieter prompts". So it's especially important for site owners to be aware of their prompt performance.

If your site requests permission to show notifications, add instrumentation so you can monitor the response rates. The CrUX dataset is not a substitute for your own UX monitoring, but it can be helpful for filling in gaps, seeing how similar websites are performing, and tracking the trends across the web. Read up on best practices for requesting permission to improve your response rates and get more yestifications than notifications. 🥁

The queries shown in this post can be run on BigQuery. You're strongly encouraged to remix the queries to discover your own insights. Read more about using CrUX on BigQuery to get started. If you have any questions or feedback about the data, the CrUX team would love to hear from you on any of these channels:

chrome-ux-report on Google Groups
@ChromeUXReport on Twitter
questions tagged with chrome-ux-report on StackOverflow
GoogleChrome/CrUX on GitHub

I created the Web Almanac. Ask me anything about the state of the web!

Rick Viscomi — Sun, 24 Nov 2019 02:17:24 +0000

Hi everyone! I'm doing my first AMA to get people thinking about the state of the web.

My day job for the past ~2 years has been web developer relations at Google. Prior to that I worked on web performance for ~4 years at YouTube. In my current role I'm a steward of web transparency datasets like the HTTP Archive and Chrome UX Report projects. Web transparency is all about cultivating a public body of knowledge about how the web is built and experienced. I also host a video series called the State of the Web where I interview members of the community about web trends and technologies. My job takes me all around the world to meet with developers at conferences, share transparency data, and hear their stories about building on the web.

The big project I've been working on this year is the Web Almanac, the first annual edition of HTTP Archive's report on the state of the web, which launched at Chrome Dev Summit last week. I led the project and coordinated with 80+ community contributors to build everything from scratch (planning/writing content, researching stats, developing the website, etc). The end result is a massive resource that sheds a light on how the web is doing at the scale of millions of websites.

Here are some of the interesting insights from each chapter:

If you find any of this interesting, I'd love to hear your questions about web transparency, the state of the web, the Almanac project, or anything. AMA!

The Web Almanac 2019 is live!

Rick Viscomi — Mon, 11 Nov 2019 05:41:29 +0000

I finally get to share with everyone what I've been working on for so long! It's called the Web Almanac and it's a free, open source, community-made "state of the web" report.

What's the Web Almanac?

Here is an excerpt of the foreword I wrote:

The open web is an amazingly complex, evolving network of technologies. Entire industries and careers are built on the web and depend on its vibrant ecosystem to succeed. As critical as the web is, understanding how it's doing has been surprisingly elusive. Since 2010, the mission of the HTTP Archive project has been to track how the web is built, and it's been doing an amazing job of it. However, there has been one gap that has been especially challenging to close: bringing meaning to the data that the HTTP Archive project has been collecting and enabling the community to easily understand how the web is performing. That's where the Web Almanac comes in.

The mission of the Web Almanac is to take the treasure trove of insights that would otherwise be accessible only to intrepid data miners, and package it up in a way that's easy to understand. This is made possible with the help of industry experts who can make sense of the data and tell us what it means. Each of the 20 chapters in the Web Almanac focuses on a specific aspect of the web, and each one has been authored and peer reviewed by experts in their field. The strength of the Web Almanac flows directly from the expertise of the people who write it.

Many of the findings in the Web Almanac are worthy of celebration, but it's also an important reminder of the work still required to deliver high-quality user experiences. The data-driven analyses in each chapter are a form of accountability we all share for developing a better web. It's not about shaming those that are getting it wrong, but about shining a guiding light on the path of best practices so there is a clear, right way to do things. With the continued help of the web community, we hope to make this an annual tradition, so each year we can track our progress and make course corrections as needed.

There is so much to learn in this report, so start exploring and share your takeaways with the community so we can collectively advance our understanding of the state of the web.

What's inside

There are 20 chapters organized into four main parts exploring different aspects of the web.

Part I. Page Content

Chapter 1. JavaScript
Chapter 2. CSS
Chapter 3. Markup
Chapter 4. Media
Chapter 5. Third Parties
Chapter 6. Fonts

Part II. User Experience

Chapter 7. Performance
Chapter 8. Security
Chapter 9. Accessibility
Chapter 10. SEO
Chapter 11. PWA
Chapter 12. Mobile Web

Part III. Content Publishing

Chapter 13. Ecommerce
Chapter 14. CMS

Part IV. Content Distribution

Chapter 15. Compression
Chapter 16. Caching
Chapter 17. CDN
Chapter 18. Page Weight
Chapter 19. Resource Hints
Chapter 20. HTTP/2

Who made it

The Web Almanac is a community effort. 85 people have contributed to the project to write, peer review, edit, and translate content, analyze and visualize the data, and build and design the website. This was an enormous effort that couldn't be done without everyone's help. You can check out each and every one of them on the Contributors page to see where they helped.

I assumed the role of ring leader to help guide everyone to today's launch :) (And I must say I think it went really well, considering the number of people to herd!)

How was it made

The Methodology page goes into all the detail of how the process worked and where the results come from. There are so many amazing pieces of technology that went into this report, spanning data from over 5 million websites and consuming terabytes of queryable storage.

What's next

I don't want us to stop here. The web is constantly changing with new technologies and evolving adoption. I would love to see this renewed each year with fresh perspectives from different members of the community offering their take on the state of the web.

If you're interested in joining us, please fill out this form and subscribe to our GitHub repository.

In order to make the web a better place, we need to observe, quantify, and analyze it over time to make sure we're heading in the right direction. Join us for next year's Web Almanac 2020 edition!

Fixing layout instability

Rick Viscomi — Wed, 18 Sep 2019 21:32:50 +0000

In an earlier post I wrote about measuring Cumulative Layout Shift (CLS) in WebPageTest. CLS is an aggregation of all layout shifts, so in this post I thought it'd be interesting to dive deeper and inspect each individual layout shift on a page to try to understand what could be causing the instability and actually try to fix the issue(s).

Measuring layout shifts

Using the Layout Instability API, we can get a list of all layout shift events on a page:

new Promise(resolve => {
  new PerformanceObserver(list => {
    resolve(list.getEntries().filter(entry => !entry.hadRecentInput));
  }).observe({type: "layout-shift", buffered: true});
}).then(console.log);

This produces an array of layout shifts that are not preceded by input events:

[
  {
    "name": "",
    "entryType": "layout-shift",
    "startTime": 210.78500000294298,
    "duration": 0,
    "value": 0.0001045969445437389,
    "hadRecentInput": false,
    "lastInputTime": 0
  }
]

In this example there was a single very tiny shift of 0.01% at 210ms.

Knowing the time and severity of the shift is useful to help narrow down what could have caused the shift. Let's turn back to WebPageTest for a lab environment to do more testing.

Measuring layout shifts in WebPageTest

Similar to measuring CLS in WebPageTest, measuring individual layout shifts will require a custom metric. Fortunately, the process is easier now that Chrome 77 is stable. The Layout Instability API is enabled by default, so you should be able to execute that JS snippet on any website within Chrome 77 and get results immediately. In WebPageTest, you can use the default Chrome browser and not have to worry about command line flags or using Canary.

So let's modify that script to produce a custom metric for WebPageTest:

[LayoutShifts]
return new Promise(resolve => {
  new PerformanceObserver(list => {
    resolve(JSON.stringify(list.getEntries().filter(entry => !entry.hadRecentInput)));
  }).observe({type: "layout-shift", buffered: true});
});

The promise in this script resolves to a JSON representation of the array rather than the array itself. This is because custom metrics can only produce primitive data types like strings or numbers.

The website I'll use for the test is ismyhostfastyet.com, a site I built to compare real world loading performance of web hosts.

Identifying causes of layout instability

In the results we can see the LayoutShifts custom metric has this value:

[
  {
    "name": "",
    "entryType": "layout-shift",
    "startTime": 3087.2349999990547,
    "duration": 0,
    "value": 0.3422101449275362,
    "hadRecentInput": false,
    "lastInputTime": 0
  }
]

To summarize, there is a single layout shift of 34.2% happening at 3087ms. To help identify the culprit, let's use WebPageTest's filmstrip view.

Scrolling to the ~3 second mark in the filmstrip shows us exactly what the cause of the 34% layout shift is: the colorful table. The way the website is built is to asynchronously fetch a JSON file, then render it to a table. The table is initially empty, so waiting to fill it up when the results are loaded is causing the shift.

But that's not all. When the page is visually complete at ~4.3 seconds, we can see that the <h1> of the page "Is my host fast yet?" appears out of nowhere. This happens because the site uses a web font and hasn't taken any steps to optimize rendering. The layout doesn't actually appear to shift when this happens, but it's still a poor user experience to have to wait so long to read the title.

Fixing layout instability

Now that we know the asynchronously generated table is causing one third of the viewport to shift, it's time to fix it. We don't know the contents of the table until the JSON results are actually loaded, but we can still populate the table with some kind of placeholder data so that the layout itself is relatively stable when the DOM is rendered.

Here's the code to generate placeholder data:

function getRandomFiller(maxLength) {
  var filler = '█';
  var len = Math.ceil(Math.random() * maxLength);
  return new Array(len).fill(filler).join('');
}

function getRandomDistribution() {
  var fast = Math.random();
  var avg = (1 - fast) * Math.random();
  var slow = 1 - (fast + avg);
  return [fast, avg, slow];
}

// Temporary placeholder data.
window.data = [];
for (var i = 0; i < 36; i++) {
  var [fast, avg, slow] = getRandomDistribution();
  window.data.push({
    platform: getRandomFiller(10),
    client: getRandomFiller(5),
    n: getRandomFiller(1),
    fast,
    avg,
    slow
  });
}
updateResultsTable(sortResults(window.data, 'fast'));

The placeholder data is generated randomly before being sorted. It includes the "█" character repeated a random number of times to create visual placeholders for the text and a randomly generated distribution of the three main values. I also added some styles to desaturate all color from the table to make it clear that the data is not fully loaded yet.

The appearance of the placeholders you use don't matter for layout stability as much as they are for assuring users that content is coming and the page isn't broken.

Here's what the placeholders look like while the JSON data is loading:

Addressing the web font issue is much simpler. Because the site is using Google Fonts, we just need to pass in the display=swap property in the CSS request. That's all. The Fonts API will add the display: swap style in the font declaration, enabling the browser to render text in a fallback font immediately. Here's the corresponding markup with the fix included:

<link href="https://fonts.googleapis.com/css?family=Chivo:900&display=swap" rel="stylesheet">

Verifying the optimizations

After rerunning the page through WebPageTest, we can generate a before and after comparison to visualize the difference and measure the new degree of layout instability:

[
  {
    "name": "",
    "entryType": "layout-shift",
    "startTime": 3070.9349999997357,
    "duration": 0,
    "value": 0.000050272187989256116,
    "hadRecentInput": false,
    "lastInputTime": 0
  }
]

According to the custom metric, there is still a layout shift occurring at 3071ms (about the same time as before) but the severity of the shift is much smaller: 0.005%. I can live with this.

It's also clear from the filmstrip that the <h1> font is immediately falling back to a system font, enabling users to read it sooner.

Conclusion

Complex websites will probably experience many more layout shifts than in this example, but the remediation process is still the same: add layout instability metrics to WebPageTest, cross reference the results with the visual loading filmstrip to identify the culprits, and implement a fix using placeholders to reserve the screen real estate.

(One more thing)

It's nice to be able to run WebPageTest on a page before and after an optimization and see an improvement to a metric, but what really matters is that the user experience is actually getting better. Isn't that why we're trying to make the site better in the first place?

So what would be great is if we start measuring the layout instability experiences of real users along with our traditional web performance metrics. This is a crucial piece of the optimization feedback loop because having data from the field tells us where the problems are and whether our fixes made a positive difference.

In addition to collecting your own layout instability data, check out the Chrome UX Report, which includes Cumulative Layout Shift data from real user experiences on millions of websites. It allows you to find out how you (or your competitors) are performing, or you can use it to explore the state of layout instability across the web.

[Video] The State of the Web: Developing with a global mindset

Rick Viscomi — Sat, 07 Sep 2019 18:55:14 +0000

To many web developers, having a global mindset just means translating the content into various languages. There are also cultural differences that may make a website difficult or even impossible to use. In this video with Andrey Sitnik, he and I talk about some of the tools and techniques for inclusivity.

Some highlights:

Users' names can be anything and might not fit the template of your sign up form. Rather than forcing a first and last name, allow them to enter their name into a single "Name" field. And whatever you do, don't enforce minimum character limits!
The browsers you support and test with can have a big effect on who is able to use your website. There are pockets of the world where some browsers are more popular than others and the distribution of popularity is not evenly spread.
Having fast and reliable access to the internet can be a luxury in some parts of the world. Even in developed countries, connectivity can be intermittent, so building offline resilience lowers the barrier to use.
Expand your global mindset by busting out of your tech bubble. If you have the means, attend conferences in parts of the world where you wouldn't normally go. Something everyone can do is simply follow underrepresented people on social media to be exposed to new and different ideas. When you reshare other people's content, think twice about creating an echo chamber and instead consider amplifying underrepresented voices.

What other takeaways resonated with you?