An interesting retrospective on how CloudFlare migrated from Gatsby to Hugo for their docs. Build times for the static site were up to an hour (!) long. At some point, the performance of a tool can really become a bottleneck for your team.
Today, we're launching a new Spatie package: Laravel Google Fonts. I've written about Google Fonts before. It's a great font catalog, but the service has it's downsides. First, fonts are hosted on a different domain than your app, so the browser needs to do an additional DNS lookup. Second, it's Google. Privacy-minded visitors might not appreciate the trip to Silicon Valley.
I haven't used Google Fonts in production for a long time. I use the service for development, and strip out all references to Google before going live. I do this for performance, and my visitors' privacy.
Google went down today. Downtime at this scale doesn't happen often, but when it rains, it pours. Google going down doesn't only affect Google products, it also affect products connected to Google. App that require authentication with your Google account weren't available, unless you were already logged in.
Coïncidentally, I came across a compelling article about local-first software. From a SaaS point of view, before the internet all we had local-first.
I recently stumbled across an over 5 year old comment on Hacker News about performance.
Lots of people make the mistake of thinking there's only two vectors you can go to improve performance, high or wide.
- High - throw hardware at the problem, on a single machine
- Wide - Add more machines
There's a third direction you can go, I call it "going deep". Today's programs run on software stacks so high and so abstract that we're just now getting around to redeveloping (again for like the 3rd or 4th time) software that performs about as well as software we had around in the 1990s and early 2000s
Going deep means stripping away this nonsense and getting down closer to the metal, using smart algorithms, planning and working through a problem and seeing if you can size the solution to running on one machine as-is.
The author talks about "high" and "wide" hardware changes, but this can apply to software too. It's easier to throw a cache at a slow piece of code than going deep and fixing it.
No need to look far, Electron is built on this principle. We're adding heavy runtimes to support multiple platforms instead of staying close to the metal, and we pay the price in performance.
Jeremy Wagner measured some performance differences between React and vanilla JavaScript. While I'm not surprised that running your code on bare metal code is faster than a framework, it's interesting to see some exact numbers.
React and ReactDOM total about 120 KiB of minified JavaScript, which definitely contributes to slow startup time. When client-side rendering in React is relied upon entirely, it churns. Even if you render components on the server and hydrate them on the client, it still churns because component hydration is computationally expensive.
If it sounds like I have a grudge against React, then I must confess that I really like its componentization model. It makes organizing code easier. I think JSX is great. Server rendering is also cool—even if that’s just how we say “send HTML over the network” these days.
Even with server-side rendering, React and other virtual DOM frameworks add loading time because they need to load more code and hydrate the page before it's interactive.
A vanilla addEventListener callback performs about 40 times faster (!) than an event handled in a React component. React's overhead worth when you have a lot of complex state, not "simple state" like menu toggles.
Read the full article on CSS-Tricks.
In his most recent essay, Craig Mod explores the effect of optimizing software for speed.
Speed and reliability are often intuited hand-in-hand. Speed can be a good proxy for general engineering quality. If an application slows down on simple tasks, then it can mean the engineers aren’t obsessive detail sticklers. Not always, but it can mean disastrous other issues lurk. I want all my craftspeople to stickle.
My newfound love for Hugo echoes this sentiment. It’s not the friendliest tool, but it’s speed and focus on doing one thing right makes it a joy to use.
That said, Sublime Text has -- in my experience -- only gotten faster. I love software that does this: Software that unbloats over time. This should be the goal of all software. The longer it’s around, the more elegant it should become. Smooth over like a river stone. I have full trust in the engineering of Sublime Text because I’ve used it for over a decade, but also because it always feels like a fast, focused tool (even though it’s actually very complicated) and has only become faster the longer I’ve used it.
Software that unbloats over time. What a beautiful idea.
Another excerpt that just had to be quoted:
Google Maps used to be a fast, focused tool. It’s now quite bovine. If you push the wrong button, it moos. Clunky, you could say. Overly complex. Unnecessarily layered.
Read the full essay on craigmod.com.
When you visit a website, your browser connects to a server via TCP. With TCP, the first roundtrip can be up to 14 KB large.
In other words, the first 14 KB sent to the client will always be the quickest to render in the browser. The rest of the response is streamed afterwards.
This website's homepage is about 9.7 KB at the time of writing. Articles are roughly 4-10 KB, depending on their lengths. All CSS is inlined, so besides fonts and images everything is loaded withing the first roundtrip, making page loads fast and snappy.
Not all sites can be contained within 14 KB — most probably can't. But keep the number in mind, and try to optimize the first 14 KB instead.
I used to think disabled JavaScript went hand in hand with visitors explicitly blocking it. I came to the conclusion that I don't necessarily need to cater to that crowd, because the degraded user experience was by choice. After reading through this chart, I realized how wrong I was.
Sometimes your JavaScript just won’t work. Be prepared.
Read the flowchart on kryogenix.org.
As a short follow-up to Everyone has JavaScript, right?, there's more to JavaScript than availability, there are also the performance implications.
I don’t think most people are saying, “don’t use JavaScript.” That would be absurd.
But use less, use it wisely, and don’t depend on a giant framework for simple stuff. Use as little JS as possible to get the experience you want. You can do that and still have a great, immersive app.
I believe we're reaching for JavaScript more often because of its ecosystem, not because it's the better solution. The JavaScript ecosystem simply has incredible tools to build interfaces, and I hope server side solutions will still be able to compete.
I don't have a conclusion ready, I'm just interested in the topic. To be explored in 2019. Meanwhile, read Chris Ferdinandi's thoughts on the matter.
2017-08-29 #javascript #animations #performance / medium.com
I love this post! requestAnimationFrame is a primitive browser API that doesn’t sound too interesting at first, but once you've grasped some basic concepts, it becomes an extremely powerful tool for dealing with animations in JavaScript.
At its core,
requestAnimationFramedoesn’t do much: it’s basically just a method that executes a callback. In fact, there are very few differences between doingrequestAnimationFrame(doSomething)anddoSomething(). So, what’s so special about it? I’m glad you asked! In short:
requestAnimationFrameschedules the callback call on the next repaintrequestAnimationFramepasses the callback the current timeThere are a few other distinctions, but these are the main benefits. Now,
requestAnimationFramedoesn’t create an animation on its own, it’s the sequence of successive callbacks that will make things move on the screen.
My favorite part: since a large part of animating with requestAnimationFrame consists of composing small mathematical expressions, you can apply all sorts of functional programming tricks to your code.
Learn all about it on Benjamin De Cock’s blog.