Tags: optimisation

29

sparkline

Thursday, November 9th, 2017

The Contrast Swap Technique: Improved Image Performance with CSS Filters | CSS-Tricks

A clever performance trick for images:

  1. Reduce image contrast using a linear transform function (Photoshop can do this)
  2. Apply a contrast filter in CSS to the image to make up for the contrast removal

Wednesday, November 1st, 2017

Rebuilding slack.com – Several People Are Coding

A really great case study of a code refactor by Mina, with particular emphasis on the benefits of CSS Grid, fluid typography, and accessibility.

Monday, October 2nd, 2017

Essential Image Optimization

Following on from Amber’s introduction, here’s a really in-depth look at image formats, compression and optimisation techniques from Addy.

This is a really nicely put together little web book released under a Creative Commons licence.

When Should You Use Which Image Format? JPG? PNG? SVG?

Amber has been investigating which image formats make sense for which situations.

Choosing image format is only one step towards optimising images on the web. There are many, many other steps to consider, and so, so much to learn!

Sunday, March 12th, 2017

WebPonize - webponize.github.io

A Mac app for converting PNGs and JPEGs to WebP.

Thursday, February 9th, 2017

Performance Under Pressure - performance, responsive web design - Bocoup

The transcript of a really great—and entertaining—talk on performance by Wilto. I may have laughed out loud at points.

Most of the web really sucks if you have a slow connection

Just like many people develop with an average connection speed in mind, many people have a fixed view of who a user is. Maybe they think there are customers with a lot of money with fast connections and customers who won’t spend money on slow connections. That is, very roughly speaking, perhaps true on average, but sites don’t operate on average, they operate in particular domains.

Tuesday, March 15th, 2016

Managing Mobile Performance Optimization – Smashing Magazine

Some solid sensible advice on optimising performance.

Sunday, February 28th, 2016

Preload: What Is It Good For? – Smashing Magazine

A comprehensive overview of rel="preload" which looks very useful indeed …I just wish it wasn’t (like “nofollow”) a nonsensical value for the rel attribute: a resource can’t have a relationship of “preload” to the linking document.

Tuesday, December 8th, 2015

briangonzalez/fontprep

The missing font generator for Mac OS X.

Very handy for subsetting fonts for the web. It doesn’t (yet) export WOFF2 unfortunately.

Thursday, November 19th, 2015

Tips for Creating and Exporting Better SVGs for the Web

Sara enumerates some handy tips aimed squarely at designers exporting SVGs. It focuses on Illustrator in particular but I’m sure a lot of this could equally apply to Sketch.

Monday, October 27th, 2014

Official Google Webmaster Central Blog: Updating our technical Webmaster Guidelines

Google has updated its advice to people making websites, who might want to have those sites indexed by Google. There are two simple bits of advice: optimise for performance, and use progressive enhancement.

Just like modern browsers, our rendering engine might not support all of the technologies a page uses. Make sure your web design adheres to the principles of progressive enhancement as this helps our systems (and a wider range of browsers) see usable content and basic functionality when certain web design features are not yet supported.

Thursday, November 1st, 2012

Trimming the Fat — Paul Robert Lloyd

A great in-depth description by Paul of how he optimised his site. More of this please!

Sunday, July 22nd, 2012

JPEGmini - Your Photos on a Diet!

This looks like a really handy tool for reducing the file size of JPEGs without any perceptible loss of quality (in much the same way that ImageOptim works for PNGs)—available as a Mac app or an installable web service.

Tuesday, June 19th, 2012

How We Improved Page Speed By Cleaning CSS, HTML and Images | Dyn Blog

Some good practical advice on improving performance. This should all be familiar to you, but it’s always worth repeating.

Tuesday, May 8th, 2012

In Flux | Trent Walton

Trent offers some excellent advice for dealing with the effects of the iPad’s retina display on your websites. That advice is: don’t panic.

Wednesday, May 2nd, 2012

HTTP Compression use by Alexa Top 1000 | Zoompf

An in-depth analysis (graphs! data!) of how popular sites are using—or not using—compression.

Highly optimized images for the web in 3 steps | pasz.nl/blog

Some practical advice for optimising your images on the web.

Tuesday, May 1st, 2012

dConstruct optimisation

When I was helping Bevan with making the dConstruct site, I kept banging on to him about the importance of performance.

Don’t get me wrong: I wanted the site to look great, but I also very much wanted it to feel great …and nothing affects the feel of a site (the user’s experience, if you will) more than performance. As Jason wrote:

If you could only do one thing to prepare your desktop site for mobile and had to choose between employing media queries to make it look good on a mobile device or optimizing the site for performance, you would be better served by making the desktop site blazingly fast.

And yet this fundamental aspect of how performant a site is going to be is all too often left until the development phase. I’d really like to see it taken into account much earlier on, during the UX and visual design phases.

