Jesse Heady

How I managed to score 100 in Lighthouse

2025-08-18T00:00:00-00:00

I’ve been building this site using npm and Jekyll, while deploying on CloudFront, for many years. It’s been just fast enough for me, but I’m always looking for ways to make things better. I’ve been skirting the line with a ‘perfect’ performance score for a long time. Lighthouse wasn’t giving me 100 across the board and that was bothering me. So, I decided to treat the site like I would any product: run a proper performance and quality audit, fix the issues, and iterate until Performance, Accessibility, SEO, and Best Practices all hit 100. Simple, right? Here’s how everything went.

Where things started

The stack was already in pretty good shape. As noted, I build static HTML and hashed CSS and JS for long-term caching, employ a service worker, and serve everything via a CDN (CloudFront). So the low-hanging fruit was already done. What was left were the kinds of issues that audits love to flag: render-blocking resources, images without dimensions or loading hints, contrast and link styling for accessibility, and a few SEO and security details. I didn’t record exact before scores but I have made other attempts at these sorts of improvements in the past, and can confidently say scores have hovered around 80-90 for a long time. If you’re in the same boat, run Lighthouse and use that as your baseline. My goal was to fix every failing or warning audit until all four categories showed 100.

Performance: critical path and Core Web Vitals

I started with performance because it touches so much of the site experience. Performance is also my passion. I love the other areas we’ll cover as well (accessibility and SEO) but I’ve spent a lot of time focused on web performance over the years, so this is one particular area I felt I needed to get right.

CSS, critical path, and third-party scripts

The single biggest fix across the site was the main stylesheet. I had a malformed link tag in my site <head> that tried to be both a preload and a stylesheet. I assume this was an attempt at an old performance tactic or a misunderstood application. I split the style reference into a proper <link rel="preload" as="style"> followed by <link rel="stylesheet">, which lets the browser prioritize CSS correctly. This directly improved First Contentful Paint (FCP) and Largest Contentful Paint (LCP) considerably.

Furthermore, I still leveraged Google Analytics which was declared in the <head> and blocked parsing while it was loading. This is a serious single point of failure (SPOF) anti-pattern. Even Google is fallable, after all! I moved this external script reference to the footer and kept it async so it no longer affected Time to Interactive (TTI) or Total Blocking Time (TBT). I also added dns-prefetch and preconnect for the the Google Analytics origin so that when those requests run, they start faster.

Images and fonts

Feature images and post cards were missing consistent width, height, loading, and fetchpriority. I added dimensions everywhere to avoid Cumulative Layout Shift (CLS), loading="lazy" for below-the-fold images, and fetchpriority="high" only for the main LCP candidate. I also added image sizes so that when I add a responsive image pipeline later, the groundwork is already there.

I was also preloading several font variants from Google Fonts, again as a third-party resource. I decided to host the fonts first-party and also migrated to more accessible font faces (more on that later). I kept preload only for the two fonts used above the fold (Lexend and Atkinson Hyperlegible Regular) and switched non-critical variants (for example, italics) to font-display: optional to reduce layout shift and avoid unnecessary network cost.

Service worker load and caching

The service worker was registering on window.load, which fires late. This is not great when we want to leverage the benefits the service worker is providing on subsequent loads. I moved registration into the <head> with a small inline script so the SW activates sooner and can serve cached assets on repeat visits.

I also tuned the Workbox config for SW caching so the worker precaches only critical assets (CSS, JS, fonts) and uses runtime caching for HTML and images with sensible TTLs. I’d previously been caching everything including all blog entry and header images. That was too aggressive and caused our SW cache to be too large, and while offline viewing of this site is neat, it’s not worth the trade-off in performance to treat like a full PWA in real-world use.

After these changes, LCP, FCP, CLS, and TBT all landed in the “good” range and the Performance score in Lighthouse reached 100. This felt like a major milestone to me and it definitely feels good to see that green Performance score. Off to a great start!

Accessibility: contrast, links, and structure

Improving readability

