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.
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.
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.
Read the flowchart on kryogenix.org.
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 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.
I love this post!
At its core,
requestAnimationFrame doesn’t do much: it’s basically just a method that executes a callback. In fact, there are very few differences between doing
doSomething(). So, what’s so special about it? I’m glad you asked! In short:
requestAnimationFrame schedules the callback call on the next repaint
requestAnimationFrame passes the callback the current time
There are a few other distinctions, but these are the main benefits. Now,
requestAnimationFrame doesn’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.