After moving my blog from Wordpress.com to my Gatsby powered blog, I ensured that all my links indexed by Google and backlinked from other sites were still valid by having redirects from the original urls to the new urls.

Yesterday, I did a quick analysis of my traffic that shows that my strategy was a success.

As seen on the following graph, I have about 49 sessions per week. Not much, but roughly the same as when I had my Wordpress.com blog running.

Looking at my traffic sources, most of the traffic is organic from search engines, primarily Google. This indicates that my redirects from the existing index urls works as intended.

Finally, looking at the page report, I can see that my recharts and intel posts are still the most viewed, which was also the case for my Wordpress.com blog.

All in all, the move did not affect my SEO negatively.

Before migrating from Wordpress.com to my GatsbyJS site, I did a website speed comparison using GTmetrix.com which runs PageSpeed and YSlow tests to determine the speed score of a site.

As seen, my Wordpress.com site was not exactly a high scoring blog on the Internet. To be fair, I never did anything to improve the performance of the site.

The new GatsbyJS site performs extremely well out of the box, much better than my Wordpress site. The comparison is not even an apple to apple comparison, since for the Wordpress site, I only loaded a few of the blog posts on the initial load. For the Gatsby site, I generate an Index file containing ALL my blog posts! The latter allows searching on the site using the browser search, which is just plain awesome.

For the Wordpress.com blog, blog posts were lazy loaded as the browser scrolls down. For the Gatsby blog, images are lazy loaded as they are shown. Looks a bit strange, but the responsiveness (as in performance) is a huge win.

The YSlow score could be better, buuut I think I will put that on my endless todo list for another time :-)

I initially started this blog the 3rd of January 2017 on WordPress.com, which is a hosted / SaaS / platform of the open source WordPress CMS: https://en.wikipedia.org/wiki/WordPress.com I just needed a place to blog, nothing more and nothing less, with no clear requirements on plugins, speed nor look and feel.

Early 2020, I heard about GatsbyJS from one of our DevOps consultants, a static site generator that leverages React to generate “blazing fast sites”. GatsbyJS sources data from one or more data sources, transforms the data, exposes the data through GraphQL and generates one or more webpages using server side React that can be deployed to CDNs (Content Delivery Networks) such as Netlify, GitHub Pages, or any web server that can serve static files. In addition, the static pages are ‘rehydrated’ after rendering in the browser, allowing React to be used in the DOM even though the site is pre-rendered and served as ‘static’ files.

This has many benefits:

• Serving HTML directly to the browser via a CDN is very cost-efficient, due to the distributed nature of CDNs and due to the static files being static and thus highly cache-able. This is harder to achieve when using server side generated pages, since a server is responsible for generating the pages upon requests from a browser.

• The browser can ‘stream the resources into the DOM’ while downloading, to provide an early partial rendering of the page. This makes the speed of the website seem very fast, since the DOM is changing the moment the user enters the site. SPAs (Single Page Applications), such as many React apps, typically lack this behavior since they need to download a JavaScript bundle, manipulate the DOM and then display the resulting page, which can easily take a few seconds.

• Compared to a SPA, since the page is statically generated, the initial DOM is contained in the HTML files and thus easier for Google and other search engines to traverse, increasing the ‘SEO Score’ of the site.

• Dependent resources, such as images, can be transformed before being outputted to fit the generated page, e.g. a 4K image can be transformed to fit the 800px of a div without requiring manual image manipulation software.

There are drawbacks as well:

• Since the site is ‘static’ no dynamic behavior from the server can be achieved, only DOM manipulation from a client side library such as React can change the page after initial rendering. GatsbyJS uses the re-hydrate feature of React to enable ReactDOM after the initial page rendering, but if the site is primarily consuming a data source which is server side, such as an SQL data source, React in the browser has no chance of consuming this and can thus not update the site.

• Updating the site with new changes to the server side data sources requires a rebuild of the site and upload of all the static resources. This can easily take minutes when doing a big site, meaning that content update is not visible to the user before a new deployment (like the good old days :-P)

