4 ms·
I completely agree with the basic sentiment of this article. Far too many sites lead with massive images and huge javascript frameworks just to serve what could
by AndrewStephens 10y ago
I completely agree with the basic sentiment of this article. Far too many sites lead with massive images and huge javascript frameworks just to serve what could be a few kilobytes of text.
That said, I did not go as far as this author when designing my personal blog[1], I considered the following tradeoffs worth the slight cost:
* I didn't inline images or CSS. I can see the appeal but I don't believe it is really worth it unless you have relatively small amounts of CSS. In theory HTTP2 is supposed to help here as well, and on really slow connections inlining can slow things down as the browser is forced to download the inlined stuff instead of progressively displaying the page as it can.
* I ended up deciding that the custom font I wanted to use was worth the cost. I thought hard about it though and would perhaps decide against it if I was designing the site again.
* You can drive yourself insane trying to minimize traffic for images. Should you try to serve 2x images for retina displays? Small images for mobile devices? In the end I just serve the same images for everybody and minimize the use of images overall. It works for me because I don't have a lot of need for splashy pictures.
* I avoided any type of social media button or plugin, they tend to make additional requests back to the mothership. Very few people actually liked or +1ed anything on my old blog anyway, but people with better blogs might find the trade-off worth it.
[1] https://sheep.horse https://sheep.horse
- spc476 10y agoI don't inline CSS or images either, but I did give them a long expiry time (a year). The first hit to my blog [1] might not be that fast, but subsequent hits should be (it's mostly text anyway). The CSS file has a unique name, and when I change it (it doesn't happen that often (last time was May 2015) it gets a new filename. Also, I serve no Javascript. I do have one external bit---a block pointing to my Amazon affiliate account (which might have Javascript, I don't know, probably does). It's disabled for mobile devices (via CSS---I use CSS to change the layout to make it more mobile friendly). [1] http://boston.conman.org/ http://boston.conman.org/
- theandrewbailey 10y agoI recently did a optimization pass at my own blog[0], and came to the same conclusions. I thought a lot about images, since I have a lot of game screenshots. I decided that since my redesigned homepage will only show summaries of a post with the first image, that my original rule of images no bigger than 80k was good enough. It makes the homepage about 500k on a uncached first hit, but I figure that's more useful than 500k of CSS and JS. Not only did I decide that my custom fonts were worth it, I started serving them in the smaller WOFF2 format, instead of (original) WOFF. Once I looked at the browser support, it was a no-brainer.[1] I'm also kind of stingy about browser requests. I've gotten it to no more than 10 (homepage; individual articles are less). If a resource is fairly small, it might not be worth the wait for the browser to open a connection and download it. All my fonts are base64 inlined into my CSS. Sure, it makes the CSS bigger, but the extra request is gone, and after gzip compression, it's almost the same size. I used Font Squirrel to eliminate unused glyphs from the fonts I use.[2] One thing I noticed about your CSS is that it has a enormous textual redundancy, but it's not gzip compressed. You can get an easy speed up by enabling it there. [0] https://theandrewbailey.com/ https://theandrewbailey.com/ [1] http://caniuse.com/#search=WOFF2 http://caniuse.com/#search=WOFF2 [2] https://www.fontsquirrel.com/tools/webfont-generator https://www.fontsquirrel.com/tools/webfont-generator