8 ms·

Web Performance 101

315 points by iamakulov 8y ago

iamakulov 8y ago
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 :)
- abraae 8y ago
  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?
- EasyTiger_ 8y ago
  I definitely learned something, thanks
- denormalfloat 8y ago
  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.
  - blinky1456 8y ago
    wouldn't the JSON object have to be pretty big before it affects performance.?
  - KingMob 8y ago
    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.
- vanderZwan 8y ago
  A few slides after you say that gifs should never be used, you use a gif ;)
- Theodores 8y ago
  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 8y ago
  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).
notaspider 8y ago
Thanks, I hadn't heard of svgo before
userbinator 8y ago
IMHO instead of going for compressing/minifying/whatever else, it is far better to just remove the useless cruft in the first place --- and then you can still apply such techniques to whatever is left to squeeze out a bit more improvement. The best way to make your site ultra-responsive is to cut out all the bloat. Related item: https://news.ycombinator.com/item?id=10820445 https://news.ycombinator.com/item?id=10820445
- magicalist 8y ago
  > and then you can still apply such techniques to whatever is left to squeeze out a bit more improvement Yes, like "compressing/minifying/whatever else", which is the subject of this presentation. What's next? Really, before minifying, you have to get a server to serve anything in the first place. And register a domain name. And, hmmm, well first you need to buy a computer and plug it in...
- Matrixik 8y ago
  This part is like always missing from such presentations. First point always should be remove as much as possible.
  - diafygi 8y ago
    You're totally right, but unfortunately, I think that's because the person writing these types of presentations don't have control over the content or design of the website, so removing stuff is often impossible or way more work that these tips. The core holdback for slow websites is usually political, not technical or lack of skill. These presentations usually just try to make the best of those team dynamics issues.
  - nicbou 8y ago
    It reminds me of "reduce, reuse, recycle, in that order". It's better to reduce resource consumption than to reduce its impact.
- silvenon 8y ago
  "Removing useless cruft" doesn't seem very practical, did it often work for you? In my experience, erring on the side of making existing stuff work faster is better than removing non-critical features.
firasd 8y ago
Good document! I wanted to mention, something I've found to be significant in practical testing but often not considered by web developers is reducing the total number of HTTP queries. It seems like fetching 5 CSS files of 5kb each will significantly slow things down compared to combining them into one 25kb CSS file.
- tyingq 8y ago
  Http/2 makes this less important. Perhaps still worth it for CSS, but higher effort things like image spriting might not be as attractive now.
  - andreareina 8y ago
    AFAIK SVG sprites (or inline SVG) are still required to style SVG images with external CSS.
  - chrisweekly 8y ago
    Yes -- in fact some webperf techniques are HTTP/1.1 - specific, and are actually _anti-patterns_ in HTTP/2. Spriting is one such example.
    - chrisweekly 8y ago
      Domain sharding is another.
- chmod775 8y ago
  It slows things down especially because the browser will likely have to layout/re-render the page everytime a new chunk of CSS arrives. Generally avoid splitting CSS. Even if you don't use all your CSS on every page, a cached 100kb CSS file will outperform a bunch of unique-per-page 25kb CSS files everytime (especially since it's 0 requests for the second page). Except for dial-up probably. It may be beneficial to split CSS files somewhere above the 300kb mark, but I wouldn't know. My one-page-app is only about 500kb over the wire, including CSS, JS, Fonts and HTML. ~30KB of that is CSS. I've been optimizing that for years though.
