dom-to-image is a library which can turn arbitrary DOM node into a vector (SVG) or raster (PNG or JPEG) image, written in JavaScript. It’s based on domvas by Paul Bakaus and has been completely rewritten, with some bugs fixed and some new features (like web font and image support) added.
Juxtapose helps storytellers compare two pieces of similar media, including photos, and GIFs. It’s ideal for highlighting then/now stories that explain slow changes over time (growth of a city skyline, regrowth of a forest, etc.) or before/after stories that show the impact of single dramatic events (natural disasters, protests, wars, etc.).
A good rule is to decrease the brightness and contrast of images a bit so that it looks comfortable to the eyes when it’s against a dark background. A super bright image on a super dark background can be jarring and dimming the image reduces some of that heavy contrast.
[…]
The CSS
filter()function is more than capable of handling this for us:
/* Apply the filter directly on the body tag */
body.dark-theme img {
filter: brightness(.8) contrast(1.2);
}
/* Or apply it via media query */
@media (prefers-color-scheme: dark) {
img {
filter: brightness(.8) contrast(1.2);
}
}
Turning raster images into SVG files, one pixel at a time. Yes, really.
What?
The PHP accepts a raster image (GIF, PNG, JPEG, that sort of thing) and creates an SVG image that recreates the raster image. It does this by drawing filled rectangles to recreate the pixels in the image. In many cases, this is literally a 1-by-1 rectangle, but it will check for runs of similar color (similar to GIF compression) and create one rectangle per run. It checks both horizontal and vertical runs to see which approach is more efficient, and returns the better option.
The script requires GD.
Why?
There are situations where people want to take small bitmaps—think primary-color buttons or badges—and make them scalable while still preserving their 8-bit appearance. See, for example, Joe Crawford’s post about upscaling a minitag. For those cases, this script will enable a quick conversion to SVG with at least some minimal attempts at optimization.
This all originally started as a one-off experiment and a bit of a jape. You can see the original at flaming-shame, if you fancy a laugh.
While testing a progressive web app for one of our clients, I bumped into a suspicious error in the browser console:
DOMException: Quota exceeded.After browsing the app a few more times, it became clear the error would occur after a small number of images were added to the cache storage by the service worker. Looking in the Chrome DevTools Application tab, the cache storage was indeed over capacity.
How could this be? There were only ~15 images in the cache storage. Something was off.
What I found could significantly impact your progressive web app—particularly if you use a CDN on a different domain for your assets.
[…]
If you are building a progressive web app and are experiencing bloated cache storage when your service worker caches static assets served from CDNs, make sure the proper CORS response header exists for cross-origin resources, you do not cache opaque responses with your service worker unintentionally, you opt-in cross-origin image assets into CORS mode by adding the
crossoriginattribute to the<img>tag.
See the source link for more details.
Recently, Chromium improved their implementation of
navigator.connectionby adding three new attributes:effectiveType,downlinkandrtt.Before that, the available attributes were
downLinkMaxandtype. With these two attributes you couldn’t really tell if the connection was fast or slow. Thenavigator.connection.typemay tell us a user is using WiFi, but this doesn’t say anything about the real connection speed, as they may be using a hot spot and the connection is in fact 2G.With the addition of effectiveType we are finally able to get the real connection type. There are four different types (slow-2g, 2g, 3g and 4g) and they are described this way by the Web Incubator Community Group:
slow-2g: The network is suited for small transfers only such as text-only pages.
2g: The network is suited for transfers of small images.
3g: The network is suited for transfers of large assets such as high resolution images, audio, and SD video.
4g: The network is suited for HD video, real-time video, etc.Let’s see how we can improve user experience by delivering images based on available connection speed.
MutationObserveris a lesser known JavaScript feature which allows you to detect when elements in a web page are inserted, changed or removed. It is still relatively new, but it is supported by every modern browser.The web is full of demos and tutorials of MutationObserver, but it’s pretty hard to find examples of it actually being used in practice. Even a search of Github is almost all libraries and test cases. We’ve had a couple occasions to use it at Eager however, which I now have the opportunity to share.
Client-side Image Optimization
Believe it or not, it’s actually possible to swap the src’s of img tags before the browser begins to load them. We can use that to optimize our images without changing the HTML source of our page. This code uses a FireSize service to handle the actual optimization.
We start by setting up a
MutationObserverwhich will call ourcheckNodefunction with any new nodes which are added to the DOM:
var observer = new MutationObserver(function(mutations){
for (var i=0; i < mutations.length; i++){
for (var j=0; j < mutations[i].addedNodes.length; j++){
checkNode(mutations[i].addedNodes[j]);
}
}
});
observer.observe(document.documentElement, {
childList: true,
subtree: true
});
If we run this code early in the head of the page, it will call our
checkNodefunction with each DOM node as the browser parses the page’s HTML. This gives us the ability to check or mutate these nodes before they’ve ever been rendered.We can define our
checkNodefunction to decide if this is an image for us to optimize.
checkNode = function(addedNode) {
if (addedNode.nodeType === 1 && addedNode.tagName === 'IMG'){
addedNode.src = optimizeSrc(addedNode.src)
}
}
Finally, we can define
optimizeSrcto switch out our image’s src for an optimized one:
optimizeSrc = function(src) {
return "//firesize.com/" + src;
}
For a complete implementation, take a look at our FireSize app source code.
Initializing When An Element Becomes Available on the Page
It’s a common pattern to wait for
jQuery.readyorDOMContentLoadedto initialize code which depends on elements on the page. Those events don’t fire until the entire DOM has loaded however, meaning the page will start to be rendered before you have a chance to change or add to its content.Our pattern from the image optimization solution also works for detecting when any element becomes available, allowing you to initialize code which depends on that element at the exact first moment it’s possible. We can redefine
checkNodeto instead check if our element matches an arbitrary selector:
checkNode = function(addedNode) {
if (addedNode.nodeType === 1){
if (addedNode.matches('.should-underline')){
SmartUnderline.init(addedNode);
}
}
}
You could settle for a basic grey box to show your placeholder images or you could substitute actual photos of the most gnarly places in the universe. We created SpaceHolder to help pull these amazing images straight from NASA’s photo archives into your Web project.
This is an incredibly exhaustive list of performance tweaks, improvements, and best practices. Some may be outside the scope of smaller websites, but there are plenty of things for everyone.
Back in the day, performance was often a mere afterthought. Often deferred till the very end of the project, it would boil down to minification, concatenation, asset optimization and potentially a few fine adjustments on the server’s
configfile. Looking back now, things seem to have changed quite significantly.Performance isn’t just a technical concern: It matters, and when baking it into the workflow, design decisions have to be informed by their performance implications. Performance has to be measured, monitored and refined continually, and the growing complexity of the web poses new challenges that make it hard to keep track of metrics, because metrics will vary significantly depending on the device, browser, protocol, network type and latency (CDNs, ISPs, caches, proxies, firewalls, load balancers and servers all play a role in performance).
So, if we created an overview of all the things we have to keep in mind when improving performance — from the very start of the process until the final release of the website — what would that list look like? Below you’ll find a (hopefully unbiased and objective) front-end performance checklist for 2017 — an overview of the issues you might need to consider to ensure that your response times are fast and your website smooth.