The Cost of JavaScript in 2018

Even though we mentioned it earlier, I thought this outstanding post by Addy Osmani all about the performance concerns of JavaScript was still worth digging into a little more.
In that post, Addy touches on all aspects of perf work and how we can fix some of the most egregious issues, from setting up a budget to “Time-to-Interactive” measurements and auditing your JavaScript bundles.

Embrace performance budgets and learn to live within them. For mobile, aim for a JS budget …
The post The Cost of JavaScript in 2018 appeared first on CSS-Tricks.

Link: https://medium.com/@addyosmani/the-cost-of-javascript-in-2018-7d8950fbb5d4

Browser painting and considerations for web performance

The process of a web browser turning HTML, CSS, and JavaScript into a finished visual representation is quite complex and involves a good bit of magic. Here’s a simplified set of steps the browser goes through:

Browser creates the DOM and CSSOM.
Browser creates the render tree, where the DOM and styles from the CSSOM are taken into account (display: none elements are avoided).
Browser computes the geometry of the layout and its elements based on the render tree.


The post Browser painting and considerations for web performance appeared first on CSS-Tricks.

Link: https://css-tricks.com/browser-painting-and-considerations-for-web-performance/

Slow Websites

The web has grown bigger. Both in expansiveness and weight. Nick Heer’s “The Bullshit Web":
The average internet connection in the United States is about six times as fast as it was just ten years ago, but instead of making it faster to browse the same types of websites, we’re simply occupying that extra bandwidth with more stuff.
Nick clearly explains what he means by bullshit, and one can see a connection to Brad Frost’s similarly framed …
The post Slow Websites appeared first on CSS-Tricks.

Link: https://css-tricks.com/slow-websites/

Delivering WordPress in 7KB

Over the past six months, I’ve become increasingly interested in the topic of web sustainability. The carbon footprint of the Internet was not something I used to give much thought to, which is surprising considering my interest in environmental issues and the fact that my profession is web-based.

The web in a warming world
As a brief recap, I attended MozFest in London last year. In between sessions, I was scanning a noticeboard to see what was coming up, and …
The post Delivering WordPress in 7KB appeared first on CSS-Tricks.

Link: https://css-tricks.com/delivering-wordpress-in-7kb/

Error Monitoring in Golang

Rollbar is proud to announce its error monitoring SDK for the Go language (aka Golang). It’s an open source programming language originally created by Google and is growing in popularity. It’s a low-level language like C, but also offers garbage collection, an easy-to-use package system, and other features.
If you’re used to languages like Java or JavaScript, then Go’s way of handling errors will be new to you. We will give a brief introduction on how error handling works in Go, then cover how you can monitor errors in production apps.

Link: https://dzone.com/articles/error-monitoring-in-golang?utm_medium=feed&utm_source=feedpress.me&utm_campaign=Feed%3A+dzone%2Fwebdev

Firefox 61 – Quantum of Solstice

Firefox 61 is now available, bringing new performance improvements that make the fox faster than ever! We’re keen on the Retained Display Lists feature to improve performance while an interactive page is painted; the Accessibility Inspector baked in to our tooling to support assistive technology users; more powerful tab management for power users; and many more Dev Tools updates and enhancements.

Link: https://hacks.mozilla.org/2018/06/firefox-61-quantum-of-solstice/

Retained Display Lists for improved page performance

Display list building is the process in which we collect the set of high-level items to display on screen (borders, backgrounds, text and much more), and then sort the list, according to CSS painting rules, into the correct back-to-front order. By retaining the display list and only reloading the assets that have changed since first paint, we are able to optimize painting performance especially for highly interactive pages. Look for this feature in this week’s release of Firefox 61.

Link: https://hacks.mozilla.org/2018/06/retained-display-lists/

Using Custom Fonts With SVG in an Image Tag

When we produce a PNG image, we use an tag or a CSS background, and that’s about it. It is dead simple and guaranteed to work.

PNG is way simpler to use in HTML than SVG
Unfortunately, the same cannot be said for SVG, despite its many advantages. Although you’re spoiled for choices when using SVG in HTML, it really boils down to inline, <object> and <img>, all with serious gotchas and trade-offs.
Problems with inline SVG…
The post Using Custom Fonts With SVG in an Image Tag appeared first on CSS-Tricks.

Link: https://css-tricks.com/using-custom-fonts-with-svg-in-an-image-tag/

7 Performance Tips for Jank-free JavaScript Animations

