TIL: When working with namespaced files in PHP it’s a huge performance win when using fully-qualified function calls.
If you’re calling is_null in your code, PHP will first check for the function’s existence in the current namespace. If not found there, it will look for the function in the global namespace. This extra check is quite a drag, as detailed in this issue for the SCSS PHP Project.
If you do want to target PHP’s built-in is_null(or any other global function), it’s more performant to refer to it using it’s fully-qualified name, e.g. \is_null
Alternatively you can also import the function first through a use statement.
use function is_null;
In the case of SCSS PHP the change from is_null to \is_null lead to a 28% speed increase!. If you’re looking for more benchmarks, Toon Verwerft has done some benching in the past.
Did this help you out? Like what you see? Thank me with a coffee.
I don't do this for profit but a small one-time donation would surely put a smile on my face. Thanks!
Tim Kaldec takes a look at our modern workflow – in which lots of tools have removed friction – and makes the case to add some “healthy friction”:
A lot of modern workflow improvements have been around removing friction. We want to make it easier to deploy rapidly. Tools like npm make it very easy to gain access to any and all modules we could think of. Tag management enables folks to very quickly add another third-party service.
All of these things, on the surface, provide some value, but the consequences are tremendous. Because these processes remove friction, they don’t ever really give us a chance to pause and consider what we’re doing.
Re-introducing some healthy friction, some moments of pause, in our processes is critical to ensuring a higher level of quality overall.
Examples would be installers that prevent you from installing large bundles, or build pipelines that mark the build as failed when the total bundle size exceeds a certain goal.
Google Fonts is great, but it also has a downside: it affects your page’s waterfall (during which some render-blocking may occur, as it involves CSS) as explained by Barry Pollard:
The problem is that your website (say www.example.com) loads the stylesheet from fonts.googleapis.com, which returns some CSS made up of font-face declarations.
This means you have to connect to fonts.googleapis.com, download the CSS, then connect to fonts.gstatic.com to download the actual fonts.
Fonts are often discovered late by the browser when loading a page (as you need to download the CSS to see them) but Google Fonts are discovered extra late, as you need to download the CSS from another domain, then the fonts from a 3rd domain and, as discussed above, making an HTTPS connection takes time.
This post goes really deep into how it all works. Covers things such as rel="preconnect", font-display: swap;, etc.
Talk by Alex Holachek, as brought forward at React Conf 2019:
As the technology to create Progressive Web Apps continues to mature, React developers have the opportunity to write web apps that in some cases can rival native ones in terms of speed and convenience.
However, one barrier to feature parity is the difficulty of creating a native-like UI transition and interaction experience on the mobile web, especially on lower-end devices.
I’ll be discussing various considerations, tips and techniques to create a web app in React that looks, moves, and feels as close to a native mobile app as possible.
Think of gesture-driven animations like these here:
Philip Walton on how to progressively enhance your site by leveraging Service Workers to fetch partial HTML content and replace it in the DOM:
On this site, after a user visits once and the service worker is installed, that user will never request a full HTML page again. Instead the service worker will intercept requests for pages and just request the contents of those pages—everything inside the <main> element—and then the service worker will combine that content with the rest of the HTML, which is already in the cache.
By only requesting the contents of a page, the networks payloads become substantially smaller, and the pages can load quite a bit faster. For example, on this site over the past 30 days, page loads from a service worker had a 47.6% smaller network payloads, and a median First Contentful Paint (FCP) that was 52.3% faster than page loads without a service worker (416ms vs. 851ms).
Harry Roberts on how to set a Performance Budgets if you really don’t have a clue where to start:
Our budget for [metric] is never-worse-than-it-is-right-now.
Harry suggest to measure in periods of two weeks (or whatever the length of your sprints I guess) and always compare against the previous value. If performance is equal or better: great, you’ve got your next maximum to compare against next time. If performance is worse: you’ve got work (or some serious explaining) to do.
By constantly revisiting and redefining budgets in two-weekly snapshots, we’re able to make slow, steady, and incremental improvements.