Introduction
When it comes to developing a website on WordPress, there are an incredible amount of routes you can take to get this done – some are simple and some are overwhelming. From hiring a freelancer that can download a theme with the click of a button, to using a page builder like Visual Composer, or hiring a team to build everything from scratch, you’ve got a lot of options.
But what truly is the best way to develop a site that allows the flexibility for end-clients to easily manage literally everything on the website without having to touch any code – while considering scalability?
So often clients reach out to us because they are tied at the hip with whoever built their website originally because it was developed using confusing code. What’s worse is that some agencies/freelancers do this on purpose so that any changes a company may want done in the backend, there’s only one person who knows how to do it and that person gets paid to do it.
Here I’m not going to be discussing scalability in terms of hosting / servers, database management, or our WordPress architecture (that’s for another day). But more-so, I want to dive into the details regarding the tools and processes we utilize for building effective and scalable WordPress sites for our clients, so that at the end of the day (and engagement) they have the freedom to manage their site and content in whatever way they see best fit.
Why Custom Code vs Page Builders and Templates?
One of the biggest misconceptions of WordPress is that all WordPress sites are built with templates and themes that require no development.
To a certain degree, I wouldn’t entirely disagree… Yes, we have a lot of clients that have come to us with websites that were using templates and page builders. But they came to us specifically because they were looking for a rebuild due to the fact that their website was moving far too slowly or had become entirely non-responsive.
But no, in short, WordPress websites nowadays can be built similarly to how a web application is built using very similar methodologies and technologies. For instance, we see a lot of freelancers and teams utilizing multi-purpose themes with built-in page builders such as Divi Themes and Elementor.
In this example, the size of a site built on DIVI is typically around 25-30 MB. This results in an average load time of around 12-14 seconds.
I don’t know about you, but thanks to Youtube and Candy Crush my attention span lasts about 2-3 seconds, not 14. When we think about scalability, this is already a non-starter.
And this is when custom development using start themes or boilerplates come into play. At Anyday, we utilize Sage to start off most of our WordPress projects.
Why Sage?
Having been around the block a handful of times, we’ve used dozens of starter templates. But nothing comes close to Sage in relation to performance and efficiency.
Sage utilizes Laravel’s Blade templating engine which allows developers to not only prototype much faster, but write much cleaner code. And in our world Clean Code is God.
Sage is also based on HTML5 boilerplate, a very user-friendly starter template that’s gained recent popularity due to its ability to prototype quick and robust websites with cross-browser compatibility. Sage offers this along with various technologies that allows us to easily integrate it into our development environment including:
- Sass
- NPM
- Bootstrap
- Composer
- Yarn / Gulp
- ESLint
This provides us developers all the freedom and the tools to craft a website that’s not only beautiful and custom, but super fast.
If this fact alone doesn’t convince you of how robust WordPress can be when leveraged properly, I’m not sure what will.
Sage provides a great starting point to ensure a scalable foundation by offering an incredibly organized theme structure. This theme structure allows us to easily organize our Gutenberg blocks with our ACF configuration to build “components” which we can then utilize to construct our website.
Think of Gutenberg Blocks as Components
We call our Gutenberg blocks, “components” because we’re essentially configuring all of our necessary ACF fields within the blocks; allowing us to reuse these components within the WordPress page editor.
As developers, we’re essentially building a library of these components to allow for a seamless experience for content managers to easily add, modify and remove these components within the page editor to modify any pages on the website.
What does all this mean?
This means that by understanding the necessary Components, content managers can easily create, delete or modify any pages on the website without having to touch a single line of code.
What this means for the bigger picture is that once we’re done building a WordPress site, the client is free.
Agencies often code with obscure language with the intent of creating a maze that only they can solve. This shackles the client to the developer or agency, financially, and in a sense of scalability, which goes against our ethos entirely.
In terms of scalability, with our WordPress builds, clients will be able to easily train or hire staff to manage the content in the backend, which ultimately is the goal for 90% of our engagements. Of course we’re always around for an extended partnership, but it’s a partnership we want based on choice, not on requirement.
.svg)
.svg)
