Gruse Mechanical Engineering


This was a rather special project: The website had been launched, concept and design long done. But the technical base did not work as expected. It needed a technical overhaul, while the look and feel had to stay the same.

Background information

The agency kilometer19 asked us to take a look at the website of their client, Gruse GmbH. The client was upset about the performance of the website.
Looking a bit closer we saw that the client did have a point: It took 11 seconds and more before the website actually appeared.

Google Chrome DevTools; medium DSL speed; two measurements in quick succession

For one page view the website needed to load a lot of files (183 requests) but only some of them were actually needed to display the page. The typical measures like caching and optimizing images didn’t change much. Therefore we proposed to change from the multipurpose theme to a much leaner theme.

Gruse Mechanical Engineering

  • Multisite
  • WPML to MLP
  • Multilingual
  • Removal multipurpose theme


We first created an exact copy of the website in our development environment and installed a new clean theme as well as the page builder plugin BeaverBuilder.

Extracting the content

The website had been built using the theme Avada, one of best-selling multipurpose themes. These themes are not really themes in the WordPress sense of the word, but collections of a theme plus plugins. But as the plugins are tied into this bundle it is not possible to address one of them separately. So it’s impossible to either deactivate functions you don’t need or to really make custom adjustments.

Normally changing the theme should not be a problem with WordPress. But due to the mix of theme and plugins it was pretty much impossible. Avada’s Fusion-Builder takes text and layout information and bundles them up into a complex mesh of shortcodes. This way it is impossible to just reuse the content once you have endeavored to change the theme. This is what it looks like in the WordPress editor:

This is what the front page that had been built using Avada looked like in the WordPress editor after we changed the theme.

Chaos in the database

After that, we deleted the Avada theme in order to work with the new theme and WPML (plugin to build multilingual websites) which the agency held a license for. But it turned out that both the Avada theme as well as the links between the Avada theme and WPML were not deleted entirely.

It is good practice in WordPress that themes and plugins remove all their data from the database once you delete them. Unfortunately there are quite a few developers who don’t follow that rule. Avada left lots of database tables as well as thousands of sets of data in the database.

We tried to delete WPML and reinstall it, but to no avail. Same thing here: WPML did not remove all its data from the database. The problem was that this made it impossible to work with WPML in connection with a new theme.

Meanwhile the performance had improved significantly:

Google Chrome DevTools; medium DSL speed; two measurements in quick succession

Clean Install

We then decided to transfer all content (text and images) into a new WordPress install and to continue with a clean basis. That did take some time, but this way we omitted searching for mistakes and figuring out how to fix these which in our experience would have taken much longer.

Since we had four languages to organize we chose to implement multilingualism via a WordPress multisite install and the plugin MultilingualPress Pro.


The performance of the website has improved drastically. Loading the front page does not even take 2 seconds anymore. Originally it took more than 10 seconds until the page was loaded.

Google Chrome DevTools; medium DSL speed; two measurements in quick succession

We moved the website to our hosting partner Spacehost which provides modern, fast hosting, with the focus on the needs of WordPress websites. With the new theme, there are only 62 file requests when loading the home page, instead of more than 180 from before.

The different language versions are now strictly separated. Each language has now it’s own website with own database tables within a WordPress multisite install. The plugin MultilingualPress takes care of connecting the different content elements with each other. This way the structure is clear and less prone to get muddled up.