Why I hard code urls in my WordPress theme

When I redesigned this site to load faster, one area that caught my attention was the “server response time”. This is how long it takes to put together a webpage’s elements before it gets passed to the visitor’s web browser. Faster is better as the longer takes, the more likely the visitor is to give up and go somewhere else. As a rule of thumb, 3 seconds is the absolute longest time it can take for the page to first appear.
Most of us host our sites on shared services with little control over how the server is set up. Therefore our efforts focus on how themes are designed and WordPress is configured. In this post I’ll outline why I decided to hard code parts of the site to reduce the work the server has to do, and make the site load faster.
WordPress configuration made easy
WordPress is attractive because it can be easily configured. By default we can set up menus, add icons and even change the fonts and style of our site. Install plugins and this can go further, with SEO, contact forms, social media integration and a plethora of other options. All configured from the Admin screen using a web browser and no code required.
Such flexibility comes with a price. Each thing we configure is stored in our WordPress database. When a visitor asks for a page these settings are retrieved from their fields, processed and then rendered. All of this takes time, and while it might be measured in thousandths of a second, it all adds up.

If you’re using a theme or plugin brought in from an outside source, this configuration makes sense. You want flexibility to add your own menus, or set the SEO the way you like it. Does it hold true if you’ve built your own theme and plugin?
How often does your WordPress theme really change?
Truth is, not much changes once WordPress is up and running. You might add an option to a menu later, or tweak an icon. By and large, much of the “furniture” around a page remains static. If you do change it, chances are you’ll use a process to verify the impact is worth the benefit.
With this in mind, I decided to hard code a lot of what WordPress normally treats as flexible configuration. Instead of asking a database to return values I already know, they’re coded directly into the page templates.

What could be hard coded in your WordPress theme?
Before starting it was important to separate what would and would not change for each page template.
What does change:
- post titles and content
- SEO meta tags
- teasers for related and latest content
What doesn’t change:
- site name, tagline and icons
- menus
- location of stylesheets and the Javascript for galleries
- links to social media accounts
In short, anything related to the post and its content is generated dynamically. Everything that surrounds it can be hard coded.
Hard coding WordPress theme elements
My hard code list falls into two categories. In the first is everything that is a part of the template. These “theme elements” includes the stylesheet, Javascript for the galleries and all the icons.
Theme elements are always located in the site’s theme folder. Right click on any image and you’ll see the URL starts with https://ross-hori.com/wp-content/themes/D1/, which is the folder for the site’s theme. For example, the URL to the portfolio icon is https://ross-hori.com/wp-content/themes/D1/icons/portfolio.png. This is hard coded into the template using
<img src="https://ross-hori.com/wp-content/themes/D1/icons/portfolio.png" width="38" height="38">
Hard coding the site structure and navigation
The second category is the “site structure”. These are links to static pages, categories, other websites and so on. For example, the URL to my portfolio is https://ross-hori.com/portfolio/, and it’s been hard coded with the “portfolio” icon on the main menu.
You’ll notice I hard code the full URL. There are functions that return the URL of the theme and the website. I decided not to use these functions given I know the full address, and it isn’t going to change.
Maintaining a hard coded WordPress theme
Hardcoding URLs into webpages does make maintenance and testing a little more complicated.
First, a hard coded URL always goes to my server. It can make testing awkward as my development environment will skip to the live one when I click a link or load a resource. If it isn’t on my Mac (where I do my development) I’ll get a 404 error. In practice, new resources are tested by hardcoding the development URL, then changing it to the live one I’m finished.
Second, the URLs can be in several different php files. If I do have to change something it could mean editing more than one file, with the risk of missing it. A feature of MacOS means I can search my theme contents for the URL I need to change rather than hunt through individual files.
That said, none of this is particularly onerous given changes happen so rarely. I also have a stable process for making, testing and releasing changes.
Should you hard code your WordPress theme?
Hard coding isn’t suitable for every site in all circumstances. Trying to reverse engineer someone else’s template, or releasing a theme for others to use aren’t wise.
In fact, I’d argue it’s only appropriate in a few very situations. Specifically:
if you’re designing a custom template for a specific site whose structure is stable and unlikely to change.
A last word
The flexibility of WordPress can also be its curse. The more you can configure, the slower your site becomes as settings and preferences are pulled from the database and put together before being presented to the visitor.
If you are designing a custom template for your site it can make more sense to bypass WordPress and hard code your menus, icons and links. Slowing your site’s performance for the ease of a once-in-a-blue-moon change might not be worth the impact on SEO and your visitor’s experience.