Statically generate a markdown-based blog using NextJS

I've begun the process of moving my site from Drupal to a custom-built React application stack using NextJS. As part of this, I'm moving content to markdown files kept with the source code, rather than maintaining a CMS for simple content storage. Let me take you through the process of how you can use NextJS to efficiently render markdown files as static HTML for fast performance, quick build times, and maximum SEO.

Drupal Performance: Eliminating the Render-Blocking resources

One of the biggest factors in page performance is render-blocking assets. These are assets that prevent the page from being rendered while they load. Typically this is Javascript and CSS in the head of the document. When you're using a CMS like Drupal, you often don't have much control over how these are structured since the CMS does its own management for combining various files into cached versions depending on what components or modules exist on a given page.

Drupal Performance: Eliminating the Flash of Invisible Text

Today there are a plethora of fonts available for use on the web. All major browsers support web font technologies, and there are many foundaries and freely licensed fonts available for making a site look just so. We no longer have to deal with the extremely limiting set of baseline fonts installed on visitors' computers. However, the rise of webfonts also means that there is a performance impact to using them. When the browser loads the site, it also has to load the fonts, just like any other static asset.

Cleaning up a compromised Drupal site

When running a web-based CMS like Drupal or WordPress, it is not uncommon to have your site compromised by hackers who inject malicious files to use your site as a hosting platform for spaming, botnets, or other malicious activies. If this happens to you, don't fret, as it is very unlikely you were specifically targeted. Instead, it's most likely your site was found with automated scanners and targeted simply because it was identified as being out of date with security patches. To protect yourself, there's a few things you should do:

Solving Lighthouse's inefficient cache policy warning on Drupal websites

While working to improve the performance of my website, I have been using Google's Lighthouse to audit the page performance and looking for quick wins. One that comes up frequently, and is easily solved, is improving the cache policy on static assets. When running Lighthouse against my Drupal site, I get the warning "Uses inefficient cache policy on static assets". This will always occur on a Drupal site, but is really easy to improve the site performance to fix this:

Moving a Drupal site to HTTPS

As part of improving the performance of my site, and bringing it up to date with modern best practices, one step is to switch over to HTTPS instead of HTTP to secure the site. This is a required condition for a Progressive Web App, but it's a good practice in the modern age.

Replacing Mollom with Akismet for spam filtering on a Drupal site

If you run a blog with comments enabled, you're probably painfully aware of the tedious task of dealing with all the spam issues. There's a many different approaches, and they all have tradeoffs:

Fixing broken content images on a HTTPS Drupal site

After switching my site over to HTTPs and implementing a Progressive Web App, I was doing some browsing, impressed at how much snappier it feels. Until I ran into an issue: the images were missing from several of my articles! Instead of showing up, or even being missing, an empty grey box was showing in their place:

Busting Gmail image caching with build scripts

Recently Google added image caching to Gmail.

This is a good thing for email service providers, because it will dramatically reduce their hosting costs as an image will only need to be downloaded once to be used by all Gmail users. For email developers though, this is Bad with a capital B.

Rapid App Development using Meteor

I was skeptical of a recent SmashingMagazine article about building a webapp in 45 minutes. So I decided to follow along and see if I could replicate their success. I have never used Meteor before, or any server-side Javascript processing (aka Node.JS) for that matter. Usually I rely on Apache and PHP for the server side, so this will all be a new learning experience for me.