I next ran the Lighthouse accessibility audit and fixed every failure and warning. The main problematic areas were color contrast, link affordance, and heading order. I followed some best practice recommendations like those from a11ty Collective. As noted earlier, I also adopted fonts designed for improved readability: Lexend by Google for body text and Atkinson Hyperlegible by The Braille Institute for headers. My base text and link colors compared with their background didn’t meet WCAG AA. I lightened body text and links (lighten(@text-color, 10–15) and lighten(@link-color, 15)) so they meet the 4.5:1 requirement. Buttons that had dark text on the accent color were switched to white (#ffffff) so they pass as well.

Proper links and headers

Links also had to be more distinguishable beyond their color. I ensured links were underlined using text-underline-offset, and a visible focus outline so keyboard users and anyone who doesn’t rely on color alone can see them clearly. Every interactive element received a visible focus style (outline: 2px solid ... with an offset) so keyboard navigation is obvious. The homepage headers also jumped from h1 to h3, which is a bad practice for screen readers and SEO alike. I fixed the hierarchy so it goes h1 (site name) to h2 (tagline) to h3 (post titles), with no skipped levels. The same idea was applied on other templates across the site where section structure was off.

After these passes, the Accessibility score hit 100. Onward!

SEO and best practices

At this stage, SEO and Best Practices were mostly cleanup of past mistakes or simple oversights. The items that were flagged in Lighthouse for SEO were generally pretty straight forward to address. They are also designed to follow security and privacy best practices.

Security and privacy

For external links from blog posts or across various templates, I ensured proper use of rel="noopener noreferrer" and fixed any protocol-relative URLs to https://. noreferrer and noopener are used on target="_blank" links so the newly opened page can’t access your page via window.opener for security purposes, and the referrer isn’t sent for privacy.

Alt text and images

Next, I replaced generic link text (for example, “Read more”) with descriptive text or aria-label where needed. Then I ensured that images had descriptive alt text everywhere, and for any image that had been hosted externally and was flaky, I moved it first-party under assets/images/ and pointed the markup at the local file.

Meta data optimization

I’d already established standard meta descriptions, canonical URLs, and Open Graph tags. I confirmed every page had a proper description and that schema (BlogPosting, WebPage) is correct. The same layouts also use microformats 2 (mf2) class names so social parsers can interpret posts and pages. Posts and cards use h-entry with p-name, u-url, e-content, dt-published, p-author h-card, and p-category on tags; older schema and mf2 live on the same elements without duplicate markup.

With all those improvements in place, SEO and Best Practices both reached 100. Very marketable!

How I measure, iterate, and maintain

I used Lighthouse in Chrome DevTools–and sometimes SiteSpeed.io loaded via docker–on the live site and on local builds. I ran Lighthouse in incognito with extensions disabled to avoid noise. For each category I fixed the listed issues, rebuilt, redeployed or refreshed, and re-ran the audit until there were no more failures or warnings. I didn’t chase a specific number so much as “zero failing audits” or digging into specific warnings, and the 100-passing scores followed.

I kept Core Web Vitals targets in mind to achieve a “good” score: LCP under 2.5s, CLS under 0.1, INP under 200 ms. I tried to follow current standards as of this writing, where the primary metrics of CWV: LCP, FID, and CLS, were originally announced in May 2020, and INP replaced FID in March 2024. I also documented the patterns in performance, accessibility, and SEO for myself to refer to so future changes (hopefully) stay compliant.

Quality gates and performance budgets

As a small bonus: I also added a small script that runs after build (npm run build:size) to report CSS and JS size and to fail the build if limits (100 KB CSS, 50 KB JS) are exceeded. These budgets ensure I stick to “Best Practices” and try to avoid regressions as I add more content or make additional changes. This sort of check can be added as a quality gate in build pipelines so that when a build:size fails, the build fails and alerts on the condition; this is nice because it forces the standards for lower package weight to be followed, maintaining performance in the long run. Similarly, one could add steps that run Lighthouse/SiteSpeed.io checks and fail on any resulting CWV that isn’t passing.

What’s next

The site is in a good place: all four Lighthouse categories at 100, Core Web Vitals in the green, and documented patterns for performance, accessibility, and SEO. Optional next steps I’ve left for later include an image pipeline (responsive srcset, WebP/AVIF), critical CSS extraction, font subsetting, and configuring CloudFront to send immutable for hashed assets. For a small static site, the current setup is enough to keep scores at 100 as long as new content and features follow the same rules.

If you’re working on a personal or small project site, the same approach works: run Lighthouse, fix the audits it reports, then encode those fixes in your templates and styles so every new page stays fast, accessible, and SEO-friendly by default.

How I managed to score 100 in Lighthouse was originally published by Jesse Heady at Jesse Heady on May 20, 2024.

Web performance: UX and revenue

2022-12-28T00:00:00-00:00

I’ve previously written on the importance of web performance and that businesses should focus and prioritize performance over quick wins to boost sales or revenue. Often those can negatively impact the performance and user experience of a web application. Viewed more holistically, and accounting for the evolution of performance as a core indexing metric by Google, I thought it was important to revisit the topic of how integral web performance is to user experience, and the impacts businesses can make by focusing on performance.

Now that we’ve settled in for well over a decade of web performance metrics being included as a critical component to search indexing, let’s dive into what makes the most impact, why web performance is integral to creating pleasing user experiences, and how measuring our efforts pays off. User experience (UX) has become the cornerstone of any successful online presence. As we continue to push the boundaries of technology, users’ expectations have evolved. They demand speed, interactivity, and a seamless experience. Web performance is no longer just a behind-the-scenes metric, it’s a fundamental aspect of creating a website that users love.

Core Web Vitals

First introduced in May 2020, Google’s Core Web Vitals (CWV) are designed to measure performance metrics, with a goal to improve user experience. CWV are becoming a defecto standard measurement for performance, aggregating many existing performance API metrics within the browser. These metrics – Largest Contentful Paint (LCP), First Input Delay (FID), and Cumulative Layout Shift (CLS) – focus on the core elements that influence how users perceive and interact with a website.

LCP and Perceived Performance: LCP measures how quickly the main content of a page loads, which directly impacts a user’s first impression. If users can see and interact with your content quickly, they’re more likely to stay engaged. Improvements in LCP can drastically reduce perceived wait times, leading to a faster and more satisfying experience.
FID and Interactivity: FID measures the time it takes for a page to become interactive. Users expect instantaneous feedback from their actions, whether that’s clicking a button or filling out a form. Reducing FID ensures that users can engage with your content without frustrating delays through a more responsive and enjoyable experience.
CLS and Visual Stability: CLS measures the stability of your page as it loads, ensuring that elements don’t unexpectedly move around. A stable page layout contributes to a trustworthy and reliable experience, reducing user frustration and enhancing overall satisfaction.

There are a number of tools available for measuring CWV and performance metrics manually or as part of continuous integration (CI) pipelines. Some of the most well known today include Web Page Test, Google’s Lighthouse, Sitespeed.io, and the recently updated Google CrUX report which collects real user metrics through Chrome browser. Configuring an application build pipeline to run performance tests against budgets is more viable now than ever before. If there’s one key take away: always make measurements before, during, and after planned changes—yes, even small ones!

Impact of load time on UX

Users appreciate speedy load times and first impressions are critical. Load time is often the first indicator of how your website is perceived and a site that loads quickly is seen as more reliable and professional, creating an immediate sense of trust. Even a small reduction in load time can improve how users perceive your site. This isn’t just about speed; it’s about making users feel valued by respecting their time.

When users encounter a site that loads swiftly and allows them to interact immediately, they’re more likely to stay longer and explore more. This increased engagement is a direct result of a performance-driven approach to UX. By focusing on load time, you’re not just improving metrics—you’re creating a more enjoyable and fulfilling experience for your users.

Reducing user bounce rates

Bounce rates often reflect a user’s frustration with poor performance. Sites that meet Core Web Vitals thresholds see significant reductions in bounce rates and this is because users are more likely to continue exploring a site that feels stable and responsive. If users can find what they need more rapidly and reliably they are more likely to stick around and engage further. By prioritizing performance we keep users engaged longer but also encourage them to dive deeper into our content.

Mobile speed is critical

Mobile performance has become a critical aspect of user experience, as more users access the web through mobile devices than on any other device. Mobile users are often on the go and their expectations for speed and responsiveness are even higher. Slow-loading web applications can quickly lead to frustration and abandonment. Improving LCP, FID, and CLS can significantly enhance the mobile user experience and focusing on performance on mobile can make your site more accessible and user-friendly across all devices.

Mobile users are particularly sensitive to load times, with even a 100ms delay leading to noticeable drops in engagement. Amazon has a famous study illustrating this point in user engagement in sales. Overall, fewer HTTP requests, smaller and optimized assets, and non-render blocking code are all the key here; furthermore employing CDN functionality and creating graceful degradation of apps for offline capability helps tremendously to provide a pleasing user experience. By optimizing your site for mobile performance, you not only improve the experience for a large segment of your audience but also increase the likelihood of retaining those users.

Performance is a user-centric discipline

The importance of web performance in enhancing UX cannot be overstated. The goal is not just to meet technical standards but to create experiences that users find intuitive, enjoyable, and memorable. By focusing on performance, we ensure that interactions a user has are reliable, which can lead to greater satisfaction and long-term engagement.

What’s the business impact of bad performance?

OK, so we should prioritize our users’ experience through web performance first. What about business impacts? While user experience is a crucial element of web performance, the business implications can be quite significant. The ability to convert visitors into customers relies upon how well your site performs. That reliablility translates into a good experience for your users and they trust the application and engage further.

LCP and conversion rates

LCP doesn’t just influence user satisfaction, it has a direct impact on your bottom line. Studies show that improving LCP by just one second can increase conversion rates by up to 13%. This is because faster load times reduce friction in the user journey, making it easier for visitors to complete desired actions, whether that’s making a purchase, signing up for a newsletter, or contacting your sales team.

When users encounter slow load times, they’re more likely to abandon their journey before completing a conversion. By focusing on LCP, you’re not just optimizing for speed; you’re creating a smoother path to conversion, ultimately driving more business results.

Small improvements can have a big impact on load time

Load time is a critical factor in the user’s decision-making process. Even a minor improvement in load time, such as 100ms, can lead to a 1-2% increase in conversion rates (ref: Amazon, Walmart, Mobify). This demonstrates the power of incremental improvements as each millisecond you shave off your load time contributes to a more efficient and effective conversion process.

Businesses that invest in reducing load times are essentially investing in their conversion rates. The faster your site, the more likely users are to complete the actions you want them to take. This is particularly important in e-commerce, where even slight delays can lead to significant revenue loss. There are points of diminishing returns on this effort however, so it’s important to understand what to prioritize.

The inverse is also true, and as I’ve noted previously, taking shortcuts to insert JS tags, content, or ads can dramatically and negatively impact site performance.

Mobile performance and conversion rates

With the majority of web traffic now coming from mobile devices, ensuring a fast and responsive mobile experience is essential. If it wasn’t already obvious, web performance on mobile plays a crucial role in conversion rates. Users on mobile devices are often less patient, and a slow mobile site can quickly lead to abandoned sessions. Optimizing mobile performance, including LCP, FID, and CLS, can result in higher conversion rates and reduced bounce rates on mobile, directly impacting overall business performance.

Performance optimization reduces bounce rates

Bounce rates don’t just reflect user engagement, they’re also closely tied to business revenue metrics. High bounce rates often indicate that users are not finding what they’re looking for, leading to missed opportunities for conversions. Compelling case study data supports that by improving performance, we can reduce bounce rates and increase conversion rates.

When users stay on your site longer, they’re more likely to explore additional products or services, increasing the chances of upselling or cross-selling. In this way, reducing bounce rates through better performance has a direct impact on your revenue streams.

Performance equals profit

Ultimately, web performance isn’t just about meeting technical standards or improving user experience, it’s also very much about driving tangible business results. By prioritizing performance, businesses can improve their conversion rates, reduce bounce rates, and ultimately drive more revenue. As we continue to push the boundaries of web performance, the connection between speed, user experience, and business outcomes will only grow stronger. For businesses looking to stay competitive, prioritizing performance is no longer optional.

Web performance: UX and revenue was originally published by Jesse Heady at Jesse Heady on August 26, 2022.

How I work: managing chaos

2018-10-11T00:00:00-00:00

I’ve learned a lot of different techniques, tools, and processes over the years all designed for productivity or efficiency. Many of these I have picked up by working with specific teams, projects, or individuals or by trial and error. Not all of these may be useful or even beneficial to everyone, because everyone’s individual way of working is unique. However, hopefully these tips are also useful to others. Here we go!

Disclaimer

Your mileage may vary with the techniques outlined in this article. I make some assumptions about prerequisite knowledge and will do my best to explain and provide links for further reading. I mention a few apps by name where they’re relevant to the process; I generally use a Mac, but the ideas work with any board, capture tool, or timer that fits your environment.

Productivity Techniques & Process

Over the years, there have been many productivity techniques that I’ve been exposed to and attempted to integrate into my workflow. Many techniques exist out there and some are even supported with data supporting their viability. Since this is a fairly subjective and opinionated article, I’m not going to dive deep into the data points, for my own use or across industries. Plenty of resources are available online with some quick searches.

Kanban

One of the most effective and reliable methods I use to manage projects and tasks is Kanban, an agile system that originated in lean manufacturing at Toyota in the 1940s. Today, it’s widely used across various fields, including software development and personal productivity, to help streamline processes and keep work organized. The term “Kanban” translates from Japanese as “visual signal” or “signboard,” reflecting its purpose in visualizing workflow to improve efficiency and reduce waste. Managing Kanban can be done using physical cards or sticky notes, or a digital board such as Trello, Redmine, or Wekan.

What makes Kanban so powerful is its adaptability. For simple tasks, I keep boards straightforward, by organizing tasks into columns like “To Do,” “In Progress,” and “Done,” allowing for a clear, at-a-glance overview of work. But for more complex projects, I might add extra stages like “Discovery”, “Testing” or “Review.” This allows me to track progress accurately and quickly spot any bottlenecks that could slow down work. This process provides a clear, visual overview of all work in a project. Another great tool in Kanban is adding work-in-progress (WIP) limits to any particular column. By limiting the number of tasks in the “In Progress” column, for example, I can stay focused and avoid spreading myself too thin. It’s a dynamic, flexible system that evolves with the project, helping me maintain momentum and ensure that nothing falls through the cracks.

I’ve found Kanban to be most useful when pairing together with another engineer or designer, working with teams on larger projects, or generally when working effectively in groups matters. Cycle time and throughput are used to measure how long tasks take to complete and inform how long they should take in a given step. In addition to managing WIP limits and dependencies, tagging people, adding keywords, or color-coding cards can help keep a project organized and scope remains realistic and deliverable. Enabling individuals and teams to pull work, rather than push work from a queue, is also quite powerful in empowering teams to dictate their true bandwidth. This is further informed not just based on WIP limits, but on historical throughput for similarly sized units of work. Over time, the size and shape of work becomes clearer and enables leaders and the team to make adjustments to the scope of work or size of tasks.

GTD

Another process for managing project work is Getting Things Done®, but for the parts I use it’s really about helping organize thoughts or ideas into actionable work. If I have one common thread in my work or home projects it’s using GTD with todo lists to capture whatever is in my head for later prioritization. This simply helps me to remove distractions or tangental thoughts or ideas and focus on the task, collection of work, project, or whatever. I typically use the Things app to capture high- or low-level thoughts, ideas, or actionable tasks into pre-defined areas or ad hoc buckets. Really, any todo list app or even just a pencil and paper works fine. If I’ve jotted something down on a notepad or sticky note, I’ll transfer those over to my todo app at some point later. The ultimate goal here is to capture the information to process later.

After the capture step, I move into clarification and organizing. These are fairly self-explanatory, but the gist is to revisit your captured items and refine where required or necessary. The goal is to move any items into idea buckets, projects, or creative areas. Grouping the captured items into logical areas may seem obvious but the process of pooling notes together can help inspire additional thoughts to capture. Once clarified, there is natural progression to organizing items and iterating upon them in their respective areas. Once organized, I tend to reflect and iterate upon each item within its respective group. Sometimes I’ll do this as I am going along creating tasks, otherwise I’ll just do a quick reflection before getting started.

Which brings about the real benefit to taking the approach of a todo list to help get shit done: jumping in and getting started. Honestly, sometimes this is the part that I have trouble with if I don’t have a whole picture of the end goal or just vague idea of an outcome. This is why looping through the earlier steps can be helpful. It’s normal for me to run through the whole process a few times before really digging into deep work related to a project. The trap that is easy to fall into is spending too much time on the earlier steps before getting started. So, there’s a bit of nuance, but making a call to just jump in and get started sometimes helps feed into earlier steps. Rinse and repeat. Typically, the outcome is good enough. As we know, perfection is the enemy of good enough, and these steps tend to help at least keep things somewhat organized.

Pomodoro

The Pomodoro® Technique is a time management practice that can be applied to daily work, projects, or even personal or home projects. The basic principles are that you have some sort of timer, in fact the concept started with a real physical kitchen timer, and you set increments of time to focus and work, then rest, and repeat. The general timeframe is usually around 25 minutes of work, followed by a short rest, with a longer break between sessions. Honestly, the focus time can be greater or smaller than 25 minutes. I don’t always use this technique, but I’ve found that when I do, I’ll adjust the time up or down depending on my mood or the work I’m doing. The general idea of Pomodoro is to help get into a flow state and encourage incremental breaks with periods of deep focused work.

If I hadn’t had a lot rest the night before, I might not be able to focus for longer periods. Sometimes I find myself in a flow state while I’m working and will disable the timer completely so I can remain focused. This has a downside, however, and as is outlined in the process, taking intermediate breaks helps us reset and create a sort of rhythm to whatever work we have in front of us. In general, having a set block of time helps to set some parameters and focus our attention to the tasks at hand. As for what timer to use, sometimes I’ll just set a timer on my phone by I also use Pomodoro Timer on my Mac. There are great other apps like Hey Focus, and many others that are web- or app-based.

Pomodoro is a great technique if you are receptive to working in bursts or need some sort of limiting factor such as a timebox for your efforts to help keep focus. The downside can be feeling overwhelmed or artificially pressured if you’re not producing in the time you’ve allotted. These are natural responses, I think, to setting some of these limits and this is why I don’t treat this process as a magic bullet for productivity and adjust the time or drop it entirely if it’s not working and move on to something else. In those times that I have an open-ended project and am not so worried about how long or how many Pomodoro I am working through to get to the end goal, then this can work great for me.

Tools in context

The specific apps I use for Kanban, capture, and timers change over time. What stays constant is the role they play: something to visualize work (a board), something to capture ideas and tasks (a list or notebook), and something to timebox focus when I need it (a timer). I’ve name-checked a few options in the sections above; if you’re looking for alternatives, AlternativeTo and your team’s existing stack are good places to start. The goal isn’t to adopt my stack. It’s to pick one or two things that support your process and stick with them long enough to see if they help.

Everyday tools

My everyday stack maps straight onto the three process roles. For capture I use Things, it’s where the GTD flow lives. For visualization I use a board, usually Trello or Wekan depending on whether I’m solo or with a team. For timeboxing I use a Pomodoro-style timer (phone or a Mac app like Pomodoro Timer or Hey Focus) when I need to lock in. I also lean on Alfred to add tasks or open the board without leaving what I’m doing, so context-switching does not eat into focus time. The point isn’t this exact list. It’s having one place to capture, one place to see work, and one way to timebox when it helps, and keeping that set consistent so you’re not constantly re-deciding.

Situational tools

I add or swap tools when the context changes. When the work is code and the team lives in GitHub, GitHub Projects or Issues can be the Kanban board so work stays in one place. When coordination matters more, Slack (or whatever the team uses) is where requests and updates live; I might add a “Waiting on” or “Blocked” column on the board to reflect that. For my calendar, I lean on Fantastical to see when I have focus blocks and when I don’t. Sometimes the right move to remain agile is an extra column in my Kanban tool such as “Review” or “Discovery”, rather than a new app. The idea is to adapt the system to the situation without turning it into a tool collection.

Taking breaks and mental agility

Process and tools only get you so far if you’re burned out or can’t switch context. Rest isn’t a reward for working hard, it’s what makes work sustainable. I’m not talking about a five-minute pause between tasks or meetings. I mean real breaks: a walk or bike ride outside, doing yoga or practicing mindfulness, time with family or friends, playing a video game or reading a book, or making art or building something with your hands. Or, here’s a wild thought: actually taking your PTO. Even a day or two away helps. Your brain needs time to process offline, and the best ideas often show up when you’re not staring at the task list.

All of these processes and tools are great, but what good are we unless we regularly take breaks and recharge. Even if you don’t want to take a big trip, just spending some time away from your work or tasks can have a tremendous benefit to your physical and mental well being.

A better board or a timer can fix some things. Expectations, boundaries, saying no, or stepping away fix others. Often it’s both. So, use a process that fits you, keep your everyday tools simple and consistent, add situationally when it helps, and protect the rest and reflection that make it all possible.

How I work: managing chaos was originally published by Jesse Heady at Jesse Heady on March 26, 2018.

The state of web performance and Internet advertising

2016-06-22T00:00:00-00:00

To say the state of web performance optimization is at odds with the realm of Internet advertising may be a bit of an understatement. Content on the web in 2016 consists of a complex ecosystem of content monetization, marketing, user experience, data analytics, and programmatic advertising, among many other valuable but competing elements of business on the web. I’d like to share my perspective on the topic as a performance engineer.

The unfortunate reality that must be addressed is that all of these various pieces of the money-making pie can, in the long-run, harm the business more than help. Without some very careful consideration to the end user experience in terms of speedy delivery of the product, service, or website they are consuming, businesses can drive customers away and lose valuable returns to their product. The business can also spend lots of money cleaning up poorly performing integrations. Performance engineering & development best practices too often perform a strange dance with these other parts of the business, but most often align with the best interests of the end user, and the very definition of web performance optimization dictates that faster speeds on the web can and do increase visitor loyalty and satisfaction.

Although it may be difficult to quantify “feels like awesome” in terms of revenues, there’s a clear correlation between a user’s satisfaction with their experience and the ability of the business to monetize that experience. Also, it’s not impossible to achieve hard data on that “feels like” metric and correlate to potential revenues. There are well established measurements of this via apdex and speed index. In fact, Google’s own search algorithm factors page speed in search rankings, as of 2010.

Fast forward a few years, on the design side of things, thought leaders like Brad Frost have called this out since at least early 2013. Tim Kadlec and Dan Mall have also written thoughtful pieces about performance budgets and how to establish them. Well respected publishing and conference organization O’Reilly Media has made this a major topic of many books, articles, and conferences including this gem from Laura Swanson in 2014:

Users expect pages to load in two seconds, and after three seconds, up to 40% of users will abandon your site. Similar results have been noted by major sites like Amazon, who found that 100 milliseconds of additional page load time decreased sales by one percent, and Google, who lost 20% of revenue and traffic due to half a second increase in page load time. Akamai has also reported that 75% of online shoppers who experience an issue such as freezing, crashing, taking too long to load, or having a convoluted checkout process will not buy from that site.

From the design and development side of things, I believe we’re on pretty solid ground keeping performance in the forefront of our efforts. There are very well established fundamentals in development of performant web applications. So why is it, after 6 years (and counting), that Google’s establishment of speed as a factor in their ranking isn’t more concerning for businesses? One theory is simply a lack of education on the topic, another may be that businesses are struggling with the advertising model. This is where I want to speak directly to those on the web involved in deciding how to generate revenues and encourage them to not take the easiest path. The easy path may be simply adding a JavaScript widget to a page, integrating with some third party service that promises to drive quick revenues, or adding more advertising.

Taken in moderation and in consideration of a pleasing (and speedy) user experience, these may not be so bad. However, as is too often the case, business/marketing and development/UX teams may not be perfectly in sync about their performance budget, let alone other means to ensure their efforts aren’t having a longer-term negative impact. Monitoring, measuring, and analysis only help identify the problem. Addressing the problem of performance degradation through continuous development and iteration is only one half of the solution, the other side of the coin involves making some tough ‘trimming the fat’ decisions.

Here lies the doomsday segment of the article and why I want to call to attention the gap between the efforts of marketing/revenues and user experience, development, and performance engineering. In summer 2015 there were a number of articles espousing the importance of web performance optimization among various media organizations and publications: identifying the web’s cruft problem, how tracking pixels can drain revenue rather than drive it, how the Washington Post cut page load by 85%, a great analysis of how so many news sites are fatter and slower than ever before, and Wired’s take on Google’s inability to control their own ad network.

In early 2016 we saw some movement in the advertising space around ads performance and more directly the behavior of users to block ads. It’s a widely held belief this is not simply because people don’t like looking at ads, but because the ads ecosystem today is riddled with bloated, latent code and creative. In some of the worst cases, malvertising is present on users’ computers, delivered via the ads networks on very popular news websites. Yet, ad blocking from the users perspective is the only recourse to continue using the websites they love. Blocking the ads means the sites load more reliably, and they have the less crucial benefit of a less cluttered & noisy user experience.

The user, however, is caught in the cross-fire of a full blown war between advertising delivery and (arguably) security/usability defenders, such as AdBlock. In October 2015, the Interactive Advertising Bureau (IAB) admitted they ‘messed up’ by stating that too many organizations followed their guidelines too explicitly. In January, we learned that AdBlock was “un-invited” from attending the yearly IAB conference that same month. The day after the IAB conference wrapped, we learned about a start-up who’s declared an effort to end AdBlock’s ‘raping and pillaging’ of online advertising.

It’s my belief the corners of the web that rely so heavily on online advertising are looking at this entirely the wrong way. It’s true that in 2015 upward of 20% or more of page views in the U.S. may have been ad blocked, and in 2016 those numbers are similar on mobile. However, we need to look again at why users are utilizing tools to block ads, tracking, and other third party services on first-party websites. As we look ahead to 2017, it’s my sincere hope that publishers/businesses on the web will begin to come together not just with their engineers and designers, but also with their vendor partners, and hold them to account for poor performance practices and drop the bad apples.

I’m optimistic on some levels but also skeptical in other ways about some of the responses in another direction to addressing the problem. Google’s AMP Project takes an aggressive approach by introducing an entire pseudo-specification atop HTML promising ‘instant’ pages, where pages which don’t validate by re-writing some commonly abused elements/attributes won’t be cached and delivered by Google AMP. Facebook provides Instant Articles of a very similar nature, delivered exclusively through Facebook as a content platform. The up side to these is that the user experience is vastly improved and developers are encouraged (reminded) of best practices, while the downside is a fragmentation of the open web and spaghettification of new standards which are pipelines between the user and one specific provider.

I’ll close by referring to one critical chapter in Lara Callender Hogan’s book Designing for Performance, where she talks about the importance of changing culture:

It’s important to recognize when a problem needs technical solutions, when it needs cultural solutions, and when it needs both.

The point is that the problem of bloated websites and degraded user experiences due to poorly performing applications cannot be solved solely by one person or even a dedicated performance operations team. It takes a cultural shift and engagement by people from every team inside your organization, and also holding your partners to high standards while helping one another along the journey to performance excellence. This shift cannot and will not happen over night, and it’s bound to continue evolving and changing. As good stewards of the web and promoting excellent user experiences, we have a duty to continue taking the harder path and an opportunity to make a faster, more enjoyable web.

The state of web performance and Internet advertising was originally published by Jesse Heady at Jesse Heady on June 08, 2016.

Take me home, country roads

2015-05-31T00:00:00-00:00

After more than 10 wonderful years living in Atlanta my wife Jenny and I have decided to move home to West Virigina to be closer to our family. We both grew up in north central West Virginia — we want our kids to know the amazing environment we grew up loving. We have been talking about this move for nearly as long as we have lived in Georgia, now we’re setting our plans in motion. We should be completely relocated by early July.

We’ve come to love our Atlanta home and our friends in the area. We’ve made some truly lasting friendships and memories. We’ll also be leaving behind many beloved family members in the region. Yet, we’re looking ahead to a new chapter in our life, closer to our families and our roots in West Virigina.

I plan on keeping my job at Cox Media Group and working remotely from West Virginia. I am fortunate enough that I work for a company willing to work with me and my family’s life goals. Occassionally I expect to travel to Atlanta for work, so there will still be opportunities to see folks. I’m really going to miss the tech community in the city — those groups and people I’ve worked with over the years will be sorely missed. I’ll make a point to visit as often as possible or return to speak or just hang out as my schedule permits. Build Guild Atlanta will continue on without me and I’m proud of what we’ve accomplished as a group in just a year and a half.

We’ll also miss the awesome artist community and friends we’ve made in Atlanta over the years. I’ve seen some of the most impressive works of visual art, performance art, community driven creative projects, musicians, and many other creative outlets. If I didn’t have the opportunity to take part in so many creative events and projects, I’d certainly leave feeling much less enriched as a person. I’m also really going to miss the food. I’ve already got a list of fine restaurants and dishes I’ve grown to love. If I can’t figure out how to make these at home, I am sure we’ll be back to eat that really amazing food, too. The Atlanta community is strong, vibrant, and thriving and I’m proud to have been a part of it all.

I’m excited to pay forward knowledge, skills, and experience I’ve gained in my field and also share some amazing culture we’ve come to love and appreciate in Atlanta. I’m also looking forward to being close to family again and soaking in the bounty that West Virginia has to offer equally in natural resources, culture, and people. To our Atlanta friends and family: we love you very much and will miss you deeply. Thanks for your continued friendship, love, and support! To our West Virginia friends and family: country roads will take us home soon enough.

If you have any specific questions or just want to say hello, ping me on social media, or if you have my number or other contact info, please do not hesitate to reach out.

Take me home, country roads was originally published by Jesse Heady at Jesse Heady on May 31, 2015.

10,944 sunrises and sunsets

2015-03-27T00:00:00-00:00

On March 27, 2015, United States astronaut Scott Kelly and Russian cosmonaut Mikhail Kornienko are scheduled to launch into Earth orbit and live for 1 year aboard the International Space Station.

The year long mission is a milestone event for the United States space program. When completed, it will mark the longest any human being in the NASA program has spent in space. The mission has nearly 600 science experiments planned while Kelly and Kornienko remain in orbit, multiple reconfigurations of the station, and additional mission dockings and crew exchanges. Additionally, cosomonaut Gennady Padalka is commanding the Soyuz launch on March 27, and upon completion of ISS expeditions 43 and 44, he will have spent the most time in space of any human in history, so far.

Most notable of the year in space mission experiments will be the physiological monitoring of the health of Scott compared with his brother Mark, also that of Scott and Mikhail. The United States and Russia have established a partnership of knowledge sharing, as the Russians have had cosmonauts in orbit even longer than one year. The data the ISS 1 Year mission will provide is invaluable to future potential long term missions to Mars and other extended missions to space beyond our Earth and Moon. NASA scientists on Earth will also monitor Scott’s twin brother, astronaut Mark Kelly, throughout the ISS 1 Year flight.

I was fortunate enought to visit Johnson Space Center in Houston on January 15, 2015 for a NASA Social event to meet with these astronauts, the science team, and supporting staff at the space center. I was honored to be selected as one of fifteen people (out of one hundred or so) to get an inside look at this upcoming mission.

I’m eager to watch in awe and support of these explorers as they launch from Baikonur Cosmodrome, Kazakhstan aboard the Soyuz bound for the International Space Station at 3:42 p.m. EDT, Friday, March 27 (March 28, Kazakh time).

Watch the launch live on NASA TV.

Additional press and social media coverage.

Godspeed, gentlemen.

10,944 sunrises and sunsets was originally published by Jesse Heady at Jesse Heady on March 26, 2015.

Usability and broken systems

2018-02-27T00:00:00-00:00

Let’s talk about the usability of broken systems for a moment. Have you ever truly spent the time to observe your own habits and understand what potentially broken systems you or others are working around every day? First of all, we must recognize that humans are adept at self correcting and circumventing broken systems, often subconsciously.

Usability is the discipline of methodically reviewing a design or system, observing users and reviewing real user data, and taking the sum of those internal and external efforts and constantly iterating on the user experience to make it better based on those findings. I’d challenge anyone in the web usability community to also pay close attention to accessibility and performance, if they aren’t already doing so.

Broken systems are experienced constantly: the elevator doesn’t work, the car doesn’t start, the button doesn’t click, the web application crashes and loses the user input, the door sticks and you have to lift the handle to open it, the drain pipe doesn’t flow fast enough to move water, or the door has a handle instead of a push plate but pushes open.

The door with a confusing user interface is a common trope in the context of this discussion. This is an occurrence where someone will pull a handle when presented with one, when perhaps the door needs to be pushed open instead. It’s a frustrating experience and the frequent addition of signage indicating a handle should be “pushed” is a bandage on an already broken system. Interestingly, no matter how many of these door handles someone encounters, people very often instinctively pull instead of push — even with signage indicating the opposite action is necessary.

Building upon the door push versus pull example, if any one of these simple or complex systems was corrected or improved, you as the user may save invaluable time if not simply be amazed by the change you experience. However, interestingly, humans excel so much at working around broken systems that they often won’t realize they are self correcting.

Additionally, there is certainly a range of acceptable yet functionally broken systems. For example, a stopped clock gives the correct time twice a day but requires a higher degree of adaptability while an escalator that has stopped working is still a functional staircase. So, what does usability of software and the general subject of broken systems have to do with one another?

In the ecosystem of the Internet, we encounter micro- and macrocosms of excellent usability and broken systems regularly. Not long after the Internet was invented, email, Internet Relay Chat (IRC), and web pages were created. IRC is one of those mediums that is still alive and well, however it’s quite old, and yet many people in the world have no idea that it exists. IRC is a medium that built the foundation for nearly real-time chat we take for granted today in Facebook, Google+, other instant messenger services, SMS, etc.

Look at a product like Facebook; ubiquitous now with nearly 1.5 billion users. That service is an amalgamation of many of the basic features available in those early systems. It was initially new and inventive, even though it was an improvement over earlier offerings such as Friendster, MySpace, and Orkut. Over time it’s remained relevant because of iterative usability measurements, feedback, and improvements of broken systems.

User behaviors are analyzed in realtime by many modern websites, and Facebook is a great example of real user monitoring of features as they are rolled out and tested in a production setting. If any of these systems are broken, either due to misconfiguration or software bugs, or just because the feature isn’t well received or is a bad user experience, the measurements tell the tale and corrective action can be taken.

Etsy is another great example of a team using this approach as they are known to release 50-60 small iterations of their software to production in a day and utilize feature flags around their software to toggle the availability of that feature to the public. This approach is tremendous for collecting data assuming you’ve set up your application appropriately to do so.

We follow many of these processes at Cox Media Group, but we’re always improving, too. My advice: get a handle on your front end instrumentation and testing strategy early and stick with it. Establish a performance budget with your business partners and other crucial team members, monitor and measure, and react when you start to slip. Reinforce your best practices through automation and code reviews, linters, and git hooks; reject any code that doesn’t pass the bar and help your fellow team members improve their discipline. Prototype new apps or user experiences quickly using tools such as yeoman, bower, and grunt/gulp. Sit in on user studies and really gain an appreciation for objective observation of the users of the things you build. Small development iterations provide clarity, while metrics and user feedback inform your next move.

As a frequent user of various Internet services and applications, mobile devices and computers, TVs and coffee pots, doors and escalators, take the time to occasionally outwardly observe yourself or your space, your home or work habits, your commute, whatever. What do you see that might be broken? What about the products and services you use? Are you working around bothersome or cumbersome systems just to complete simple tasks?

Usability is a discipline that always strives to observe and collect data and focus on improving the ease of use of something. We live in a golden age of information, automation, and smart devices. The most crucial piece of these systems is you, the user. Without the user, these systems become broken themselves. Do yourself a favor and break the systems that aren’t necessarily broken, correct your own behavior and subconscious work arounds, and focus on improving that next iteration. Be the empowered user and don’t just self correct but fix the broken parts of the system in your experience.

Usability and broken systems was originally published by Jesse Heady at Jesse Heady on January 06, 2015.

Bonnie G. Holmes

2018-02-27T00:00:00-00:00

It is difficult to say goodbye to dearly loved ones without also honoring their memory. Great aunt Bonnie Holmes had an incredible wit and kind demeanor with an ever so subtle funny bone. I will remember her fondly for as long as I live, and I intend to share her story as frequently as possible so that others who didn’t know her might understand her undeniable impact on those around her and history itself.

My great aunt Bonnie G. Holmes died on Friday, December 5 at the age of 84 after complications from a stroke. It was my honor to offer eulogy at Bonnie’s funeral along with her grandson and my mother. I’ve recently been reading over some of the many notes that she kept from her 18 year career at NASA as Dr. Wernher von Braun’s secretary, including some of her own remembrances. It’s difficult to represent a lifetime of achievement in a simple collection of words.

Her involvement in shaping history is awe inspiring and I intend to share more of those remembrances, memorabilia, and history in future writings. I’d like to share below a copy of the text that I delivered at her funeral on December 8, 2014 in Eva, AL. It was an exceptionally difficult thing to do, just as saying goodbye to her has been so hard, however it’s the love that we all shared for Bonnie and memories of her that bring a smile back.

Remembrances of Bonnie G. Holmes

Hello, my name is Jesse Heady, I’m one of Bonnie’s grand nephews. I’d like to take a few moments to honor great aunt Bonnie and represent the great- grand kids of the extended Green family.

Bonnie inspired myself and others as children to push our personal boundaries and dreams, she introduced us to astronauts and space and technology, and I will always be grateful for her tremendous legacy at NASA. Her work with Dr. von Braun and others was remarkable and priceless; she lived history and we live in awe and admiration of her contributions.

It wasn’t until years after my experiences at Space Camp that I realized and recognized the significant role she played at Marshall, NASA, and the Rocket Center, let alone the very foundation of Space Camp itself. While many children grow up dreaming to be astronauts, so many of us here are fortunate enough to have lived it vicariously through Bonnie.

I had a phone conversation with my brother Eli on Friday where we discussed great aunt Bonnie and our grief and joy. Eli quipped that the timing of the recent Orion launch delay on Thursday morning, and subsequent successful launch on Friday morning, was auspicious. I agree; it’s as if they were waiting for Bonnie to go along for the ride, and we know that she did. I hope that an entirely new generation carries us forward, just as pioneers like Bonnie did.

Great aunt Bonnie was known as Granny to her grand- and great-grand- children. My own daughter, Bettye Grace, is named for two of her great grandmothers, one of whom was Bettye Maddux Green Payne, my own Granny who passed away in 2007. Unfortunately, just before Thanksgiving this year, we also lost my wife Jenny’s own Granny, Shirley Heston, who everyone also called simply “Granny”.

Now we gather here to celebrate the life, and mourn the passing, of another amazing and inspirational Granny; a woman who in some ways I consider another Granny, just as the others we’ve lost. Great aunt Bonnie was one of a kind, and humble in her career and deeds with NASA, and while we’re all very proud of that especially, we knew her simply as great aunt Bonnie or Granny.

My own name is a name-sake of my great grandfather Jesse Green. My mother’s sister and my aunt, Bonnie Sue, is the namesake of great aunt Bonnie just as my own daughter is the namesake of my Granny. That’s a lot of “name-saking” going on in our family, I know, but let me just say I am looking forward to meeting the next Bonnie.

Strong matriarchs are the foundation of our family and Bonnie embodied these principles. We knew her generous spirit, her clever wit, her beautiful smile, her cooking, and her prowess at Scrabble and Chicken Foot. She truly was a force to be reckoned with; and I know those Grannies are together and that brings me solace in this time of grief.

I will miss her smile and jovial nature. I will miss her generosity and care at taking care of others. I will miss her very presence and being. She will be missed deeply by us all but I know her spirit lives on and I am so very grateful for the time we all had with her on this Earth.

Bonnie Holmes was such a wonderful, caring, and inspirational woman. It’s such a difficult thing we have to do, to say goodbye to such a force, an amazing person who inspired multiple generations within our family, and beyond. We do that today, we celebrate her with all the grace and love that she taught us in life.

Media coverage

Bonnie G. Holmes was originally published by Jesse Heady at Jesse Heady on December 10, 2014.

On photography and graffiti

2013-08-02T00:00:00-00:00

I began working on photograff.it back in June 2013 as a side project simply to find a creative outlet for two of my passion areas: photography and development. The subject of the combined media is graffiti and, in some small way, I pay homage to the real artists who make some amazing street art.

There are three major components to this project: photographs of street art that I have personally taken, geo-locations of the art that’s been photographed, and a means to tie the media and the data together in a consumer friendly manner (web site). I’ll probably spend a separate post here or on photograff.it detailing my technical approach and critical thinking on the hurdles to overcome.

Part of my challenge in this project has been picking the right platform to publish with the lowest barrier to entry, while still supporting enough flexibility to custom develop solutions to manage content. Additionally, I’ve had to overcome a number of technical hurdles with how to manage the geographical data for the photographs, currently without automatic geo-tagging from my DSLR.

The biggest challenge of all, however, has been my own self-defeating attitude and also a lack of time to really commit to the project. Working 15-20 minutes here and there doesn’t really cut it when there are dozens to hundreds of shots to edit. The development of the website and normalization of the EXIF data to appropriate for publishing and associating in some manner to maps while simultaneously presenting the photographs in an aesthetically pleasing format also presents a formidable challenge.

However, with all of that, I am still very driven to make this happen. The concept has been bouncing around my head for years, long before I actually put “pencil to paper” and just got a skeleton of a site running last summer. Since then, I’ve put in dozens of hours shooting and developing, but nothing substantial enough to feel like it’s really clicking. I still believe I’m close and not giving up on the project.

Even though there are already similar projects out there, and most famously the Google Cultural Institute street art project, I’m most excited to share my love of photography and development and maybe help to preserve some of the street art from paths less traveled. I may even learn some things along the way, not just about how to become a better photographer and developer, but how to continually improve prioritizing time-consuming tasks and projects under constrained conditions.

On photography and graffiti was originally published by Jesse Heady at Jesse Heady on July 09, 2014.

Welcome back to the intarwebs

2013-06-18T00:00:00-00:00

I’ve spent about 20 years of my life as a user of the Internet. My first network connected computer was a Tandy (yes, Radio Shack) of some make, maybe a 286 processor, which I initially used to dial in to local BBSes in my hometown. That is, until my good friend and sysadmin started using his modem that was dedicated to his popular BBS for this thing called “The Internet”. People were pissed, myself included. “What the fuck man, I can’t play my door games,” we’d proclaim. It wasn’t until a month or two later that I realized there were infinitely more “doors” on the Internet and I was really missing out.

I convinced my mother to sign us up to a local dial-up ISP. I logged obscene amounts of hours on my 28.8k, 33.6k, and later 56k, baud modems. So much so, that at one point we received a phone bill proclaiming that I’d left an open line to the ISP and was charging hundreds of dollars in “long distance”. It was bullshit, and we called them on it, because we were within the same area code. I am sure it was an attempt to eliminate the open line for whatever reason. It doesn’t matter.

Anyway, I’ll fast forward a little and focus on my introduction and immediate obsession with web programming and architecture. I was fortunate enough to have some really intelligent, like-minded, and highly technically adept friends in high school. We were punks and geeks and didn’t really care about “normal” stuff. I spent a lot of time hacking on servers and websites and designs throughout high school. So much of what I know today was self taught but guided by a few friends who also qualify equally as mentors. I’m so grateful for those friendships and for the path I’ve managed to navigate over the years. The hipster cool geek culture of today was normal life for us then; I feel like the rest of the world is catching up in a lot of ways (ironically, thanks to the Internet). I’m actually very pleased about that. Nerd love.

Over the years, I have maintained a few different static websites that mostly provided an outlet for whatever creative passion I held at that point in time. I also blogged rather obsessively for a while, too. One day I might re-publish that old stuff just for the sake of nostalgia and to remember where I’ve come from to keep me looking ahead. As to where I am going and what I am looking for and what I intend to write about here, mostly I am hoping to focus on the things I’ve already described: technology, development, design. My intention is to get back to writing and hopefully give some things back to the community that’s helped me learn so much.

So, here I am, my grand re-entrance to blogging in cyberspace. Welcome back!

Welcome back to the intarwebs was originally published by Jesse Heady at Jesse Heady on June 18, 2014.