How do plugins like WP Super Cache https://wordpress.org/plugins/wp-super-cache/ compare with straight HTML pages? The extra overhead is in the PHP serving up the cached HTML page, but how effective is it in comparison? More of the static site development setups don't have an admin system that compares with WP, is there a WP plugin to export to a static site?
> is there a WP plugin to export to a static site?
Here is one I found [1], I've never used it though, so I don't know how good it is. I'm sure there are others as well. It would be nice if there were a static site generator with an interface as nice as WP.
It would be nice if wordpress itself had the option of pressing a button saying - push to static. When you make an edit -> update static files. This would be fantastically easier + it would potentially mean 1/4 of the web gets faster overnight.
What makes you think that it would grow its adoption rate at all? If I were to take a guess, I'd say most Wordpress installations are done by people who don't care about server load, and don't fret out over a 2s load time instead of 200ms.
I was really meaning when you hit publish it would auto-reflow all the static pages. The great news is WordPress could come up with a static way of using javascript for things like sidebars so you wouldn’t necessarily have to repaint every page with every blog post.
Something like call partial (list of recent blog posts) which itself could be static. Two-to-three static calls and you could have a very clean and robust system with no database queries.
Unfortunately you'd have to at least modify most WP plugins to get them to work with this new system. At some point it becomes easier just to try to move everyone over to a born-static platform like Ghost.
ModX - a PHP cms which is fairly popular has a static site exporter. I havent' played with modx in a while, hopefully it's still a feature since their many updates in the last 5 years.
WP Super Cache is a good starting point.
Taken alone is not enough though.
Most web shared hosting where custom wp are configured use Apache which doesn't solve the problem because apache (2.2, the 2.4 version should have improved a bit) spawns processes containing the PHP modules, therefore using more ram than it actually needs to process an html page.
This issue is vastly solved if you have a Nginx webserver with a good configuration.
You can also improve that if you use memcached and the nginx memcached_pass, which directly outputs the memcached cached html without passing through php, giving a super-boost to response times. (to use this feature, checkout the WP-FFPC plugin)
If one page ends up on reddit/hackernews/producthunt homepage, a system designed like this should support the bump with relatively small issue.
Obviously if many people start commenting you will still have performance issue because that's when the php part is called (and that's the most memory expensive).
If you configure WP Super Cache correctly (e.g. rewrites), you won't be running any PHP when visiting the cached version of the site. So there's really no need to "export" anything.
Absolutely, take static as far as you possibly can. In a world with S3 and Cloudfront, there is really no reason for a static site to ever be down. This is great for a company's marketing focused web presence. But often the reason you're getting all those visitors to your site in the first place is that it does something valuable that requires data persistence, which usually implies user sessions, which implies authentication flows, and all of this requires being able to serve dynamic requests at scale, so you need to figure out how to do that as well.
But we definitely serve too much of the web from dynamic php sites that could easily just be HTML files sitting in a cache or on a file system.
Just to take it a step further though, in a world where every browser can run Javascript and make AJAX requests, which of your requirements can't be handled by the client communicating with an API directly? Considering sessions for example, local storage is supported by virtually every browser you can name: http://caniuse.com/#feat=namevalue-storage
In my experience, it's significantly easier to scale an API than a traditional (PHP-style) web server.
I don't disagree at all, but scaling a dynamic API is still harder than scaling static resources. Saying "we're doing everything through an API" is one solution to the problem of scaling the dynamic portions of the application, which I alluded to.
Something of an aside: You really don't need localStorage to do this. You can still use cookies, you just can't use HttpOnly cookies, and in fact that's what the localStorage polyfills I've used fall back to. The trade-off (drat! there's always one of those) of both localStorage and non-HttpOnly cookies is that it once again becomes easy to steal user access credentials outright if you can manage an XSS attack, which is what HttpOnly cookies helped prevent in theory. On the other hand, in practice XSS attacks can still usually steal an account even with HttpOnly cookies (for instance, by sending a request to change a user's password, which dutifully sends along the valid cookie anyway) or do other nefarious things, so you just can't let XSS happen either way.
Another question is: Is the user experience of applications built this way as good? It definitely can be once everything is loaded and churning along, but the initial load can be quite slow and choppy as data comes back piecemeal. Server-rendering the initial page and doing updates through an API is, I believe, the way forward, but it's still tricky and inconvenient to do. And then you once again need to scale the rendering of full pages server-side!
tl;dr; Yes, that's a good approach, but not a panacea.
It's referring to system updates. The need to update your MySQL version, or your Bash version when there's an new vulnerability. All the things you have to do to keep a server on the internet secure and operational over time.
I assumed as much. But someone still needs to do that for the server hosting your static website. And for a dynamic site, you still have the option to offload operational concerns to a third party.
Static website generators seem to come and go -- would anyone like to comment on one they like that seems to be lasting the test of time? The obvious one seems to be jekyll (possibly with octopress on top of it), but I'm interested in any others.
Pelican I've had great luck with so far, but I can't testify honestly to whether it will last. Since it is Python and makefiles, I have found it very easy to modify myself just with my background knowledge.
Middleman still receives consistent updates. It's been a rock solid platform for us to build static websites and the occasional prototype out of for the last few years. Deploys easily to GitHub pages, too.
Middleman has been the most usable for me. In the past I've tried Jekyll, Hexo, Huge and DocPad.
Middleman is just simple enough that you can quickly build out an entire website/blog with great functionality, but extensible enough that you can write some custom Ruby to do that one specific thing you want.
I also really like how middleman can essentially use any markdown renderer or template engine. As someone that loves erb, Sass and Rake, Middleman just makes the most sense.
http://www.staticgen.com is a great tool to help you find one to fit your needs. It does a daily poll of github stats on the most popular static site generators (72 on last count!) and lets you sort by programming language and popularity.
That being said, I'm been using gulp to hack together a system when the site isn't something conventional like a blog, marketing page or docs that many of these generators excel at.
I get the point he's making, but when I want to add something as simple as a counter my website already stops being static. The question you have to ask yourself: How many static websites are in your "favourite" folder? When I look into it, I have a hard time finding a single one.
Fortunately websites can run javascript now, allowing you to do virtually any dynamic thing you need. Counters in particular are an interesting example, because they were inserted as images into websites long before the idea of a dynamic website was popularized.
You can see many of the things you can do just on the client in our apps list: https://eager.io/apps. We don't have a counter in there yet, but it's certainly possible.
I'm not sure if I don't understand or you don't understand. No, a counter requires (at least) one integer of persistent memory. And if it's not on your server it's on someone else's server. Bottom line, your site stops being static.
I like the static site idea (I used it for years for my personal site), but I also like having a web front end for editing. I can't find a static site generator with a dynamic admin/posting end. Anyone seen one?
Ah yes I saw prose before and it looked promising. A bit techie for most, but it's fine for me. I had wondered about build and deploy - thanks for the pointer to TravisCI.
I started a working on a little node-webkit app with a markdown editor and some node.js static site generator embedded, giving a nice UI for editing and generating the site. I never got it working well enough to use, let alone share, but I hope somebody else does it someday.
Yeah it's a really hard problem (content editing in the browser). I am working on something like this now (for HTML content, not markdown specifically) and all I can say is it's prickly. The browser's content editing APIs are terrible so you have to do most everything yourself. But then there are some things that are very difficult to emulate, like selections. Still I think it's worth doing because I am tired of hand-coding my HTML pages all the time, and I think someone who can figure this might make a few dollars.
I've been trying this philosophy out on a little GitHub Pages editor app [1]. Everything happens client side apart from a tiny bit of OAuth handled by heroku!
I tried building a static website for people to browse tech article headlines that were gather ed from around the web. The feedback was that people like the style and general idea, but wanted a crap ton of features that can only be accomplished in a highly dynamic and scalable web site. IE Logins, Voting, Commenting, Friending, Favoriting, Etc and so forth.
You can do any of these things by building an API and communicating with it using javascript in the browser. This method generally leads to a more responsive interface as well, as you don't have to reload the page when the user favorites, friends, etc.
At http://HockeyBias.com we recreate our html every time we have a new story to display on the site and push the static html out using AppEngine. The pages load very quickly compared to other sports sites that are making countless roundtrips...
Another solution we implemented was to have a WordPress site up, but only serving a spidered copied HTML version of it in the public_html directory.
Every 2 minutes the site gets fully spidered, dumped into flat HTML files. And if the dump is not successful, because of a database connection or any problem at all, it doesn't get saved and doesn't overwrite the public_html dir.
This is interesting. Do the internal links get updated to point to the static spidered version or do they still point to the dynamic website?
I've been toying with the idea of creating a product / service that would let you choose which internal links went to the static copy and which would be forwarded to the original site so that dynamic stuff like commenting could still work (although perhaps display would be delayed), but everything else could be static / cached.
Honestly I think a proof of concept could be done using something like wget to mirror the site and a little ruby or awk to do the specific link rewriting.
Working for a web firm that has a CMS, and web platform that is 95% ran from SQL queries. Reading this reminds me how cluttered and loaded websites have become. Granted I'm not a developer, but it's noticeable when you have to account for 1.5 seconds of latency because of database pulls, and the fact that it makes everything more complicated, as well as harder to design for resiliency.
I'm running a discount for my design service today
Somebody might find it helpful, especially when you are focused on building websites, it saves you time https://gumroad.com/l/kxkNL
Static websites are great, I love them. I definitely generate them when possible.
But beware, if your website start to grow and becomes more dynamic, take a step back and rethink if you should still go with all that generation. Could be a pain in the future.
Someone correct if I'm wrong, but the people behind the The New York Times website had to do a major rewriting of their code base due to that (I remember seeing some presentation about it some time ago, but I can't find the link nowadays...).
If caching is setup properly, you won't need any Database-Querys unless your Content changes.
A static site needs also to be served. HTML-files are on the Servers Harddrive. They have to be read and send to the client.
A clever Caching-Strategy might beat this aproach by reading the files once and Serving the content from memory. When I write "reading the files once", this also includes making a db-query, rendering a HTML-Site and caching the result in a Tool like memcache to serve it from there.
I get that building static websites is interesting, if only because they're easily backupable, deployable and are generally lightweight.
But if the problem is about resisting traffic, then that's the reason why CDNs were invented: cloudflare is an example, and the seemingly unactive coralcdn (http://www.coralcdn.org/), even simpler to "install" and has a very interesting architecture (I encourage anyone interested in P2P stuff to take a look at their papers).
Keeping your server behind some form of CDN also has the advantage that you keep control over the actual storage of your data.
59 comments
[ 2.9 ms ] story [ 127 ms ] threadEdit: WP caching benchmarks http://cd34.com/blog/scalability/wordpress-cache-plugin-benc...
Here is one I found [1], I've never used it though, so I don't know how good it is. I'm sure there are others as well. It would be nice if there were a static site generator with an interface as nice as WP.
[1]: https://github.com/megumiteam/staticpress
oh man, that's a great idea, that would grow WP adoption rate by 1000x
Something like call partial (list of recent blog posts) which itself could be static. Two-to-three static calls and you could have a very clean and robust system with no database queries.
Most web shared hosting where custom wp are configured use Apache which doesn't solve the problem because apache (2.2, the 2.4 version should have improved a bit) spawns processes containing the PHP modules, therefore using more ram than it actually needs to process an html page.
This issue is vastly solved if you have a Nginx webserver with a good configuration.
You can also improve that if you use memcached and the nginx memcached_pass, which directly outputs the memcached cached html without passing through php, giving a super-boost to response times. (to use this feature, checkout the WP-FFPC plugin) If one page ends up on reddit/hackernews/producthunt homepage, a system designed like this should support the bump with relatively small issue.
Obviously if many people start commenting you will still have performance issue because that's when the php part is called (and that's the most memory expensive).
I came across this a little while ago: https://decoupled.de/
But we definitely serve too much of the web from dynamic php sites that could easily just be HTML files sitting in a cache or on a file system.
In my experience, it's significantly easier to scale an API than a traditional (PHP-style) web server.
Something of an aside: You really don't need localStorage to do this. You can still use cookies, you just can't use HttpOnly cookies, and in fact that's what the localStorage polyfills I've used fall back to. The trade-off (drat! there's always one of those) of both localStorage and non-HttpOnly cookies is that it once again becomes easy to steal user access credentials outright if you can manage an XSS attack, which is what HttpOnly cookies helped prevent in theory. On the other hand, in practice XSS attacks can still usually steal an account even with HttpOnly cookies (for instance, by sending a request to change a user's password, which dutifully sends along the valid cookie anyway) or do other nefarious things, so you just can't let XSS happen either way.
Another question is: Is the user experience of applications built this way as good? It definitely can be once everything is loaded and churning along, but the initial load can be quite slow and choppy as data comes back piecemeal. Server-rendering the initial page and doing updates through an API is, I believe, the way forward, but it's still tricky and inconvenient to do. And then you once again need to scale the rendering of full pages server-side!
tl;dr; Yes, that's a good approach, but not a panacea.
http://gohugo.io/
Node.js-based, lots of plugins available via npm, sane themeing syntax. I have a script that generates my site and then pushes it to S3.
My site, such as it is, is available here: https://github.com/drhayes/drhayes.io
https://middlemanapp.com https://github.com/middleman/middleman
Middleman is just simple enough that you can quickly build out an entire website/blog with great functionality, but extensible enough that you can write some custom Ruby to do that one specific thing you want.
I also really like how middleman can essentially use any markdown renderer or template engine. As someone that loves erb, Sass and Rake, Middleman just makes the most sense.
A few sites I've built with middleman
- http://ryanSrich.com/blog
- https://resources.catalyze.io
That being said, I'm been using gulp to hack together a system when the site isn't something conventional like a blog, marketing page or docs that many of these generators excel at.
(On the other hand, I don't like using javascript for things that don't need it, so it's not soo clear cut...)
You can see many of the things you can do just on the client in our apps list: https://eager.io/apps. We don't have a counter in there yet, but it's certainly possible.
You can then use TravisCI (or the like) to trigger the site rebuild and deployment.
1: http://github.com/iamdanfox/ghupdate/
Every 2 minutes the site gets fully spidered, dumped into flat HTML files. And if the dump is not successful, because of a database connection or any problem at all, it doesn't get saved and doesn't overwrite the public_html dir.
I've been toying with the idea of creating a product / service that would let you choose which internal links went to the static copy and which would be forwarded to the original site so that dynamic stuff like commenting could still work (although perhaps display would be delayed), but everything else could be static / cached.
Honestly I think a proof of concept could be done using something like wget to mirror the site and a little ruby or awk to do the specific link rewriting.
But beware, if your website start to grow and becomes more dynamic, take a step back and rethink if you should still go with all that generation. Could be a pain in the future.
Someone correct if I'm wrong, but the people behind the The New York Times website had to do a major rewriting of their code base due to that (I remember seeing some presentation about it some time ago, but I can't find the link nowadays...).
A static site needs also to be served. HTML-files are on the Servers Harddrive. They have to be read and send to the client.
A clever Caching-Strategy might beat this aproach by reading the files once and Serving the content from memory. When I write "reading the files once", this also includes making a db-query, rendering a HTML-Site and caching the result in a Tool like memcache to serve it from there.
But if the problem is about resisting traffic, then that's the reason why CDNs were invented: cloudflare is an example, and the seemingly unactive coralcdn (http://www.coralcdn.org/), even simpler to "install" and has a very interesting architecture (I encourage anyone interested in P2P stuff to take a look at their papers).
Keeping your server behind some form of CDN also has the advantage that you keep control over the actual storage of your data.