Anyway, as the dConstruct site came together, I just kept asking “What would Steve Souders do?”

For a start, that meant ripping out any boilerplate markup and CSS that was there “just in case.” I very much agree with Rachel when she says stop solving problems you don’t yet have. But one of the areas where the unfortunately-named HTML5 Boilerplate excels is in its suggestions for .htaccess rules so I made sure to rip off the best bits.

Initially jQuery was being included, but given how far browsers have come in their JavaScript support, I was able to ditch it and streamline the JavaScript a bit.

Wherever possible, I made sure that background images in CSS were Base64 encoded as data URIs; icons, textures, and the like. That helped to reduce the number of HTTP requests—one of the easy wins for improving performance.

I’ve already mentioned the conditional loading that’s going on.

Then there’s the thorny issue of responsive images. The dConstruct 2012 site is similar to the dConstruct archive in that there is no correlation between browser width and image: quite often, a smaller image is required for wider screens than for narrower viewports because of the presence of a grid. So instead of trying to come up with some complex interplay of client and server cross-communication to figure out which size image would be appropriate to serve up, I instead took the same approach as I did for the archive site: optimise the hell out of images, regardless of whether they’re going to be viewed in a desktop or a mobile device.

Take a look at the original image of Kevin Slavin compared to the version that appears on the dConstruct archive.

Kevin Slavin Kevin Slavin, retouched

See how everything except the face is so much blurrier in the final version? That isn’t just an attempt to introduce some cool bokeh. It makes for much smaller JPGs with fewer jaggy artefacts. And because human beings tend to focus on other human faces, the technique isn’t really consciously noticeable (although you’ll notice it now that I’ve pointed it out to you).

The design of the 2012 dConstruct site called for monochrome images with colour filters applied.

Ben Hammersley

That turned out to be a fortunate boon for optimising the images. This time we were using PNGs rather than JPGs and we were able to get the number of colours down to 32 or even 16. Run them through Image Optim or Smushit and you can squeeze even more bytes out of them.

The funny thing is that sweating the file sizes of images used to be part and parcel of web development. Back in the nineties, there was something of an aesthetic that grew out of the need to optimise images with limited (web-safe!) colour palettes. That was because bandwidth was at a premium and you could be pretty sure that plenty of people were accessing your site on slow connections.

Well, here we are fifteen years later and thanks to the rise of mobile, bandwidth is once again at a premium and we can be pretty sure that plenty of people are accessing our sites on slow connections. Yet again, mobile is highlighting issues that were always there. When did we get so lazy and decide it was acceptable to send giant unoptimised images down the pipe to our long-suffering visitors?

Mathew Pennell recently wrote:

…it’s certainly true that the golden rule I grew up with – no page should ever be over 100Kb – has long since been mothballed.

But why? That seems like a perfectly good and still-relevant rule to me.

Alas, on the dConstruct site I wasn’t able to hit that target. With an unprimed cache, the home page comes in at around 300K (it’s 17K with a primed cache). By far the largest file is the CSS, weighing at 113K, followed by the web font, Futura bold oblique, at 32K.

By the way, when it comes to analysing performance in the browser, this missing manual for the Webkit inspector is really, really handy. I also ran the site through Google Page Speed but it seems that the user-agent chooses an arbitrary browser width (960? 1024?) so some of the advice about scaling images needs to be taken with a pinch of salt when applied to responsive designs.

I took a look at some other conference sites too. The beautiful site for the Build conference comes in at just under a megabyte for the homepage—it has quite a few fonts and images. It also has a monochrome aesthetic going on so I suspect quite a few of those images could be squeezed down (and some far-future expiry dates would help for repeat visitors).

Then there’s site for this year’s Mobilism conference which is blazingly fast. The combined file size on the homepage isn’t that different to the dConstruct site (although the CSS is significantly smaller) and I suspect there’s some server-side wizardry going on. I’ll have to corner Stephen at the conference next week and quiz him about it.

For now, server-side performance optimisation is something beyond my ken. I should really do something about that, especially as I’m expecting the dConstruct site to take a hammering the day that tickets go sale (May 29th—save the date).

In the meantime, there’s still plenty I can do on the front end. As Bruce put it:

It seems to me that old-fashioned, oh-so-dull techniques might not be ready for retirement yet. You know: well-crafted HTML, keeping JavaScript for progressive enhancement rather than a pre-requisite for the page even displaying, and testing across browsers.

All those optimisation techniques we learned in the 90s—and even wacky ideas like lowsrc—are back in fashion. Everything old is new again.

Wednesday, February 29th, 2012

ImageAlpha — lossy compression for 24-bit PNG images

From Kornel, the genius who gave us ImageOptim, comes another Mac desktop tool for optimising PNGs, this time converting 24-bit PNG to 8-bit with full alpha channel.