Category Archives: General

27 Aug

Improve Gatsby Performance Using NGINX

As a multi-national web platform with millions of visitors per month, website performance is of the utmost importance. We recently worked with a Silicon Valley based customer who was dealing with a slow loading Gatsby website, who engaged us to improve Gatsby performance metrics.

Their homepage regularly took up to 15 seconds to load on mobile and Lighthouse performance scores for desktop screens were a measly 42 out of 100. For our client, anything less than 75 is unacceptable. The effects of slow load time on user experience and conversion rates are well documented.

It was clear that we were going to improve the performance scores, but refactoring the Gatsby codebase could cost our client weeks of man-hours. How could we improve these performance scores without breaking the bank?

Using Chrome’s Dev Tools, we analyzed the page load times, images, bundle sizes and anything else that would cause inefficiencies. We focused on identifying the most egregious offenders to help improve Gatsby performance.

Using Chrome DevTools to analyze a website’s network requests and file sizes

Among other issues, we found that our client’s servers were not configured to compress files as they were being served. To address this problem, we launched a new server and installed NGINX. Our client’s files were being stored in an S3 bucket. NGINX gave us the ability to forward traffic to the S3 bucket and gzip the responses along the way.

The performance scores improved dramatically. Load times on mobile fell from 15 seconds to 2 seconds and the Lighthouse performance score went from 45 / 100 to 98 / 100. Better still, we were able to make these improvements at a minimal cost to our client.

If you have a codebase that seems unmanageable, it isn’t always necessary to pay for a complete refactor. With a little bit of analysis and research, you may find a way to get a big payoff with little effort.

11 Aug

Enabling JWT Authentication on WordPress

There are lots of reasons a developer might have for Enabling JWT Authentication for their WordPress instance. Perhaps you are doing some automated migration, or maybe you are building an app that uses WordPress as a back-end with some other technology on the front-end, such as Vue or React. Whatever you might need JWT for, it’s a pretty simple process to enable. After enabling JWT authentication, you will be able to authenticate via scripts or other code bases to add, update, read, and delete data as you please.

Step 1: Modify Your .htaccess file

This step requires modification to the WordPress files. So beware if you aren’t familiar with this. This file is read by Apache, and it can make all sorts of things go wrong if you aren’t careful. Go ahead and add the following lines of code between the IfModule tags:

RewriteEngine on
RewriteCond %{HTTP:Authorization} ^(.*)
RewriteRule ^(.*) - [E=HTTP_AUTHORIZATION:%1]

This code allows HTTP Authorization headers, which are disabled by WordPress out of the box.

Step 2: Install the JWT Authentication Plugin

After trying a few solutions, this plugin by Enrique Chavez ended up being the one that worked best. It has a few drawbacks in certain situations, but it was perfect for us. Notably, if you are using basic auth for your site, this plugin won’t work simply for you. There seem to be a few workarounds, but I haven’t tested them.

Log in to your WP admin page and go to Plugins. Search for JWT, and the first result should JWT Authentication for WP REST API. This is the one we want.

Step 3: Authenticate with JWT

With those steps out of the way, you can use whatever code language you want to authenticate with JWT. I have done this with Python and Javascript, both of which worked just fine. If you are interested in seeing an example of WordPress authentication with Node.js, check out this article.

11 Aug

Local WordPress Multi-Site Development

Multi-site WordPress can get a bit confusing for those uninitiated. So let’s go through a bit about them, and how you can go about getting started with a WordPress multi-site installation. There is room for a lot of decisions and customization. How will we deploy? Where will we host it? What tools will be required to monitor and maintain such an instance? Most importantly, how will we create a local environment that will reflect our multi-site network on a remote server.

What is a Multi-Site?

A WordPress multisite is a collection of sites that share a single WordPress installation. They can share plugins and themes, but the individual sites are virtual. They don’t have their own directories on your server, aside from media uploads, but they have separate tables in the MySQL database. 

Think of a multi-site as a network of WordPress sites. Where a network is the WordPress installation with core files, themes, plugins, etc, and each site is just a virtual site, with a different table in the database. Much like a single instance is a way to manage blog posts, categories, and content, a multi-site is a way to manage many WordPress instances on a single installation.

Setting up a Local WordPress Multi-Site

To simplify and add the ability to share this type of configuration with a client, other developers, or your boss perhaps, let’s use something to containerize the process.

Lando is a fantastic tool developed by my friend and his team at Tandem. It spins up local Docker environments based on .yml configurations. It handles all the services including setting up the LAMP stack, routing the containers, port management, instance installation, and database importation. It’s pretty amazing. Check it out here: https://docs.lando.dev/.

Step 1 – Download and Install Lando

This is simple if you are on a Mac. It’s going to install Docker for you as well. If you already use Docker, you can remove the current version, or brew will error out during the install.

Use brew cask install lando to get started. It takes a while to install since it has to download all the packages, so grab a cup of coffee while you wait.

Step 2 – Initialize a new Lando yml file

This command will initialize a yml file, which we need to modify slightly:

lando init \
  --source remote \
  --remote-url https://wordpress.org/latest.tar.gz \
  --recipe wordpress \
  --webroot wordpress \
  --name wordpress-app