Saying Goodbye to WordPress

June 6th 2020

Why We’re Moving Away from WordPress and You Should Too

It’s been a long time coming. Years maybe. But as they say “the writing is on the wall”. Website technology has changed drastically in the last five years. The change has been driven by the advent of highly popular JavaScript frameworks such as React, Vue, Angular etc. Ironically, the web is returning to it’s roots of static generated pages. But this go around is different than it’s historical past. Build tools that have been created for these JavaScript libraries allow for a pseudo-server side processing (and in some cases such as Nuxt universal mode it is server side processing) that generates all of the pages into static files with hydrated data. Moreover, any data that is not needed or hydrated on the server can be queried on the client through a REST API or GraphQL query. This static site generation allows for optimized, minified files that are lightweight and can be served and delivered with speed through content delivery networks – making static generated sites lightning ⚡fast. Also, since the processing is already done, the site does not necessarily require an advanced server setup with database management, leaving it safe and secure from malicious attackers.

The Downfalls of WordPress

Don’t read me wrong, I love and appreciate everything WordPress has given me over the years. I’ve spent thousands of hours developing on the platform and it’s provided so much value to me, my clients and the world wide web as a whole. But as they say, everything good and bad must pass, and the era of WordPress too shall pass. We all know technology changes at an astronomical rate. It’s pretty remarkable that WordPress has dominated the web technology for this many years.

One major downfall for WordPress is the security risks involved. To run a WordPress installation you need a lot of different technologies and languages working together in order for the site to work including: database (MySQL etc), PHP processor, web server, and of course the client side technology (JavaScript). This leaves a large attack surface for any malicious attacker. Moreover, most sites heavily rely on third party plugin development, which do not go through stringent security tests and compatibility testing before they are used in production.

The reason static sites are more secure is that they have a significantly smaller attack surface. There is no code running on the server besides what is necessary to listen to HTTP requests and serve files (and this part can be abstracted away by the platform, such as with AWS or Netlify.)

Static Site Generation vs Server Programming Languages

The other major downfall of WordPress is speed. As previously mentioned WordPress requires a lot of different processes and languages to run through before serving and rendering a page. Every time you make a page request to a WordPress the web server handles the request and passes the request off to the appropriate PHP file. From there, all of the required bootstrap files are run and any installed plugins, core function and theme functions are executed. During this process one or multiple calls to the database are made, which includes another process being involved. Finally, the html/css is generated, injected into the page and served back to the client. Yes, there are many ways to optimize this process by server side caching, load balancing and other techniques but 99% of WordPress sites are not performance tuned for this speed optimization; and doing so usually requires more plugins to be installed an included.

Conversely, static generated sites and applications have already been generated, hydrated with data, minified and optimized to be served back to the client upon request. There is no code running on the server besides what is necessary to listen to HTTP requests and serve files.

It’s sort of like a WordPress site if you were to use an aggressive, full-page caching strategy — and then automatically flushed and re-populated the cache every time you published a change to your content.

Microservices are Replacing Plugins

As previously mentioned, most WordPress installations rely on a multitude of plugins to run common website functionality. Need a form? Install a plugin. Need a modal? Install a plugin. Need to do some basic HTML/CSS layout on a page? Yup, install a plugin. These plugins slowly become like a beaver damn building up in a river. One stick (I mean file) at a time the site speed degrades. What about the integrity of all of these plugins? Who wrote them and were they tested against all of the other plugins your site is using? Not only is there an integrity issue with third party plugins but also an inherent security risk.

Microservices and REST APIs are replacing the functionality provided by third party plugins. Microservices allow you to send a HTTP request to their endpoints (either from the server or client) to get required data or provide functionality that would otherwise have to rely on plugins. Even complete content management systems (CMS) are decoupling from the from the front-end while exposing functionality through REST APIs. These decoupled content management systems such as are known as headless content management systems and are gaining wild popularity in the internet community.

The benefit of decoupling functionality from the front-end view layer is that you can rely on the microservices to handle their own security concerns and concentrate on improving the functionality of each service. You also don’t have to be concerned about the integrity of API services conflicting with one another, since the interfaces between your application and the microservices are handled through HTTP REST requests.

Initial Cost vs Ongoing Costs

The initial development cost of building a JAMStack (JavaScript API Markup) website is likely going to be more expensive than finding and installing a WordPress theme. However, with security management, software updates and server requirements for a WordPress website the ongoing costs of hosting, maintenance and resolving plugin conflicts are going to outweigh the initial costs incurred by a JAMStack website.

Hosting and ongoing maintenance for a WordPress site is going to incur hundreds of dollars a month in hosting costs as compared to the $20 – $50 cost of hosting and maintaining a JAMStack site.

The nature of a static generated website requires a lot less server computation, security and processing power than a monolithic (coupled) CMS such as WordPress. This significantly decreases the ongoing costs of hosting a static generated site over a WordPress website.

Speed and Security are Paramount for SEO

If you take away anything from this article, you should take away this: security and speed are paramount in search engine optimization ranking factors. Search engines, such as Google, reward sites that protect their users and serve fast websites. Everything else being equal, statically generated websites are going to outperform and outrank their WordPress counterparts. If being found and ranking high in search result pages (SERPs) is important to you than you need to highly consider the future of the internet and movement to JAMStack websites.

Site security and speed are paramount in search engine optimization ranking factors.

Hopefully we’ve shined some light on the benefits of moving your website to newer, better technologies such as static generated sites. Join us as we show our appreciation for what WordPress has provided, and our excitement for the future of the internet as we say goodbye to WordPress and hello to the JAMStack. If you are interested in learning how to move your WordPress website to Strapi you can follow our tutorial on migrating to a Headless CMS model. Bon voyage as we sail to new internet horizons!