Why am I, a Frontend Developer using WordPress and a Theme I bought from ThemeForest?

Reading Time: 9 minutes

I’m that guy, a Frontend developer who is using a WordPress theme that he purchased from everybody’s favorite theme store; Themeforest.

This seems a bit crazy ,right?

It’s my job to build this stuff, yet I’m paying somebody else for their work.

I don’t think it’s strange at all, I think it was a pretty smart choice, or at least I hope it was.

When I decided to create this blog, I faced a choice. Spend weeks and weeks, maybe even months and months painstakingly designing a bespoke theme from the ground up, or just get started now!

I’m a big advocate of not reinventing the wheel. If somebody has gone through all of that trouble to build something that looks great, works great, and has more features built-in than I’ll likely ever need, why on earth would I want to do it all again myself?

After all, I don’t know if anybody is going to read this stuff, it’s not a good use of my time to do all that work for no reason.

A quote I like that a former colleague brought my attention to, comes from the Spotify team and it goes…

Fail Fast. Learn Fast. Improve Fast.

Spotify

If by some miracle anybody reading this decides to engage with me and we gain some traction, there’s always the opportunity in the future to develop a bespoke theme at that point right?

So why did I pick this theme, and what is it?

This particular theme is called “Breek” and it’s made by EStudioPatagon, go and check them out, they have a great selection of WordPress blog themes.

The decision to settle on this rather than something else was quite quick, impulsive almost.

I don’t know why it just felt right. Maybe it’s because I’m a sucker for the masonry layout, maybe it was the minimalist design, maybe it was the bright colours, take your pick. There’s no right or wrong answer.

I’ve never really used WordPress very much. As a CMS (content management system) it carries a bit of a stigma in the world of development as sort of a bloated, “beginner” level system. Us professionals kind of look down our noses at it, it’s just something that people who don’t know how to make a “proper” website use right? It’s going to be slow, limited, clunky.

Is any of that true, or is that just what we tell ourselves to justify our existence?

On the whole, it’s probably not true, it’s pretty impressive what you can throw together in a matter of hours really and the skills required to do so are fairly limited.

It’s all relative after all, of course, if you want a blog type website or somethings static, then paying a developer to build it for you vs getting into WordPress is almost a no-brainer. One is going to cost a lot of money, the other is going to give you the chance to learn something new and valuable.

But if your needs are more complex, then maybe the scales begin to shift more towards getting professional help.

All of that aside, there was one thing that had my interest when about getting into using WordPress though…

Speed

Nowadays, everything on the web is about speed. Page load, it’s incredibly important and not only has a direct effect on your Google rankings but also your customer conversion rate.

You might think that “conversion rate” simply refers to an e-commerce site, but all websites have a purpose, even this one you’re on now. Hopefully, through reading the content you’ll subscribe, comment, or engage in some way.

However, you’re far less likely to ever get the chance to do any of that stuff, if the page you are trying to reach takes too long. You might give up and just go somewhere else if it takes a long time!

So, here I am, a new WordPress installation, a new theme installed and I’m thinking, how much work have I got to do to get this to load in a half-decent time.

Just like any other website, I begin with some basic testing.

Testing

Google PageSpeed

The cornerstone of any website benchmarking, google pagespeed. That’s where we want to be found, so it makes sense to find out exactly what we’re lacking direct from the horse’s mouth right?

Normally, (unless there’s a specific purpose) I’ll use the homepage to test as in theory that page *should* be getting the most traffic.

So, out of the box, what sort of score am I getting?

That’s not quite as bad as I thought it would have been, although, to be honest, it’s not great either.

There’s a couple of obvious things that could be impacting this straight out away. For example, currently, this site is hosted on a “shared” hosting environment. This means that it lives on a server, alongside a bunch of other websites that have nothing whatsoever to do with me.

Every site on this server is requiring its own resources to run, and hopefully, none of them are asking for too much. Ultimately the server can only handle so much.

Also, because this is a shared host, it means I as the developer have very limited access to the actual setup of the server itself.

As a result, I happen to know that this server is NOT running the latest version of PHP. This also maybe be causing slight performance issues.

Both of the above problems are easily resolved by migrating the site to a cloud computing platform, such as Amazon AWS, Microsoft Azure or the Google Cloud platform to name a few.

I’d be able to install whatever I wanted on the server, update everything and even run a dedicated instance if I wanted to, to avoid sharing resources.

However as you might expect, this doesn’t come cheap, there is no point doing this sort of stuff until you are sure you want to take your website very seriously.

Opportunities

If we take a look at the feedback Google gives us regarding our page, we can see what sort of things we need to correct to make a positive change.

Number one on the list is “Reduce initial server response time”, this is exactly what we were talking about above. Shared hosting means we have no control whatsoever over how fast or slow the server responds to queries.

Annoyingly, nothing much we can do there right now, although it’s an easy win once we’re happy that this website is worth the money of setting up proper hosting.

Remove unused Javascript

Next up, we have “Remove unused Javascript”, this one is fairly simple really. It means that of the Javascript we are loading on this page, some of it is unused. Therefore we are taking up extra time and resources, loading something we don’t need!

Helpfully, Google will even tell you which Javascript files are causing the issue as well.

For us, currently, there are four files, one of which is google’s reCaptcha script, and therefore not something we can do much about. However, the other three, are all loaded through our theme.

Why is there unused Javascript in my theme?

