> That gives near instant live reload when writing posts which makes a huge difference from waiting 4 seconds.
Mhm. Why? I can write all of my post and look at it only afterwards? Perhaps if there's a table or something tricky I want to check before. But normally, I couldn't care less about the reload speed.
> I use that plugin because it digests your assets by adding a SHA-256 hash to their file names. This lets me cache them with nginx. I can’t not have that feature.
> Mhm. Why? I can write all of my post and look at it only afterwards?
My site has a fixed max width which is what most tablets or desktops will view it as.
Sentence display width is something I pay attention to. For example sometimes I don't want 1 hanging word to have its own full line (a "hanger") because it looks messy. Other times I do want it because it helps break up a few paragraphs of similar length to make it easier to skim.
Seeing exactly what my site looks like while writing lets me see these things as I'm writing and having a fast preview enables that. Waiting 4 seconds stinks.
> Why? [asset digesting and cache busting with nginx]
It helps reduce page load speeds for visitors and saves bandwidth for both the visitor and your server. If their browser already has the exact CSS or JS file cached locally, this allows you to skip a server side call to even determine if the asset can be served locally or needs an update from the server.
The concept of digesting assets with infinitely long cache header times isn't new or something I came up with. It's been around for like 10+ years as a general purpose optimization.
> Sentence display width is something I pay attention to. For example sometimes I don't want 1 hanging word to have its own full line (a "hanger") because it looks messy. Other times I do want it because it helps break up a few paragraphs of similar length to make it easier to skim.
Isn't your website responsive? If it is, for how many different resolutions do you check this? I think I obsess about details, but thankfully not about this!
You should be able to use `text-wrap: pretty;` to eventually remove orphans. If you sometimes want them on purpose and sometimes avoid them, that's just weird. I'm sure this is a lost fight: it'll look different with different setups anyway. Different browser, different OS, different fonts, ... it's a lost battle.
> It helps reduce page load speeds for visitors and saves bandwidth for both the visitor and your server.
Mhm I just use apache's cache_dist[0]. It works fine out of the box, for all my myriads of websites. Yes sometimes there's a new file and a browser is stuck on the old version. Requires a hard refresh. Someone who doesn't know will see the old version. I don't particularly mind that.
Right, I missed that!
> That gives near instant live reload when writing posts which makes a huge difference from waiting 4 seconds.
Mhm. Why? I can write all of my post and look at it only afterwards? Perhaps if there's a table or something tricky I want to check before. But normally, I couldn't care less about the reload speed.
> I use that plugin because it digests your assets by adding a SHA-256 hash to their file names. This lets me cache them with nginx. I can’t not have that feature.
Why?
> Mhm. Why? I can write all of my post and look at it only afterwards?
My site has a fixed max width which is what most tablets or desktops will view it as.
Sentence display width is something I pay attention to. For example sometimes I don't want 1 hanging word to have its own full line (a "hanger") because it looks messy. Other times I do want it because it helps break up a few paragraphs of similar length to make it easier to skim.
Seeing exactly what my site looks like while writing lets me see these things as I'm writing and having a fast preview enables that. Waiting 4 seconds stinks.
> Why? [asset digesting and cache busting with nginx]
It helps reduce page load speeds for visitors and saves bandwidth for both the visitor and your server. If their browser already has the exact CSS or JS file cached locally, this allows you to skip a server side call to even determine if the asset can be served locally or needs an update from the server.
The concept of digesting assets with infinitely long cache header times isn't new or something I came up with. It's been around for like 10+ years as a general purpose optimization.
> Sentence display width is something I pay attention to. For example sometimes I don't want 1 hanging word to have its own full line (a "hanger") because it looks messy. Other times I do want it because it helps break up a few paragraphs of similar length to make it easier to skim.
Isn't your website responsive? If it is, for how many different resolutions do you check this? I think I obsess about details, but thankfully not about this!
You should be able to use `text-wrap: pretty;` to eventually remove orphans. If you sometimes want them on purpose and sometimes avoid them, that's just weird. I'm sure this is a lost fight: it'll look different with different setups anyway. Different browser, different OS, different fonts, ... it's a lost battle.
> It helps reduce page load speeds for visitors and saves bandwidth for both the visitor and your server.
Mhm I just use apache's cache_dist[0]. It works fine out of the box, for all my myriads of websites. Yes sometimes there's a new file and a browser is stuck on the old version. Requires a hard refresh. Someone who doesn't know will see the old version. I don't particularly mind that.
I guess you're more of a perfectionist than I am.
[0]: https://httpd.apache.org/docs/2.4/mod/mod_cache_disk.html
1 reply →