Performance Icon

Performance

71 Stories
All Topics

Zach Leatherman zachleat.com

Use Speedlify to continuously measure site performance

Zach Leatherman:

Instantaneous measurement is a good first step. But how do we ensure that the site maintains good performance and best practices when deploys are happening every day? How do we keep the web site fast? The second step is continuous measurement. This is where Speedlify comes in. It’s an Eleventy-generated web site published as an open source repository to help automate continuous performance measurements.

Demo here.

Use Speedlify to continuously measure site performance

Chrome debugbear.com

How the most popular Chrome extensions affect browser performance

I used to be the guy with dozens of Chrome extensions. These days I limit my use of both (Google Chrome and browser plugins). Performance and reliability are features I desire more than what most plugins have on offer.

That being said, if you have a lot of extensions and you’re curious which ones might be bogging down your machine’s resources, this is a great analysis of the top 1000.

How the most popular Chrome extensions affect browser performance

Achiel van der Mandele Cloudflare

Cloudflare launches speed.cloudflare.com

There’s a new speed test in town…

With many people being forced to work from home, there’s increased load on consumer ISPs. You may be asking yourself: how well is my ISP performing with even more traffic? Today we’re announcing the general availability of speed.cloudflare.com, a way to gain meaningful insights into exactly how well your network is performing.

We’ve seen a massive shift from users accessing the Internet from busy office districts to spread out urban areas. Although there are a slew of speed testing tools out there, none of them give you precise insights into how they came to those measurements and how they map to real-world performance.

Cloudflare launches speed.cloudflare.com

Christian Scott christianfscott.com

Making Rust as fast as Go (fake news)

Is this more proof of Cunningham’s law, which says, “The best way to get the right answer on the Internet is not to ask a question; it’s to post the wrong answer.”

Update: as some keen HN commenters have pointed out, it looks like the rust program is not actually equivalent to the go program. The go program parses the string once, while the rust program parses it repeatedly inside every loop. It’s quite late in Sydney as I write this so I’m not up for a fix right now, but this post is probably Fake News.

Read Christian’s post then have fun in the comments and discussions on HN and Reddit analyzing his hypothesis, which includes a repo of code to backup his ideas.

Addy Osmani github.com

Automating web performance testing with Puppeteer 🎪

Addy Osmani has created an excellent resource for all developers interested in optimizing their web performance (which should be pretty much all of us).

You’ve probably heard of Puppeteer, which lets you control Chromium headlessly over the DevTools protocol. This repo shows you how to use Puppeteer to automate performance measurement, such as getting a performance trace for a page load:

const puppeteer = require('puppeteer');

(async () => {
  const browser = await puppeteer.launch();
  const page = await browser.newPage();
  // Drag and drop this JSON file to the DevTools Performance panel!
  await page.tracing.start({path: 'profile.json'});
  await page.goto('https://pptr.dev');
  await page.tracing.stop();
  await browser.close();
})();

Which produces the results in the image below.

Automating web performance testing with Puppeteer 🎪

JavaScript timkadlec.com

The cost of JavaScript frameworks

We all know our users pay a cost when we push our JS framework in to their browser. Now, thanks to Tim Kadlec doing the yeoman’s work of crunching the numbers, we can approximate just how much that cost really is.

There is no faster (pun intended) way to slow down a site than to use a bunch of JavaScript. The thing about JavaScript is you end up paying a performance tax no less than four times:

  1. The cost of downloading the file on the network
  2. The cost of parsing and compiling the uncompressed file once downloaded
  3. The cost of executing the JavaScript
  4. The memory cost

Thanks to HTTP Archive, we can figure that out.

I’m pretty happy with how sites using jQuery size up. Granted, it’s not really a UI framework like the others are, but you have to imagine that many of those sites also use jQuery UI and their overall cost still compares well to the more modern solutions.

JavaScript github.com

The Axios API, as an 800 byte Fetch wrapper

For those searching for ways to shave a few kilobytes off of their bundles, that’s less than 1/5th of the size. This is made possible by using the browser’s native [Fetch API][fetch], which is supported in all modern browsers and polyfilled by most tools including Next.js, Create React App and Preact CLI.

Of course, you could always use Axios directly if/when you can justify the dependency.

Eric Meyer meyerweb.com

It’s time to get static

Eric Meyer says…

If you are in charge of a web site that provides even slightly important information, or important services, it’s time to get static.

…too many sites are already crashing because their CMSes can’t keep up with the traffic surges. And too many sites are using dynamic frameworks that drain mobile batteries and shut out people with older browsers. That’s annoying and counter-productive in the best of times, but right now, it’s unacceptable.

JavaScript github.com

An extremely fast JavaScript bundler and minifier

Why build another JavaScript build tool? The current build tools for the web are at least an order of magnitude slower than they should be. I’m hoping that this project serves as an “existence proof” that our JavaScript tooling can be much, much faster.

According to the author, esbuild is fast because..

  1. it’s written in Go
  2. much of the work is done in parallel
  3. it takes very few passes and avoids data transformations
  4. it was coded with performance in mind
An extremely fast JavaScript bundler and minifier

Docker github.com

Minify and secure your docker containers (30x?)

DockerSlim promises a lot:

