4 ms·

Do a test proving it this way is more inefficient. BTW, everything is separated before publishing. CSS is one file, reset CSS is in another, there is a HTML te

by sramov 16y ago

Do a test proving it this way is more inefficient. BTW, everything is separated before publishing. CSS is one file, reset CSS is in another, there is a HTML template etc. Easy maintenance off line, online and published does not matter. It is similar with dynamic publishing. As for the inefficiency we all know HTTP requests are the biggest enemy. All my pages are exactly one request. With everything being minimized, gzipped and unused CSS selectors stripped I do not see how this can be more 'inefficient'.

alttab 16y ago
How long would it take to understand, learn, implement, and test this set up? I understand the fully-packed 1 request situation is great for serve-time and page-rank, and after it is all said and done its probably the better solution. This is a slippery slope though because its possible to do too much of that and not enough real work.
- sramov 16y ago
  There is a distinction to be made here. Inefficient in page load times and performance or inefficient in the unnecessary complication? I was talking/responding about performance. The bigger the site, lesser the point in all of this (and harder). It is a small personal site and I enjoyed the process of doing all of this. Makefile is nice to have in the end, which means it was a one time investment.
  - alttab 16y ago
    Right - I was merely pointing out the opportunity cost of doing it. I'm sure its a fun project and for a personal site would work great. Unless you have it set up in a certain way - it does require one more step. When you save the content you still have to run the makefile and then upload it. Even though this could be done in a batch script, just looking at the problem you are trying to solve (run a personal site/blog), it seems rather over-complicated. The virtue and delivery of the idea is cool though - never discounted that. I just wanted to play devil's advocate on the practicality - which you seem to agree that it isn't really practical.
    - sramov 16y ago
      The one more step is the same as in Jekyll or any other static site generator. You have content on disk, (re)generate the site and then upload it. In my case I edit an article or write a new one, type 'make all', preview the result locally in the browser, if it is fine, I type 'make live' and off it goes to a server -- with only differences from the last time uploaded. It can also be integrated with DVCS post-hooks.
jasonkester 16y ago
To be fair, since it's your thing and you're going against conventional wisdom, it's probably your job to demonstrate it's better. As it stands, you're re-sending all your images and all your css and all your javascript to every one of your users every time they ask for a page on your site. So if I like your blog and read 50 articles, you've sent me that stuff 50 times over. If you come to my site and flip through 50 pages, you'll get one css file, seven images, and one javascript file from the first page you request, all minified, gzipped and compressed just like yours is. The only difference being those extra requests, which might end up faster overall since they're to a CDN endpoint at your end of whatever continent you're on. For the next 49 requests, all you get is content.
- sramov 16y ago
  I don't have any JavaScript, CSS is small, there is only one tiny image which is very small even base64 encoded. So I don't think this applies in my case. For bigger advanced sites, yes, you are right. Up to certain point, this is 'better', from the certain point, it is not.
  - theli0nheart 16y ago
    You could probably do one better one yourself if you served the CSS separately (with the inline images included). Two requests isn't that bad. And that's only two requests the first time someone visits your site--the next visits will have cached the CSS and will only request the HTML. But I definitely see the novelty in only having one.
- blaix 16y ago
  I was thinking this exact thing while reading his article (losing the benefit of caching external files locally). It would be my guess that this does improve performance for single requests (like an article that gets popular on HN...), but as you said, reading 50 pages would be worse. Still it's very cool, especially for a minimalist blog.

by sramov 16y ago

alttab 16y ago

How long would it take to understand, learn, implement, and test this set up? I understand the fully-packed 1 request situation is great for serve-time and page-rank, and after it is all said and done its probably the better solution. This is a slippery slope though because its possible to do too much of that and not enough real work.

sramov 16y ago
There is a distinction to be made here. Inefficient in page load times and performance or inefficient in the unnecessary complication? I was talking/responding about performance. The bigger the site, lesser the point in all of this (and harder). It is a small personal site and I enjoyed the process of doing all of this. Makefile is nice to have in the end, which means it was a one time investment.
- alttab 16y ago
  Right - I was merely pointing out the opportunity cost of doing it. I'm sure its a fun project and for a personal site would work great. Unless you have it set up in a certain way - it does require one more step. When you save the content you still have to run the makefile and then upload it. Even though this could be done in a batch script, just looking at the problem you are trying to solve (run a personal site/blog), it seems rather over-complicated. The virtue and delivery of the idea is cool though - never discounted that. I just wanted to play devil's advocate on the practicality - which you seem to agree that it isn't really practical.
  - sramov 16y ago
    The one more step is the same as in Jekyll or any other static site generator. You have content on disk, (re)generate the site and then upload it. In my case I edit an article or write a new one, type 'make all', preview the result locally in the browser, if it is fine, I type 'make live' and off it goes to a server -- with only differences from the last time uploaded. It can also be integrated with DVCS post-hooks.

jasonkester 16y ago

To be fair, since it's your thing and you're going against conventional wisdom, it's probably your job to demonstrate it's better. As it stands, you're re-sending all your images and all your css and all your javascript to every one of your users every time they ask for a page on your site. So if I like your blog and read 50 articles, you've sent me that stuff 50 times over. If you come to my site and flip through 50 pages, you'll get one css file, seven images, and one javascript file from the first page you request, all minified, gzipped and compressed just like yours is. The only difference being those extra requests, which might end up faster overall since they're to a CDN endpoint at your end of whatever continent you're on. For the next 49 requests, all you get is content.

sramov 16y ago
I don't have any JavaScript, CSS is small, there is only one tiny image which is very small even base64 encoded. So I don't think this applies in my case. For bigger advanced sites, yes, you are right. Up to certain point, this is 'better', from the certain point, it is not.
- theli0nheart 16y ago
  You could probably do one better one yourself if you served the CSS separately (with the inline images included). Two requests isn't that bad. And that's only two requests the first time someone visits your site--the next visits will have cached the CSS and will only request the HTML. But I definitely see the novelty in only having one.
blaix 16y ago
I was thinking this exact thing while reading his article (losing the benefit of caching external files locally). It would be my guess that this does improve performance for single requests (like an article that gets popular on HN...), but as you said, reading 50 pages would be worse. Still it's very cool, especially for a minimalist blog.