The Tech Stack For My Site and Why

When I decided to rebuild my website, I wanted to make use of the things I had learned and keep it simple to avoid any problems later on. The site needed to be a simple blog where I can publish my writing and any applications I build. I wanted it to be fast i.e load quickly. It didn’t need any user login or anything that required a backend so I decided to go server less. The other requirement was that it was cheap because it was not intended to generate any money, just a place for me to publish my work.

Photo by Taylor Vick on Unsplash

I’ll take you through some of the major choices I made along with things I’ve learned along the way.

Homepage

If you go to my homepage, you’ll see that it is very basic. It doesn't have any images except for the few icons and there is no pagination, just a list of articles. This might seem a bit strange because the homepage is supposed to be amazing to welcome people in and get them excited to be here, isn’t it?

At first, I thought so too and I had plans to go back and make it special. I didn’t do it initially because it is one of those hurdles that’s easy to get stuck on and that’s where procrastination sets in. A simple homepage let me get on with things quickly and move onto the next task.

So what did I learn? Most people don’t even see the homepage. I have Analytics & search console installed and they tell me that my homepage is one of the least visited pages on the site. I’ll get more into why this is in the SEO section.

The homepage is a simple directory. I have a list of articles and pages that each have a title and short description that reflects the content. There is a short paragraph at the top of the page that explains the website so you know you’re in the right place.

The two glaring things that stand out from most websites are that there are no preview images and not pagination or filters. Having no preview images makes the homepage text dominated, this isn’t as bad as it sounds because I’ve made the effort to break things up a bit by having well-spaced/sized copy.

Having no pagination is fine with me, I don’t think I will be changing that any time soon unless I see good reason too. Most modern websites have done away with pagination and have instead gone with infinite scroll. All of the links to my content simply load all at once. I’m sure you can see why I decided not to include image previews now but this could be solved by lazy loading - i.e. the content loads as the user scrolls down the page.

A filter is something I want to implement as the amount of content increases. Right now, if you want to find an article from the homepage, you have to scroll until you find what you are looking for. A much better option would be to have a filter that narrows down the content based on what the user types into a search input. I like the idea of having a smart search that doesn’t have to rely on exact match keywords and can return results based on understanding.

Don’t need a CMS, Use github

I mentioned how the homepage is a list of previews with links to articles. As you might be able to tell, I update the site quite regularly. So, how do I publish new content? In my mind, there are three ways to update a site like mine with content; 1 - create the new pages and re-build the site then publish the whole thing. 2 - Have the site read from a database and automatically update when new information is provided. 3 - Use a CMS (content management system).

I manage this site myself and in an effort to keep things simple, I decided to go with option 1 which is to rebuild and publish the site each time. I use Github for version control and the site is built using React and Gatsby. I type the content out in notes then edit it in word to correct any mistakes. Then I format it in HTML adding any pictures and links. To publish a Gatsby project, it needs to be built first. Once I've built it, I push the project to Github, then I push the build directory to a different repository.

My hosting is set up to pull information from github when a change occurs. It means I can do all the publishing through the command line and don’t have to login and do anything on my hosting account.

I had to copy and replace the whole build file before I found a host that could link to Github. That was a pain. The good thing about using Github as version control is that only the necessary files get pushed, not the whole project.

Gatsby for speed and SEO

I decided to use the Gatsbyjs framework for a few reasons. The first being that it uses server side rendering. Second for its templating and structuring capabilities then for its speed.

Server-side rendering is necessary for modern SEO. When the google bot crawls a website, it reads through and makes sense of HTML. React is a Javascript framework that is client side-rendered. Using Gatsby on top allows server side rendering as I’ve mentioned. Google claims that it can read Javascript and I don’t doubt it can. But, in my experience, it doesn’t prioritise small sites or pages.

If you are curious about if a page is server-side or client-side rendered, right click the page and click inspect. If you see HTML it’s server side, if not, it’s probably client side.

SEO is a big part of the marketing strategy of most businesses. Especially if you don’t already have a huge presence on one of the social medias. This way, if someone searches for a term that you have a product or service for and you are a leader in that solution, you should be coming up high. It’s one way brands stay relevant.

Gatsby and its SEO capabilities allow the content that I write to get ranked in the first place. With some effort, I can get ranked on the first page or even the number one spot.