This was a fun little trip down memory lane. Those BDConf events are still some of my absolute favorite memories, and so many of the speakers and attendees have remained good friends years later.
Really nice walkthrough about diagnosing and solving slow tooltips.
Philip takes a trip down memory lane with some fun stories from the early Yahoo! days around performance.
But most importantly, he suggests that the SEO carrot has tipped the focus of performance, and not for the better.
Sites that truly care about performance and the business impact of that performance, worked hard to make their sites faster.
This changed when Google started using speed as a ranking signal.
I made a similar point in a revamped version of my “Performance Budgets that Stick” talk the other week. If we want this burst of performance interest to stick, and to have the impact we want it to have for users, we’re going to need to make it easier for folks to connect the dots between business metrics and performance.
But now, I find myself all consumed by the question, WHY are links blue? WHO decided to make them blue? WHEN was this decision made, and HOW has this decision made such a lasting impact?
I turned to my co-workers to help me research, and we started to find the answer. Mosaic, an early browser released by Marc Andreessen and Eric Bina on January 23, 1993, had blue hyperlinks. To truly understand the origin and evolution of hyperlinks though, I took a journey through technology history and interfaces to explore how links were handled before color monitors, and how interfaces and hyperlinks rapidly evolved once color became an option.
The computers sitting on our desks are incomprehensibly fast. They can perform more operations in one second than a human could in one hundred years. We live in an era of CPUs that can perform billions of instructions per second, tens of billions if we take multi-cores into account, of memory that can transfer data to the CPU at hundreds of gigabytes per second, of disks that support streaming reads of gigabytes per second. This era of incredibly fast hardware is also the era of programs that take tens of seconds to start from an SSD or NVMe disk; of bloated web applications that take many seconds to show a simple list, even on a broadband connection; of programs that process data at a thousandth of the speed we should expect. Software is laggy and sluggish — and the situation shows little signs of improvement.
The relevant parts of an image aren’t limited to the cold hard facts. Images can make you feel a particular way, and that’s something that should be made available to a screen reader user.
Smart stuff (as per his always) from Zach on how he’s automating the process of creating custom Open Graph images for his blog posts.
Alex is back at it with another very well written and important post, this time focusing on the state of mobile browser choice and how each major contributor is undermining user choice.
The mobile web is a pale shadow of its potential because the vehicle of progress that has delivered consistent gains for two decades has silently been eroded to benefit native app platforms and developers. These attacks on the commons have at their core a shared disrespect for the sanctity of user choice, substituting the agenda of app and OS developers for mediation by a user’s champion.
This post summarizes how we analyzed publicly available web transparency data and ad hoc A/B testing to understand the adoption and performance characteristics of native image lazy-loading. What we found is that lazy-loading can be an amazingly effective tool for reducing unneeded image bytes, but overuse can negatively affect performance. Concretely, our analysis shows that more eagerly loading images within the initial viewport—while liberally lazy-loading the rest—can give us the best of both worlds: fewer bytes loaded and improved Core Web Vitals.
If fixing the introverted checkout button caused a three-quarters of a percentage point increase in online orders, it would increase Darden’s revenue by $8.1 million annually.
All of these numbers are guesses. They’re probably wrong. But even if they were a tenth of what I estimated, it would still be $812k. See what I mean about small changes making a big difference at this scale?
Jason documents his struggles trying to order from Olive Garden, and notes how a simple fix could provide them a significant boost in revenue.