26 September 2020 0 comments Web development, Web Performance, JavaScript
You can write your CSS so that it depends on images. Like this:
li.one {
background-image: url("skull.png");
}
That means that the browser will do its best to style the li.one with what little it has from the CSS. Then, it'll ask the browser to go ahead and network download that skull.png URL.
But, another option is to embed the image as a data URL like this:
li.one{background-image:url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAIAAAACACAYAAADDPmHL...rkJggg==)
As a block of CSS, it's much larger but it's one less network call. What if you know that skull.png will be needed? Is it faster to inline it or to leave it as a URL? Let's see!
First of all, I wanted to get a feeling for how much larger an image is in bytes if you transform them to data URLs. Check out this script's output:
▶ ./bin/b64datauri.js src/*.png src/*.svg
src/lizard.png 43,551 58,090 1.3x
src/skull.png 7,870 10,518 1.3x
src/clippy.svg 483 670 1.4x
src/curve.svg 387 542 1.4x
src/dino.svg 909 1,238 1.4x
src/sprite.svg 10,330 13,802 1.3x
src/survey.svg 2,069 2,786 1.3x
Basically, as a blob of data URL, the images become about 1.3x larger. Hopefully, with HTTP2, the headers are cheap for each URL downloaded over the network, but it's not 0. (No idea what the CPU-work multiplier is)
Experiment assumptions and notes
- When you first calculate the critical CSS, you know that there's no
url(data:mime/type;base64,....) that goes to waste. I.e. you didn't put that in the CSS file or HTML file, bloating it, for nothing. - The images aren't too large. Mostly icons and fluff.
-
If it's SVG images should probably inline them in the HTML natively so you can control their style.
- The HTML is compressed for best results.
- The server is HTTP2
It's a fairly commonly known fact that data URLs have a CPU cost. That base64 needs to be decoded before the image can be decoded by the renderer. So let's stick to fairly small images.
The experiment
I made a page that looks like this:
li {
background-repeat: no-repeat;
width: 150px;
height: 150px;
margin: 20px;
background-size: contain;
}
li.one {
background-image: url("skull.png");
}
li.two {
background-image: url("dino.svg");
}
li.three {
background-image: url("clippy.svg");
}
li.four {
background-image: url("sprite.svg");
}
li.five {
background-image: url("survey.svg");
}
li.six {
background-image: url("curve.svg");
}
and
<ol>
<li class="one">One</li>
<li class="two">Two</li>
<li class="three">Three</li>
<li class="four">Four</li>
<li class="five">Five</li>
<li class="six">Six</li>
</ol>
See the whole page here
The page also uses Bootstrap to make it somewhat realistic. Then, using minimalcss combine the external CSS with the CSS inline and produce a page that is just HTML + 1 <style> tag.
Now, based on that page, the variant is that each url($URL) in the CSS gets converted to url(data:mime/type;base64,blablabla...). The HTML is gzipped (and brotli compressed) and put behind a CDN. The URLs are:
Also, there's this page which is without the critical CSS inlined.
To appreciate what this means in terms of size on the HTML, let's compare:
inlined.html with external URLs: 2,801 bytes (1,282 gzipped)inlined-datauris.html with data URLs: 32,289 bytes (17,177 gzipped)
Considering that gzip (accept-encoding: gzip,deflate) is almost always used by browsers, that means the page is 15KB more before it can be fully downloaded. (But, it's streamed so maybe the comparison is a bit flawed)
Analysis
WebPagetest.org results here. I love WebPagetest, but the results are usually a bit erratic to be a good enough for comparing. Maybe if you could do the visual comparison repeated times, but I don't think you can.
WebPagetest visual comparison
And the waterfalls...
With regular URLs
With data URLs
Fairly expected.
With external image URLs, the browser will start to display the CSSOM before the images have downloaded. Meaning, the CSS is render-blocking, but the external images are not.
The final result comes in sooner with data URLs.
With data URLs you have to stare at a white screen longer.
Next up, using Google Chrome's Performance dev tools panel. Set to 6x CPU slowdown and online with Fast 3G.
I don't know how to demonstrate this other than screenshots:
Performance with external images
Performance with data URLs
Those screenshots are rough attempts at showing the area when it starts to display the images.
Whole Performance tab with external images
Whole Performance tab with data URLs
I ran these things 2 times and the results were pretty steady.
- With external images, fully loaded at about 2.5 seconds
- With data URLs, fully loaded at 1.9 seconds
I tried Lighthouse but the difference was indistinguishable.
Summary
Yes, inlining your CSS images is faster. But it's with a slim margin and the disadvantages aren't negligible.
This technique costs more CPU because there's a lot more base64 decoding to be done, and what if you have a big fat JavaScript bundle in there that wants a piece of the CPU? So ask yourself, how valuable is to not hog the CPU. Perhaps someone who understands the browser engines better can tell if the base64 decoding cost is spread nicely onto multiple CPUs or if it would stand in the way of the main thread.
What about anti-progressive rendering
When Facebook redesigned www.facebook.com in mid-2020 one of their conscious decisions was to inline the SVG glyphs into the JavaScript itself.
"To prevent flickering as icons come in after the rest of the content, we inline SVGs into the HTML using React rather than passing SVG files to <img> tags."
Although that comment was about SVGs in the DOM, from a JavaScript perspective, the point is nevertheless relevant to my experiment. If you look closely, at the screenshots above (or you open the URL yourself and hit reload with HTTP caching disabled) the net effect is that the late-loading images do cause a bit of "flicker". It's not flickering as in "now it's here", "now it's gone", "now it's back again". But it's flickering in that things are happening with progressive rendering. Your eyes might get tired and they say to your brain "Wake me up when the whole thing is finished. I can wait."
This topic quickly escalates into perceived performance which is a stratosphere of its own. And personally, I can only estimate and try to speak about my gut reactions.
In conclusion, there are advantages to using data URIs over external images in CSS. But please, first make sure you don't convert the image URLs in a big bloated .css file to data URLs if you're not sure they'll all be needed in the DOM.
Bonus!
If you're not convinced of the power of inlining the critical CSS, check out this WebPagetest run that includes the image where it references the whole bootstrap.min.css as before doing any other optimizations.
With baseline that isn't just the critical CSS
10 September 2020 0 comments Node, JavaScript
To transpile .scss (or .sass) in Node you have the choice between sass and node-sass. sass is a JavaScript compilation of Dart Sass which is supposedly "the primary implementation of Sass" which is a pretty powerful statement. node-sass on the other hand is a wrapper on LibSass
which is written in C++. Let's break it down a little bit more.
Speed
node-sass is faster. About 7 times faster. I took all the SCSS files behind the current MDN Web Docs which is fairly large. Transformed into CSS it becomes a ~180KB blob of CSS (92KB when optimized with csso).
Here's my ugly benchmark test which I run about 10 times like this:
node-sass took 101ms result 180kb 92kb
node-sass took 99ms result 180kb 92kb
node-sass took 99ms result 180kb 92kb
node-sass took 100ms result 180kb 92kb
node-sass took 100ms result 180kb 92kb
node-sass took 103ms result 180kb 92kb
node-sass took 102ms result 180kb 92kb
node-sass took 113ms result 180kb 92kb
node-sass took 100ms result 180kb 92kb
node-sass took 101ms result 180kb 92kb
And here's the same thing for sass:
sass took 751ms result 173kb 92kb
sass took 728ms result 173kb 92kb
sass took 728ms result 173kb 92kb
sass took 798ms result 173kb 92kb
sass took 854ms result 173kb 92kb
sass took 726ms result 173kb 92kb
sass took 727ms result 173kb 92kb
sass took 782ms result 173kb 92kb
sass took 834ms result 173kb 92kb
In another example, I ran sass and node-sass on ./node_modules/bootstrap/scss/bootstrap.scss (version 5.0.0-alpha1) and the results are after 5 runs:
node-sass took 269ms result 176kb 139kb
node-sass took 260ms result 176kb 139kb
node-sass took 288ms result 176kb 139kb
node-sass took 261ms result 176kb 139kb
node-sass took 260ms result 176kb 139kb
versus
sass took 1423ms result 176kb 139kb
sass took 1350ms result 176kb 139kb
sass took 1338ms result 176kb 139kb
sass took 1368ms result 176kb 139kb
sass took 1467ms result 176kb 139kb
Output
The unminified CSS difference primarily in the indentation. But you minify both outputs and the pretty print them (with prettier) you get the following difference:
▶ diff /tmp/sass.min.css.pretty /tmp/node-sass.min.css.pretty
152c152
< letter-spacing: -0.0027777778rem;
---
> letter-spacing: -0.00278rem;
231c231
< content: "▼︎";
---
> content: "\25BC\FE0E";
...snip...
2804c2812
< .external-icon:not([href^="https://mdn.mozillademos.org"]):not(.ignore-external) {
---
> .external-icon:not([href^='https://mdn.mozillademos.org']):not(.ignore-external) {
Basically, sass will use produce things like letter-spacing: -0.0027777778rem; and content: "▼︎";. And node-sass will produce letter-spacing: -0.00278rem; and
content: "\25BC\FE0E";.
I also noticed some minor difference just in the order of some selectors but when I look more carefully, they're immaterial order differences meaning they're not cascading each other in any way.
Note! I don't know why the use of ' and " is different or if it matters. I don't know know why prettier (version 2.1.1) didn't pick one over the other consistently.
node_modules
Here's how I created two projects to compare
cd /tmp
mkdir just-sass && cd just-sass && yarn init -y && time yarn add sass && cd ..
mkdir just-node-sass && cd just-node-sass && yarn init -y && time yarn add node-sass && cd ..
Considering that sass is just a JavaScript compilation of a Dart program, all you get is basically a 3.6MB node_modules/sass/sass.dart.js file.
The /tmp/just-sass/node_modules directory is only 113 files and folders weighing a total of 4.1MB.
Whereas /tmp/just-node-sass/node_modules
directory is 3,658 files and folders weighing a total of 15.2MB.
I don't know about you but I'm very skeptical that node-gyp ever works. Who even has Python 2.7 installed anymore? Being able to avoid node-gyp seems like a win for sass.
Conclusion
The speed difference may or may not matter. If you're only doing it once, who cares about a couple of hundred milliseconds. But if you're forced to have to wait 1.4 seconds on every Ctrl-S when Webpack or whatever tooling you have starts up sass it might become very painful.
I don't know much about the sass-loader Webpack plugin but it apparently works with either but they do recommend sass in their documentation. And it's the default implementation too.
It's definitely a feather in sass
's hat that Dart Sass is the "primary implementation" of Sass. That just has a nice feelin in sass's favor.
Bonus
NPMCompare has a nice comparison of them as projects but you have to study each row of numbers because it's rarely as simple as more (or less) number is better. For example, the number of open issues isn't a measure of bugs.
The new module system launched in October 2019 supposedly only comes to Dart Sass which means sass is definitely going to get it first. If that stuff matters to you. For example, true, the Sass unit-testing tool, now requires Dart Sass and drops support for node-sass.
02 September 2020 0 comments Web development, Web Performance, JavaScript, Preact
I'm working on a Firebase app called That's Groce! based on preact-cli, with TypeScript, and I wanted to see how it appears with or without Firestore and Authenticated lazy-loaded.
In the root, there's an app.tsx that used look like this:
import { FunctionalComponent, h } from "preact";
import { useState, useEffect } from "preact/hooks";
import firebase from "firebase/app";
import "firebase/auth";
import "firebase/firestore";
import { firebaseConfig } from "./firebaseconfig";
const app = firebase.initializeApp(firebaseConfig);
const App: FunctionalComponent = () => {
const [auth, setAuth] = useState<firebase.auth.Auth | null>(null);
const [db, setDB] = useState<firebase.firestore.Firestore | null>(null);
useEffect(() => {
const appAuth = app.auth();
setAuth(appAuth);
appAuth.onAuthStateChanged(authStateChanged);
const db = firebase.firestore();
setDB(db);
}, []);
...
While this works, it does make a really large bundle when both firebase/firestore and firebase/auth imported in the main bundle. In fact, it looks like this:
▶ ls -lh build/*.esm.js
-rw-r--r-- 1 peterbe staff 510K Sep 1 14:13 build/bundle.0438b.esm.js
-rw-r--r-- 1 peterbe staff 5.0K Sep 1 14:13 build/polyfills.532e0.esm.js
510K is pretty hefty to have to ask the client to download immediately. It's loaded like this (in build/index.html):
<script crossorigin="anonymous" src="/bundle.0438b.esm.js" type="module"></script>
<script nomodule src="/polyfills.694cb.js"></script>
<script nomodule defer="defer" src="/bundle.a4a8b.js"></script>
To lazy-load this
To lazy-load the firebase/firestore and firebase/auth you do this instead:
...
const App: FunctionalComponent = () => {
const [auth, setAuth] = useState<firebase.auth.Auth | null>(null);
const [db, setDB] = useState<firebase.firestore.Firestore | null>(null);
useEffect(() => {
import("firebase/auth")
.then(() => {
const appAuth = app.auth();
setAuth(appAuth);
appAuth.onAuthStateChanged(authStateChanged);
})
.catch((error) => {
console.error("Unable to lazy-load firebase/auth:", error);
});
import("firebase/firestore")
.then(() => {
const db = firebase.firestore();
setDB(db);
})
.catch((error) => {
console.error("Unable to lazy-load firebase/firestore:", error);
});
}, []);
...
Now it looks like this instead:
▶ ls -lh build/*.esm.js
-rw-r--r-- 1 peterbe staff 173K Sep 1 14:24 build/11.chunk.b8684.esm.js
-rw-r--r-- 1 peterbe staff 282K Sep 1 14:24 build/12.chunk.3c1c4.esm.js
-rw-r--r-- 1 peterbe staff 56K Sep 1 14:24 build/bundle.7225c.esm.js
-rw-r--r-- 1 peterbe staff 5.0K Sep 1 14:24 build/polyfills.532e0.esm.js
The total sum of all (relevant) .esm.js files is the same (minus a difference of 430 bytes).
But what does it really look like? The app is already based around that
const [db, setDB] = useState<firebase.firestore.Firestore | null>(null);
so it knows to wait until db is truthy and it displays a <Loading/> component until it's ready.
To test how it loads I used the Chrome Performance devtools with or without the lazy-loading and it's fairly self-explanatory:
Before, no lazy-loading
After, with lazy-loading
Clearly, the lazy-loaded has a nicer pattern in that it breaks up the work by the main thread.
Conclusion
It's fairly simple to do and it works. The main bundle becomes lighter and allows the browser to start rendering the Preact component sooner. But it's not entirely obvious if it's that much better. The same amount of JavaScript needs to downloaded and parsed no matter what. It's clearly working as a pattern but it's still pretty hard to judge if it's worth it. Now there's more "swapping".
And the whole page is server-side rendered anyway so in terms of immediate first-render it's probably the same. Hopefully, HTTP2 loading does the right thing but it's not yet entirely clear if the complete benefit is there. I certainly hope that this can improve the "Total Blocking Time" and "Time to Interactive".
The other important thing is that not all imports from firebase/* work in Node because they depend on window. It works for firebase/firestore and firestore/auth but not for firestore/analytics and firestore/performance. Now, I can add those lazy-loaded in the client and have the page rendered in Node for that initial build/index.html.
02 July 2020 2 comments JavaScript
This saved my bacon today and I quite like it so I hope that others might benefit from this little tip.
So you have two "URLs" and you want to know if they are "equal". I write those words, in the last sentence, in quotation marks because they might not be fully formed URLs and what you consider equal might depend on the current business logic.
In my case, I wanted http://www.peterbe.com/path/to?a=b to be considered equal to/path/to#anchor. Because, in this case the both share the exact same pathname (/path/to). So how to do it:
function equalUrls(url1, url2) {
return (
new URL(url1, "http://example.com").pathname ===
new URL(url2, "http://example.com").pathname
);
}
If you're doing TypeScript, switch the arguments to (url1: string, url2: string).
That "http://example.com"
is deliberate and not a placeholder. It's because:
>> new URL("/just/a/path", "http://example.com").pathname
"/just/a/path"
>> new URL("https://www.peterbe.com/a/path", "http://example.com").pathname
"/a/path"
In other words, if you do it like that the first argument to the URL constructor
can be with or without a full absolute URL.
Discussion
Be careful with junk. For example new URL(null, 'http://example.com').pathname becomes /null. So you might want to extend the logic to use "falsyness" like this:
return (
+ url1 && url2 &&
new URL(url1, "http://example.com").pathname ===
new URL(url2, "http://example.com").pathname
);
22 June 2020 0 comments Node, JavaScript
I need this function to relate to open-editor which is a Node program that can open your $EDITOR from Node and jump to a specific file, to a specific line, to a specific column.
Here's the code:
function* findMatchesInText(needle, haystack, { inQuotes = false } = {}) {
const escaped = needle.replace(/[.*+?^${}()|[\]\\]/g, "\\$&");
let rex;
if (inQuotes) {
rex = new RegExp(`['"](${escaped})['"]`, "g");
} else {
rex = new RegExp(`(${escaped})`, "g");
}
for (const match of haystack.matchAll(rex)) {
const left = haystack.slice(0, match.index);
const line = (left.match(/\n/g) || []).length + 1;
const lastIndexOf = left.lastIndexOf("\n") + 1;
const column = match.index - lastIndexOf + 1;
yield { line, column };
}
}
And you use it like this:
const text = ` bravo
Abra
cadabra
bravo
`;
console.log(Array.from(findMatchesInText("bra", text)));
Which prints:
[
{ line: 1, column: 2 },
{ line: 2, column: 2 },
{ line: 3, column: 5 },
{ line: 5, column: 1 }
]
The inQuotes option is because a lot of times this function is going to be used for finding the href value in unstructured documents that contain HTML <a> tags.
19 May 2020 0 comments Node, JavaScript
tl;dr; I wanted to see which is fastest, in Node, Highlight.js or Prism. The result is; they're both plenty fast but
Prism is 9% faster.
The context is all the thousands of little snippets of CSS, HTML, and JavaScript code on MDN.
I first wrote a script that stored almost 9,000 snippets of code. 60% is Javascript and 22% is CSS and rest is HTML.
The mean snippet size was 400 bytes and the median 300 bytes. All ASCII.
Then I wrote three functions:
f1 - opens the snippet, extracts the payload, and saves it in a different place. This measures the baseline for how long the disk I/O read and the disk I/O write takes.f2 - same as f1 but uses const html = Prism.highlight(payload, Prism.languages[name], name); before saving.f3 - same as f1 but uses const html = hljs.highlight(name, payload).value; before saving.
The experiment
You can see the hacky benchmark code here: https://github.com/peterbe/syntax-highlight-node-benchmark/blob/master/index.js
Results
The results are (after running each 12 times each):
f1 0.947s fastest
f2 1.361s 43.6% slower
f3 1.494s 57.7% slower
Memory
In terms of memory usage, Prism maxes heap memory at 60MB (the f1 baseline was 18MB), and Highlight.js maxes heap memory at 60MB too.
Disk space in HTML
Each library produces different HTML. Examples:
Prism
<span class="token selector">.item::after</span> <span class="token punctuation">{</span>
<span class="token property">content</span><span class="token punctuation">:</span> <span class="token string">"This is my content."</span><span class="token punctuation">;</span>
<span class="token punctuation">}</span>
Highlight.js
<span class="hljs-selector-class">.item</span><span class="hljs-selector-pseudo">::after</span> {
<span class="hljs-attribute">content</span>: <span class="hljs-string">"This is my content."</span>;
}
Yes, not only does it mean they look different, they use up a different amount of disk space when saved. That matters for web performance and also has an impact on build resources.
f1 - baseline "HTML" files amounts to 11.9MB (across 3,025 files)f2 - Prism: 17.6MBf3 - Highlight.js: 13.6MB
Conclusion
Prism is plenty fast for Node. If you're already using Prism, don't worry about having to switch to Highlight.js for added performance.
RAM memory consumption is about the same.
Final HTML from Prism is 30% larger than Highlight.js but when the rendered HTML is included in a full HTML page, the HTML compresses very well because of all the repetition so this is not a good comparison. Or rather, not a lot to worry about.
Well, speed is just one dimension. The features differ too. MDN
already uses Prism but does so in the browser. The ultimate context for this blog post is; the speed if we were to do all the syntax highlighting in the server as a build step.
