I do agree with the sentiment that web page speed matters in most cases. However this article provides little insight into how important page load time is, why it is important, or what you can do about it.
Instead of this one example of a very basic solution to this very specific site's problem, I would prefer to see perhaps a list of common problems and how to deal with them. "Lastly, I changed a few configuration settings to improve transfer of data by the server." what configuration settings, and how do they improve the "transfer of data"?
Perhaps also an introduction to when optimising for fast load time makes sense, and some more statistics, instead of (paraphrasing) "it makes economical sense for two of the largest companies on earth, so I guess it's important".
Also why are they debugging asset requests using webpagetest.org instead of devtools?
Well if you look at the graph almost half of the load time is taken by Magento's server response.
Magento is slow. Ofcourse you can optimize all assets but in the end Magento is still slow.
I've seen companies throwing lots and lots of money at Magento hosting to speed it up. But at the end of the day I think Magento is great for marketeers but not so great for the rest of the world.
The best you can do is pre-render on the server, and use static where possible. Then you would need to optimise delivery and networks. And then you're done... and spend some time on usability.
In my experience, a server response time of several 100ms is "slow" for example Laravel with a bunch of Eloquent relationships. Drupal can also easily run thousands of queries per page load and Magento is possibly even worse. This can be easily cached and optimised though.
And it doesn't really make that much of a difference compared to asset loading. As in, a dozen js / css files and a bunch of images. Even when you compress / gzip them as best as you can and load from CDN, they still tend to take up an excruciating amount of time.
The article is good but very "beginner". The more challenging stuff is browser caching with htaccess rules etc.
Google Page Speed tests are actually very useful here and if you follow all their advice you end up with a very noticeably faster site.
* Doesn't actually explain why speed matters (hint: over 3 seconds people perceive a slow experience and over 10 seconds people will assume the site is broken)
* Doesn't say how to fix speed issues other than one specific small image/tiling "fix"
* If you worked at a real company this would never fly. The solution isn't to change the background altogether and go with tiling vs a big image.
I actually wrote an article on how to improve performance for everyone [1], and it's the biggest bang for your buck that anyone can do (designers, developers, or product folks).
I don't understand either how this article got so many upvotes.
Your article is good. But it's still incomplete, simple tasks like using a CDN / Reduce the number of HTTP calls / Caching can be implemented in an afternoon for lots of simple website, et can dramatically improve load times.
Agreed, it wasn't meant to be a comprehensive guide to speed, just tackling the quickest one. You can run these compressors in a matter of minutes whereas CDNs can take a few hours to implement, and generally can't be run by everyone (whereas ImageOptim can be run by basically anyone).
Perhaps some day I'll create a mega checklist of all things to consider to speed up a site :)
It's pretty good. The problem with automatic lossy compression is consistent quality.
There is a number of issues with each and every tool you mentioned, e.g. color information stripped with metadata causing color shifts in wide-gamut and non-sRGB images, camera images changing orientation when Exif stripped, color banding on PNGs and JPEGs even when using Guetzli (JPEGmini is not nearly as good in other cases, but Guetzli is extremely slow), unexpected dithering noise on flat PNGs, tracing artefacts on screen recorded GIFs, JPEGs being overcompressed, poor lossless compression (virtually any online service), progressive JPEGs incompatible with Photoshop, etc.
These are just some of the problems I've been solving, and yes, there are better tools.
The only solution I found is to build a new tool, and that required a complete rewrite of existing optimizers and significant changes to underlying libraries.
It's not automatic then, which is critical for batch processing, and does not solve all the problems, and create new usability problems for most users.
19 comments
[ 2.9 ms ] story [ 49.2 ms ] threadInstead of this one example of a very basic solution to this very specific site's problem, I would prefer to see perhaps a list of common problems and how to deal with them. "Lastly, I changed a few configuration settings to improve transfer of data by the server." what configuration settings, and how do they improve the "transfer of data"?
Perhaps also an introduction to when optimising for fast load time makes sense, and some more statistics, instead of (paraphrasing) "it makes economical sense for two of the largest companies on earth, so I guess it's important".
Also why are they debugging asset requests using webpagetest.org instead of devtools?
Magento is slow. Ofcourse you can optimize all assets but in the end Magento is still slow.
I've seen companies throwing lots and lots of money at Magento hosting to speed it up. But at the end of the day I think Magento is great for marketeers but not so great for the rest of the world.
When a user needs something - he'll wait. No one gives up on a good search result just because the page loaded partially.
And it doesn't really make that much of a difference compared to asset loading. As in, a dozen js / css files and a bunch of images. Even when you compress / gzip them as best as you can and load from CDN, they still tend to take up an excruciating amount of time.
The article is good but very "beginner". The more challenging stuff is browser caching with htaccess rules etc.
Google Page Speed tests are actually very useful here and if you follow all their advice you end up with a very noticeably faster site.
* Doesn't actually explain why speed matters (hint: over 3 seconds people perceive a slow experience and over 10 seconds people will assume the site is broken)
* Doesn't say how to fix speed issues other than one specific small image/tiling "fix"
* If you worked at a real company this would never fly. The solution isn't to change the background altogether and go with tiling vs a big image.
I actually wrote an article on how to improve performance for everyone [1], and it's the biggest bang for your buck that anyone can do (designers, developers, or product folks).
[1] https://userinterfacing.com/the-fastest-way-to-increase-your...
Your article is good. But it's still incomplete, simple tasks like using a CDN / Reduce the number of HTTP calls / Caching can be implemented in an afternoon for lots of simple website, et can dramatically improve load times.
Perhaps some day I'll create a mega checklist of all things to consider to speed up a site :)
There is a number of issues with each and every tool you mentioned, e.g. color information stripped with metadata causing color shifts in wide-gamut and non-sRGB images, camera images changing orientation when Exif stripped, color banding on PNGs and JPEGs even when using Guetzli (JPEGmini is not nearly as good in other cases, but Guetzli is extremely slow), unexpected dithering noise on flat PNGs, tracing artefacts on screen recorded GIFs, JPEGs being overcompressed, poor lossless compression (virtually any online service), progressive JPEGs incompatible with Photoshop, etc.
These are just some of the problems I've been solving, and yes, there are better tools.