You could also use the NodeIterator API, but TreeWalker is faster

The alternative was to have multiple scripts or stylesheet links on one page, which would trigger multiple HTTP requests. Multiple requests mean multiple connection handshakes for each link “hey, I want some data”, “okay, I have the data”, “alright I heard that you have the data, give it to me” (SYN, ACK, SYNACK). Even once the connection is created there is a feature of TCP called TCP slow start that will throttle the speed of the data being sent at the beginning of a request to a slower speed than the end of the request. All of this means transferring one large request is faster than transferring the same data split up into several smaller requests.

Because Jamstack projects don’t rely on server-side code, they can be distributed instead of living on a single server. Serving directly from a CDN unlocks speeds and performance that can’t be beat. The more of your app you can push to the edge, the better the user experience.

Better PerformanceWhy wait for pages to build on the fly when you can generate them at deploy time? When it comes to minimizing the time to first byte, nothing beats pre-built files served over a CDN.

when it comes to your web browsing experience, it turns out that latency, not bandwidth, is likely the constraining factor today.

Figure 1-1. In this data from StatCounter Global Stats, we can see that the total percentage of Internet traffic coming from mobile devices is steadily increasing.

75% of online shoppers who experience an issue such as a site freezing, crashing, taking too long to load, or having a convoluted checkout process will not buy from that site. Gomez studied online shopper behavior and found that 88% of online consumers are less likely to return to a site after a bad experience. The same study found that “at peak traffic times, more than 75% of online consumers left for a competitor’s site rather than suffer delays.”

users expect pages to load in two seconds, and after three seconds, up to 40% of users will abandon your site. Moreover, 85% of mobile users expect sites to load at least as fast or faster than sites on their desktop.

components of its user experience: layout, hierarchy, intuitiveness, ease of use, and more.

link rel="preconnect

This is especially true for online gaming

Join Darin Fisher, VP of Chrome as he talks the past, present and future of the web.

It’s known that Angular becomes slower with around 2,000 bindings due to the process behind dirty-checking. The less we can add to this limit the better, as bindings can add up without us really noticing it!

Here are a few handy tips on measuring your project’s performance profile:

If your timeline graph is dominated with the color green after recording

there does not seem to be a general rule for how many workers to spawn. Some developers claim that 8 is a good number, but use an online calculator and suit yourself

The $digest loop keeps iterating until the model stabilizes

The value function should return the value which is being watched. AngularJS can then check the value returned against the value the watch function returned the last time

Both accessibility and performance are invisible aspects of an experience and should be considered even if they aren’t explicit goals of the project.

So instead we introduced the loading spinner on each widget. Nothing is actually any faster, but the whole experience feels more responsive

Simply reducing some CSS transition times from 500ms to 250ms, and cutting others out entirely, made the whole dashboard feel snappier and more responsive.

This means content is served from the nearest possible geographic location to the user, cutting down request latency from as high as 2500ms (in places such as Singapore) to tens of milliseconds

We eventually came up with a compromise solution based on Addy Osmani’s basket.js, using a combination of server-side script concatenation and localStorage for caching. In a nutshell, the page includes a lightweight loader script, which figures out which JS and CSS it has already cached and which needs to be fetched. The loader then requests all the resources it needs from the server in one request, and saves all the resources into localStorage under individual keys. This gives us a great compromise between cutting down the number of HTTP requests while still being able to maintain cacheability, and not re-downloading code unnecessarily when it hasn’t changed. Addtionally, after running a few benchmarks, we found that localStorage is (sometimes) actually faster than the native HTTP cache, especially on mobile browsers.