Project Highspeed – Before the Start

This is the first of what will be a series of blog posts describing and documenting the building stages of the new website for our side project After a lot of reading and thinking, the implementation phase has started recently. This article summarizes the approach chosen and also why other approaches were not considered.

Background on Pinhok Languages

Pinhok Languages has been a side project of Wohok Solutions to fill downtimes when less project work is to be done. Under the brand, we publish vocabulary books to give learners around the world access to high-quality learning material.

The current website was implemented using WordPress and the Divi theme. Given the nature of this being a side project and starting out more like an experiment, efficiency and time-to-market were important factors, speed and scalability less so, even though both were addressed and implemented in a decent way. The main reason for the decision to rebuild now has to do with starting to push content creation in the blog area together with SEO measures.

Speed more and more important for SEO

I followed general SEO talk online as well as Google’s AMP project for quite some time and the trend is clearly that quick websites rank higher in search results, especially on mobile. This was nothing new to me. However, a look at the number of clicks in one of my older projects left me a bit baffled realizing how important speed seemingly has become. is a very old website and I haven’t done any work on it for several years. It’s not pretty, not current and isn’t linked to too much. The only thing it has going for it is that it is quick, both server side and for loading.

I hadn’t looked at the statistics of that site for over 1 year but went back and took a look just out of curiosity two weeks ago. The number of visits were stable until this spring where numbers suddenly doubled. Most of the visits to the site come directly from search engines, so the only real explanation I have for this is that speed became a much more important factor in search algorithms.

Current website

This made me think and re-evaluate what I planned to do with going forward. I had planned to keep the site on WordPress and build a custom theme for the site to improve performance beyond what was possible with the Divi theme. I love Divi and it’s perfect for many smaller websites, but to keep flexible in the future, I planned to make a change and go with Advanced Custom Fields (ACF) as only input method on the backend.

For people interested, here’s what I use on the current WordPress site:

The resulting performance both in terms of SEO and speed is actually very good and if I wouldn’t plan to add a number of new features in the future, I would stick to what I currently have. Here are the current Google PageSpeed test results:

Looking at the results it’s clear that there’s still room for improvement. If you do WordPress development, however, you know that many things here have already be optimized to get to this score.

WordPress and its limits

I love WordPress and use it for most of the websites I make. In fact, our company website also runs on WordPress and thanks to a custom theme together with good architecture it has great speed. However, for this project I want to see how far I can go with speed optimization and that’s where I got to the limits of this great CMS.

It’s actually not so much WordPress itself than it is the plugins that are the problem. Even though the plugins I’m using are first class, I’m limited in what I can do about their performance. They are optimized, but not optimized enough for what I want to achieve with the new website. Based on this, I decided to part ways with WordPress for this project and go back to the roots, back to what web development used to be like several years ago before WordPress & Co came along.

Accelerated Mobile Pages (AMP)

I followed the developments around AMP since it was first introduced by Google in 2015. It’s a great idea and I started to get more into it recently. During that process, I read a lot on what experts and fellow developers had to say and in the end came to the conclusion that it’s not the right tool for this project either. The main problem I have with AMP is that it’s not a standard, it’s a Google project and it is open source, but it’s not a web standard and that means it might change or be discontinued in the future.

However, there are several ideas of AMP that I have taken to heart and will use in similar fashion during the implementation of the new website:

No Javascript

I admit this is an extreme measure and for some articles in the blog area I won’t be able to completely avoid the use of Javascript, but it is something I want to try. Over the last months I was reminded of how slow some websites get due to the use of too much Javascript. I had some problems with my GPU and was running on the basic graphic chip for some time which made me realize just how much Javascript is slowing things down and how quick websites without much Javascript were loading.

Given that is mostly a content website, Javascript would only be used for styling reasons and maybe for the contact form. Styling is, of course, important, but I would argue that with certain limitations, it is possible to create a good user experience without using Javascript – maybe even a better one. When it comes to the contact form, it’s also possible to do things without Javascript – basically go old school and validate the input server side, something that needs to be done anyway.

No database

On the backend, I decided to not use a database but rather have all the content stored in files. This is quite convenient for me as a programmer, as I know the structure of the files and might even speed things up in the process of publishing new content. If I would do this for a client, I would build an admin are where the client can edit the content and store the files as JSON. I would probably also use some sort of database in a client project, as it’s usually even quicker, but for this project I have a good reason not to.

Going without a database has the huge advantage that I can use GIT both for publishing new content and as backup system. Pushing changes to the repository will automatically be populated to the server and appear immediately on the website. Having the content locally, in the repository as well as on the server also immediately creates security and acts as an automatic backup system.

Do I need a framework?

After ditching WordPress, the final question was if I would use a framework or if I would start completely from scratch. I played with the latter option for some time, had to realize, however, that some sort of structure and forced architecture would be good to have.

I decided to go with Codeigniter as framework for this project mainly because I have worked with this framework a lot and because it has good speed metrics when used properly. Like most frameworks, Codeigniter also provides good support for multi-lingual websites, a major factor for the decision to ultimately go with a framework over developing the new website completely from scratch.

Next steps

The next steps are the implementation of the new website starting with header and footer. Given that this is a side project, the implementation will take some time depending on the workload from other projects. However, I will put up more posts on progress and interesting parts of this project on a periodic basis. If you have any questions, please get in touch through the contact form!

Share this Article

About the Author

Wolfgang GeigerHi, I'm Wolfgang, the founder, director and developer behind Wohok Solutions. Passionate about web development from an early age, I have built websites for more than half of my life. I have degrees in both, Computing and Business Management and I am fluent in German, English and Mandarin. Based in Hong Kong, I help companies in the city and around the world to improve their business through technology.

Get in Touch

Do you have any comments or questions? Get in touch, I'd love to hear from you!