I optimized 998 clicks for a given user story down to just 4 and this is how you can too.

Not all users click. Some tap the screen or keys on a keyboard. Others may use dictation to interact with your interface. In this post we’ll refer to any single user interaction as a “click”.

How many clicks does it take to accomplish tasks within your interface? Each click is an exhaustive investment made by your users. If they begin to feel they aren’t getting a return on their investment they will bounce leaving you with a unsuccessful conversion. …

The holy “px vs em” war wages on. But it never should have started. Not because one side is absolutely correct, but because these design decisions should not be reduced to binary. It’s not all or nothing or one or the other.

Image for post
Image for post
An unfocused lense captures the bokeh effect and reminds us not all users are perfectly sighted

This is a response to David Gilbertson’s rems and ems, and why you probably don’t need them post and addresses each section in order.

It’s definitely better for accessibility

David writes:

My point: you don’t need in depth knowledge and fancy tools for working out if rems and ems are ‘better for accessibility’ — just imagine that you are someone with bad eyesight

This may be well intended but is ridiculous advice nonetheless. You can’t just “imagine” disability. Abled developers making naive assumptions about what a disabled person would want is how we got into this mess. The fact remains users expect to be able to increase font sizes using the user agent, not just browser zoom. Need proof? …

The year is 2017 and for better or worse JavaScript is everywhere. Tools like React allow us to virtualize our documents, making turning web pages into web applications more approachable than ever. But sometimes what we can do with these tools conflicts with what we should do with them.

As Web Developers we should remind ourselves what the “web” fragment of our job title stands for. The “web” stands for the “world wide web”. …

Within the Web Development industry we say that if a page loads quickly it has good performance. But we’re wrong.

There are several definitions to the word performance but the only definition that is even remotely close to referring to speed is:

performance: the capabilities of a machine, product, or vehicle

That definition has the following synonyms: working, operation, running, behavior, capabilities, capacity, power, potential. Don’t worry you aren’t missing anything. Speed is not a synonym for performance. But if web performance is not about speed what is it about?

Web performance is about reliability. If a page, site, or application successfully caries out a given task then it performed that task and is therefore performant. It is a web performance. It may be slower than molasses in the winter time at performing that task but it performed it nevertheless. …

Image for post
Image for post
A cascade of windows with a select few uniquely ajar

Cascading Style Sheets are designed to, well, cascade. !important declarations overrides the cascading nature of CSS and are often considered to be a hack. You should avoid using them for the most part. But like most things proposed to the CSS spec, !important has several practical applications. But what are they?

First we need to travel back in time. Long before media queries and responsive design. The !important keyword was first introduced in CSS1 as a way to increase the specificity of CSS declarations. But it did something rather strange.

When !important was first introduced in CSS1, an author rule with an !important declaration held more weight than a user rule with an !important declaration; to improve accessibility, this was reversed in CSS2
The Important CSS Declaration How and When to use…

Oh. You were expecting 10,000 tips weren’t you? You won’t find that many tips today. At least not here. But you will find some tips for keeping the initial weight of your progressively enhanced web experience under 10,240 bytes (10kB).

Perhaps you’ve heard of this year’s 10K Apart Competition. Or maybe you are just looking for some tips on how to optimize and measure performance byte–by–byte. Either way, let’s get started.

Start with HTML

Starting with HTML–first is crucial to creating lightweight progressively enhanced experiences. It is also the center of an accessible experience. JavaScript is great, but not all users receive JavaScript. Think of JavaScript like glass. It is incredibly useful but heavy and fragile. Challenge yourself to initially work within the limitations of synchronous design patterns of HTML for a lighter and more accessible experience. Constraints are a designer’s coach. You might not be fond of them, but they foster creativity and genius. Could that WYSIWYG graphics editor be enhanced from a standard HTML form? Could that fancy asynchronous markdown editor be enhanced from a good old fashion <textarea>? …

URLs (Uniform Resource Locators) are how we arrive at a given location on the web. Similar to how a building has a unique address, every web page has a unique URL. In addition to navigating to a specific webpage, URLs can take us to a specific part of a webpage.

If you live in an apartment complex you have the same building address as your neighbor. Your apartment number along with the building address define your unique mailing address. Elements on a webpage have the same ability. Sheltered under the roof of the same DOM (Document Object Model), elements all live within the same “building”. Just like a unique apartment number, assigning a DOM element a unique id attribute allows that element to be directly linked to. …

You’ve been experimenting with React lately and you are aware that in accordance with accessibility, SEO, and performance best practices you should serve a semantic HTML document that React enhances — not creates. But how do you author an initial synchronous experience and an enhanced asynchronous experience isomorphically?

One of the most common arguments against progressive enhancement stems from the assumption that duplication is necessary to serve both synchronous and asynchronous experiences. Nobody wants to maintain wet code. DRY (Do–not–Repeat–Yourself) code is something we all should strive for. If we have to make an update in multiple areas of our codebase we increase the risk of introducing bugs. …

Inlining critical CSS is an optimization technique designed to make your site render blazingly fast. But does it?

A website is one or more web pages bound together by a domain, hyperlinks, commonly used assets, and the browser cache. Web pages are not websites. Websites are not web pages. Optimizations that lighten the payload of a web page may increase the payload of a website.

What is the difference between optimizing front end web pages and websites? How are files cached by the browser? When should you be designing for first visits and when should you be leveraging the browser cache? What is the payload of a website how is it affected by inlining performance techniques? …


JP de Vries

Senior Application Engineer

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store