4 ms·

Your site isn't faster because it's only HTML. It took ~360ms for DOMContentReady in average on your site while on pothibo.com (My blog running on Ecrire) took

by pothibo 12y ago

Your site isn't faster because it's only HTML. It took ~360ms for DOMContentReady in average on your site while on pothibo.com (My blog running on Ecrire) took an average of ~260ms. Your post made quite a lot of emphasis on "speed" but the first argument I checked was false. I used static site generation and it's a very poor choice for your personal website. Works fine to create a Readme on github. Sucks if you use it to manage your personal website (brand).

monkey_slap 12y ago
Can you offer some alternatives or ideas as to why its slow and yours is oh-so-fast? Or offer some advice on how to speed his site's load times up?
colinramsay 12y ago
In what way does it "suck"?
- pothibo 12y ago
  - Can't edit anywhere beside the machine that has your source & access to server. - Refactor your posts' tag? You need to manually edit all your post one by one. - Refactor your theme? Same thing as above - You can't have dynamic content, ever.
  - icebraining 12y ago
    - Can't edit anywhere beside the machine that has your source & access to server. Not true. OP himself hosts his source on Github, so not only he has access to it everywhere, as he can edit it from any machine with a browser. - Refactor your posts' tag? You need to manually edit all your post one by one. - Refactor your theme? Same thing as above Not true. Static site generation engines like Pelican (which OP uses) can do it for you. - You can't have dynamic content, ever. You can with JavaScript (or by integrating a third-party service, though that's cheating a bit).
  - djur 12y ago
    Use SSH, write scripts to facilitate bulk changes, do dynamic content with Javascript on the client side. If you need server-side logic, build some APIs and talk to them from the JS. Much cleaner than hacking additional features into off-the-shelf CMS/blog software.
    - chc 12y ago
      What you are describing sounds like a hodge-podge of workarounds. Like, one solution is "Use SSH, write scripts to facilitate bulk changes, write multiple backend services and front-end JavaScript to interface with them for any actual functionality you want on the site." The other is "Push a button on your blog software." How is the first one "cleaner"? You're basically re-inventing half of a blog with duct tape and toothpicks.
  - opendais 12y ago
    To be honest, your objections sounds more like "It doesn't work for me, personally" and not objectively factual objections. > - Can't edit anywhere beside the machine that has your source & access to server. Eh? Use CI and push via Git & a Markdown editor? They have apps for these on your phone? Or just GitHub? > - Refactor your posts' tag? You need to manually edit all your post one by one. I can replace all in an entire directory of documents in ~5 seconds. This is a non-issue. > - Refactor your theme? Same thing as above I modify two files to refactor all my blog posts. > - You can't have dynamic content, ever. Eh? AJAX? Allows you to make calls to another api/domain to throw in dynamic content?
icebraining 12y ago
With a non-primed cache, your site gave me >1s for DOMContentReady consistently. OP's never reached 700ms. The main HTML page alone of this post[1] takes ~280ms here. [1] http://pothibo.com/2013/11/rails-journey-dispatch-to-the-controller http://pothibo.com/2013/11/rails-journey-dispatch-to-the-con...
opendais 12y ago
Fresh cache run of your site took me 800ms vs. 400ms for OP. I suspect you didn't try with a fresh cache for your blog. If all your JS, CSS, etc was cached locally already that would explain your "performance advantage" to me.

by pothibo 12y ago

monkey_slap 12y ago

Can you offer some alternatives or ideas as to why its slow and yours is oh-so-fast? Or offer some advice on how to speed his site's load times up?

colinramsay 12y ago

In what way does it "suck"?

pothibo 12y ago
- Can't edit anywhere beside the machine that has your source & access to server. - Refactor your posts' tag? You need to manually edit all your post one by one. - Refactor your theme? Same thing as above - You can't have dynamic content, ever.
- icebraining 12y ago
  - Can't edit anywhere beside the machine that has your source & access to server. Not true. OP himself hosts his source on Github, so not only he has access to it everywhere, as he can edit it from any machine with a browser. - Refactor your posts' tag? You need to manually edit all your post one by one. - Refactor your theme? Same thing as above Not true. Static site generation engines like Pelican (which OP uses) can do it for you. - You can't have dynamic content, ever. You can with JavaScript (or by integrating a third-party service, though that's cheating a bit).
- djur 12y ago
  Use SSH, write scripts to facilitate bulk changes, do dynamic content with Javascript on the client side. If you need server-side logic, build some APIs and talk to them from the JS. Much cleaner than hacking additional features into off-the-shelf CMS/blog software.
  - chc 12y ago
    What you are describing sounds like a hodge-podge of workarounds. Like, one solution is "Use SSH, write scripts to facilitate bulk changes, write multiple backend services and front-end JavaScript to interface with them for any actual functionality you want on the site." The other is "Push a button on your blog software." How is the first one "cleaner"? You're basically re-inventing half of a blog with duct tape and toothpicks.
- opendais 12y ago
  To be honest, your objections sounds more like "It doesn't work for me, personally" and not objectively factual objections. > - Can't edit anywhere beside the machine that has your source & access to server. Eh? Use CI and push via Git & a Markdown editor? They have apps for these on your phone? Or just GitHub? > - Refactor your posts' tag? You need to manually edit all your post one by one. I can replace all in an entire directory of documents in ~5 seconds. This is a non-issue. > - Refactor your theme? Same thing as above I modify two files to refactor all my blog posts. > - You can't have dynamic content, ever. Eh? AJAX? Allows you to make calls to another api/domain to throw in dynamic content?

icebraining 12y ago

With a non-primed cache, your site gave me >1s for DOMContentReady consistently. OP's never reached 700ms. The main HTML page alone of this post[1] takes ~280ms here. [1] http://pothibo.com/2013/11/rails-journey-dispatch-to-the-controller http://pothibo.com/2013/11/rails-journey-dispatch-to-the-con...

opendais 12y ago

Fresh cache run of your site took me 800ms vs. 400ms for OP. I suspect you didn't try with a fresh cache for your blog. If all your JS, CSS, etc was cached locally already that would explain your "performance advantage" to me.