runako 8y ago
Based on my first scan, I've bookmarked this for the next time I have a perf issue on a site. One thing I didn't notice is that one of the biggest speedups is removing junk from the pages. That could be too many JS trackers, user-hostile videos, or whatever. IMHO it's an underrated skill for Web developers to be able to push back with cogent arguments when asked to ruin the performance of the sites they work on.
- taf2 8y ago
  Why? Most trackers load async and don’t block the page from loading or rendering. I get it’s popular to hate but technically they load without blocking page from rendering. A good read is https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index https://sites.google.com/a/webpagetest.org/docs/using-webpag...
  - jazzyjackson 8y ago
    They may not be blocking, but it's an extra burden on my limited bandwidth (slows other connections down while it downloads) and balloons the memory usage of sites that are otherwise delivering static content.
    - taf2 8y ago
      Usually the browser has a priority on each connection and when you load a script async the priority is set to low. Have a read here: https://developers.google.com/web/fundamentals/performance/resource-prioritization https://developers.google.com/web/fundamentals/performance/r...
      - jazzyjackson 8y ago
        Love knowing this kind of stuff, thanks
  - pmichalina 8y ago
    Even just one poorly designed library can cause serious memory issues and trigger a ton of events. Usually it’s the marketing and ad people that throw around this “but they are async loaded”. That’s true, but doesn’t change the the fact that 40 trackers and their dependencies that come with it are slowing down and infringing on the users privacy. Let’s be real.
Mr_Manager 8y ago
I've found the server PageSpeed module (in my case for Nginx) does a lot of good things "on the fly".
- Theodores 8y ago
  This is the correct way to do a lot of it. For instance, images. Yes you could optimise the things in Photoshop but actually you want your artworkers to be doing the images right, so they look good and tell the story. Optimising the images is something that should be abstracted out, so on your dev version of the site everything is in 100% glorious, maybe even phone-res megapixels. Then, abstracted out with PageSpeed you can deliver the webp when you need to and also the source set images so every device has the right size images that update themselves automagically if people zoom in. Same with minification, why have complex build tools when you can just have PageSpeed do it properly? You can also have beautiful HTML for view source by putting on the right PageSpeed filters. The list goes on, apart from the results it also does the abstraction bit, so artworkers can do their Photoshop stuff unencumbered, same for frontend and backend devs. The thing about it though is that you need to understand a mix of different things that are nowadays split up into different job roles of ever increasing specialisation. A Photoshop person isn't going to go all command line on the server for the perfect PageSpeed Nginx setup, neither is a CSS person, a UX expert, a JS expert or a backend expert. Not even the guy who keeps the site online is going to typically step up to using Pagespeed for the benefit of the team. Pagespeed just doesn't fit into one of these niche-jobs so it is more likely to be found on smaller one-person efforts where there aren't the organisational hurdles in the way.
  - gitgud 8y ago
    Well, in reality, all of these build tools for performance are design to deploy to a "static server" which is out of the control of the developer. That is why they process the images at build time rather than "on the fly" Not saying that Page speed is wrong, but it is a niche tool that depends on the server side implementation. Some developers prefer to abstract "the server" from their architecture...
  - C1sc0cat 8y ago
deleted 8y ago
[deleted]
anitadig01 8y ago
At this time these all factors are very important. Thanks for sharing.
vladdanilov 8y ago
> Compress your JPG images with the compression level of 70‑80. In practice some images can get noticeable artifacts even at around 90. Most of JPEG compressors always apply chroma subsampling which is often destructive on its own [1]. On the contrary, many hidpi images can be compressed at around 50. > Use Progressive JPEG… Thanks to this, a visitor can roughly see what’s in the image way earlier. That's not the point of using progressive JPEGs nowadays. The 10-200% decompression slowdown is for the 5-15% size reduction. > Use Interlaced PNG. Don't. Interlaced PNGs can easily be 1/3 bigger. There are better ways to show loading images, and it's already used on the website. > webpack has image-webpack-loader which runs on every build and does pretty much every optimization from above. Its default settings are OK > For you need to optimize an image once and forever, there’re apps like ImageOptim and sites like TinyPNG. These tools are no good for automatic lossy image compression [1]. The default is mostly JPEG 4:2:0 at quality 75, PNG quantized with pngquant at settings as low as conscience allows, missing out many PNG reductions and optimal deflate, no separation between lossy and lossless WebP if at all, etc. As a result, the images on the website have about 13-24% more to optimize losslessly. [1] https://getoptimage.com/benchmark https://getoptimage.com/benchmark
- Raphmedia 8y ago
  > [1] https://getoptimage.com/benchmark https://getoptimage.com/benchmark A score of 24/55 for TinyPNG and then 55/55 for their own service makes it look as if this article is an advertisement. Especially since TinyPNG gets better/very similar file size while staying visually lossless up to a point (images where it's nothing but a bunch of rainbow gradients are its weakness). Remember that TinyPNG is optimized for web use where artifacts are tolerated. It was configured with that in mind. They test for images that are visually identical and won't get it from any images optimizer that is made for web usage. Users only spend a few seconds looking at images that on web pages and the artifacts from optimizers are very minor. See: https://3perf.com/talks/web-perf-101/#images-compress-jpg-size-2 https://3perf.com/talks/web-perf-101/#images-compress-jpg-si...
