Author: Robert

  • The Core Web Vitals Report

    [et_pb_section fb_built=”1″ _builder_version=”4.8.1″ _module_preset=”default” custom_padding=”||7px|||”][et_pb_row column_structure=”3_5,2_5″ _builder_version=”4.8.1″ _module_preset=”default” min_height=”711px” custom_margin=”|auto|0px|auto||” custom_padding=”||0px|||”][et_pb_column type=”3_5″ _builder_version=”4.8.1″ _module_preset=”default”][et_pb_text module_id=”section1″ _builder_version=”4.8.2″ _module_preset=”default” custom_padding=”9px|||||”]

    Google’s Core Web Vitals: Executive summary

    [/et_pb_text][et_pb_text admin_label=”#section1″ _builder_version=”4.8.2″ _module_preset=”default” text_font_size=”19px” custom_padding=”5px|12px|9px|12px|false|false” border_radii=”on|1px|1px|1px|1px” border_width_all=”1px” box_shadow_style=”preset2″]

    [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.

    [/et_pb_text][et_pb_text admin_label=”#section2″ module_id=”section2″ _builder_version=”4.8.2″ _module_preset=”default” text_font_size=”19px” custom_padding=”||1px|||”]

    [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.

     

    [/et_pb_text][et_pb_text module_id=”section3″ _builder_version=”4.8.2″ _module_preset=”default”]

    The Core Web Vitals: What Are They?

    [/et_pb_text][/et_pb_column][et_pb_column type=”2_5″ _builder_version=”4.8.1″ _module_preset=”default”][et_pb_toggle title=”Toc” _builder_version=”4.8.2″ _module_preset=”default” inline_fonts=”Encode Sans Expanded”]

    Executive Summary

    Algorithm Changes

    What Are the Core Web Vitals?
    How to Get CWV Scores
    Do CWV Scores Matter?
    CWV Strategies

    [/et_pb_toggle][/et_pb_column][/et_pb_row][/et_pb_section][et_pb_section fb_built=”1″ _builder_version=”4.8.2″ _module_preset=”default” custom_padding=”0px|||||”][et_pb_row column_structure=”3_5,2_5″ _builder_version=”4.8.2″ _module_preset=”default”][et_pb_column type=”3_5″ _builder_version=”4.8.2″ _module_preset=”default”][et_pb_text _builder_version=”4.8.2″ _module_preset=”default” text_font_size=”19px”]

    [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.

    [/et_pb_text][/et_pb_column][et_pb_column type=”2_5″ _builder_version=”4.8.2″ _module_preset=”default”][et_pb_text _builder_version=”4.8.2″ _module_preset=”default” custom_margin=”167px|||0px|false|false” custom_padding=”14px|20px|14px|20px|false|false” custom_css_main_element=”padding: 10|| ” border_width_all=”3px” border_color_all=”#7CDA24″ border_style_all=”groove” box_shadow_style=”preset2″]

    THE “OTHER” WEB ESSENTIALS

    As mentioned, there are three “core” essentials. But there are four other metrics that Google considers “essential”:

    • Being “mobile friendly”
    • Being safe to browse
    • Using HTTPS
    • Avoiding Intrusive Interstitial ads and notices.

    You’ll notice that this is more a list of do’s and don’ts. You’re either using HTTPS or you’re not, for instance. 

     

    [/et_pb_text][/et_pb_column][/et_pb_row][et_pb_row column_structure=”3_5,2_5″ _builder_version=”4.8.2″ _module_preset=”default” locked=”off”][et_pb_column type=”3_5″ _builder_version=”4.8.2″ _module_preset=”default”][et_pb_text module_id=”section4″ _builder_version=”4.8.2″ _module_preset=”default”]

    How to “See” the CWV Measurements

    [/et_pb_text][et_pb_text _builder_version=”4.8.2″ _module_preset=”default” text_font_size=”19px”]

    [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”).

    [/et_pb_text][et_pb_image src=”https://peakzebra.com/wp-content/uploads/2021/02/inspection-console.png” title_text=”inspection-console” _builder_version=”4.8.2″ _module_preset=”default”][/et_pb_image][et_pb_text _builder_version=”4.8.2″ _module_preset=”default”]

    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.

    [/et_pb_text][et_pb_text _builder_version=”4.8.2″ _module_preset=”default” text_font_size=”19px”]

     

    [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:

    [/et_pb_text][et_pb_image src=”https://peakzebra.com/wp-content/uploads/2021/02/text-paint-example-1.png” title_text=”text-paint-example” _builder_version=”4.8.2″ _module_preset=”default”][/et_pb_image][et_pb_text _builder_version=”4.8.2″ _module_preset=”default” text_font_size=”19px”]

    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.

    [/et_pb_text][/et_pb_column][et_pb_column type=”2_5″ _builder_version=”4.8.2″ _module_preset=”default”][et_pb_image src=”https://peakzebra.com/wp-content/uploads/2021/02/low-pagespeed-performance.png” title_text=”low-pagespeed-performance” _builder_version=”4.8.2″ _module_preset=”default”][/et_pb_image][et_pb_text _builder_version=”4.8.2″ _module_preset=”default”]

    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. 

    [/et_pb_text][/et_pb_column][/et_pb_row][et_pb_row column_structure=”3_5,2_5″ _builder_version=”4.8.2″ _module_preset=”default”][et_pb_column type=”3_5″ _builder_version=”4.8.2″ _module_preset=”default”][et_pb_text module_id=”section5″ _builder_version=”4.8.2″ _module_preset=”default”]

    Do CWV Scores Matter?

    [/et_pb_text][/et_pb_column][et_pb_column type=”2_5″ _builder_version=”4.8.2″ _module_preset=”default”][/et_pb_column][/et_pb_row][et_pb_row column_structure=”3_5,2_5″ _builder_version=”4.8.2″ _module_preset=”default”][et_pb_column type=”3_5″ _builder_version=”4.8.2″ _module_preset=”default”][et_pb_text _builder_version=”4.8.2″ _module_preset=”default” text_font_size=”19px”]

    [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.

    [/et_pb_text][et_pb_text module_id=”section6″ _builder_version=”4.8.2″ _module_preset=”default”]

    CWV Strategies

    [/et_pb_text][et_pb_text _builder_version=”4.8.2″ _module_preset=”default” text_font_size=”19px”]

    There are four ways a company might opt to deal with CWV (aside from just ignoring it), listed here in decreasing order of hassle:

    1. Relaunch on a more performant platform
    2. Make substantial adjustments to the existing platform (really paying attention to tuning a WordPress site, for example)
    3. Use the existing website as a headless CMS for a statically generated front end to the site
    4. 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

    [/et_pb_text][/et_pb_column][et_pb_column type=”2_5″ _builder_version=”4.8.2″ _module_preset=”default”][/et_pb_column][/et_pb_row][et_pb_row _builder_version=”4.8.2″ _module_preset=”default”][et_pb_column type=”4_4″ _builder_version=”4.8.2″ _module_preset=”default”][et_pb_text module_id=”section6″ _builder_version=”4.8.2″ _module_preset=”default”]

    How to Choose

    [/et_pb_text][et_pb_text _builder_version=”4.8.2″ _module_preset=”default” text_font_size=”19px”]

    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.

      [/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section][et_pb_section fb_built=”1″ fullwidth=”on” _builder_version=”4.8.2″ _module_preset=”default”][/et_pb_section]

    1. TheJam.dev Day Two: Looks at Angular+Jamstack, Github Founder’s Take

      Key among the events at the second day of the Jam.Dev online event was the concluding “fireside chat” with RedwoodJS creator and Github founder Tom Preston-Warner, in which Preston-Warner imagined a more full-stack edge architecture, something he is working on RedwoodJS to create. (Coverage of day one is here.)

      Tom Preson-Warner

      Moderator Brian Rinaldi, developer advocate at StepZen, asked Preston-Warner what he thinks of the “Jamstack” terminology. “The term jamstack was coined by the founders of netlify and I got involved with them very early in their journey when I think it was just the two of them, Preston-Warner said. “The term jamstack was something we talked about a great deal at some bars in the Dogpatch in San Francisco when they were just setting out and trying to define what Netlify was going to be and where they were going and how do you talk about the ideas behind what we now know as the jamstack, without a term. At the time, before we had the term jamstack, it was all static site generators, but When you say a static site, this does not  necessarily convey that you’re going to use javascript to pull in third-party APIs, or do dynamic things, or pull in external content and kind of mix it all together. So ‘static site generation’ did not do the job.  … . So that’s where jamstack really came from, and I thought it was great.

      “It always makes me think of Ajax when google maps first came out and it blew everyone’s mind because you could drag this map around it will just load stuff in automatically. And this concept that Ajax became, it was out there, all the pieces were there but nobody thought about it and no one could really leverage it because no one could talk about it until Ajax was coined. And now this concept this more complex concept had a name and everyone could talk about how they were going to do Ajax. And to me jamstack is the same kind of a thing.”

      He went on to note that “the industry needed a name for what the jamstack is, this collection of technologies that allows you to have better security, faster sites, all of these characteristics that jamstack has are now wrapped up in one word that you can talk to your colleagues about, talk to your boss about, that Netlify can talk to their customers about.”  

      Rinaldi asked what RedwoodJS is providing that Jamstack isn’t providing yet. “I love Jamstack in the way that most people think about it today,” Preston-Warner said. “But I think it can go even further. There’s a lot of potential in what you can do in a serverless environment now and if you mix that with some of the ideas around static site generation and third-party apis, or even just javascript on the front end and the client talking to something, some kind of api on the backend. I think that’s cool, but what I want to do is create a custom website completely from scratch and probably not even use a lot of the third-party apis. I might pick and choose a few here and there, but I want to create a custom site that is doing a lot of its own business logic. So, being involved in Netlify, when they came out with their function support where you can write the body of a lambda function in a file and they’ll pick it up and deploy it to AWS Lambda for you. That was kind of a revelation for me in what could be possible using this stack, because nobody wants to use AWS’s ways to get your code into AWS Lambda. It’s just not pleasant.

      “You can push all of these things out as far to the edge as you can, and you can get a level of architectural simplicity and scalability for a tremendously small amount of effort. Thinking about that made me want to find a framework that was going to let me do that.”  

      Jamgular

      Another session concerned with somewhat alternative frameworks walked through a mix of Jamstack and Angular. The presenter, Netlify Developer Experience Engineer Tara Manicsic called the combination “Jamgular.” What was nice about the session was that it featured Tara on a highwire of live demonstration and viewers got a good view into what had to happen, complete with lots of detail, in the actual work of building and configuring an Angular project. The flip-side was that, as tends to happen with live coding, various things didn’t go as expected and, well, it was like real programming.

      A less-known detail that came forward was that Angular has built-in support for generating a folder containing the static output for a project, so even though Angular doesn’t come up as frequently in jamstack conversation, it’s definitely in the hunt.

      Manicsic was asked by an attendee why she’d mentioned in passing that redirects were important. The point here was that a user can request something using a URL that is redirected at the CDN edge and sent to an edge handler (a function running serverlessly at the CDN). The callback is made so that it includes data about the edge node where the call originated, so that geographically specific actions can be taken.

      Other Talks

      Gatsby Software Engineer Obinna Ekwuno gave a more philosophical talk about when it’s good to simplify architectures and when too much gets lost in the simplification. While he pointed to some interesting tensions between having to learn lots of frameworks and libraries to find one’s way through the jamstack world (and even more as the line between front-end and back-end blurs), it seemed like we are doomed to live with those complexities for the foreseeable future.

      Agility CMS President Joel Varty tackled what is surely one of the major questions that pops up around Jamstack front ends: where “everything else” goes – things like user registration, authentication, restricted access, user-generated-content, commerce and search. His talk met with lots of approval in the conference chat stream, insofar as it created a lot of clarity around the big picture of jamstack’s many architectural elements.

      Jamstack, Varty said, plays mind games with us to make it hard to know, especially when first getting acquainted, to know where a given snippet of code will actually be executed.

      Tessa Mero’s walkthrough of the Cloudinary (where she is a developer advocate) options for media accessibility was interesting, in that Cloudinary does indeed do some interesting tricks like using AI to automatically generate ALT tag text for images, checking photos for potential problems when viewed by color-blind users, and providing machine-generated captioning for videos. She also pointed to several open resources for testing accessibility issues.

      Ohad Eder-Pressman

      Ohad Eder-Pressman, cofounder and ceo of Stackbit, presented two open tools that Stackbit has created for spinning up various flavors of jamstack site. A site called Jamstack.new let’s you pick a theme, a static-site generator, and a headless store for content, then creates an instance nearly instantaneously. The company also maintains jamstackthemes.dev, which is a repository for, you guessed it, themes that can be used with various frameworks.

    2. TheJam.dev 2021 kicks off with azure and ecommerce

      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.

    3. It’s Raining Headless CMS Systems

      There are two competing dynamics in the world of JAMstack. First, there’s the idea that JAMstack is the approach of choice for creating lots of different applications, beginning with marketing sites that are essentially just five pages (about, contact, products, solutions, resources) and continuing on to blogs, and from there to sites that are interactive, consult data through APIs, and so on. In other words, static is the best current choice for making websites. The second dynamic is that, even for those basic marketing sites, decoupling the content management is a good thing.

      Building a static site draws most of what ends up live on the website from source code files and, in the simplest approaches, in markdown files. You can build a perfectly snazzy blog just by writing all your entries in the markdown format and storing them in the right directory.

      If all you do is put your content into markdown files, you’ve still effectively decoupled the content from the presentation, because you could copy that directory full of blog entries to some other system and present it using some completely different application.

      The CMS-as-a-Service Upside

      It’s clear why this would be attractive compared to, say, WordPress (the defacto competitor to JAMstack as a whole). In WordPress, you use the site itself (albeit in an administrator console interface) to create and edit your content. Normally, you then serve it up using the WordPress application and, should you decide you don’t like WordPress anymore, you are more or less stuck. (As an aside I’m obligated to say that it’s now easily possible to just use the back end of WordPress and then use something else—Gatsbyjs, for example—to serve up the files to website visitors.)

      With a headless CMS, you can theoretically change horses midstream by changing which horses are presenting your web pages. In practice, there just aren’t a lot of sites around that have actually done this—changing from one static site generator (SSG) to another and running the new setup without interruption using data from a third-party headless CMS tool. As long as we’re basically talking about blogs, there’s no reason to think this isn’t readily done, but in some ways it fixes a problem that site builders may not be entirely aware that they have.

      It may be increasingly valuable to change presentation (and delivery channel—let’s not forget that this CMS may additionally serve up tweets and Instagram posts) and keep the existing CMS, but one thing that’s immediately attractive is that headless CMSs can offer high-quality user experiences for content creators using the system, plus it’s possible in most of the current platforms to customize things like approval workflows. There’s plenty of room now for anyone who can provide a fantastic content creation and workflow experience. For whatever reason, traditional CMS UX has been something of a backwater. WordPress is probably as good as it ever gets in the old school, and while it’s capable of getting the job done these days, it’s certainly not flawless. If you doubt this, just ask a typical WordPress user how to set a paragraph within a post with a hanging indent. (Hint: there’s not actually an option for this, though you can do it if you tweak the CSS).

      Headless CMS has into its own and you can get every flavor you can imagine, except the one where you run WordPress on the front and a different headless CMS on the back (probably someone’s working on this, though it’s not clear to me what the gain from it would be).

      There are lots—probably too many—variants on the headless CMS idea, most of them recent startups but a handful of them dating back a half dozen years or so. The list assembled for this article was at 71 companies when this was prepared. The current list is over in our New World Map.

      PeakZebra will take a look at all the options that seem to have some measure of traction, but not in this article. We’ll tackle of them in turn, beginning with those that have early market share and influence.

      In this article, we’ll look at the concept and capabilities that most or all of the contendors provide, with details and screenshots coming from Contentful, which is the most widely deployed of the headless CMSs. It’s not an endorsement of Contentful in particular, just a reflection of how this service is representative.

      JAMstack and GraphQL

      To be clear, when people talk about a “modern web stack” in current parlance, they are usually referring to a site written in a JavaScript framework like Gatsbyjs or Nextjs, with content retrieved by way of a GraphQL interface. This setup is appealing for lots of reasons, but it’s not the only way to get things done and plenty of options out there support RESTful APIs.

      An early draft of this report tried to sort between offerings that support GraphQL, but it became apparent that practically every one of the services we were looking at were adding support for GraphQL so fast that it was pointless to make the distinction. The problem for organizations looking to adopt a headless CMS strategy is going to be having too many choices. Most of them seem likely to use GraphQL, which will still leave them having to choose between dozens of CMS services.

      Contentful is one of the founding companies in this space, having released it’s first beta in 2013. The focus then was on delivering content from one source to multiple targets and frameworks. Obviously, that remains part of the headless CMS value proposition, but the emphasis has shifted over the years towards fitting into the JAMstack ecosystem. According to a TechCrunch article back in June (when Contentful raised $80 million in Series E venture funding), 28% of the Fortune 500 use Contentful. This kind of penetration makes them a heavy hitter in this space.

      In terms of how the service works: once you’ve established an account (and they have a free account option for dabblers and zebras), you create one or more “spaces,” within which you create content types. From a developer point of view, this is the equivalent of defining a “struct” variable type in C or, roughly, of creating a class in JavaScript. From the database point of view, it’s the equivalent of defining the fields in a table (and, of course, that’s what’s going on behind the scenes in Contentful).

      For the straight-up, no-frills blog application, you’ll create a content type that spells out the data that’s stored in a post. You’ll want a title, might want to be able to store a user-specified slug name, no doubt will want a publishing date, and will need a bunch of text for the body of the entry.

      An important difference between defining a database table and creating content types in Contentful is that content types may wind up defining something that you’d do with multiple tables in a SQL database. In the example workspace that Contentful gins up for you when you create an account, you have a set of content types for a learning site, with lessons and courses that include lessons, and so on. In this scheme, there’s a content type for Categories, containing two fields, as shown in Contentful’s interface here:

      The JSON preview tab here shows you what you’ll get if you do a meta query to get a description of what I think of as the table definition (though content types don’t talk about it that way). The sidebar tab is interesting: it lets you configure what widgets will populate the right rail when your users are editing this type of content. The entry editors tab lets you replace the editor itself.

      So the page where users will enter and edit your content has a main window for the editing and a right sidebar, like this:

      It looks, in fact, rather like the back end of WordPress. I’m not sure whether that’s because this is the way this sort of editor page tends to look, or whether it’s because Contentful made a conscious choice to make something WordPress refugees would be familiar with (which would have been, honestly, a smart product design choice).

      Two things to note here:

      1. Remember that you can define lots of different content types and arbitrarily change out the tools available as well as the editor used for those types. There’s enormous underlying flexibility, in other words.
      2. Funnily, this actually looks like what’s now called the “Classic” WordPress interface. The new Gutenberg UI in WordPress is based on the idea of serially adding blocks of various types. Gutenberg, in turn, is arguably running a bit behind the design principles of the popular add-on theme/editing tools in the WordPress ecosystem, like Divi and Elementor. They have both the concept of blocks and support for (within limits) dragging and dropping them. Furthermore, they are WYSIWYG. My point here is that Contentful, along with lots of other headless CMSs, has a fairly blog-centric notion of how to build content.

      To summarize, a headless CMS lets developers set up specific types of content (the rough equivalent, in WordPress, of creating new page template types) and provides a non-developer, end-user interface for creating and editing instances of those content types. Differentiation among the services revolves mostly around support for things like role-based access and editorial workflows.

      Following along on this “blog-centric” idea, note that non-CMS online services like Coda, which offer a sort of document-meets-spreadsheet authoring environment, may provide a model for what the CMS will become. Here’s a sample page I edited by dragging objects like the embedded table around the page:

      Coda seems to understand the possibility here—they allow you to present Coda documents as web pages. And yes, there’s an API if you want developer access to those pages (RESTful, not GraphQL). You can see how the headless CMS and the “document+formulas” will begin to overlap in interesting ways.

      Pricing for headless CMS varies widely, but seems to tend toward $500/month for business-level use. Most have free options for getting your feet wet or supporting personal blogs and the like.

      The Down Side?

      Based on numerous reviews on services like G2, discussions on Discord channels, and tweets, there certainly are some potential pitfalls in the headless CMS model:

      1. Some see the learning curve as steep. I suspect that’s not true if you’re coming from immersion in React, but is probably absolutely on the mark if you’re coming into the JAMstack world cold. Even if developers have to pick up some new skills in, say, GraphQL, once they’ve got the basics sorted out, the approach is no harder (and is arguably easier) than using RESTful approaches or old-school SDKs.
      2. Speaking of SDKs, some headless CMSs offer them and they sometimes don’t match the functionality of the GraphQL interface (or the interface of other SDKs for other channels within the same service). This may be the sticking point for adoption of CMSs that can’t get this problem sorted.
      3. Some services make it awkward to use one content type within another as content is created. In other words, this isn’t an issue where it’s hard to have a content type defined as containing or referring to another content type as developers create the type. Rather, it’s reportedly hard or involves too many steps to embed a video type (to take one example) inside a text blog post. This is actually one area where the block approach of the WordPress Gutenberg editor works with a satisfying simplicity.
      4. The CMS service becomes separate cost. Whether this ultimately matters is a function of whether you could previously get by with a no-frills WordPress site running on a third-party hosting service. In that scenario, you get a lot accomplished with one monthly fee. Once you get fancier than that, though, the costs may be allocated differently, but are likely to be the same or lower overall.

      If you are a JAMstack purist, your approach is not just to have a headless CMS, but to have all manner of capabilities delivered by way API connections to third-party services. The difference between headless CMS and all the other possibilities (such as search functions, comment providers, authorization services and so on) is that the other services are invoked from the live, running site. The headless CMS, though, is a sort of integrated development environment (IDE) for content, used to create what is essentially the content source code for a site. My view is that the “pre-compile” nature of the headless CMS means that some interesting potential capabilities that could be provided, but I’ll save these for a subsequent post.

      You can’t swing a JavaScript developer without hitting a headless CMS. It’s heartening how the churn of creativity has presented so many takes on almost all the pieces of the JAMstack ecosystem. But probably some kind of rough consensus about actual JAMstack stacks will need to emerge before more complex systems can be routine achievements. What’s interesting about the CMS, though, is that it has a fairly large interface component and, as such, might serve as a center point for building future web presences. That is, it may not be so much about choosing your SSG wisely, but choosing your content system wisely and then hanging other capabilities around it. In any case, businesses should almost certainly spend more time choosing the CMS service than they currently do, because what your CMS will do will, more than ever, determine what your website can do.

    4. CMS Market Share

      To hear some people talk, you’d think WordPress was in some danger of being rapidly overtaken by JAMstack alternatives (though it’s not entirely clear that JAMstack is the right thing to call them). It’s good self-discipline to periodically take a look at the relative CMS market share among current competitors, where it’s true that WordPress is losing market share over the past six months, and furthermore true that Gatsbyjs (the leader among the more recognized JAMstack frameworks) has gained market share in that same time period. But, to paraphrase an old saying, WordPress has lost more sites in a month than Gatsbyjs has ever had.

      According to whatcms.org, WordPress has 335 of the top 1000 Alexa-ranked sites. That’s down 6.37 percent from mid July 2020. Overall, WordPress has 30% of the CMS market share on the web.

      Gatsbyjs, in contrast, has .146 percent market share. Less than two-tenths of a percent. It runs on 49 of the top 1000 Alexa-ranked sites, which is up 33% over six months. The trend is definitely up, but to my earlier point, a bad run for WordPress may drop them 7% overall, but that relatively small loss for WordPress is 16 times more sites than Gatsbyjs has at all.

      Top CMS market share holders at whatCMS

      Jekyll comes in at a quarter of the penetration of Gatsby. Other JAMstack frameworks don’t turn up at all in WhatCMS’s tracking.

      It’s all kind of humbling, from a “modern web stack” point of view.

      On the other hand, things change quickly, stunningly quickly, in the internet world. It was only twelve years ago that CompuServe, the predominant “online service” prior to widespread public internet adoption, was shuttered. I suspect that the current generation of JavaScript developers mostly have no idea what CompuServe was (whatever it was, being online cost seven bucks an hour back then, at 28k baud).

      Things change quickly, and it certainly feels like the underlying assumptions of web applications have shifted. Websites are coded using CSS-enhancing template tools, clients are React while back-ends tend toward Node.js, data is represented in JSON, services are decoupled and delivered by way of APIs.

      You can tackle a JavaScript and APIs approach in a number of ways, but the cleanest and fastest really does seem to be JAMstack. I don’t think JAMstack fully meets the marketplace that WordPress serves yet, but in time it will. As more developers and agencies come up to speed on JAMstack, the world’s new projects will be JAMstack projects, or whatever JAMstack morphs into as it moves forward. This is good for website and content developers (and their roles will move closer together, at least in the technology space), but is probably going to be tumultuous for the companies that live in the JAMstack ecosystem. But that’s OK, it’ll be interesting.

    5. WordPress Features: What’s Worth Stealing?

      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.

      The Gutenberg editor that WordPress uses is really pretty capable.
      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.

    6. FireEye Hack: Maybe All Security News Can Be Good News

      When FireEye announced yesterday that “a nation with top-tier offensive capabilities” had used “novel techniques” to steal an inhouse red-team tool, the security community found itself wondering what their reaction should be. It’s a community that, in the past, has struggled not to eat its own children when embarrassing things happened.

      This time around, there were FireEye defenders, among them James Azar, who posted to LinkedIn to say that anyone “bashing FireEye, Inc. for a #nationstate attack” should “think twice.”

      A few dozen replies followed, many of the replies along the same lines as a comment posted by Ramesh Rajagopal, president of Authentic8, who said “defense in depth should also reflect how the industry stands behind each other to support the attacked.”

      The general line of thinking was that even companies that are expert in cyberdefense will, on occasion, fall victim to hackers.

      Well, yes, there’s always the chance that a well-provisioned nation-state attacker will break through even the best defenses. No argument there. But what seems the bigger thing to support is that FireEye appears to have done all the right things when the breach was discovered.

      Several commentors took this line of thought: A tool used for pentesting and outfitted with several hundred individual attack capabilities was stolen, so the victim has publicly released countermeasures and information that can be used to catch attacks mounted from the stolen tool. FireEye was quick to announce the breach and has been transparent about it, so far as outsiders can tell. This is certainly how you’d like to see a breached company react.

      Of course, the New York Times said rather flatly that “The breach is likely to be a black eye for FireEye,” but I’m not so sure. In some ways, it may actually be a good thing, as much as I’m sure they absolutely hate that the breach happened.

      Because, if you’re going to be breached, this is the sort of breach that makes you look like you are all about hardcore hacker juju.

      Consider comments that have cropped up under Bruce Schneier’s brief post on the event in his “Schneier on Security” blog have included much speculation on where FireEye actually fits in the security industry. Someone posting as Assumed said “I’ve always assumed that FireEye was an ‘agency’ corporation. At one point, they were helping decrypt hard drives that were infected with Ransomware for free. What kind of resources does that take? And who is capable?”

      Nothing about the incident reveals anything substantive about the government agency ties that FireEye may or may not have. A blog entry that digs into the materials FireEye released on its GitHub points out that “From what’s been made available in the repo, the tools are mostly open source and not developed by FireEye.”

      So they had a bunch of tools for testing various exploits, just as you’d expect that a company in FireEye’s line of work would have. But, wow, they seem like ninjas when this gets referred to as a “red team tool” that was heisted by “a nation with top-tier offensive capabilities.” Does this event mean that they will no longer be, as the New York Times put it in the lead paragraph, “the first call for government agencies and companies around the world who have been hacked?” Heck no. These guys obviously roll with the bad boys.

    7. Basecamp HEY: Why’d You Have to Change Everything?

      Hey is a mail service you may have heard of. It’s been one of the trendy new things on the internet this year and it’s intriguing because it so solidly comes from a “you’re doing it wrong” sort of mentality. There’s just the tiniest hint of religious zeal about it.

      To be sure, though: there are awesome redesigns of the email experience in Hey. To take one small but wonderful capability: You can change the subject of an email or thread for yourself, so that you always see it with that subject, even though all the other suckers out there in old-school land still see their old, ill-considered email subject lines.

      Hey Screening

      And when a new person sends you something in Hey, you don’t receive it. How’s that for email magic?

      No, seriously, you get a separate button that leads to a page that shows a line or two of each email from each new sender. You decide whether you want to receive emails from this sender or not. You can change your mind later, but if you wish the sender didn’t exist, then they don’t.

      This is golden, I’ll be the first to say. Changing the subject header at will? Also golden. But it’s Hey’s way or the highway: you don’t get folders, for instance. You do get category labels (as with mail clients in general these days). To be honest, it may well be that categories are all anyone needs in email.

      Hey, No Folders!

      The fact is, I do something very close to using no folders in my various email accounts. Everything that I think is worth keeping goes into one subfolder, which I rather creatively call “hold.” Everything that doesn’t go into “hold” is deleted (by me, by hand). Multiple folders, I’ve tended to think, are for people who don’t have proper search functions.

      For me, I suspect that paying a hundred bucks a year for a new email system that locks me into a particular client is a bridge too far. I’ll have already paid for Office for the year (and, frankly, in the business world there’s little choice but to do so) and that comes with Outlook, which is a first-rate email client even if it doesn’t let you change subject headers.

      But I suspect that some of the features are, in some way or other, going to sneak into the world of traditional SMTP and IMAP email. Like a client that lets you screen senders on their first appearance in your inbox. Consider that Gmail already does a fairly good job of sorting social and sales-pitch emails into separate tabs. They wouldn’t have to move that much further to build the initial screening in. I don’t know that people will pay a premium for privacy (they haven’t often, historically), but they’ll be happy enough to get it for free.

      This kind of thing is going to make email a better experience and that’s going to upend the world online marketing, which is still largely based on pummeling your inbox after arm-twisting you into giving up your email. If you can kill that kind of email in a single stroke (as opposed to doing the same thing in several steps by creating a rule in Outlook), then email marketers are going to have to be a great deal more engaging and entertaining if they’re going to stay alive in inboxes (where they now thrive in an atmosphere where it’s often too much bother to cull them).

      No More Total Crap Marketing Emails

      We’re going to have to write emails that people actually want to read. Marketing gurus always give lip service to this idea, but the arrival of Hey may mark the shift to people radically reclaiming their inboxes.

    8. Cybersecurity Content Marketing SEO for Vendors

      Summary: Here are the on-page SEO basic steps that will get you more results per ounce of cybersecurity content marketing effort than anything else you might do.

      If you are a security vendor that hasn’t built basic SEO into your workflow, I’m going to share with you the easiest approach to tuning up a blog post. This doesn’t use the best tools, omits a whole lot of small points of SEO “science” that can sometimes make a difference, only looks at “on-page” SEO factors, and doesn’t take advantage of some of the current additional steps (such as adding structured data to the page) that can give you a leg up. But it’s still, on the other hand, a highly effective approach provided you actually integrate it into your workflow.

      Companies tend to shirk off this process and that’s because the people writing and editing the blogs tend to shirk off this process. And they avoid it because writing the blog was hard in the first place. Now that it’s “done,” they are kind of satisfied with what they said and don’t want to muck around with it anymore. Let’s face it, a lot of the SEO work is highly detail oriented, and if you could otherwise push the “Publish” button but now you have to do a bunch of keyword research, every fiber of your being will tell you to just push the freaking button already.

      This is one of the reasons people bring me in to be part of the process. They have neither the time nor the desire, plus with tools and expertise, I’m a lot faster at it than they are. In the best of circumstances, I’m also steering toward interim marketing goals that the blog writer may or may not be aware of.

      The Basic Steps of the Process

      It’s pretty simple.

      • You need to pick a good target (or primary) keyword for the piece, then use that keyword in the title of the page (the actual title as identified by the <Title> tag on the HTML page).
      • Then you find some additional keywords logically related to the target keyword and use them wherever they fit as you then write at least 300 words and…
      • You include at least one sub header, which is marked as an <H2>, <H3>, or <H4> header.
      • You use the target keyword (exactly as it stands in the title—no plurals or small tweaks) somewhere in the first couple of paragraphs.
      • You include an image and that image should have an alternate text tag that includes either the target keyword or a related one.
      • You include a handful of links both to other pages on your site and to appropriate pages elsewhere on the web.

      Do these things and, provided you got the critical step of picking the target keyword opportunity done well, you’ll see progress over time (very little in SEO happens instantly, unfortunately).

      Cybersecurity content marketing: More Detail

      Some of the steps in the above stripped-down version are probably not entirely clear, so let’s dig in a little bit.

      It’s actually best to pick out your target keyword before you’ve fully written the piece. You may want to write a couple of paragraphs so that you have a good idea where the piece is headed. It’s certainly possible to do this after you’ve written a full draft, in fact I do it this way all the time for clients, but you’ll have more room for creativity and for using the best available keyword if you’re not too locked down when you pick it.

      By “target keyword,” what I principally mean is the keyword that Google is likely to associate with the page and rank the keyword for. Can Google rank a page for more than one keyword? Absolutely. But let’s not get fancy. Now we’re just setting a mental marker for what we think Google will think the page is most about.

      The primary way we communicate to Google that a keyword is important (and signal what the piece is about) is by using the keyword in the title. Of course, this is also what we’re trying to do with the potential reader, so there’s a duality of purpose here and much of the time these two purposes are well aligned.

      We’ll talk about picking the target keyword in a second, but first let’s just say that there are better and worse keywords and that there are two theoretical frameworks in which you can write a title. The first framework is the one we’re talking about: picking a good title for the search engine. The second framework is picking something really clever that the user will want to click on.

      There’s nothing wrong with the second framework, picking the “clicky” title. (OK, actually the resulting title is so awful that it should be illegal to publish such a thing.) But it does assume that you have a lot of readers who are seeing the title. This brings us back to one of my early observations: no one is reading your blog. People aren’t saying to themselves, gosh, I’m going to drop by Vendor X’s blog and see if something catchy has turned up there.

      If you do have the big audience, OK fine. Go nuts. But if that’s not you, then avoid titles like:

      The Twelve Security Ideas (ask me how I know...)

      Inside of a Dog, It’s Too Dark to Read

      The Screen Door on a Submarine

      Secrets Your Employees Won’t Keep

      Top Ten Firewall Disasters!

      Don’t Abandon Your Data Security Agenda

      None of these titles contains a target keyword, except possibly the last two, with “firewall” and maybe “data security agenda”. We’ll check on that in a moment.

      Cybersecurity marketing SEO keyword selection by search volume
      This is what it looks like the SEMrush keyword tool is telling you nobody searches for your fancy long-tail keyword

      A phrase is not a keyword just because you could, if you wanted to, type it into Google and search for it. Rather, something becomes a keyword when multiple people across the world search for it. Most keywords only have a few people searching for them in a given month, ranging from twenty searches a month right up through multiple hundreds of thousands.  

      Getting back to our last two title options above, “firewall” searched for an average of 49,500 times a month. “Data Security” was searched for 2900 times a month on average. And, just to drive home the point about what makes a keyword a keyword, nobody searched for “data security agenda”.

      Off the top of your head, you might say that the best choice here would be to use “firewall” as a keyword. It has the most searches, therefore, it generates the most clicks through to web pages.

      Search Volume Complications

      But it’s not that simple. The other side of the equation is that there are other pages competing for ranking on a term. For “firewall”, there are 111 million pages that Google will show you when you search for it, provided you live long enough to click through all those results. Some of those pages are great, some of them are miserable. Google tries to put the good ones earlier in the results.

      With 111 million pages, the good ones are pretty good. Wikipedia has a page that Google likes. So do Cisco, Forcepoint, and Comodo. The tech B2B publisher TechTarget has a page up there in the top entries.

      “Data Security” has six billion pages available in Google results.

      So one factor in a keyword decision might be how many pages you’re competing with. Going at it that way, “Firewall” is definitely better than “data security” because “firewall” has way more search volume and way fewer competing pages.

      More Detail

      Alas, it’s still not as simple as that. That’s because, thing is, you really aren’t competing with all 111 million or six billion pages. You’re only competing with pages that have a prayer of being near the top of the heap.

      So how do you choose the right target keyword? Unfortunately, there is no simple answer. A lot of factors can go into the selection process:

      · What the trend of search volume looks like for each candidate

      · Projected click through rate for organic search results

      · The dollar value of click-throughs from the search term (how much do Google ads for this term go for?)

      · One of the “keyword difficulty” metrics supplied by some of the paid SEO tools out there

      · Number of pages that have the keyword in their title

      · Keyword options that match the keywords for which your competitors rank in top spots

      · Examination of the quality of the top several pages you’ll be competing against

      · The “Domain Authority” score you’ll be up against when competing against the top ranking pages

      And, of course, if you go looking on the Internet, you find plenty of other random magical approaches.

      Remember, you’re trying to pick the best opportunity for a short list of possible keywords. Some keywords will obviously not be likely winners. If there are four ads and a featured snippet for a keyword, then the organic results will fall well below the fold on the results page, meaning other keywords that didn’t have all that clutter on the results page would be better bets.

      Consider Typical Top Search Volume

      For an extremely rough-and-ready approach to settle less-obvious cases, I suggest you figure out some top keywords that your competitors rank for, then have a look at the approximate search volume for each, get a sense of what typical search volume looks like for top keywords in your industry, then pick the keywords that best fall into that traffic level.

      By way of saving you some time, I can tell you that longer-tail keywords in security tend to get 200-600 searches. More popular stuff, like “firewall”, does 40-60k.

      How do you get the search volume? Well, the free way to do it is to use the Google keyword tool. The downside of this is that it only gives you the range of searches (which order of magnitude does it fall in). That’s a pretty blunt instrument, but in the case of security it does give you a sense of where it fits in the two levels I mention in the previous paragraph.

      Early in the game, aim for stuff in the lower-volume group. Aim for stuff where the competing pages look like something you can beat. There are ways to make more sophisticated predictions about where you’re likely to do well, but at the end of the day these are educated guesses, so make the best choice you can given the tools at hand and move on. You’ll be way ahead of this game of cybersecurity content marketing if you simply make sure you pick something that actually is a keyword and has some search volume.

      After that, you need at least a couple related keywords. Don’t get fancy here, just doublecheck that your keywords are actually keywords and actually have some traffic. Tackle real information security issues and let the keywords fall into line–don’t let the cybersecurity content marketing tail wag the actual cybersecurity content dog.

      Then, make sure you hit all the items on the list at the start of the chapter. This takes extra time and discipline, but it leads to the small wins that add up over time and that lift the performance of your website.

    9. Cybersecurity: Still Not a Profit Center in 2021

      What I haven’t seen yet in the inevitable year-end blog predictions of what will happen in the coming year–and it struck me as odd because it seems like someone always has to have it as a bullet point–is that brands can start using their better-than-average security postures as a way to build a tighter bond with their customers. Indeed, those security-savvy consumers are going to be ready to pay more for better security.

      Unfortunately, this is mostly hogwash. Except in some very specific instances, consumers don’t actually want to pay a little extra for more cybersecurity. There’s a way in which Amazon gets the business for certain transactions (with international sellers, for instance) because they create a safe market for these transactions, but the main reason people are buying things via Amazon is because the prices are at least as low as anyone else’s, because they deliver things almost faster than you can decide to buy them, and because some of us are just complete suckers for Amazon Prime’s free delivery.

      A 2016 report from Cisco interviewed just over a thousand security executives and found almost half of them at least paying lip service to the “competitive advantage” theory:

      The underlying report can be found here, but I note in passing that when I went looking for it, I got a stern warning from my browser. I don’t think Cisco is losing any sleep or any business (or even any downloads of their report) over this.

      On the other side of the coin, there isn’t a lot of convincing evidence that most companies that undergo publicly reported breaches actually lose all that much business or that many customers as a result.

      There are exceptions. There are businesses that got creamed because of breaches. And there are ways in which financial institutions trade directly in customer trust…and this almost certainly spills over into the cybersecurity realm.

      But as 69% of Cisco’s recipients rightly put it, security is about managing risk. It’s about keeping the transactions flowing uninterrupted. It’s the cost of doing business, just like accounting or paying for Salesforce.

      So, if you’re a security marketer and you’re thinking about everyone’s mid-pandemic heightened awareness of security issues, well, there might be something there. But you’re pushing it too hard if you try to paint your product or service as something that will actually return a profit for your buyer’s investment. That’s just not how security works.