docker-slim will optimize and secure your containers by understanding your application and what it needs using various analysis techniques. It will throw away what you don’t need reducing the attack surface for your container. What if you need some of those extra things to debug your container? You can use dedicated debugging side-car containers for that.

Their minification examples are impressive…

Polina Gurtovaya Evil Martians

Images done right: Web graphics, good to the last byte

Polina Gurtovaya:

Start taking graphics on the web seriously and boost your applications’ performance by learning the essentials about image formats, both modern and old-school. Dig into SVGs and adopt the latest and greatest tools to optimize your graphical content: both vector and raster. Study the theory behind digital images and how humans perceive them—to improve the experience for your users.

Philip Walton philipwalton.com

Cascading cache invalidation

Turns out one of our asset caching best practices (content hashes in filenames + far-future expiry) has a serious flaws in it:

In practice, changes to one of your source files almost always invalidates more than one of your output files—and this happens because you’ve added revision hashes to your filenames.

Philip goes on to explain why this happens and then proposes 3 possible solutions. Good stuff 👌

Shopify Engineering Icon Shopify Engineering

How to write fast code in Ruby on Rails

If I had to pick one engineering team to write up how they make (and keep) Rails running fast, it’d be Shopify’s. What a treat!

Part of Shopify’s success with Ruby on Rails is an emphasis on writing fast code. But, how do you really write fast code? Largely, that’s context sensitive to the problem you’re trying to solve. Let’s talk about a few ways to start writing faster code in Active Record, Rails, and Ruby.

Conrad Irwin blog.superhuman.com

Performance metrics for blazingly fast web apps

Measure it so you can improve it, but how?

…performance metrics are surprisingly challenging to get right.

On the one hand, it is hard to design metrics that accurately represent the user experience. On the other hand, it is difficult to make metrics that are usefully precise. As a result, many teams cannot trust their performance data.

Even with accurate and precise metrics, the data is hard to use. How do we define “fast”? How do we balance speed and consistency? How do we quickly find regressions or see the impact of optimizations?

CSS Wizardry Icon CSS Wizardry

Time to first byte — What is it? Why does it matter?

Harry Roberts writing on CSS Wizardry:

One metric I feel that front-end developers overlook all too quickly is Time to First Byte (TTFB). This is understandable—forgivable, almost—when you consider that TTFB begins to move into back-end territory, but if I was to sum up the problem as succinctly as possible, I’d say: While a good TTFB doesn’t necessarily mean you will have a fast website, a bad TTFB almost certainly guarantees a slow one.

Even though, as a front-end developer, you might not be in the position to make improvements to TTFB yourself, it’s important to know that any problems with a high TTFB will leave you on the back foot, and any efforts you make to optimises images, clear the critical path, and asynchronously load your webfonts will all be made in the spirit of playing catchup.

Victor Zhou victorzhou.com

Minify Your SVGs

Victor Zhou uses a lot of SVGs on his blog. Do you? So now he optimizes their size as part of his build process. Do you?

62 SVGs minified, reducing the total size from 459322 bytes to 208897 bytes, a reduction of 54.5%! That’s a total of 250 KB, or 4 KB per SVG. Keep in mind that all of my SVGs were already saved in the Optimized SVG format - these savings were on top of already optimized SVGs. If you haven’t thought about minifying your SVGs before, chances are you’d see much more drastic results.

Smashing Magazine Icon Smashing Magazine

Using the web for a day on a 50 mb budget

This is a fascinating look at how “size negligence”, AKA not paying close attention to the size of your images, javascript, etc impacts people in parts of the world where data is slow and expensive. Author Chris Ashton on why you should care:

We don’t have the power to change the global cost of data inequality. But we do have the power to lessen its impact, improving the experience for everyone in the process.

Tim Kadlec timkadlec.com

Web performance as exclusion?

Tim Kadlec writes about “The ethics of web performance” and the idea of web performance having ethical ramifications.

When you look at the evidence, it’s hard to see one could argue performance doesn’t have ethical ramifications. So clearly, folks who have built a heavy site are bad, unethical people, right? Here’s the thing. I have never in my career met a single person who set out to make a site perform poorly. Not once. People want to do good work. But a lot of folks are in situations where that’s very difficult.

The business models that support much of the content on the web don’t favor better performance. Nor does the culture of many organizations who end up prioritizing the next feature over improving things like performance or accessibility or security.

I would argue the other angle, “Web performance as compassion” to show how you can show compassion for the users of your software through performance.

Tom Warren The Verge

Slack’s new desktop app loads 33 percent faster and uses less RAM

Good news fellow Slack users, your productivity just got bumped by the perf gods of Slack thanks to their continued efforts and focus on the desktop app’s performance.

Slack is unveiling a new version of its desktop app for Windows and macOS today that promises big performance improvements. Slack has rebuilt its desktop app to focus on speed, and the company claims Slack will now launch 33 percent faster than before. The Slack app will even use 50 percent less RAM than before, according to the company.

Slack has been working on this overhaul for two years, slowly modernizing parts of its code along the way. While the desktop apps still run on Electron, all of the UI parts have been rebuilt using React to fix some of the shortcomings of the existing Slack app.

0:00 / 0:00