Tags: form



5G Will Definitely Make the Web Slower, Maybe | Filament Group, Inc.

The Jevons Paradox in action:

Faster networks should fix our performance problems, but so far, they have had an interesting if unintentional impact on the web. This is because historically, faster network speed has enabled developers to deliver more code to users—in particular, more JavaScript code.

And because it’s JavaScript we’re talking about:

Even if folks are on a new fast network, they’re very likely choking on the code we’re sending, rendering the potential speed improvements of 5G moot.

The longer I spend in this field, the more convinced I am that web performance is not a technical problem; it’s a people problem.

Website Carbon Calculator – Calculate your websites carbon emissions

Get an idea of how much your website is contributing to the climate crisis.

In total, the internet produces 2% of global carbon emissions, roughly the same as that bad boy of climate change, the aviation industry.

How Web Content Can Affect Power Usage | WebKit

The way you build web pages—using IntersectionObserver, for example—can have a direct effect on the climate emergency.

Webpages can be good citizens of battery life.

It’s important to measure the battery impact in Web Inspector and drive those costs down.

Less Data Doesn’t Mean a Lesser Experience| TimKadlec.com

If you treat data as a constraint in your design and development process, you’ll likely be able to brainstorm a large number of different ways to keep data usage to a minimum while still providing an excellent experience. Doing less doesn’t mean it has to feel broken.

“Never-Slow Mode” (a.k.a. “Slightly-Fast Mode”) Explained

I would very much like this to become a reality.

Never-Slow Mode (“NSM”) is a mode that sites can opt-into via HTTP header. For these sites, the browser imposes per-interaction resource limits, giving users a better user experience, potentially at the cost of extra developer work. We believe users are happier and more engaged on fast sites, and NSM attempts to make it easier for sites to guarantee speed to users. In addition to user experience benefits, sites might want to opt in because browsers could providing UI to users to indicate they are in “fast mode” (a TLS lock icon but for speed).

Is client side A/B testing always a bad idea in your experience? · Issue #53 · csswizardry/ama

Harry enumerates the reasons why client-side A/B testing is terrible:

  • It typically blocks rendering.
  • Providers are almost always off-site.
  • It happens on every page load.
  • No user-benefitting reuse.
  • They likely skip any governance process.

While your engineers are subject to linting, code-reviews, tests, auditors, and more, your marketing team have free rein of the front-end.

Note that the problem here is not A/B testing per se, it’s client-side A/B testing. For some reason, we seem to have collectively decided that A/B testing—like analytics—is something we should offload to the JavaScript parser in the user’s browser.

Paint Holding - reducing the flash of white on same-origin navigations  |  Web  |  Google Developers

This is an excellent UX improvement in Chrome. For sites like The Session, where page loads are blazingly fast, this really makes them feel like single page apps.

Our goal with this work was for navigations in Chrome between two pages that are of the same origin to be seamless and thus deliver a fast default navigation experience with no flashes of white/solid-color background between old and new content.

This is exactly the kind of area where browsers can innovate and compete on the UX of the browser itself, rather than trying to compete on proprietary additions to what’s being rendered.

Accessibility and web performance are not features, they’re the baseline | CSS-Tricks

Performance and accessibility aren’t features that can linger at the bottom of a Jira board to be considered later when it’s convenient.

Instead we must start to see inaccessible and slow websites for what they are: a form of cruelty. And if we want to build a web that is truly a World Wide Web, a place for all and everyone, a web that is accessible and fast for as many people as possible, and one that will outlive us all, then first we must make our websites something else altogether; we must make them kind.

Redux: Lazy loading youtube embeds

Remy has an excellent improvement on that article I linked to yesterday on using srcdoc with iframes. Rather than using srcdoc instead of src, you can use srcdoc as well as src. That way you can support older browsers too!

Time to First Byte: What It Is and Why It Matters by Harry Roberts

Harry takes a deep dive into the performance metric of “time to first byte”, or TTFB if you using initialisms that take as long to say as the thing they’re abbreviating.

This makes a great companion piece to Drew’s article on server timing headers.

Lazy load embedded YouTube videos - DEV Community 👩‍💻👨‍💻

This is a clever use of the srcdoc attribute on iframes.

Native lazy-loading for the web  |  web.dev

The title is somewhat misleading—currently it’s about native lazy-loading for Chrome, which is not (yet) the web.

I’ve just been adding loading="lazy" to most of the iframes and many of the images on adactio.com, and it’s working a treat …in Chrome.

Form design: from zero to hero all in one blog post by Adam Silver

This is about designing forms that everyone can use and complete as quickly as possible. Because nobody actually wants to use your form. They just want the outcome of having used it.

LukeW | “Mad Libs” Style Form Increased Conversion by 25-40%

I was chatting with Rachel at work the other day about conversational forms, and I mentioned that I kicked that whole thing off with the mad libs style form on Huffduffer. Here’s the research that Luke later did on whether this style of form could increase conversion.

Don’t build that app! – Luke Jackson - YouTube

This is a fascinating look at how you can get the benefits of React and npm without using React and npm.

Here’s an accompanying article on the same topic.

How to test vanilla JS performance | Go Make Things

Did you know about console.time() and console.timeEnd()? I did not.

Fast Software, the Best Software — by Craig Mod

Fast software is not always good software, but slow software is rarely able to rise to greatness. Fast software gives the user a chance to “meld” with its toolset. That is, not break flow.

Maybe You Don’t Need a Date Picker | Adrian Roselli

In some situations, a date picker is overkill:

I have relied on plain text inputs as date fields with custom validation for the site, typically using the same logic on the client and the server. For known dates — birthdays, holidays, anniversaries, etc — it has tested well.

The Simplest Way to Load CSS Asynchronously | Filament Group, Inc.

Scott re-examines the browser support for loading everything-but-the-critical-CSS asynchronously and finds that it might now be as straightforward as this one declaration:

<link rel="stylesheet" href="/path/to/my.css" media="print" onload="this.media='all'">

I love the fact the Filament Group are actively looking at how deprecate their loadCSS polyfill—exactly the right attitude for polyfills in general.

Initial thoughts on standardizing form controls | Greg Whitworth

Greg has done a lot of research into developer frustrations with customising form controls.

My current thinking in this space, and I know some folks will find this controversial, but I think we should completely standardize in-page form controls with no limitations on their styling capabilities. What do I mean by in-page controls? I am referring to any form control or component that is rendered within the content process. This standardization would include the sub-parts and their related states and how these are exposed (probably through CSS psuedo classes or HTML attributes). This will enable the shadow-dom to be encapsulated while providing web developers with a consistent experience to adjust to match their brand and needs of their site/application.