Web Performance Calendar

In the earlier days of web development, and to some extent still today, when creating brochure websites for small businesses needed to be done “yesterday,” there was the iron triangle: “fast”, “good”, and “cheap”. The sole proprietor client was told they could only pick two. They usually went for “good” and “cheap”, providing webmasters the time to do the best they could for their clients. In front-end engineering of web applications with some complexity, we have our own iron triangle: “fast to code”, “fast to load”, and “accessible”. Many will argue you can only pick one, not even two. I posit you can have all three.

If you always keep your user’s needs in mind, you can, on the first try, develop a site or app that is not only accessible and fast to load, but is also secure, private, internationalizable, and usable. Good user experience requires all of these things. Focusing on the user experience throughout the entire development lifecycle is “fast to code” as you’ll get it right the first time, with little-added effort and little technical debt.

User Experience

According to the International Organization for Standardization, user experience is a “person’s perceptions and responses resulting from the use and/or anticipated use of a product, system or service. User experience includes all the users’ emotions, beliefs, preferences, perceptions, physical and psychological responses, behaviors and accomplishments that occur before, during and after use. User experience is a consequence of brand image, presentation, functionality, system performance, interactive behavior and assistive capabilities of the interactive system.”

As developers, we are responsible for the presentation, functionality, system performance, interactive behavior and assistive capabilities of our web applications. This includes ensuring our apps load quickly, that the content is accessible whether accessed on a tablet, phone, or computer, with a mouse, keyboard, via touch or via screen-reader, and is available in a language the user can understand. This includes ensuring the user interface is responsive to interaction, with the user understanding exactly where they are within the application at all times, and understanding which interactions are expected and/or necessary. It also means ensuring the content is secure: including using encryption and authentication standards to protect the confidentiality of all transactions; minimally using TLS, or Transport Layer Security, protocol.

In other words, user-experience is much more than good performance measure by load time or time to interactive. Good user experience, including good performance and the rest of these six features, is an asset. Bad user experience is a liability.

Developer Experience

It is important to always focus on user experience over developer experience. Developer experience, now often referred to as DX, does not have a dictionary entry in the International Organization for Standardization. So, what do we mean by developer experience?

Many definitions you’ll see in the wild refer to developing software for developers, and the experience the users, in this case, developers, will have using the product, like auto-complete in Sublime, or finding browser compatibility data on MDN Web Docs. That subsection of developer experience is actually user experience when your target users are developers.

What I am referring to when I use the term “developer experience”, is the methodologies, processes, and tools by which developers develop web applications for their user base: their user base being the general population or any subset thereof. In this conversation, I want to focus on the tools used to build those apps, such as frameworks, libraries, node modules, pre- and post-processors, build tools, other third-party scripts, and APIs.

Developer tools are made to make things generally simpler for engineers (I would argue they make things more complicated, but that’s a whole different article). They enable developers to produce robust features very quickly. But they also tend to add a lot of code including support for features not used in the user flow. For example, I have seen jQuery and a multi-select with autocomplete plugin incorporated into a React site because a developer wanted to quickly style a select list of 16 options. That’s a lot of bloat for what took me 16 lines of CSS, with either zero lines of JavaScript and one checkbox, or no checkbox and a single event listener to change a class on click. A friend of mine had a worse story: a PHP developer at her agency added a JavaScript library to convert PHP to JavaScript online to fix a small bug because he didn’t know JS. Fortunately, she was quickly able to remove the bloat because regression tests showed a significant increase in download time. JavaScript bloat — the extra kilobytes and sometimes megabytes of script — has to be downloaded, parsed, and executed. It also consumes memory, which can be limited on low-end devices. A few extra minutes, not even a full hour, of effort on the developer’s part, could have prevented the increase in bytes downloaded. Adding the multi-select and PHPtoJS Converter scripts to the code base are examples of prioritizing developer experience over user experience.

The Balancing Act

It is important to always focus on user experience over developer experience, but that doesn’t mean we can’t have both. Developers have access to fantastic frameworks, processors, build tools, and scripts. A lot of brain power went into creating most of those tools, addressing features an individual developer may not have considered in developing similar capabilities on her own. But, in the end, we are incorporating all these tools to render CSS and HTML, with media and interactivity. How we get there, in terms of what tools we use, doesn’t really matter, as long as always keep the end product in mind as we pick our tools and implement our developer process. That “end product” is always the user experience.

HTML is by default fast and accessible. It’s our job to not break it. Semantic HTML comes with standardized user interactions. For example, take the radio button. All you have to do is give all the radio buttons in your button group the same name, preferably with differed values. Associate a label to each radio button to define what each one means. Simply using <input type="radio" name="" value=""> allows for selecting only one value with completely accessible, fast keyboard navigation. Each radio button is keyboard focusable. Users can select a different radio button by using the arrow keys, or clicking anywhere on the label or button. The arrows cycle thru the radio buttons, going from the last in the group to the first with a click of the down or right arrow. Developers don’t have to listen for keyboard, mouse, or touch interactions with JavaScript. These native interactions are robust and accessible. There is rarely a reason to rewrite them, especially since they’ll always work, even if the JavaScript doesn’t.

In the end, browsers are simply rendering HTML and CSS, along with media, possibly altered with JavaScript. We should always be thinking about that final output — about the CSS and HTML our JavaScript or other tools generate.

Coding includes marking up content, perhaps dynamically generating code using non-web languages like python, ruby, and PHP, among others. Development includes the tools we choose to use, and also requires communication and empathy. Front-end engineering is all those things, but mostly it requires attention to user experience, accessibility, performance, security, privacy, and internationalization.

Remember, the most performant JavaScript is omitted JavaScript.

Before importing a tool, consider the ramifications of the code: does it improve accessibility or does it harm the default accessibility provided? Is your project using all of the features provided by the tool, or could you write a simple (or complex) function and save on bytes, parsing and execution time, along with CPU and battery life? The minutes to hours saved up front by dropping in every framework, library, and other third-party written script is very rarely worth the negative impact on customer acquisition, satisfaction, and retention in the long term. Including third-party code may help you develop features more quickly, but it also creates complications around maintenance and updates, as well as the learning curve to understand the included code. While the developer who includes a script likely learned a bit about the code, can create a basic explanation as to the goal of including the script, and possibly understands how to implement the code, developers added to the project at a later date are required to add that script to their toolbelt, maintain it, and stay abreast of updates, releases, and security holes. Oftentimes they find it faster to just implement their own favorite tool, abandoning the prior tool without removing the tech debt from the code base.

Remember, tech debt omitted is tech debt saved.

I am not saying don’t use tools. A lot of brain power has gone into many of them. But the browser is pretty powerful on its own. It’s important to understand what your tools are doing: control your tools. Don’t let them control you. Understand your dependencies and
why you’re adding them.

Understand your tools, languages, and features you are adding, or may add, to your code. Taking the time to do it right the first time is “fast to code”. Refactoring is not. If you keep the six areas of concern — user experience, performance, accessibility, internationalization, privacy, and security — at top of mind while developing, your finished product will be usable, fast, accessible, internationalizable, private, and secure, without much effort. Because the web is all of those things, unless you break it.

#PerfMatters, the Front-End Web Performance Conference