[iamakulov]

So, in summer, I gave an introductory talk into web performance. This is its textual version :)

The talk includes 94 slides with text about:

  — why web performance matters
  — how to optimize:
    — JS (async/defer, code splitting)
    — CSS (the critical CSS approach & tools for it)
    — HTTP/connection stuff (Gzip/Brotli, preloading, CDN)
    — Images (compressing images, webp, progressive vs baseline images)
    — Fonts (the `font-display` trick)
  — and what tools help to understand your app’s performance

Would love to hear your feedback :)

[beachy]

I found this super interesting and there were a few areas I wasn't familiar with where I learnt something new. Kudos.

Meta node: I find this presentation style to be great. You can scroll up and down at speed, can text search the whole page, we have a nice mixture of imagery and text, its clean and accessible, we even have a table of contents. How did you author this?

[Theodores]

Some more ideas for your next talk:

HTTP2 is a doddle to implement. Do it.

PWA makes it possible to work fully offline.

With CSS best to chuck it all out including those reset files someone wrote a decade ago. Instead re-write the whole lot using CSS Grid and using custom variables.

Inline the SVG into the CSS as custom variables.

Get rid of the bulk of the JS by only targeting evergreen browsers. No polyfills, no jQueries, just minimal javascript that does a lot of things in the PWA and manipulates CSS custom variables rather than the DOM.

Use HTML5 properly, with no lip service. Get rid of JS for forms and rely on HTML5 to do it.

Pagespeed to sort out the images and make them into source sets.

The goal of a lot of the above is to strip out convoluted build tools and have actual neat HTML that can be maintained. No more 'add only' CSS to hand on to the next guy, instead have something with comments in the code and sensible names that target HTML5 things like 'main' and 'aside' or 'nav' rather than made up class names.

A final thought is that the starting point can be to build a green website, i.e. one that cause too much cruft to be downloaded. This is the same thing as 'minimizing/cutting out bloat' but I find that setting out to build a website that sets the example of being green is a better mindset than 'must do those hacky things to make website faster'.

[glassesman]

Good article! The main thing I didn't quite agree with was the blanket statement that GIFs should never be used. I fully agree that they shouldn't be used for video clips, and I understand this was the main context, but for small animations (especially pixel-art types) they're still a good format.

I also found them useful recently for small (28x28px) thumbnail images on my personal website. On average, saved as a PNG the thumbnails were 20kb, as a JPEG 9kb, and as an optimized GIF about 1-2kb. With about 100 thumbnails on one of the pages, the savings are pretty significant. (At least, this seemed to be the best approach; if anyone with more knowledge of image compression has a better suggestion, please let me know).

[denormalfloat]

I'm saddened to not see Closure listed on there for JS minification. It might be worth mentioning that there are more advanced minification tools.

Also, there doesn't seem to be anything on JSON minification, which is a sizable portion of responses. There are techniques to transpose JSON objects to be easier to gzip compress.

[KingMob]

Google Closure is still best in class at DCE and cross-module motion, but it's never caught on with the larger web community, partly because it applied certain constraints to your Js code that weren't always met. This has changed a bit with modern Closure better able to consume npm modules, but AFAIK, the only heavy non-Google user is still ClojureScript.

[blinky1456]

wouldn't the JSON object have to be pretty big before it affects performance.?

[vanderZwan]

A few slides after you say that gifs should never be used, you use a gif ;)

[EasyTiger_]

I definitely learned something, thanks