The role of web animation has evolved from mere decorative fluff to serving concrete purposes in the context of user experience — such as providing visual feedback as users interact with your app, directing users’ attention to fulfill your app’s goals, offering visual cues that help users make sense of your app’s interface, and so on.
To ensure web animation is up to such crucial tasks, it’s important that motion takes place at the right time in a fluid and smooth fashion, so that users perceive it as aiding them, rather than as getting in the way of whatever action they’re trying to pursue on your app.
One dreaded effect of ill-conceived animation is jank, which is explained on jankfree.org like this:

Modern browsers try to refresh the content on screen in sync with a device’s refresh rate. For most devices today, the screen will refresh 60 times a second, or 60Hz. If there is some motion on screen (such as scrolling, transitions, or animations) a browser should create 60 frames per second to match the refresh rate. Jank is any stuttering, juddering or just plain halting that users see when a site or app isn’t keeping up with the refresh rate.

If animations are janky, users will eventually interact less and less with your app, thereby negatively impacting on its success. Obviously, nobody wants that.
In this article, I’ve gathered a few performance tips to help you solve issues with JavaScript animations and make it easier to meet the 60fps (frame per second) target for achieving smooth motion on the web.
#1 Avoid Animating Expensive CSS Properties
Whether you plan on animating CSS properties using CSS Transitions/CSS keyframes or JavaScript, it’s important to know which properties bring about a change in the geometry of the page (layout) — meaning that the position of other elements on the page will have to be recalculated, or that painting operations will be involved. Both layout and painting tasks are very expensive for browsers to process, especially if you have several elements on your page. As a consequence, you’ll see animation performance improve significantly if you avoid animating CSS properties that trigger layout or paint operations and stick to properties like transforms and opacity, because modern browsers do an excellent job of optimizing them.
On CSS Triggers you’ll find an up-to-date list of CSS properties with information about the work they trigger in each modern browser, both on the first change and on subsequent changes.

Changing CSS properties that only trigger composite operations is both an easy and effective step you can take to optimize your web animations for performance.
#2 Promote Elements You Want to Animate to Their Own Layer (with Caution)
If the element you want to animate is on its own compositor layer, some modern browsers leverage hardware acceleration by offloading the work to the GPU. If used judiciously, this move can have a positive effect on the performance of your animations.
To have the element on its own layer, you need to promote it. One way you can do so is by using the CSS will-change property. This property allows developers to warn the browser about some changes they want to make on an element, so that the browser can make the required optimizations ahead of time.
However, it’s not advised that you promote too many elements on their own layer or that you do so with exaggeration. In fact, every layer the browser creates requires memory and management, which can be expensive.
You can learn the details of how to use will-change, its benefits and downsides, in An Introduction to the CSS will-change Property by Nick Salloum.
#3 Replace setTimeOut/setInterval with requestAnimationFrame
JavaScript animations have commonly been coded using either setInterval() or setTimeout().
The code would look something like this:
var timer;
function animateElement() {
timer = setInterval( function() {
// animation code goes here
} , 2000 );
}

// To stop the animation, use clearInterval
function stopAnimation() {
clearInterval(timer);
}

Although this works, the risk of jank is high, because the callback function runs at some point in the frame, perhaps at the very end, which can result in one or more frames being missed. Today, you can use a native JavaScript method which is tailored for smooth web animation (DOM animation, canvas, etc.), called requestAnimationFrame().
requestAnimationFrame() executes your animation code at the most appropriate time for the browser, usually at the beginning of the frame.
Your code could look something like this:
function makeChange( time ) {
// Animation logic here

// Call requestAnimationFrame recursively inside the callback function
requestAnimationFrame( makeChange ):
}

// Call requestAnimationFrame again outside the callback function
requestAnimationFrame( makeChange );

Performance with requestAnimationFrame by Tim Evko here on SitePoint offers a great video introduction to coding with requestAnimationFrame().
The post 7 Performance Tips for Jank-free JavaScript Animations appeared first on SitePoint.

Link: https://www.sitepoint.com/7-performance-tips-jank-free-javascript-animations/

The web can be anything we want it to be

I really enjoyed this chat between Bruce Lawson and Mustafa Kurtuldu where they talked about browser support and the health of the web. Bruce expands upon a lot of the thoughts in a post he wrote last year called World Wide Web, Not Wealthy Western Web where he writes:
…across the world, regardless of disposable income, regardless of hardware or network speed, people want to consume the same kinds of goods and services. And if your websites are made for …
The post The web can be anything we want it to be appeared first on CSS-Tricks.

Link: https://www.youtube.com/watch?v=tvLF7zllsv0