This is the thing with WordPress you see. Whilst it is GREAT as doing a lot of different things, in a lot of different ways, giving the user tons and tons of flexibility to build whatever they want. It’s not going to be very good at being compact and optimised, simply because the theme creator can’t know what you will and won’t use from what they are building.

For example, perhaps there’s a big of Javascript in there to handle some sort of gallery. Well, that’s great, but I’m not using a gallery on this page. So that script which might be loaded in scripts.min.js for example. Has to be loaded, despite being useless to me on this page.

Now on another page, I might use a gallery, and therefore that script becomes useful. However, I can’t specify what I do and don’t want on each specific page.

If your goal is to reduce your load time as much as humanly possible, you would need to think about whether or not you are ever going to need certain elements within the script. Then you could remove them.

It should be fairly obvious at this point that, those sorts of decisions about what you do and what you do not want, should be saved until AFTER you have finished developing your website!

You eagle-eyed viewers may have noticed that 3rd on the list of Javascript files, is jquery.js and it’s stating it’s using version 1.12.4, this seems like quite an early version to be using, so if you’re in a similar situation and you’re using WordPress there’s a quick and easy fix!

Simply install the plugin “jQuery updater” by Ramoonus, after activating it, not only will it replace your current jquery version with the latest version, it also does the same for jQuery migrate (which was the last file in our list).

If you’re not using WordPress, you’ll have to manually replace your scripts, hopefully with CDN links from somewhere like CDNJS. I’ll go into why we use CDN’s in another post altogether some time.

Enable Text Compression

Text compression isn’t something that your average blog poster is going to be familiar with at all. However it’s fairly straight forward to put in place and can save you a little on your load times, so it’s worth doing.

If you’re using WordPress, the easiest way is to install a plugin called “W3 Total Cache”, I’m sure there are plenty of others as well, but this one is one of the most popular out there.

It has a load of options in it, but the ones you’re going to want to look out for are, “Minify”, “Browser Cache”, “CDN”, which all can be set to enabled.

What that’s done (among other things) is edit your .htaccess file, which is essentially a set of rules which dictate how your server responds to the requests coming from the user before the page loads.

If you go and inspect that file, you’ll see something a bit like this:

<IfModule mod_deflate.c>
        AddOutputFilterByType DEFLATE text/css text/x-component application/x-javascript application/javascript text/javascript text/x-js text/html text/richtext text/plain text/xsd text/xsl text/xml image/bmp application/java application/msword application/vnd.ms-fontobject application/x-msdownload image/x-icon application/json application/vnd.ms-access video/webm application/vnd.ms-project application/x-font-otf application/vnd.ms-opentype application/vnd.oasis.opendocument.database application/vnd.oasis.opendocument.chart application/vnd.oasis.opendocument.formula application/vnd.oasis.opendocument.graphics application/vnd.oasis.opendocument.presentation application/vnd.oasis.opendocument.spreadsheet application/vnd.oasis.opendocument.text audio/ogg application/pdf application/vnd.ms-powerpoint image/svg+xml application/x-shockwave-flash image/tiff application/x-font-ttf application/vnd.ms-opentype audio/wav application/vnd.ms-write application/font-woff application/font-woff2 application/vnd.ms-excel
    <IfModule mod_mime.c>
        # DEFLATE by extension
        AddOutputFilter DEFLATE js css htm html xml
    </IfModule>
</IfModule>

Whilst this is nothing to worry about, it might be useful for somebody who isn’t using WordPress, as it can simply be added to any .htaccess to get the same results (providing mod_deflate is enabled on the server).

Simply put it’s just a list of different file types and an instruction to the server to “deflate” them before rendering them, in other words, take out anything that’s not needed, whitespace, line breaks, etc.

Removing Unused CSS

Unused CSS is exactly like unused Javascript, there’s a lot in there in case you use it, but chances are you won’t use everything on every page.

I’m not going to go too deep into all of this, but what I like to do (once I’ve finished with a website NOT whilst it’s still in development) is to use another great tool called PurifyCSS. What this does for you, is scan all your CSS files, and filter out anything that you’re not using on the page you specified to it.

It’s important to note, that if you enter one URL for example, the homepage, it will only take into account what’s required for that specific page. You can, however, add more URLs, for example, a category page, a product page, a blog post page, etc to build up a more complete picture of what your entire site uses rather than just one page.

Once you’ve done that, you can simply click, “Download combined, purified & minified CSS” which will give you one CSS file containing all of the CSS your site needs. Wonderful!

Obviously please use this with caution and don’t overwrite any original files in case there’s anything you might still need in there.

What has all this effort got us?

A decent amount of improvement!

We’re in the green on both types now, although there’s still a long way to go.

At the moment I’m quite happy with that, the main and most critical issue is still the server response time. However, as we discussed earlier that should be fairly easy to solve when the time comes.

Conclusion

So when I started this post, I asked the question, why am I using WordPress?

The answer now after delving a little deeper is quite simple. The purpose of this website, was for me to put something together at speed, for very little money and with an end result that’s more than adequate.

If I feel the need to enhance it further through speed improvements, etc, I can without necessarily even getting my hands dirty with code or server tweaks.

I’m now sat here only two days since I decided to even begin this, with a fully functioning blog site and my first proper blog post on it, open to the public and ready for all the accolades and praise that I so rightly deserve. As opposed to still being sat here working on a responsive layout.

Hopefully, that is a good enough reason and you’ve enjoyed taking this journey with me.

Do you like looking at more technical things, like improving page speed and performance? Or perhaps you like learning about the tools of the trade and what’s out there, maybe even something else altogether.

Why not let me know in the comments!