Select Page

Category: Performance

Fast Software

There have been some wonderfully interconnected things about fast software lately. We talk a lot of performance on the web. We can make things a little faster here and there. We see rises in success metrics with rises in performance. I find those type of charts very satisfying. But perhaps even more interesting is to think about the individual people that speed affects. It can be the difference between I love this software and Screw this, I’m out. Craig Mod, in “Fast Software, the Best Software”, totally bailed on Google Maps: Google Maps has gotten so slow, that I did the unthinkable: I reinstalled Apple Maps on my iPhone. Apple Maps in contrast, today, is downright zippy and responsive. The data still isn’t as good as Google Maps, but this a good example of where slowness pushed me to reinstall an app I had all but written off. I’ll give Apple Maps more of a chance going forward. And puts a point on it: But why is slow bad? 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. Sometimes it’s even life and death! Hillel Wayne, in “Performance Matters,” says emergency workers in an ambulance don’t use the built-in digital “Patient Care Report” (PCR)...

Read More

Jeremy Keith – Building the Web

I really enjoyed this interview with Jeremy Keith on the state of the web, how things have changed in recent years and why he’s a mix of optimistic and nervous for the future. One thing that caught my attention during the interview more than anything was where Jeremy started discussing how folks think that websites are pretty crummy in general. This reminded me that I cannot count the number of times when someone has said to me “ah, I can’t view this website on my phone.” We have websites that aren’t responsive! We have websites that litter the UI with advertisements and modals! And we have websites that are slow as all heck just when we need them the most! Of course folks are going to start complaining about the web and working around them if they find that this is the case. I’ll even catch myself sending an email to myself when I know that the mobile experience is going to be crummy. Or I’ll Instapaper something because the design of the website is particularly difficult to read. Remember, Reader Mode is the button to beat. My quick thought on this is that we shouldn’t become sour and pessimistic. We should roll up our sleeves and get to work because clearly there’s much left to do. Direct Link to Article — Permalink The post Jeremy Keith – Building...

Read More

How to Increase Your Page Size by 1,500% with webpack and Vue

Disclaimer: This article is mostly satire. I do not think that I am better than you because I once wrote some TypeScript nor do I think that it’s a good thing for us to make web pages bigger. Feel free to misrepresent these views to maximize clicks. You know, there are a lot of articles out there telling you how to make your page smaller: optimize your images, remove extraneous CSS rules, re-write the whole thing in Dreamweaver using framesets. Look,  Walmart just reduced their page size by some numbers, give or take. JavaScript housekeeping: 🗑️ Remove old &...

Read More

A Deep Dive into Native Lazy-Loading for Images and Frames

Today’s websites are packed with heavy media assets like images and videos. Images make up around 50% of an average website’s traffic. Many of them, however, are never shown to a user because they’re placed way below the fold. What’s this thing about images being lazy, you ask? Lazy-loading is something that’s been covered quite a bit here on CSS-Tricks, including a thorough guide with documentation for different approaches using JavaScript. In short, we’re talking about a mechanism that defers the network traffic necessary to load content when it’s needed — or rather when trigger the load when the...

Read More

The Serif Tax

Fonts are vector. Vector art with more points makes for larger files than vector art with fewer points. Custom fonts are downloaded. So, fonts with less points in their vector art are smaller. That’s the theory anyway. Shall we see if there is any merit to it? Open Sans (top) and Garamond (bottom) Let’s take two fonts off of Google Fonts: Open Sans and EB Garamond. The number of points isn’t a dramatic difference, but the seriffed Garamond does have more of them, particularly in looking at the serif areas. It’s not just serifs, but any complication. Consider Bleeding...

Read More

Using React Loadable for Code Splitting by Components and Routes

In a bid to have web applications serve needs for different types of users, it’s likely that more code is required than it would be for one type of user so the app can handle and adapt to different scenarios and use cases, which lead to new features and functionalities. When this happens, it’s reasonable to expect the performance of an app to dwindle as the codebase grows. Code splitting is a technique where an application only loads the code it needs at the moment, and nothing more. For example, when a user navigates to a homepage, there is...

Read More

Fighting FOIT and FOUT Together

Lots from Divya with the setup: There are 2 kinds of problems that can arise when using webfonts; Flash of invisible text (FOIT) and Flash of Unstyled Text (FOUT) … If we were to compare them, FOUT is of course the lesser of the two evils If you wanna fight FOIT, the easiest tool is the font-display CSS property. I like the optional value because I generally dislike the look of fonts swapping. If you want to fight them both, one option is to preload the fonts: But… Preload is your friend, but not like your best friend … preloading in excess can significantly worsen performance, since preloads block initial render. Just like CSS does. Even huge sites aren’t doing much about font loading perf. Roel Nieskens: I expected major news sites to be really conscious about the fonts they use, and making sure everything is heavily optimised. Turns out a simple Sunday afternoon of hacking could save a lot of data: we could easily save roughly 200KB Fonts are such big part of web perf, so let’s get better at it! Here’s Zach Leatherman at the Performance.now() conference: Part of the story is that we might just have lean on JavaScript to do the things we need to do. Divya again: Web fonts are primarily CSS oriented. It can therefore feel like bad practice to reach for JavaScript...

Read More

The Three Types of Performance Testing

We’ve been covering performance quite a bit — not just recently, but throughout the course of the year. Now, Harry Roberts weighs in by identifying three types of ways performance can be tested. Of particular note is the first type of testing: The first kind of testing a team should carry out is Proactive testing: this is very intentional and deliberate, and is an active attempt to identify performance issues. This takes the form of developers assessing the performance impact of every piece of work they do as they’re doing it. The idea here is that we spot the problem before it becomes problematic. Prevention, after all, is cheaper than the cure. Capturing performance issues at this stage is much more preferable to spotting them after they’ve gone live. I think about this type of performance all the time when I’m working on a team, although I’ve never had a name for it. I guess what I’m always thinking about is how can we introduce front-end engineers into the design process as early as possible? I’ve found that the final product is much more performant in when front-end engineers and designers brainstorm solutions together. Perhaps collaborating on a performance checklist is a good place to start? Direct Link to Article — Permalink The post The Three Types of Performance Testing appeared first on CSS-Tricks....

Read More

The Cost of JavaScript in 2018

Even though we mentioned it earlier, I thought this outstanding post by Addy Osmani all about the performance concerns of JavaScript was still worth digging into a little more. In that post, Addy touches on all aspects of perf work and how we can fix some of the most egregious issues, from setting up a budget to “Time-to-Interactive” measurements and auditing your JavaScript bundles. Embrace performance budgets and learn to live within them. For mobile, aim for a JS budget of < 170KB minified/compressed. Uncompressed this is still ~0.7MB of code. Budgets are critical to success, however, they can’t magically fix perf in isolation. Team culture, structure and enforcement matter. Building without a budget invites performance regressions and failure. Super specific and super practical! Surprisingly, Addy mentions that “the median webpage today currently ships about 350KB of minified and compressed JavaScript,” which seems like an awful lot lower than I’d expected, if I’m being honest. The stat that scares me most is that the median webpage takes around fifteen whole seconds until it’s interactive. And pulling all that JS into a Web Worker or caching with Service Workers won’t even make up that time to interaction. Yikes. Another key point: not all bytes are equal. For example, 200KB of JavaScript is not equal to a 200KB JPG image file: A JPEG image needs to be decoded, rasterized, and painted...

Read More
  • 1
  • 2
www.000webhost.com