JAM Stack vs. Wordpress

I ran my site on a shared server running WordPress for the longest time, and drawn by the promise of faster, more secure sites that cost less to host in multiple locations, I migrated to JAM stack in March of 2019. Anyone considering a similar move, this is my running take.

I won’t restate everything from their site, but suffice to say: If you update infrequently and are capable with Javascript / APIs / Markup, it’s worth consideration.

Picking a static site generator

My annual server payment was coming up, so my biggest deciding factor was which one I could wind up fastest. I tried Hugo, Jekyll and Gatsby, and Jekyll was the fastest off the boilerplate. It integrates with GitHub Pages as well, which (will be) a much more convenient method of updating content vs. building and uploading the generated site.

Support: WordPress wins

WordPress has plenty of ready to use themes, plugins, third-party and help desk support.

Jekyll has ready to use themes—though orders of magnitude fewer. JAM inherently doesn’t have plugins in the same sense, and while there are sample sites demonstrating different microservice APIs that serve the same purposes, support is very DIY.

Maintenance / Security: JAM wins

Even with no changes, WordPress required regular updates for the installation itself, plugins, and less frequently, for the server—Often with alarming notifications on what would happen if I didn’t. I quickly learned to take them seriously after I had a contact form’s vulnerability exploited. Using WordPress.com would eliminate maintenance requirements for the server and installation, but not plugins—which have also created broken elements on my page.

Using AWS S3 to host the static site requires some setup, but is very straightforward—as is setting up HTTPS via AWS Certificate Manager and CloudFront. I haven’t had to do any maintenance, and I worry a lot less about security for two reasons: 1) I trust the third-party API providers to handle their security well because it’s their core business, and 2) In the worst case, JAM better compartmentalizes any potential breaches.

Speed: Tie

The response time is marginally faster. However, even with a comparable number of elements on the page, the difference in load time is negligible, with the exception of loading my WordPress site right after clearing cache (much longer). Given the giant that WordPress is, and the business critical sites that rely on it, there are a lot of built-in and add-on optimizations. The same can not be said of the Jekyll-built JAM sites.

Verified by accessing via VPN, the JAM site is faster worldwide, which is expected given the edge locations in AWS CloudFront, vs. jumping to the N. California server.

Cost: JAM wins

I was paying $120 / year for the shared server I had WordPress on. My AWS S3 charges are basically nothing ($0.01 a month to be exact).

Customization (added 12/2020): WordPress wins

The Jekyll theme I chose only provides a minified CSS file, so though I would like to adjust the featured image’s object-fit property and add alt text to them, it is just not doable.

WordPress is far more accommodating and user friendly for this.

SEO (added 6/2022): WordPress wins

I have old posts that kept showing up in search results. WordPress is much better about maintaining robots.txt and sitemap.xml to avoid this. Meanwhile, the corresponding files Jekyll generated still had localhost:4000 in them.

Featured image source: voxdigital.ca