There are lots of static site generators (SSGs) out there these days, coupled to a lot of different headless content management systems (CMSs), using various development frameworks, running with various templating languages, and making life seem a lot more complicated than it probably needs to be. But you may still be scratching your head and asking, what is a static site generator?
With that in mind, this article aims to explain in a more general way what’s going on in a typical SSG these days. Because even though there are a lot of different names flying about, there are some key general elements and processes that are common pretty much across the board.
What Is a Static Site Generator?
Let’s start at the beginning: a static site generator (SSG) takes some “source” files that describe a website and, processing those files, creates the files needed for the website that was described.
I think of it as basically a compiler. You have some source code, the compiler runs, and out comes a binary executable that you can run on your computer. I realize that, in the current web world, developers work largely with interpreted languages, not compiled ones, but bear with me.
The SSG, in other words, is an application that reads some files, processes their contents, and then writes some new files, with the new files constituting a web site. This process is the heart of the matter, the place where the magic happens, and so on.
The Website
The SSG creates a website and that website is a website that you could (sort of) say has no moving parts. This is why people talk about “static” sites.
Now, the simplest website is one that is made up entirely of a single HTML file. This is nothing more than a text file with some special “markup” tags and it is very fast and very simple for a web server to send off to a browser that has requested the page across the internet.
All the web server has to do is grab that one file, stick some delivery headers on it, and send it on its way. This can happen with almost instantaneous speed if the internet connections involved are fast ones.
This speed is one of the key benefits of static sites, even though they aren’t as simple as a single HTML file. Generally speaking, though, they are nothing more than HTML files, CSS (style) sheets, possibly the occasional javascript file, and whatever images are displayed on the site. They are all 100% ready to deliver whenever they are requested, with no additional processing needed.
Why the Build?
The reason the world needs SSGs is because there are generally lots of pages of content that need to go into a website. We don’t really want to have to create HTML versions of all the content—and there’s a pretty simple reason why this is.
I’m old enough to have coded a couple early commercial sites on the web. Every page on those sites was individually created in HTML. If there was a menu at the top of the page, it was there it was copied from some other page and pasted there. If you wanted the currently selected menu item to be highlighted, you had to make a version of the menu with the selected element set in reverse text (or whatever the treatment was) that was specific to the page you were working on.
A site with a hundred copies of the same header, except for which selections are highlighted, is a mistake waiting to be copied and pasted. There are typically lots of repeated elements on web content pages (footers, anyone? Sidebars?), and hand management is a fool’s errand.
The world could have moved to SSGs then and there, twenty years ago, but what happened instead was that web servers became integrated with databases. In this scenario, the server would assemble the elements of each requested page as it was requested. The header would be connected to the newly fetched main page content, then the footer retrieved and tacked on, then the final page shipped off to the user.
This is still how most web sites work and such web sites are said to be dynamic.
An SSG does the same assembly that a dynamic web server might do, but it does it before the website is served to users—it does the page creation in advance.
Thus…
So, an SSG needs to get the headers, get the sidebars, get the footers. It needs to get the main bits of content for each page, along with the titles and subtitles, anything that needs to be on each page.
So there’s the actual generator, the SSG, and there’s some kind of store for page content, and there’s some way of describing what each kind of generic page will look like in HTML.
In a simple example, there’s the SSG called Eleventy. It takes page content (in the simplest setup) in more-or-less plain text files called “Markdown files.” It arranges the content from those files with guidance from a templating system called Nunjucks. A diagram might look like this:
In the case of Gatsby, the SSG is Gatsby, the simplest data source is the same markdown that Eleventy uses, and the templating is handled by functionality that comes with the React JavaScript framework. Same diagram, different labels.
Jekyll is yet another SSG, in this case written in Ruby. Again, the simple way to feed content data to it is once again Markdown, and the templates for how the content fits on the final HTML pages is a system called Liquid.
If you take a look at the ridiculously long list of SSGs maintained by Netlify at https://jamstack.org/generators/, you’ll see that each listing mentions the language the SSG uses and which template systems it supports. Looping back to Eleventy for a second, it actually supports several other templating languages beyond Nunjucks: Liquid, Handlebars, Mustache, EJS, Haml, Pug, and JavaScript template literals.
Beyond Markdown
If you want to capture the content of a blog entry, Markdown is a nice, clean way to do it. SSGs tend to support it as the entry-point content data source. It was sufficiently prevalent in the early days of SSGs that when Netlify was looking for some kind of term to encapsulate all the different approaches to SSGs being created and coined the term “jamstack,” the M stood for Markdown. (The J stood for JavaScript and the A stood for APIs. A person could argue pretty convincingly that none of these three selections were accurate, but it did at least spell something recognizable with “Jam.”)
There are lots of other options beyond Markdown, including using the same sorts of databases that dynamic web sites use. This isn’t the article to dive into all those options.
There’s also more involved than just plain-old HTML. There need to be CSS files, frequently there need to be JavaScript libraries to handle user interface elements that click and move and so on within the client browser window, and the SSGs that use the React framework play some pretty fancy tricks with swapping components in and out on the fly at the client browser.
But the basic setup is that the SSG is an application that takes content data from sources like markdown files or headless CMS services (such as Contently and Sanity and Ghost and lots of others), uses templates to create the layout of the output pages, and when it’s all said and done, creates a static site.
Of course, there are some other bits that you may be curious about beyond this simplest reduction of what makes an SSG what it is. For one thing, you may be wondering about the API part of the original JAMstack term (these days, Jamstack is used predominantly as a term that doesn’t specifically stand for anything, but instead refers to the entire ecosystem). That’s coming up shortly.
In WordPress, you can get lots of potential looks and (to some extent) behaviors just by installing a “WordPress Theme” and activating it within the admin panel of your WordPress instance. This site, PeakZebra, for instance, is running the Extra theme, made by ElegantThemes. It’s based on their Divi page-builder franchise, with page builders being a discussion for another day. There are endless WordPress themes, but there are not really static site generator themes–not in the same sense.
I’m running Extra on this site, but I could just as well have run Hestia or TwentyTwenty or GrilledFish as the theme for this site (OK, actually, I made up GrilledFish… But then I looked just to make sure there wasn’t one, and of course there was). There are, at least in theory, some 30,000+ themes (you’ll see much higher estimates, but this number comes from Scepter, which made a noble effort to weed out unmaintained and unused themes).
This is a smart setup. It makes it easy to go from something that has a bunch of “cards” on the front page to something that has more “flowing” dynamics. If you are a dentist and you want a site that “looks like a dentist site” (I have only a vague idea of what that look might be), you are quite certain to find a theme that has calm, serious fonts, a “safe-feeling” color scheme, and so on.
Themes Play By The Rules
This only works because the things that themes can change are (mostly) completely pre-defined. You’d think that’d make all WordPress sites look vaguely the same, but in fact there are lots of things that it’s completely kosher to change, so the range of possible designs is enormous.
In a slightly confusing (but practical) move, WordPress allows themes to use a “functions.php” file, which can contain absolutely whatever functions a theme designer wants to build in. Anything you can do in a plugin, you could at least in theory accomplish by leveraging the functions.php option.
One of the more confusing things to wrap one’s head around in the WordPress ecosystem is that—even as WordPress creator Matt Mullenweg keeps pushing the notion that open-source software is the best way to make software, and even though everything that swims in the WordPress ocean has to honor WordPress’s free software licensing, there’s a huge trade in “premium” themes, for which you’ll chunk out, typically, $50 to $75 for use on one web site.
Premium or not, each WordPress theme consists of a subdirectory in the “themes” folder, a “style.css” file, and a “functions.php” file. Generally, there are also a number of “template files” and a bunch of other optional stuff as well. The TwentyTwentyone theme (which comes as part of the base WordPress install these days) has a directory listing that looks like this:
If you download a theme, all these files come bundled up in a zip file that WordPress expands into a folder with the same name as the theme.
Meanwhile, In the SSG World…
If you’ve used React, particularly in the context of a static site framework like Gatsby for Next.js, you’ve dealt with components that render pages or parts of pages. That’s exactly what’s going on here, just in PHP rather than JavaScript.
It’s different, though, in this respect: You can’t download a new Gatsby theme and just turn it on (Gatsby has a “themes” concept, but it’s more for supporting particularly functionalities—like a blog that uses Contentful as its headless CMS). If you were going to do this with Gatsby, then you’d need to be using a common, agreed-upon manifestation of Gatsby that understands, for starters, that there might be more than one theme installed at this site, that themes are in a specific folder, that the active theme is, say, named in the Gatsby config file, that elements used in page and partial templates are named using conventions that theme designers can rely on and use, and so on.
The setup here would be different in another way: the style components would be incorporated when the site was rebuilt, not at run time. But that doesn’t really change anything.
What this presumes is a general-purpose set of rules for, say, Gatsby sites that are essentially blog sites (to take one obvious example) about what CSS files are in play and how blog listing versus single-entry page scenarios are built.
Particularly given that WordPress provides a model to work from (and one can imagine an improvement or two), this is doable. I even wonder if it could be sorted out in such a way that this sort of theming might work on more than one static site generator framework. This is one thing that I’m looking at as a PeakZebra project and I’ll keep you posted. If you’re laboring in the same fields, please be in touch.
[dropcap]G[/dropcap]oogle earlier pre-announced a May 2021 shift to using what it calls “Core Web Vitals” (CWV) metrics as part of its ranking algorithm. The pandemic has pushed this plan out to an unknown future date–Google has said it will provide six months further notice before the change is made. This report offers an initial explanation of the three metrics involved, how they relate to other Google page experience metrics, and how to strategize for what will likely be a noticeable effect on rankings when CWV enters the ranking algorithm.
[dropcap]T[/dropcap]he fact that Google is changing its ranking algorithm is not, in itself, cause for alarm. Google changes its process—what gets measured, how it’s weighted, and so on—all the time. Generally there are several hundred (mostly trivial) changes in a year.
CWV promises to be one of Google’s bigger deal changes. How much bigger is worth contemplating. We’ll get to that.
One indication that this one matters to Google (besides the lengthy advance notice) is that CWV is an addition to a group of metrics that Google puts into the category of Page Experience. How does a user feel about the experience of using a particular page?
As you can imagine, Google wants to send you to results that you are happy you were sent to. So, if you asked a question, they’d like to send you to a page that answers your question (or, better yet, they’d like to answer your question right there on the search results page). Beyond the content of the page, though, lots of things figure into how you experience the page you’ve just been sent to.
If the page takes forever to load in your browser, odds are you won’t even stick around to see the page. But speed comes in more than one flavor, and CWV tries to get at a few elements that are important in how you perceive the speed of a page.
[dropcap]C[/dropcap]ore Web Vitals (CWV) is a set of three measurements Google has said it will add to the group of measurements it uses when deciding which results you see first when you perform a search on Google. The decision to add these metrics was announced months in advance (something Google only very rarely does), was originally slated for May 2021, but has been pandemic postponed. Google has said it will provide six months of warning before pulling the switch and, as I write this, that hasn’t been given yet. So, perhaps late fall 2021.
Google says there are three “core” essentials.
The first measurement is how long it takes for the largest piece visible on the page in your browser (what’s “below” your window doesn’t matter until you scroll down to it) to appear. This is the “Largest Contentful Paint” (LCP) and it’s really just a proxy measurement. If you can get the biggest piece displayed in a hurry, probably the overall sense the user gets is that the page loaded in a hurry.
How you can tell a page is performing in LCP measurements is something we’ll return to later—it takes some tooling.
Measurement two is how long the user has to stare at the browser window before it will react to their input. How long before they can click on a button and something actually happens. This is First Input Delay (FID).
Making things slightly more complicated, there are testing situations where Google uses a metric called Total Blocking Time (TBT) as a proxy for FID. For the moment, let’s not split hairs. What Google is trying to get at is how long before the page is sufficiently loaded that you can actually use it.
The third measurement is largely targeting the mobile experience and focuses on the weird jittery effect you get when a page has started to paint, but some big piece drops into place and the page is repainted in a way that makes everything shift position all at once. You’ve started to read the page, but now everything shifts up a paragraph. It’s kind of hard to explain, but everyone with a smart phone knows what this is. Google measures it with Cumulative Layout Shift (CLS). Not just “does it jump,” but how much overall does it jump before it settles down and stays put.
[dropcap]G[/dropcap]oogle provides several tools that let you see specific scores for CWV, but probably the quickest way to get a general sense of how a given page is performing is to use the Pagespeed Insights tool. You paste in the URL of the page you’re interested in, it chews on things for a moment or two, and then two color wheels pop up, most likely sporting the red or orange rings that indicate a less-than-fabulous score.
You’re generally going to want more detail than this score gives you, though. You’ll want to know what element is the one Google is counting as the largest when it times the Largest Contentful Paint, to give one example.
Getting the info is as simple as going to the page you’re interested in using the Chrome browser, then toggling yourself into the developer tools pane (use the keystroke combination Ctrl+shift+i, which I think maybe stands for “inspection”).
Here’s the developer tools console in action, after recording the load of a page on PeakZebra. Following the timeline in the middle of the display is a great reminder that a lot of things are going on under the hood of a modern browser.
[dropcap]I[/dropcap]n the “Timings” bar in the top pane of the image above, the LCP flag marks the spot in the timeline when the Largest Contentful Paint was rendered in the viewport (in this case, at 2747.9 ms).
Total Blocking Time (which will become important to us because it’s a proxy for First Input Delay) is recorded (as an estimate, though it’s given in hundredths of a millisecond, which I’ll concede is puzzling) just above the lower (console) pane of the tool display. In this case, it’s 654.52ms. But as for what it actually is? Google’s process looks at the timeline for tasks that took longer than 50ms. For each, the number of milliseconds that the task ran after the 50ms mark is added together. The “long tasks” (as they are called) are highlighted in the timeline by red hashmarks and a red triangle in the upper right of the offending taskbar. Google wants you under 300 milliseconds, so this page kind of sucks.
Cumulative Layout Shift is marked in the timeline with red bars where Chrome noticed things shifting. If you click on the red bar, the part of the page that is shifting will be highlighted for you. The damage that is done to your score is a special Google concoction that looks at the number of frames in which elements are shifting and the distance in pixels that they shift.
This is a place where things can go screwy in a hurry. And elements may be shifting in ways that you are completely unaware of. On the page I’ve been looking at here, for example, I noticed that the title of the page is rendered first in the font it’s supposed to be in, then in a default font that the theme I’m using (this is in WordPress) overwrites, then rerenders as the font it’s supposed to be. The change in font means the title is longer in the default, so that it runs over to the next line, which shifts that segment of the page, though just for the shortest blink of an eye:
Everything returns to normal a millisecond later and, at least on a reasonably peppy system, this repaint is completely undetectable. The metric that matters to Google here is really more how it performs on a mobile device, but the change is undetectable there as well.
At present, the CLS metric is less weighted in Google’s algorithms and the fact that they’re still sorting out how to detect what actually impacts the experience is presumably the reason why. They’ll get better at measuring this as the year progresses and it seems pretty likely that at some point the weighting will shift to make CLS equally important.
Here’s a meh score for a page on the WordPress version of PeakZebra. In truth, this score isn’t actually that bad and you’ll see considerably worse scores on many perfectly normal WordPress pages. This shows the desktop score; the mobile score is (and usually is) considerably worse.
[dropcap]I[/dropcap]f you’re running on a typical WordPress, Drupal, or similarly architected web publishing framework, your CWV scores at present are probably not all that great. You are right to wonder whether fixing the ills of your website are worth the trouble. Will your rankings really suffer all that much if you don’t bother? What if everybody just decided to ignore this stuff?
The only true answer to this at the current moment is: nobody outside of Google has any idea whether this matters much or at all. We’ll find out when and if there are huge reorderings on search engine results pages (SERPs).
That said, if it figures in the rankings in any modestly significant way, you can bet that organizations that actively tune for SEO will tune for CWV. In any “all things equal” situation, their page is going to do better than the organization that didn’t bother. I’m operating mostly on an experienced hunch here, but I think there will be some serious shifts as a result, particularly in the world of B2B and technical vendor pages.
There are four ways a company might opt to deal with CWV (aside from just ignoring it), listed here in decreasing order of hassle:
Relaunch on a more performant platform
Make substantial adjustments to the existing platform (really paying attention to tuning a WordPress site, for example)
Use the existing website as a headless CMS for a statically generated front end to the site
Create groups of new pages on the existing domain that run in tandem to the existing site, these pages being ones that matter to the organization’s content and SEO strategy
Is it worth the trouble to, say, relaunch on a new platform? Hard to say at this point, and maybe not, but if you were going to relaunch something anyway, now is the time to make sure that whatever you relaunch with has screamingly good performance when it comes to CWV.
Otherwise, your choice will come down to the specifics of your site and what it does. We can dig into the virtues and mechanics of the various options in future articles, but it’s certainly worth taking a few moments now to run a representative sample of your website’s pages against these CWV metrics.
Today was the first day of a two-day Jam.Dev event online. The event had a lot to offer people who are presently trying to sort out the lay of the land in the static site generator ecosystem.
The Azure Take on Static
Shmuela Jacobs, cloud developer advocate at Microsoft, walked through the Static Web App service that is currently in developer preview on the Azure platform. The introduction of the service makes perfect sense, of course, given the success of companies like Netlify and Vercel in providing production build and hosting services. The basic structure of the new service looks a lot like Netlify in terms of what it does, but doesn’t have nearly as friendly a UI, at least not at this point. Part of this no doubt lies in the higher degree of complexity that large sites on Azure tend to bring to their cloud game.
Like other options in the space, Azure basis the static service on repositories stored in github, such that when a new commit is made to the application’s repository, Azure runs the build and, assuming a successful build, deploys the application to the Azure CDN. You set up a config file that sets up things like environment variables that your app needs in the production environment.
Shmuela Jacobs, cloud developer advocate at Microsoft
By and large, this look at Azure’s entry into the jamstack ecosystem (beyond the already existent capability to host Docker images of jamstack servers) was perhaps the most interesting part of the day.
Stephanie Eckles, a software engineer at Microsoft, gave a full-throated and interesting walkthrough of the 11ty static site generator. She built a basic site as a demo that ran in 3 minutes, complete with a timer running in the screen. It definitely underscored the simplicity and direct approach of 11ty compared to static sites built with React or Vue frameworks running on client pages. A panel that followed brought together Sara Drasner, vp of developer experience at Netlify, Phil Hawksworth, developer experience engineer at Netlify, and Gift Egwuenu, frontend developer at Passionate People. These are all heavy hitters in the jamstack world, but the panel never quite gelled and thus wandered a bit.
Quicktime
A series of quick, ten-minute talks covered a lot of ground, including an overview of Google’s Lightspeed metrics given by freelance developer Henri Helvetica. There’s no doubt that Helvetica knows whereof he speaks—he’s a frequent speaker at events and turns up involved in lots of projects—but the lightning format didn’t serve him well when it comes to Google metrics, which get deep and detailed in a hurry.
Tamas Piros, developer advocate at Cloudinary, talked about image management (and, in particular, distributing tailored images from the edges of the net. The takeaway here was a link to a site he put together for comparing various approaches in real time. It’s at know-your-media.dev. Miriam Schwab, CEO and cofounder of Strattic, talked through the basic scenarios for making WordPress a backend for various kinds of static site, as well as making a compelling argument for why this is important in a world that has become very accustomed to WordPress and capable of using it to turn out tailored sites very quickly.
Miriam Schwab, CEO and cofounder of Strattic
The final two talks of the day focused on jamstack approaches to ecommerce, though largely it was a matter of showing that it was indeed possible to do. Flor Antara of Zipwhip worked through four approaches to selling on static-based sites.
Option one, Antara said, was the non-jamstack Shopify-like third-party service. This part of the talk had me looking for the option to turn the playback speed to 1.5x. This can be a problem with live events. Option two was integration with an API, which she pointed out could be fairly time consuming to set up. Option 3 was what Antara called “Add-on” ecommerce.
Snipcart, etc
In a quick demo, she demonstrated the Square “Buy Link”, the second the PayPal equivalent, the third was Shopify buy button, and the final was SnipCart, which is, not to split hairs, actually an API approach, just one that happens to use GraphQL. These are all good ways to handle basic sales capabilities, but somewhat glossed over in the presentation was the fact that if you go with, say, a PayPal buy button, then you have to handle anything that would typically fall into tasks that collectively we call a shopping cart. In other words, you have to have static pages that describe the products. You don’t get any integration with inventory data unless you code it yourself. If you want to offer, say, three for the price of two bundling, you’ve got to track how many things have been ordered and whether the relevant items quality for the discount.
It _is_ possible to support some shopping cart options into a PayPal scenario, but basically you are handing off to PayPal, just like you might hand off to any other third-party ecommerce store, as per Antara’s Option One. But SnipCart is a different animal in that it supports GraphQL. As a technicality, this is an API interface, too, but it’s particularly well geared to jamstack frameworks that use GraphQL. Antara gave a walkthrough of how this could be added to her flat HTML product pages, but arguably what’s valuable here is the ability to use templated product pages that query SnipCart for data elements that are dropped into the page.
The conclusion of the talk, that SnipCart is the clean, jam-savvy way to do this, is spot on. Since this was a demo-based talk, SnipCart was the only vendor discussed as a headless eCommerce vendor, but needless to say, there are others, such as commercetools, and even a headless variant of Shopify.
We’ll cover day two of Jam.Dev in a separate article.
WordPress Capabilities that JAMstack Really Should Steal
The precursor of WordPress was called Cafelog, and there’s a sort of architectural fragment left from it that carbon dates its demise occurring sometime in 2004. That fossil page makes clear what the defining idea of b2 (as Cafelog’s underlying software was called) was all about: “pages are generated dynamically from the MySQL database, so no clumsy ‘rebuilding’ is involved.”
Tying a web site’s content presentation to a database made it possible, first, to offer a console where administrators could add and arrange blog articles quite separately from the engine used to deliver those pages. Secondly, the shift made it obvious that, as long as the administrative interface was there, a large selection of tools could be aggregated there in a single view. WordPress carried forward this dynamic connection to a database when Matt Mullenweg and Mike Little forked b2’s code in 2003. In the new blog realm, web pages were produced on the fly from database entries; those database entries got there by way of a backend application. This continues to be the basic operating order of WordPress.
JAMstack Page Speed
Plugins came along in 2004, themes in 2005. Plugins meant that site builders could add prepackaged functionality without having to alter the core blog engine. The addition of dozens of “hooks” several months later meant that developers of plugins could tie functions in their code to specific moments in the sequence WordPress used to serve up each page.
The basic pattern for a blog (and later, any content-centric site) emerged as a generally flawless installation of the free WordPress software, picking a theme so to overlay a specific design look, then choosing and seamlessly installing plugins to provide capabilities that weren’t built into the core. There are some 55 thousand plugins by now, most of them overlooked and unused, but a sufficient number that there are widely distributed plugins to add all sorts of capabilities, including paid subscriptions, custom page (data) formats, specialized reporting, caching of pages and graphics, third-party comment services, anti-spam protections, and so on. Kinsta maintains a page of statistics where the growth of plugins can be tracked.
In a similar vein, Scepter Marketing tracks themes, reporting that there are 211 companies that sell themes (and of course there are multitudes of free themes), with an overall count of 31,000 or so themes.
While WordPress was becoming the dominant web Content Management System (CMS), a great deal of the web that wasn’t running on WordPress had moved to JavaScript. On the back end, where WordPress was written in the PHP programming language, there was a growing wave of JavaScript programmers using Node.js. On the client side of things, JavaScript morphed into several key libraries for creating UI components. There are a lot of libraries, but there’s rarely discussion of them without mention of React.
The chatter nowadays is about JAMstack, which is to say applications that are built with JavaScript, APIs, and Markup. With JAMstack, development has circled back to the days before b2 and its MySQL-constructed pages: once again we seek sites that serve flat HTML pages, often with JavaScript included inline to provide the bells and whistles that web application users have become accustomed to. In this world, a web site creation tool is something that takes your supply of page data (which might or might not be stored in a database) and generates a flat HTML web site.
Static Site Generators (SSGs) essentially take web page inputs and compile a static collection of web pages. In the case of SSGs like Gatsbyjs, the tactic is to deliver an HTML page with enough JavaScript capability embedded in it that it can prefetch data from the server and display interactive components as if they were new pages, when in fact only part of the page is being replaced.
The static approach is attractive, in large measure, because it is, by default, blindingly fast. If you’re determined, you can screw up an SSG site so that it’s as slow as a sloth, but that’s not typically how it goes.
There are lots of ways to go at this basic JAMstack scenario, lots of frameworks and libraries. Sorting them out is part of the brief of PeakZebra.com, but in this particular report let’s lump them together and notice that they tend to be offered to the world as a good way to move from the pre-owned Chevy Tahoe of WordPress to the Maserati that JAMstack can provide.
JAMstack Page Speed
JAMstack proponents tend to be heavily focused on its page delivery speed, with a lot of emphasis placed on how valuable this raw speed is going to be when Google starts using Core Web Vitals as a ranking factor, something they’ve said they’ll do in May 2021.
And it’s blinding fast, done right, pretty much no matter which flavor of JAMstack you decide to use, whether Gatsbyjs or Next.js or 11ty, or whatever. Not only is it as fast as flat HTML pages, but in some instances, it’s actually faster, because it uses JavaScript in embedded pages to preload content before it’s clicked on, displaying that content on the current page, rather than preforming a full page reload. It can be shocking how fast pages load in this kind of arrangement.
WordPress defenders rightly point out that simply using a good caching caching plugin or service can make previously served pages into cached static pages, ready for instantaneous delivery. A well-tuned WordPress installation on a fast server, using a well configured caching capability is capable of impressive performance, however dowdy WordPress in general may seem. Nitropack.io has a particularly interesting spin on this—reading through the explanation on their site is worth your while.
WordPress Is a Little Clunky, Yup
Now, I’m writing this report for publication (at least initially) on a WordPress site, and it will become clear momentarily that I think there’s a great deal to admire in WordPress. That said, though, there really are some things about WordPress that feel a bit creaky.
First and foremost, if you measure a representative sample of WordPress pages around the Web for page delivery speed, you’ll get a lot of mediocre scores—no need to take my word for this, by the way. Have a look, for instance, at this broad investigation of different kinds of sites in the wild and how they performed.
Then, there’s the aforementioned PHP language and what seems to be a widespread perception that WordPress isn’t well optimized internally. I don’t especially buy the argument that an outdated language is what makes WordPress clunky. Yes, most of the front-end design world is using JavaScript and associated libraries (reactjs in particular). Heck, even WordPress is written in JavaScript when it comes to new, client-side features.
But while it’s fashionable to paint PHP as outdated, there’s simply not much substance in that claim. Viewed from a certain distance, C, PHP, Java, JavaScript, TypeScript and no doubt some others that I’m missing here all look pretty much like the C language, just without C’s myriad potential pitfalls. PHP used to be a rather old-school language in terms of support for object-oriented programming and things like closure, but pretty much all the bells and whistles that are enjoyed among the JavaScript cognoscenti have been available in PHP for some several years.
PHP may not inherently degrade WordPress, but one thing that does make it hard to build in extra client-side functionality is that the environment is not merely PHP, but is PHP running inside a framework that is trying pretty hard to completely hide the PHP from you. Perhaps you want to toss a PHP variable into a blog entry. That’s not going to happen in the direct way that PHP was expressly written to facilitate.
In unfettered PHP, you can just embed a variable right in the middle of some text in an HTML page:
<? echo $myHelloMessage; ?>
But in WordPress you cannot embed PHP in your page content. It’s not allowed—and that’s for good reasons, too. Embedding PHP in your page data is an invitation for less experienced programmers (and non-programmers) to get into deep security trouble.
PHP Inside WordPress
You can’t embed PHP, and furthermore the WordPress environment aggressively influences how things get done in code. And serious coding work can get messy. I won’t delve into details here, in part because I won’t claim to have complete mastery of them at this point, but the way you have to tie into “the Loop” at different points in the cycle can make for some seriously disjointed code.
There’s also a lot of ways you can hook into WordPress internals. That’s good in terms of flexibility, but can mean that all sorts of clutter gets hooked in. Things can get bloated and slow in ways that you wouldn’t necessarily anticipate as you add this or that plugin.
Aren’t Dynamic Pages a Good Thing?
Defending WordPress from the claim that it’s clunky also requires that we return to that core truth of WordPress: the fact that there’s a database running in the background. The casual argument in favor of static sites is that they are, well, static.
And yes, having a database means that pages get put together by way of several database queries, at least now and then when the cache system has a miss. But precisely because of that cache system, these pages are going to tend to get stored for re-use, so they are essentially static pages in many instances. Where the database really does add time to the equation is when something dynamic is done that caters to a specific user’s situation or preferences. If a page has to be put together for each user, well, there’s no caching that’s going to help that (um, actually that’s not true, but the details don’t matter here). If the page has to be put together dynamically each time it’s served, then it’s going to be slow.
A framework like Gatsby claims to have the upper hand by using static pages, but of course that’s not quite comparing apples to apples. If a JAMstack site needs to personalize pages on a per user basis, it may do so by way of API calls to a third-party services, but make no mistake, this is still just referencing a database on the back end. In the customized-page scenario, there’s no inherent JAMstack speed advantage. And, frankly, this is a fairly common scenario.
Maybe the database thing doesn’t make WordPress clunkier than JAMstack, but some other aspects of the WordPress ecosystem do produce a certain amount of rattle when you head out for highway driving. WordPress bolted on responsive site design after the fact, with the result that delivery of mobile pages is nearly always worse that delivery of desktop pages. In a world that’s drifting toward mobile first, this is a problem (and it’s a bigger people than most people want to talk about—lots of current websites are utterly miserable performers when viewed on a smartphone). Adding special capabilities to your WordPress is easy when a good plugin is already available, but if you’re trying to build your own application, getting it done with a mishmash of configuration settings, existing plugins, and your own PHP plugin code can make for an inefficient mess that’s hellish to return to later when modifications are needed. Adding a plugin that does absolutely nothing at all drags down page delivery times by a handful of milliseconds.
And even though caching cures a lot of ills, the fact remains that when you turn Google’s pagespeed tests loose on WordPress sites, they tend to produce sluggish results. You might argue that Core Web Vitals aren’t a good measure, but the truth on the ground is that these are the metrics that Google is going to factor into its search result rankings come May.
The upshot here is that more websites are going to built using SSGs in the coming year, if only for the gain in CWV scores. But whether your preferred JAMstack is Gatsby or Next or something else, turning the page and moving to an SSG approach will instantly make you aware of the many wonderful things you’re accustomed to and that have gone missing as WordPress is abandoned behind you.
My purpose here is not to prove that WordPress is outdated or a second-rate CMS, but to point out how many things are right about it. For those moving toward SSG deployments, these are key features and capabilities that need to be carried over to the JAMstack ecosystem as quickly as possible. Otherwise, the vast adoption that WordPress has enjoyed won’t be visited on JAMstack.
Call me crazy, but I think it’s a decent editor, and the administrative capabilities of WordPress are impressive.
The WordPress Theme Approach
You can change the look of a WordPress site in dramatic ways just by changing the theme you are using. For the most part, you can change indiscriminately from one theme to another at the click of a button, and the site still functions as you’d expect. This works because most of WordPress’s use focuses on fairly traditional pages. A page is exactly what you think it is, while a post is a page that has a more clearly delineated chronological relationship to other posts (it’s a blog entry, in other words).
I’ll talk about Gatsby on the SSG side of the coin: that’s the framework I currently know the most about. Gatsby, as it happens, has themes. But it doesn’t have themes in the same way that WordPress does, and the difference is one that matters.
In WordPress, a “theme” is roughly synonymous with a “design.” When you consider using a particular theme, you are mostly thinking about what your site will look like (there are also sometimes extra features built into themes, but even those elements tend to be about the look of the site).
Want a site with a huge picture and just a few words on the home page? Then you might want the “Twenty Seventeen” theme.
Or maybe you want something that looks like a busy magazine site:
You can tailor the look of a theme because, within the administrative console, there’s an interface for changing things like typefaces, accent colors, menu styles, and so on (depending on which configuration options a theme offers).
This works in large measure because, to date, WordPress has tended to be centered on “bloglike” deployments. A theme is about look and feel, or as WordPress.org puts it: “A WordPress Theme is a collection of files that work together to produce a graphical interface with an underlying unifying design for a website.”
Gatsby, on the other hand, says that its themes “are plugins that include a gatsby-config.js file and add pre-configured functionality, data sourcing, and/or UI code to Gatsby sites. You can think of Gatsby themes as separate Gatsby sites that can be put together…” The aim is different, though UI is a factor, but Gatsby themes don’t allow you to “reskin” your Gatsby site on demand.
All that said, I should note that there’s a shift underway in WordPress to themes that function as “builders,” meaning they are drag-and-drop design tools (Elementor and Divi, to take two examples) that let you design whatever you want (within the constraints of WordPress’s blog-like view of the universe). These are practically frameworks in and of themselves, and not surprisingly there are now themes that are only meaningful when deployed at a site that uses the underlying base theme.
In response to the rise of the Divis and Elementors of the WordPress world, WordPress itself has shifted to a “blocks” interface that treats elements on a page in a way that would be draggable in a simpler, kinder world. What’s great about this “Gutenberg” version of the content editor is that it enables you to embed elements (interactive graphs, say) that aren’t part of the normal fare of blog entries.
Themes in Gatsby (as they currently exist) certainly can control the design of the site, and in principle could do the same things that a WordPress theme does, but they install from a developer interface, not from a user interface. You can change them on the fly in principle, but honestly, I wouldn’t bet my career on a swap-out going seamlessly at this point.
Not every Gatsby user is going to want a WP-style theme for their site, but it’s in large part the ability to have a good-looking design out of the box that has made WordPress adoption so widespread. Right now, themes in Gatsby are a developer’s tool. But an enormous number of sites in the world are a home page, an about page, some product description pages, and a blog. These sites need a theme capability that lets them reskin with professionally designed layouts on demand.
People are thinking about this, to be sure. There are several hundred SSG themes collected at JAMstackthemes.dev, for example. Also of interest: https://gatsbywpthemes.com/. It seems clear enough to me that some kind of ecosystem will develop around SSG framework themes, but it certainly remains to be seen how these themes will be managed. (Please be in touch if you’re up to something in this arena.)
[Added 1/8/21] Another good looking Gatsby theme we ran across of late is Flat Magazine. Technically, this isn’t a theme in Gatsby parlance, but is instead a “starter.” There are important distinctions lurking in the difference between “theme” and “starter”: with a starter, you are setting up the look and feel forever, as far as using starters is concerned. With themes, you could overlay a set of new configurations, design elements, and functionality over the top of (or alongside) the existing site.[/end addition]
So: steal the themes, even if they have to be called something else so that they aren’t confused with the existing Gatsby theme capability.
Plugins
Since WordPress doesn’t want developers mucking around in the core code, at least not for one-off customizations, they’ve made it simple to plug in code. If you’re a developer, it’s not too horrible messy to work with. If you’re a user, you can search for, download, and install a plugin from the administrator console. Once you’ve clicked the box to activate the installed plugin, you can tweak it’s configurations from within the back end as well.
Gatsby has plugins, too. But they are more akin to developer libraries. While this sort of library is powerful and enables developers to do things like hook up a Gatsby front end to a headless WordPress deployment, what’s missing here is the “load-and-tweak” simplicity of WordPress. The lack of a plug-and-play variety of plugins won’t matter to developers who are building from scratch. But it will kill the small-business agencies that today build sites predominantly atop WordPress.
Maybe it should be a third-party service with an API, just like headless CMS, but in some way or another, we need those WordPress features to find their way into the JAMstack universe.
The API Thing
With JAMstack, the backend for the blog primarily shifts to a third-party headless CMS provider like Contentful or Sanity.io (see the New World Map for a longer list). A report on the current options will be out on this site in February, but for the moment let’s just say that while moving to a headless CMS is appealing in lots of ways, and in particular it gives you an editing and publishing administrative interface that can have some great bells and whistles, but it doesn’t give you an integrated back-end console.
There are lots of capabilities that the JAMstack world has to date presumed would be likewise handled by third-party API services. Again, see the New World Map for vendors who provide identity, reader comments, edge function support, search, and e-commerce options. We’ll be working through these various subcategories over the next few months.
Using APIs to handle the heavy lifting can offer great benefits, but there’s an appealing and comprehensive reach to the administrative interface on WordPress.
Before you write that comment you’re forming in your mind right now…I am well aware that you can run WordPress as a backend CMS for a Gatsby front end. It’s a great solution, attractive enough that even the Gatsby site uses it, but it still doesn’t give you a console where you can control front end theme selection, or users, or all that good stuff that WordPress has built in over the years.
What needs to be on the JAMstack console is something where WordPress’s experience can be borrowed, but updated. The layout and menuing of the backend can almost certainly improve on the quirks of WordPress (where many UI sins have accumulated).
In Sum
JAMstack should heat up the competition between frameworks like Gatsby and the massive incumbent that is WordPress. In particular, it should shamelessly steal:
WordPress-style themes
WordPress-style plugins
Some kind of option for a native back-end administrative interface
These are all things that JAMstack platforms need to either steal outright or modify and improve. There are interesting arguments for using CMS as a service, but there’s something to be said for the way that you get the CMS in WordPress as part of an administrative console that also lets you control themes, plugins, and a number of user options in a coherent, fuss-free way. If WordPress publishers are going to be coaxed away to JAMstack platforms anytime soon, someone needs to create a way to carry forward the features that grew the WordPress ecosystem to its current gargantuan size.
WordPress has a huge—genuinely huge—number of users who are not looking for edge-case solutions. They want a blog and a plugin that lets them sell some custom hoodies. They want a plugin that lets customers book appointments. And yes, many of them want top-notch SEO performance, which is going to mean fast, performant sites, but there’s a lot of room out there right now for smart companies to build on the ease of use that the WordPress universe is used to.
It’s a minor thing, but somehow I never until just today knew that when you name variables using hyphens between words, like some-variable or count-of-chickens, it’s called kebab case. And, duh, of course it is.
I did already know, just so the record is clear, about camel case and snake case.
It sounds like a developer’s version of rock, paper, scissors: kebab skewers snake, snake bites camel case, camel case crushes kebab. I’m not sure how to differentiate the hand signals for kebab and snake. Programming is hard.
One thing I recently heard for the first time (because I’m not really all that immersed in the current world of WordPress development) is that the Gutenberg block system that new versions of WordPress use is implemented in JavaScript. And it would appear that all the client-side work on WordPress is in JavaScript where possible.
This makes a lot of sense, frankly, only because the dominant language for browser experience tweaking has long been JavaScript and all the leading libraries and frameworks for client-side apps and UX are written with it.
This leads us to the question of how to throw some JavaScript of our own into web pages on our WordPress sites. Not having needed to do anything like this in a WordPress environment (if ever… since I’ve tended to use WordPress on content publishing sites, I’ve never needed to roll up my sleeves like that.
Three ways to add JavaScript to WordPress
There’s more than one way to add your JavaScript, as you might already have suspected. What everybody adds in any discussion of this sort of thing is that there’s also a fourth way, the Way of Darkness, where you actually start mucking about in native WordPress files. This is a bad business you should avoid, if for no other reason than that it’s going to get overwritten by a WordPress update at some point. So, having set the Way of Darkness aside, that leaves us three ways.
Just plunking it in
You’ll also find warnings about this approach, which is simply to use the newfangled block editor system to throw in a block of HTML. In that block, you write HTML, which includes throwing in a <SCRIPT> tag, a bunch of JavaScript, and then the </SCRIPT> tag.
Depending on what you’re trying to get done, I really fail to see what the problem is with doing it this way. It seems to work fine, it’s not going to bollocks up other JavaScript code running as part of WordPress (because you’re going to be careful about naming any variables you create in what is likely a global scope (I’m not actually quite sure that the code that runs in a page is running in an overall global scope, but I can’t think of any reason why it wouldn’t be).
This is the approach I’m using right now to create an on-page tool that calculates potential ROI for keyword SEO campaigns. It’s self contained, any data that might need to be stored from one session to the next will be stored somewhere other than WordPress (written to the localStorage object, for instance), and, hey, it seems to work OK. Maybe I’ll learn firsthand why this is a bad idea, or someone will kindly comment with an explanation.
Even in this age of contagion, I had a situation where it really made sense to fly out on a morning and back that evening. I decided to take the iPad instead of the notebook, and while I was at it, I decided to take a look at what the possibilities for coding on iPad these days.
There are certainly more code options than there used to be (and I suspect we’ll see more and more as Apple slowly overlaps the iOS and MacOS domains. In any case, the tool that seemed closest to the Gatsbyjs stuff I’ve been doing lately was the Play.js app. There are other JavaScript app options and they may be great. Generally, they are free where Play.js costs five bucks. But Play.js is really pretty fascinating.
As you can see in the screen shot above (a view of some sample code that comes with the app), the editor looks a lot like Visual Studio Code, which makes it immediately look friendly (assuming VSC is what you’re using). The app builds in a fairly impressive port of node.js as well as npm, along with support for react native.
I’ve got some catching up to do on react native. I get the basic idea: it lets you write an iOS app in reactjs. So that’s cool, but how does that work? And I thought you still had to have a Mac to build an iOS app, so I guess what Play.js is doing is actually more of an emulated environment?
If nothing else, it looks like Play.js provides a pretty decent editor that looks like VSC. Plus it has support for basic git functions, so you can work with code stored in online repositories. Nice.
What a brilliant thing it was to come up with “hello, world!”, which I think can be attributed to Brian Kernighan. He used the phrase in an example program internal to his lab in 1974, then he and Ritchie put it on the world map in 1978 with their introduction to the C computer language.
When I started programming in 1986 or so, the book was still a perfectly good way to fundamentally learn about C, though in fact I started in Pascal, using Borland’s Turbo Pascal because it was cheap and it was so freaking cool (at the time, at the time).
To me, having cut my teeth as a professional programmer in C, it’s fascinating to see how many of the prominent languages today look and act a lot like C, especially if you allow yourself to range forward to C++ in order to pick up object-oriented capabilities. As I write this, the PeakZebra site is running on WordPress, which is built using PHP. It probably really should be running on a JAMstack platform, but for the moment I am the proverbial bull in JAMstack’s ecosystem, at least as far as learning and trying things out are concerned. I’d be breaking the site pretty much every day. WordPress, on the other hand, I can basically set up and leave alone, except for adding new content.
The logical place to go from here is the About page, or possibly the Services page, if you’re already confident that PeakZebra can help you.