• If using CDNs, there can be a delay between the upload of the site and the propagation through the network.

In any case, May the 11th I started migrating from WordPress.com to a ‘Gatsby generated site’. To achieve this, I had to do several things:

• I needed to export and import all my WordPress blogs into a format GatsbyJS could understand. GatsbyJS can source data from Markdown and transform this into HTML, so I decided to leverage this functionality and convert all blog posts into Markdown using a mixture of homebrew and standard tools (a blog post on its own)

• I needed to implement the blog using React and hookup the markdown data source. Luckily for me, the blog starter provided this out of the box: https://www.gatsbyjs.org/starters/gatsbyjs/gatsby-starter-blog/ and I could simply copy and paste :-)

• I needed to implement tag support, since this was not provided by the blog starter and my WordPress site uses tags.I had to extend the markdown with tags and extend the gatsby-node.js file such that ‘tag pages’ could be generated. (also a post on its own)

• I wanted a look and feel similar to my WordPress site, so I made several smaller adjustments to the way the site was generated, with the primary adjustment being that all posts are served from /index.html including the content of the blog posts. Lucky me, the blog starter do lazy loading of all images so I simply output all blog posts without issues. This might not scale when I have 1000+ posts, but hey! that’s a problem for a future time.

• I needed a simple way to update my site with new blog posts. A bit of googling and I found Netlify-CMS, an open source SPA that can be embedded into a site and be used to read and write markdown directly into GIT. (also a post of its own)

• I needed a place to put my generated site. Initially I had chosen Github, but with the googling of Netlify-CMS I decided to tryout Netlify and host my site there.

• Lastly, I needed to redirect my routes such that when I point Deepstacker.com to Netlify, Google gets a 301 in its face when asking for paths from the old WordPress site. Netlify supports the writing of a _redirects file, where one can redirect from X to Y, making it easy to enforce a redirect from the WordPress format to the new Gatsby format.

That’s it! My Gatsby blog is now alive.

Stuff I still need to do:

• Fix some conversion errors in the old blog posts
• Add the ‘about me’ page, which I have not yet moved from WordPress.
• Improve look and feel a bit more after getting some feedback.
• Improve SEO
• Analyze the speed of the site and fix potential bottlenecks.

I am a huge fan of static web-sites with no fuss, especially in regards to blogs where ease of consuming information is the key. Recently, I have been looking into site generator frameworks to help generate fast and ‘no fuss sites’. One of my consultant buddies recommended me to look into ‘Gatsbyjs’.

So I did! Gatsbyjs is a site generator for React. It provides the ability to generate HTML based upon one or more React templates. What makes Gatsbyjs a bit special, compared to some of the other site generators that I have seen, is the fact that it abstracts away the file system (and other data sources) using a GraphQL.

GraphQL is a query language for API’s. Using GraphQL, one can request what is needed, including references to other resources, by specifying a query containing the types of resources and their relations to other resources. Compared to a REST API, which typically returns a predefined representation, GraphQL allows much more control and is type-safe since the resources are described as types (including references to other types) and not as endpoints .

Gatsby provides the ability to source data from many different sources: file-system, sql, mongodb, rest, etc. into GraphQL. In addition to being sourced, data can also be transformed, e.g. Markdown can be parsed for easier consumption, images can be optimized for the web, etc..

Pages can be generated in many ways. Simplest way is to put a React component into src/pages, which in turn is rendered to HTML and copied to output. Pages can also be generated programmatically, using the createPages API, or by importing a plugin.

Pages can run GraphQL queries that return data previously sourced, allowing the page to be populated with data from the GraphQL server and in turn statically generated and saved in one or more HTML files.

Gatsby also supports Reacts concept of “hydrate”, making it possible to add client-side React to a static generated page and thus provide app like functionality when all JS files have been loaded.

Next step for me is to try to implement this Blog using Gatsbyjs and see how it performs and manages - and if the results are good! Move my blog 100% to Gatsbyjs.