- CharlesW 8y ago
  > These tools are no good for automatic lossy image compression The self-promotion didn't bother me until this claim, because you posted some great advice along with it. ImageOptim is great. If you choose "lossy minification" it does automatic lossy image compression, preserving perceptual image quality while making huge reductions to file sizes. Users can even adjust how aggressive it is. I'll take your word for it that I could get 13-24% smaller file sizes with your Optimage product on top of the 80% (or whatever) that I can get with ImageOptim. But I'd prefer that you didn't claim that other choices are "no good".
Klathmon 8y ago
I know i'm kinda self-promoting here, but since you mention webpack loaders like responsive-loader, and you recommend image-webpack-loader multiple times, I figured I could mention my plugin imagemin-webpack-plugin [0] The problem with image-webpack-loader is that it only works on images which are `require`d or `import`ed. responsive-loader adds those images to webpack in a way that the loader cannot compress them. Plus there are a bunch of other fany features that many helpful users have added like caching (no need to re-compress every image every time you run it!), the ability to minify images not in the webpack pipeline, and more. [0] https://github.com/Klathmon/imagemin-webpack-plugin https://github.com/Klathmon/imagemin-webpack-plugin
commandlinefan 8y ago
Careful with GZip and SSL, though - your payloads become vulnerable to the BREACH attack.
- virmundi 8y ago
  I've seen that. My understanding is that you can compress CSS, images, pretty much anything that does not require a secret. So if your sending a secret to get an image, I think you're doing something wrong. If you keep the secret in a cookie, or transfer it in a header rather than a body, you should be clear to use Gzip and HTTP compression.
timmytwotime 8y ago
I would have liked to have seen more on HTTP/2

315 points by iamakulov 8y ago

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 :)

abraae 8y ago
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?
EasyTiger_ 8y ago
I definitely learned something, thanks
denormalfloat 8y ago
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.
- blinky1456 8y ago
  wouldn't the JSON object have to be pretty big before it affects performance.?
- KingMob 8y ago
  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.
vanderZwan 8y ago
A few slides after you say that gifs should never be used, you use a gif ;)
Theodores 8y ago
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 8y ago
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).

notaspider 8y ago

Thanks, I hadn't heard of svgo before

userbinator 8y ago

IMHO instead of going for compressing/minifying/whatever else, it is far better to just remove the useless cruft in the first place --- and then you can still apply such techniques to whatever is left to squeeze out a bit more improvement. The best way to make your site ultra-responsive is to cut out all the bloat. Related item: https://news.ycombinator.com/item?id=10820445 https://news.ycombinator.com/item?id=10820445

magicalist 8y ago
> and then you can still apply such techniques to whatever is left to squeeze out a bit more improvement Yes, like "compressing/minifying/whatever else", which is the subject of this presentation. What's next? Really, before minifying, you have to get a server to serve anything in the first place. And register a domain name. And, hmmm, well first you need to buy a computer and plug it in...
Matrixik 8y ago
This part is like always missing from such presentations. First point always should be remove as much as possible.
- diafygi 8y ago
  You're totally right, but unfortunately, I think that's because the person writing these types of presentations don't have control over the content or design of the website, so removing stuff is often impossible or way more work that these tips. The core holdback for slow websites is usually political, not technical or lack of skill. These presentations usually just try to make the best of those team dynamics issues.
- nicbou 8y ago
  It reminds me of "reduce, reuse, recycle, in that order". It's better to reduce resource consumption than to reduce its impact.
silvenon 8y ago
"Removing useless cruft" doesn't seem very practical, did it often work for you? In my experience, erring on the side of making existing stuff work faster is better than removing non-critical features.

firasd 8y ago

