Static Website vs WordPress for Your Next Redesign



Back in the old days of the internet, there was exactly one way to build a website. You would have to learn HTML and you would code a page. And then you would copy and paste that page and you would tweak the title and some of the content and you would have and repeat, repeat, repeat.

Before too long, businesses began to build websites to promote their products or services, although in those days these sites were more like online versions of a yellow page ad.

These pages were super simple. Someone would type into their browser your website’s URL and the the HTML would be served right up to the browser and you could view the web page.

The obvious drawback to building websites this way is that the people building the websites and the people who are managing the content for the site. So if you decide that you want to change the page title on your About page, you would have to submit a request to your development team, and, in between projects, they would go in and tweak the HTML for your page and update the content.

WordPress burst onto the stage in 2003 and changed the way that people built websites. Instead of static sites, these sites were dynamic. Non-technical users now could now create and edit page templates, change content, create new pages, manage for submissions, and more. You could implement logic, so if someone is logged in to your site you can show them one thing and if they’re not then you can show them something else.

At the risk of over-simplifying, here’s how a WordPress site works. When a user visits a page on the website, WordPress looks in its database to find the info for the headers, copy, images, and footer info and then it references that pages template file to determine where to put that data on the page and how to style it. Because the pages were being built in real time, it allowed you to do some really cool things and, before long, people started getting really creative with WordPress sites.

At its core, WordPress is a blogging platform, and it does that very well. If you’re wanting to run a personal blog, then it’s pretty great right out of the box. But what if you’re trying to run a business and need to collect information from users through forms, integrate with a CRM like HubSpot or an email system like MailChimp, manage e-commerce through WooCommerce or collect payments with Stripe?

To answer these questions, developers got to work and built plugins that extended WordPress and allowed it to go above and beyond simple blogs. WordPress now powered some of the most complex sites on the web.

For a long time, this was probably THE undisputed way to build websites. But, it came with some difficulty. The more functionality you needed, the more plug-ins that you had to install. The more plug-ins that you installed, the more your server was required to work behind-the-scenes to build the site and present it to your visitors, which meant you either had to pay up for a great hosting provider or deal with a slow website.

Let’s say you were integrating your website with a service like MailChimp to send marketing emails to your customers when they submitted a form. If MailChimp made a change to the way that their back-end sends or receives info, then it could break the plug-in. So you have to rely on the developer who created that plug-in to write an update so that your MailChimp integration continues to work.

Alternatively, WordPress is constantly rolling out updates to help with security and performance, which can sometimes interact with your plug-ins in weird ways. So, while WordPress sites can be cheap to host, if you don’t have somebody with decent development chops on your team, it can be pretty expensive to maintain.

In my opinion, if you’re spending time and money working on a website, you should be looking at user behavior and running tests to help you generate more leads and revenue, not fooling with plug-ins and integrations. To me, that’s just not a good use of a developer’s time or your money. (Growth Driven Design, on the other hand is a great use of this time)

What is a Static Site Generator?

When I first heard about Static Site Generators, my jaw dropped. These are pretty slick pieces of technology and they make a ton of sense for many small marketing sites.

A developer will write the code for each type of page that will exist on the site. For instance, they might build the shell for the Home Page, a page with a sidebar, a page without a sidebar, a blog listing page, and a Contact page. There won’t actually be any content on these pages yet, but all of the styles and scripts will be ready.

Then, the developer will set up and configure a Headless Content Management System (CMS) so that the website admins can go in and manage content. The only thing that this CMS will do is store the Content that will be on the pages. Unlike WordPress, it doesn’t perform any logic and it doesn’t actually build the site. It only stores the content that will go on the pages.

So we have the Content in one place and the styles in another. Here’s where it gets cool – hang with me. Using a package like Middleman, you can write a program that looks at each piece of Content in the CMS, matches it with the write template file and writes all of the HTML for each page for you. The entirety of each page is written out as if you had hand-coded the page (like we did back in the old days) so there’s no need for a server and the pages load lightning fast.

Using a tool like Netlify, you can set up a workflow where anytime an admin updates content in the CMS, it’ll run through all the content, build out all the pages, and publish them to your domain.

Depending on how much of a geek you are, this may or may not sound like a big deal, but it is a huge deal.

It’s kind of like this. If you go into a car dealership to buy a new car and, in the showroom, they have 3 wheels, in the bathroom they have a bumper, in one of the offices, they have the engine, and in the dumpster is the 4th wheel. When you sit down to talk to the salesperson, they say, “Oh yeah, we have the car you want but we’ll have to assemble it before we can give that to you.” That’s not what you want to hear, right? Just give me the car.

That’s kind of what happens when you visit a WordPress site. The header is over here in this row of this database, the template is over here in this folder, each link in the footer is in another database table. The main content of the page is in a third database table. Any other plug-ins that you’re using have information spread out all over the internet.

So when you visit that WordPress site, the server says to your browser, “Hang on a sec, I have to go find all of the content and build this page out while you wait.” Once it finishes, it serves up the page.

With a static site, your browser visits a page, the page is already assembled and it’s just served up. Lightning quick, right?

Who Could Benefit from a Static Site?

Most small websites could benefit from a static site. If you mostly show the same content to everyone, don’t need a ton of functionality, and won’t be creating a lot of new page types, then a static site is right for you.

Who Won’t Benefit from a Static Site?

If you show content that is specific to the user that is logged in, need a bunch of functionality (like a shopping cart), or make use of personalization on your site, then a static site might not be for you. However, there are a bunch of companies that are springing up that are addressing these shortcomings, like Snipcart for eCommerce and FormSpree for form submissions.

When it comes time for your next website redesign, it would at least be worth considering whether a static site is right for your business model.

Related Articles