Saying Goodbye to WordPress
June 6th 2020
Why We’re Moving Away from WordPress and You Should Too
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.
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.)https://forestry.io/blog/is-it-time-to-move-on-from-wordpress/
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.https://forestry.io/blog/is-it-time-to-move-on-from-wordpress/
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 Strapi.io 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
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!