Good document! I wanted to mention, something I've found to be significant in practical testing but often not considered by web developers is reducing the total number of HTTP queries. It seems like fetching 5 CSS files of 5kb each will significantly slow things down compared to combining them into one 25kb CSS file.

tyingq 8y ago
Http/2 makes this less important. Perhaps still worth it for CSS, but higher effort things like image spriting might not be as attractive now.
- andreareina 8y ago
  AFAIK SVG sprites (or inline SVG) are still required to style SVG images with external CSS.
- chrisweekly 8y ago
  Yes -- in fact some webperf techniques are HTTP/1.1 - specific, and are actually _anti-patterns_ in HTTP/2. Spriting is one such example.
  - chrisweekly 8y ago
    Domain sharding is another.
chmod775 8y ago
It slows things down especially because the browser will likely have to layout/re-render the page everytime a new chunk of CSS arrives. Generally avoid splitting CSS. Even if you don't use all your CSS on every page, a cached 100kb CSS file will outperform a bunch of unique-per-page 25kb CSS files everytime (especially since it's 0 requests for the second page). Except for dial-up probably. It may be beneficial to split CSS files somewhere above the 300kb mark, but I wouldn't know. My one-page-app is only about 500kb over the wire, including CSS, JS, Fonts and HTML. ~30KB of that is CSS. I've been optimizing that for years though.

runako 8y ago

Based on my first scan, I've bookmarked this for the next time I have a perf issue on a site. One thing I didn't notice is that one of the biggest speedups is removing junk from the pages. That could be too many JS trackers, user-hostile videos, or whatever. IMHO it's an underrated skill for Web developers to be able to push back with cogent arguments when asked to ruin the performance of the sites they work on.

taf2 8y ago
Why? Most trackers load async and don’t block the page from loading or rendering. I get it’s popular to hate but technically they load without blocking page from rendering. A good read is https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index https://sites.google.com/a/webpagetest.org/docs/using-webpag...
- jazzyjackson 8y ago
  They may not be blocking, but it's an extra burden on my limited bandwidth (slows other connections down while it downloads) and balloons the memory usage of sites that are otherwise delivering static content.
  - taf2 8y ago
    Usually the browser has a priority on each connection and when you load a script async the priority is set to low. Have a read here: https://developers.google.com/web/fundamentals/performance/resource-prioritization https://developers.google.com/web/fundamentals/performance/r...
    - jazzyjackson 8y ago
      Love knowing this kind of stuff, thanks
- pmichalina 8y ago
  Even just one poorly designed library can cause serious memory issues and trigger a ton of events. Usually it’s the marketing and ad people that throw around this “but they are async loaded”. That’s true, but doesn’t change the the fact that 40 trackers and their dependencies that come with it are slowing down and infringing on the users privacy. Let’s be real.

Mr_Manager 8y ago

I've found the server PageSpeed module (in my case for Nginx) does a lot of good things "on the fly".

Theodores 8y ago
This is the correct way to do a lot of it. For instance, images. Yes you could optimise the things in Photoshop but actually you want your artworkers to be doing the images right, so they look good and tell the story. Optimising the images is something that should be abstracted out, so on your dev version of the site everything is in 100% glorious, maybe even phone-res megapixels. Then, abstracted out with PageSpeed you can deliver the webp when you need to and also the source set images so every device has the right size images that update themselves automagically if people zoom in. Same with minification, why have complex build tools when you can just have PageSpeed do it properly? You can also have beautiful HTML for view source by putting on the right PageSpeed filters. The list goes on, apart from the results it also does the abstraction bit, so artworkers can do their Photoshop stuff unencumbered, same for frontend and backend devs. The thing about it though is that you need to understand a mix of different things that are nowadays split up into different job roles of ever increasing specialisation. A Photoshop person isn't going to go all command line on the server for the perfect PageSpeed Nginx setup, neither is a CSS person, a UX expert, a JS expert or a backend expert. Not even the guy who keeps the site online is going to typically step up to using Pagespeed for the benefit of the team. Pagespeed just doesn't fit into one of these niche-jobs so it is more likely to be found on smaller one-person efforts where there aren't the organisational hurdles in the way.
- gitgud 8y ago
  Well, in reality, all of these build tools for performance are design to deploy to a "static server" which is out of the control of the developer. That is why they process the images at build time rather than "on the fly" Not saying that Page speed is wrong, but it is a niche tool that depends on the server side implementation. Some developers prefer to abstract "the server" from their architecture...
