Some of my favorite optimizations: If you use a CMS but none of your site needs to be interactive, publish to static files and serve them directly from an object store like S3. No need to run...
Some of my favorite optimizations:
If you use a CMS but none of your site needs to be interactive, publish to static files and serve them directly from an object store like S3. No need to run every request through WordPress or whatever if the output is the same every time; this has the added benefit of ejecting your admin dash into a non-public location, hardening your site against attack.
Use SVGs instead of bitmap images wherever possible. You can optimize the crap out of SVGs with online tools, if you're crazy like me you can further squeeze out precious bytes by hand-tuning in Inkscape and/or your favorite text editor.
If you must use bitmap images for frequently-used UI elements, use a CSS spritesheet! I had a ton of fun learning about box-packing algorithms to optimally arrange irregularly shaped assets into the smallest possible PNG.
PNGs themselves can be optimized in interesting ways like stripping metadata, indexing colors to an optimal limited palette, discarding color information from transparent pixels, etc. I like this article's suggestion of switching to WebP. Haven't experimented with that format yet but it sounds promising.
Reduce HTTP requests by embedding small assets directly in the page as data URIs. Typically this requires base64 encoding, which can increase the asset size, so be aware of that tradeoff. It works pretty well with SVGs. Another downside is that multiple HTTP requests can be a good thing if you're making the same requests from every page on your site, since users will only need to download them the first time, after which they'll be fetched from local cache. So don't use this for UI.
If you want to include a font that will only be used in known, limited scenarios, edit the TTF with a tool like FontForge and delete all the glyphs that will never be used. You can cull a ton of bloat from a font if you know exactly what characters you need from it.
The savings are negligible but you can minify HTML and CSS just like you would with JS. Mostly that involves stripping whitespace and making your source unreadable... but smaller.
Pretty sure gzip compression is standard across the board now, but it's always worth making sure you've got it enabled on your server.
The savings are negligible but you can minify HTML and CSS just like you would with JS. Mostly that involves stripping whitespace and making your source unreadable... but smaller.
I don't think it's possible for every page to skip front-end frameworks, but I do agree that people tend to be too eager to use them. With younger colleagues I've realized they often lack the...
I don't think it's possible for every page to skip front-end frameworks, but I do agree that people tend to be too eager to use them. With younger colleagues I've realized they often lack the understanding of the technologies they use in frameworks and couldn't implement their own styles even if they realized this might be an issue.
But I've seen the same in the backend, so that might be a general issue, not only regarding the frontend. The database design I've seen gives me nightmares.
I think as ever it comes down to the old "cheap, fast, good - choose two" If you want your portfolio site out the door in two days and are only paying £1000 then damn right I'm just throwing up a...
I think as ever it comes down to the old "cheap, fast, good - choose two"
If you want your portfolio site out the door in two days and are only paying £1000 then damn right I'm just throwing up a bootstrap template. I'll do the freebies like optimising the images which the client has for some reason sent over as 45MB TIFFs inside a PowerPoint file, but I'm not hand-tuning everything to get ever last byte under control.
On other hand if you're after a highly bespoke site with a whole raft of complex interactions and are prepared to pay then sure, I'll sit and write a load of custom JS, then optimise every last DB query and CSS rule. Way back in the day I remember simulating low-end dial-up load times for the kind of client who gave a shit about that kind of thing. They were rare but they did exist. Caring about that did cost them a lot of money but perhaps they saw it back from having their site be quick for everyone.
Yeah, that's basically it. I had a client request to make the app/backend capable of handling bad connections. How bad? "Imagine sitting in a bunker underground without any connection. Can you...
Yeah, that's basically it. I had a client request to make the app/backend capable of handling bad connections. How bad? "Imagine sitting in a bunker underground without any connection. Can you make it prefetch all or specific data depending on what the user wants?". Sure we can, but that'll come at a cost. Customer didn't mind the money. It was a fun project.
I'm finding I've included bootstrap and end up writing my own styles anyway because BS feels so limited and frustrating. Why do I need 3 classes and loads of !Important just to hide and show an...
I'm finding I've included bootstrap and end up writing my own styles anyway because BS feels so limited and frustrating. Why do I need 3 classes and loads of !Important just to hide and show an element? I'm about to convince my company to drop it off I can
It is tough to use unicode/emojis in web design. Browsers are pretty inconsistent, and the styling will differ based on the selected font so you need to be confident in your font stack. I only use...
It is tough to use unicode/emojis in web design. Browsers are pretty inconsistent, and the styling will differ based on the selected font so you need to be confident in your font stack.
I only use emoji when I'm using common enough glyphs that they'll have a text representation available (+VS15), and not just emoji representation (+VS16). For example, if I had an envelope beside a mail link.
Text: ✉︎
Emoji: ✉️
The text representation can be styled as expected, with font size, color, etc. The emoji cannot, and likely will clash with the rest of the page as a result.
In CSS, the text version might look something like: .mail::before {content: "\2709\fe0e"}
Where the first part is the envelope, and the second part is the chosen representation.
Even when taking these precautions, I've still had websites decide to render the emoji representation on random devices. I hope browsers come up with a solution that makes emojis a more reliable option for webpage icons. There is the (hopefully) upcoming font-variant-emoji, but I'm pretty sure that just performs the same override as above, so it doesn't solve the real issues with font and browser support.
Inline SVG seems like the best option we have right now. It's relatively compact, and you don't need to base64 it.
Some of my favorite optimizations:
Back in the dialup days this was very common.
I don't think it's possible for every page to skip front-end frameworks, but I do agree that people tend to be too eager to use them. With younger colleagues I've realized they often lack the understanding of the technologies they use in frameworks and couldn't implement their own styles even if they realized this might be an issue.
But I've seen the same in the backend, so that might be a general issue, not only regarding the frontend. The database design I've seen gives me nightmares.
I think as ever it comes down to the old "cheap, fast, good - choose two"
If you want your portfolio site out the door in two days and are only paying £1000 then damn right I'm just throwing up a bootstrap template. I'll do the freebies like optimising the images which the client has for some reason sent over as 45MB TIFFs inside a PowerPoint file, but I'm not hand-tuning everything to get ever last byte under control.
On other hand if you're after a highly bespoke site with a whole raft of complex interactions and are prepared to pay then sure, I'll sit and write a load of custom JS, then optimise every last DB query and CSS rule. Way back in the day I remember simulating low-end dial-up load times for the kind of client who gave a shit about that kind of thing. They were rare but they did exist. Caring about that did cost them a lot of money but perhaps they saw it back from having their site be quick for everyone.
Yeah, that's basically it. I had a client request to make the app/backend capable of handling bad connections. How bad? "Imagine sitting in a bunker underground without any connection. Can you make it prefetch all or specific data depending on what the user wants?". Sure we can, but that'll come at a cost. Customer didn't mind the money. It was a fun project.
I'm finding I've included bootstrap and end up writing my own styles anyway because BS feels so limited and frustrating. Why do I need 3 classes and loads of !Important just to hide and show an element? I'm about to convince my company to drop it off I can
It is tough to use unicode/emojis in web design. Browsers are pretty inconsistent, and the styling will differ based on the selected font so you need to be confident in your font stack.
I only use emoji when I'm using common enough glyphs that they'll have a text representation available (+VS15), and not just emoji representation (+VS16). For example, if I had an envelope beside a mail link.
Text: ✉︎
Emoji: ✉️
The text representation can be styled as expected, with font size, color, etc. The emoji cannot, and likely will clash with the rest of the page as a result.
In CSS, the text version might look something like:
.mail::before {content: "\2709\fe0e"}Where the first part is the envelope, and the second part is the chosen representation.
Even when taking these precautions, I've still had websites decide to render the emoji representation on random devices. I hope browsers come up with a solution that makes emojis a more reliable option for webpage icons. There is the (hopefully) upcoming font-variant-emoji, but I'm pretty sure that just performs the same override as above, so it doesn't solve the real issues with font and browser support.
Inline SVG seems like the best option we have right now. It's relatively compact, and you don't need to base64 it.