Full stack web dev.
Studying FP web development approaches, while helping Mission Bit create paths to programming for underserved public school kids.
Previously @ Gradescope.
CMSs (e.g Joomla, Drupal, Wordpress) typically load the content from some kind of data store, inject it into a template, and serve the dynamically-generated page. You need the web server to do this work -- in other words, it's serving the output of an application rather than static files.
If you do the fetching/injecting on the page itself, in JS, you can have the server just send static files. (But they'll rely on an HTTP API to provide content, so there's technically still a back-end.) See:
It's also possible to have a fully static site that is generated ahead of time from a CMS-like architecture: en.wikipedia.org/wiki/Movable_Type
Such sites are blazing fast and truly need no back end. But they require the developer to generate and deploy a new set of files every time any of the content changes.
I mostly run smaller WP on sites from 0-30K uniques a day ish. <1s load on unprimed cache. 50K+ pages no prob. It would be to replace that.
My site is currently well below 1s with the counter removed (with cache on, partial optimization, WIP).
If I make a 50K page static site with constantly updating content (I like every page to change content to some degree as often as possible) & 50+ new pages (posts) a day will there be any issues with constant redeployment (I am assuming that is all handled)?
I don't care much about dev difficulties, mostly about scale/speed of actual publishing as that is 90% of energy (web performance is ok).
Full stack web dev.
Studying FP web development approaches, while helping Mission Bit create paths to programming for underserved public school kids.
Previously @ Gradescope.
If I make a 50K page static site with constantly updating content (I like every page to change content to some degree as often as possible) & 50+ new pages (posts) a day will there be any issues with constant redeployment (I am assuming that is all handled)?
I'm unfortunately not the right person to answer that well. I did use movable type in the bad old days, but not for anything of the scale you're describing.
But my guess is that static site generation wouldn't be a great fit for this -- not having to rebuild and redeploy frequently is a big advantage of CMSs. And using a page cache will give you most of the benefits of serving static pages.
...but if you're below 1s then I'd guess you're aware of what they bring up.
And in general, I'd definitely recommend profiling, to whatever extent is possible. I know there are plugins for profiling WP page rendering performance. If you can do something on the db side as well, that'd probably cover everything except the speed of the host itself.
scale/speed of actual publishing
If by that you mean the publishing workflow makes you jump through hoops, maybe it's worth looking into adding something like wordpress.org/plugins/json-api/ and writing a tool that lets you publish from the command line.
Do you have a website to share with a <1s page load? And any pointers for Wordpress? My sites only get in the 80s with Google's Page Insights tool and I'm also looking for ways to speed it up. :-)
I love static site generators, Elm, JavaScript and building things for the web.
In my previous life I was a working classical pianist. I try to combine music and programming when I can.
The difference is do you want to compile your site upfront front flat files (ie markdown, templates,...) or hold you data in a database like wordpress?
This has a lot of benefits like
better security (no backend or database to be hacked)
simple deployment (git push to publish with netlify)
cheaper to host (don't need php and/or some caching service)
Not to argue (from ignorance), but these seem like pretty low value reasons:
Sec is not a CMS thing (I get the db, but that's not really a big concern).
Deployment is a dev, not consumer thing. I deploy nonstop.
Hosting is cheap.
These are all dev benefits, which I don't really care about in the sense that: Do they improve traffic/UI/SEO/performance etc.
I choose based on the consumer experience/value with less regard for what the devs want (think of it like race cars vs regular).
Trying to figure out if it is better or just another tech trend that is no real improvement. Not really into small, trafficless sites. Seems a lot like the old days (static HTML file can stay for 20 yrs, that part is nice).
I love static site generators, Elm, JavaScript and building things for the web.
In my previous life I was a working classical pianist. I try to combine music and programming when I can.
No that's fine. No offense taken. Your points are valid.
For me, it really depends on the use case. For my own blog, being able to write markdown and deploy the flat files is a consumer thing when I write my own blog.
I like to program my blog as I blog and this way has given me a lot of flexibility.
If I want to move to a different blog platform I don't have to export from a database.
If I were setting up a blog for a customer, wordpress is still a good choice. For business websites wordpress seems overkill to me, so I use an ssg.
I just listed some of the reasons I have switched. Again for security, I got tired of staying on top of updating and securing my wordpress site. If I didn't touch my WP blog for several months it would get hacked.
I hope this gives you some more context on my comment.
From a user/viewer perspective, CMSs are often a lot slower than static. In fact, it's hard for me to see how they wouldn't be. My main concern is my user/viewer/reader, so unless we need functionality only possible in a CMS, I go with a static. FWIW, since you can do a lot of simple JS in a static web page, it's super easy to add Disqus, etc., for commenting and some other basic functionality.
Thanks Ryan, I like the sound of it in a number of scenarios. Pretty agnostic on this stuff overall.
In general a cms is spitting out a static cached page mostly so they can be fast but most devs throw some Gfont embed, ga, a few plugins, db bloat & suddenly the site is garbage.
My site is not fully optimized, but is usually <1s. WP (& php) has a bunch of advanced stuff that i'd have to code already. There are many annoying {solvable} CMS related issues.
I am not using very many 3rd party services anymore unless requested as there is no need for a handful of players to have control of everything. My users are being respected (mostly) & I am enjoying working on my stuff under those circumstances (this is not that relevant to the sitegen but it's where growth is).
What static gen do you use? (I will make some things to see how it suits my needs).
Also, I've seen CMSs and I've seen CMSs. They're not all the same.
For static gen, I've only used Jekyll, actually. It's a bit of a new world to me.
For CMSs, my favorites are Joomla!, Drupal, Ghost (oooooh, love it), and a little known one called BrightSpot. There are some lightweight ones that are also pretty good, if simpler.
Sec is not a CMS thing (I get the db, but that's not really a big concern).
I don't know what this means, but I recently had to fix up a Wordpress blog which had been hacked because of an insecure plugin. There were ads inserted as posts, and links hijacked to go to really bad sites. The administrator didn't notice for quite a while because the malware was smart enough not to appear if you were logged in as a user.
It's hard to imagine that happening to a static site. With a static site there are just files on a server. What is there to hack? Only the SSH connection to the server itself.
Yeah, my first one was an injected encrypted footer links with useragent & tore down a set of top ranking sites (long time ago). I didn't mean to dismiss CMS sec, it's a pain.
"Sec is not a CMS thing" just meant: Lots of the serious stuff (beyond annoying defacing) is social engineering & lower down the stack. The CMS or db is one part of many.
Not to be contentious but what is a "static site" vs a cms?
CMSs (e.g Joomla, Drupal, Wordpress) typically load the content from some kind of data store, inject it into a template, and serve the dynamically-generated page. You need the web server to do this work -- in other words, it's serving the output of an application rather than static files.
If you do the fetching/injecting on the page itself, in JS, you can have the server just send static files. (But they'll rely on an HTTP API to provide content, so there's technically still a back-end.) See:
It's also possible to have a fully static site that is generated ahead of time from a CMS-like architecture: en.wikipedia.org/wiki/Movable_Type
Such sites are blazing fast and truly need no back end. But they require the developer to generate and deploy a new set of files every time any of the content changes.
Understood, good explanation thanks.
I mostly run smaller WP on sites from 0-30K uniques a day ish. <1s load on unprimed cache. 50K+ pages no prob. It would be to replace that.
My site is currently well below 1s with the counter removed (with cache on, partial optimization, WIP).
If I make a 50K page static site with constantly updating content (I like every page to change content to some degree as often as possible) & 50+ new pages (posts) a day will there be any issues with constant redeployment (I am assuming that is all handled)?
I don't care much about dev difficulties, mostly about scale/speed of actual publishing as that is 90% of energy (web performance is ok).
Cool
I'm unfortunately not the right person to answer that well. I did use movable type in the bad old days, but not for anything of the scale you're describing.
But my guess is that static site generation wouldn't be a great fit for this -- not having to rebuild and redeploy frequently is a big advantage of CMSs. And using a page cache will give you most of the benefits of serving static pages.
This article, if you haven't seen it, looks pretty comprehensive: wpcurve.com/wordpress-speed/
...but if you're below 1s then I'd guess you're aware of what they bring up.
And in general, I'd definitely recommend profiling, to whatever extent is possible. I know there are plugins for profiling WP page rendering performance. If you can do something on the db side as well, that'd probably cover everything except the speed of the host itself.
If by that you mean the publishing workflow makes you jump through hoops, maybe it's worth looking into adding something like wordpress.org/plugins/json-api/ and writing a tool that lets you publish from the command line.
For someone who claims to not know much, this is interesting reading & ideas (not just for me). Appreciate it. 👍
I have fast host/front end & the db stuff I can deal with. API UI is interesting.
Workflow goal is to make WP publish more like twitter but higher quality xdevice.
Do you have a website to share with a <1s page load? And any pointers for Wordpress? My sites only get in the 80s with Google's Page Insights tool and I'm also looking for ways to speed it up. :-)
The difference is do you want to compile your site upfront front flat files (ie markdown, templates,...) or hold you data in a database like wordpress?
This has a lot of benefits like
git pushto publish with netlify)Thanks Ryan,
Not to argue (from ignorance), but these seem like pretty low value reasons:
These are all dev benefits, which I don't really care about in the sense that: Do they improve traffic/UI/SEO/performance etc.
I choose based on the consumer experience/value with less regard for what the devs want (think of it like race cars vs regular).
Trying to figure out if it is better or just another tech trend that is no real improvement. Not really into small, trafficless sites. Seems a lot like the old days (static HTML file can stay for 20 yrs, that part is nice).
No that's fine. No offense taken. Your points are valid.
For me, it really depends on the use case. For my own blog, being able to write markdown and deploy the flat files is a consumer thing when I write my own blog.
I like to program my blog as I blog and this way has given me a lot of flexibility.
If I want to move to a different blog platform I don't have to export from a database.
As far as small tragficcless sites, smashing magazine produces their whole site this way. smashingmagazine.com/2017/03/a-lit...
If I were setting up a blog for a customer, wordpress is still a good choice. For business websites wordpress seems overkill to me, so I use an ssg.
I just listed some of the reasons I have switched. Again for security, I got tired of staying on top of updating and securing my wordpress site. If I didn't touch my WP blog for several months it would get hacked.
I hope this gives you some more context on my comment.
Ryan,
This answers all my questions as well as possible tbh.
Dev heavy markup, injection, intrusion are good reasons (I was wondering if it was worth losing the breadth of options). I'll try a couple.
Appreciate the explanation, thanks.
From a user/viewer perspective, CMSs are often a lot slower than static. In fact, it's hard for me to see how they wouldn't be. My main concern is my user/viewer/reader, so unless we need functionality only possible in a CMS, I go with a static. FWIW, since you can do a lot of simple JS in a static web page, it's super easy to add Disqus, etc., for commenting and some other basic functionality.
Thanks Ryan, I like the sound of it in a number of scenarios. Pretty agnostic on this stuff overall.
In general a cms is spitting out a static cached page mostly so they can be fast but most devs throw some Gfont embed, ga, a few plugins, db bloat & suddenly the site is garbage.
My site is not fully optimized, but is usually <1s. WP (& php) has a bunch of advanced stuff that i'd have to code already. There are many annoying {solvable} CMS related issues.
I am not using very many 3rd party services anymore unless requested as there is no need for a handful of players to have control of everything. My users are being respected (mostly) & I am enjoying working on my stuff under those circumstances (this is not that relevant to the sitegen but it's where growth is).
What static gen do you use? (I will make some things to see how it suits my needs).
Yeah, absolutely.
Also, I've seen CMSs and I've seen CMSs. They're not all the same.
For static gen, I've only used Jekyll, actually. It's a bit of a new world to me.
For CMSs, my favorites are Joomla!, Drupal, Ghost (oooooh, love it), and a little known one called BrightSpot. There are some lightweight ones that are also pretty good, if simpler.
I don't know what this means, but I recently had to fix up a Wordpress blog which had been hacked because of an insecure plugin. There were ads inserted as posts, and links hijacked to go to really bad sites. The administrator didn't notice for quite a while because the malware was smart enough not to appear if you were logged in as a user.
It's hard to imagine that happening to a static site. With a static site there are just files on a server. What is there to hack? Only the SSH connection to the server itself.
Yeah, my first one was an injected encrypted footer links with useragent & tore down a set of top ranking sites (long time ago). I didn't mean to dismiss CMS sec, it's a pain.
"Sec is not a CMS thing" just meant: Lots of the serious stuff (beyond annoying defacing) is social engineering & lower down the stack. The CMS or db is one part of many.
This question and the answers to it are extremely useful. Thanks for this brilliant discussion.