- C1sc0cat 8y ago

deleted 8y ago

[deleted]

anitadig01 8y ago

At this time these all factors are very important. Thanks for sharing.

vladdanilov 8y ago

> Compress your JPG images with the compression level of 70‑80. In practice some images can get noticeable artifacts even at around 90. Most of JPEG compressors always apply chroma subsampling which is often destructive on its own [1]. On the contrary, many hidpi images can be compressed at around 50. > Use Progressive JPEG… Thanks to this, a visitor can roughly see what’s in the image way earlier. That's not the point of using progressive JPEGs nowadays. The 10-200% decompression slowdown is for the 5-15% size reduction. > Use Interlaced PNG. Don't. Interlaced PNGs can easily be 1/3 bigger. There are better ways to show loading images, and it's already used on the website. > webpack has image-webpack-loader which runs on every build and does pretty much every optimization from above. Its default settings are OK > For you need to optimize an image once and forever, there’re apps like ImageOptim and sites like TinyPNG. These tools are no good for automatic lossy image compression [1]. The default is mostly JPEG 4:2:0 at quality 75, PNG quantized with pngquant at settings as low as conscience allows, missing out many PNG reductions and optimal deflate, no separation between lossy and lossless WebP if at all, etc. As a result, the images on the website have about 13-24% more to optimize losslessly. [1] https://getoptimage.com/benchmark https://getoptimage.com/benchmark

Raphmedia 8y ago
> [1] https://getoptimage.com/benchmark https://getoptimage.com/benchmark A score of 24/55 for TinyPNG and then 55/55 for their own service makes it look as if this article is an advertisement. Especially since TinyPNG gets better/very similar file size while staying visually lossless up to a point (images where it's nothing but a bunch of rainbow gradients are its weakness). Remember that TinyPNG is optimized for web use where artifacts are tolerated. It was configured with that in mind. They test for images that are visually identical and won't get it from any images optimizer that is made for web usage. Users only spend a few seconds looking at images that on web pages and the artifacts from optimizers are very minor. See: https://3perf.com/talks/web-perf-101/#images-compress-jpg-size-2 https://3perf.com/talks/web-perf-101/#images-compress-jpg-si...
CharlesW 8y ago
> These tools are no good for automatic lossy image compression The self-promotion didn't bother me until this claim, because you posted some great advice along with it. ImageOptim is great. If you choose "lossy minification" it does automatic lossy image compression, preserving perceptual image quality while making huge reductions to file sizes. Users can even adjust how aggressive it is. I'll take your word for it that I could get 13-24% smaller file sizes with your Optimage product on top of the 80% (or whatever) that I can get with ImageOptim. But I'd prefer that you didn't claim that other choices are "no good".

Klathmon 8y ago

I know i'm kinda self-promoting here, but since you mention webpack loaders like responsive-loader, and you recommend image-webpack-loader multiple times, I figured I could mention my plugin imagemin-webpack-plugin [0] The problem with image-webpack-loader is that it only works on images which are `require`d or `import`ed. responsive-loader adds those images to webpack in a way that the loader cannot compress them. Plus there are a bunch of other fany features that many helpful users have added like caching (no need to re-compress every image every time you run it!), the ability to minify images not in the webpack pipeline, and more. [0] https://github.com/Klathmon/imagemin-webpack-plugin https://github.com/Klathmon/imagemin-webpack-plugin

commandlinefan 8y ago

Careful with GZip and SSL, though - your payloads become vulnerable to the BREACH attack.

virmundi 8y ago
I've seen that. My understanding is that you can compress CSS, images, pretty much anything that does not require a secret. So if your sending a secret to get an image, I think you're doing something wrong. If you keep the secret in a cookie, or transfer it in a header rather than a body, you should be clear to use Gzip and HTTP compression.

timmytwotime 8y ago

I would have liked to have seen more on HTTP/2