Massive Site Migration for the World’s Leading Web Engine Platform

NGINX is a global company providing an award-winning web server and application platform used by more than 300 million websites worldwide. Their website, nginx.com, is a critical tool powering their complex marketing operation. As a massive website, with years of many hands working on it, the NGINX code had gained some quirks and become fragmented. So the NGINX team was looking for a development partner with WordPress expertise to recode it properly.

NGINX is a global company providing an award-winning web server and application platform used by more than 300 million websites worldwide. Their website, nginx.com, is a critical tool powering their complex marketing operation. It’s also a public symbol for their performance-driven brand.

As a massive website, with years of many hands working on it, the NGINX code had gained some quirks and become fragmented. So the NGINX team was looking for a development partner with WordPress expertise to recode it properly. Critically, NGINX wanted no loss in existing search engine rankings due to the update project.

Solutions Provided

Web Development
Agile Development

Discovery

The NGINX website contained hundreds of pages, blogs posts, ebooks, glossaries, infographic libraries, white papers, reports, data sheets and admin resources.

Millions of visitors were regularly accessing this content, and all of the content would need to be handled and preserved perfectly during migration.

Because new pages had been added over a series of years, with no central design requirements, templates were not consistent across pages. So depending on the page, the look and feel could vary significantly.

During discovery, we determined that the NGINX WordPress site had a lot of its content embedded directly into the code. This meant that if marketing, sales, or another non-technical team wanted to change the content, they couldn’t do so without the help of a developer.

This was a huge bottleneck for making changes to the site. The NGINX team needed to be able to maintain and update content in the marketing department without needing a coder to make those changes.

The NGINX site also had integrations with about 10 different third party services utilized in their marketing efforts. A CRM integration, an AB testing platform, a marketing automation solution for form fills and marketing funnel management. Google Tag Manager was in place for analytics and for including other code. Several JavaScript libraries were in use as well as some custom WordPress code that would need to be preserved through the migration.

The NGINX team was also using a legacy plug-in Meta Boxes to add custom fields. In our assessment, this was not the currently accepted best practice for adding custom fields to WordPress.

We migrated the site from using Meta Boxes to the more user-friendly Advanced Custom Fields

With Meta Boxes, field groups are defined in code. So if you want to add field groups, you have to do it in code inside of a custom template. We would need to address this, most likely with a more standardized, user-friendly solution like Advanced Custom Fields (ACF).

Our goals were clear:

There should be no loss in existing search engine rankings due to the project.
We needed to achieve less than 20 search console errors post-migration.
We needed to update the infrastructure to be templated. Meta title, description, alt tags, etc, should all be set to follow SEO best practices.
All content and meta content visible on a page should be editable using the CMS.
We needed to remove any unused elements in the CSS and JavaScript. This would make the files smaller which would lead to faster load times.

NGINX needed the entire site — new pages, new infrastructure, updated pages and templates — fully tested for functionality and performance ready to launch by end of summer 2018.

Lastly, Launch Brigade would need to rebuild the plane while it was in flight: There’d be a continuous stream of new blog posts published during the development and migration process. The newly rebuilt site would need that content synced smoothly as well.

Design

We set about updating the site, cleaning up the underlying code while ensuring that the front end of all templates remained pixel perfect replicas of the originals. Menu headers, footers, and other brand elements needed to be designed so they could be easily implemented on any web page.

Extra time and care was spent separating content from design, so that content was no longer hardcoded and could be changed using the WordPress CMS, without the help of a coder.

The main WordPress theme needed to be robust, responsive, and modular. It had to work well across any device and screen size, and the content on any given page needed to be easy to move around the page.

To improve site performance, we removed old, extraneous and unused CSS and JavaScript elements, such as unused trackers, object classes and IDs. These improvements decreased load times.

In addition to fast page load times, there are other measures of page performance. Google and the user both care how long it takes for the web page to be usable and interactive. Even if some elements have not been fully loaded yet — like those at the bottom of the page — if top of the page can be loaded a second or two earlier, the user can begin using the website as intended. Google recognizes this and gives web pages that load in this special order a better score.

We also made improvements to the NGINX site in terms of how the actual construction of the page happened. For example, ensuring that things like render-blocking Javascript, which delays loading any part of the page until the entire page is loaded, is turned off.

We had certain objectives that we needed to achieve in terms of the Google page speed insights score of above 80. They needed a complete page load in less than five seconds, and a time to first byte of under half a second.

We worked with NGINX’s hosting provider to determine how to better optimize the site and get even faster speeds out of it.

The scope and complexity of these efforts made the website rewrite a little bit more like a software development project than a simple website. Several pieces of code within the site were managed in a revision control that had a deployment process that involved third party tools like Codeship.

The other main objective really focused on the search engine optimization side. We absolutely had to maintain PageRank. While we at Launch Brigade have no direct control over what Google decides to do, we do have control over certain things. We can audit a site and find out where things are broken that we know Google would flag and weight negatively.

While the visual look remained that same, the changes we made in the backend greatly improved site performance.

For most projects, we prefer to build a new theme from scratch, starting with something pristine and building everything into it. It’s an additive approach.

For NGINX, we decided against that approach. The NGINX site had so many moving parts, it would have been too easy to miss something during the migration process.

Instead, we used a subtractive approach.

The CRM and marketing automation portions of the WordPress theme were very fragmented. In a small WordPress site, you might have four to six templates within the theme. NGINX had more on the order of over a hundred different template files, as well as partial templates. (When you need to re-use code, you put it in a partial which you then include it in the various templates.) This was in addition to the in-line styling we identified.

We went through all of the various styles that NGINX had and then put them into a unified CSS file. For this, we used one of our standard tools, Sass — Syntactically Awesome Stylesheets, a framework for managing the CSS. Because the site is so personalized on a per page basis, pages that used a specific template might have specific Sass settings for the page that uses that template.

The intent was to provide consistency throughout the site so that styling could be re-used.