2018 was the year of website speed. That’s what we’ve been hearing from our customers, industry colleagues, and Google. Many influencers see slow websites as the biggest issue facing the web today.
​
In July of 2018, Google announced to use speed as a ranking factor. Add to that the fact that Google will use the mobile-first index and you can see that mobile + speed is very important for success on the web. In addition to the importance Google places on it, speed is important for other reasons too.

For example, we know sites that show users content quickly are much more likely to show engagement, conversion, and lower bounce rates. We know from DoubleClick that 53% of mobile visits are abandoned if it takes them more than 3 seconds to load. In other words, if you’re running any paid advertising, half of your budget could go out the window because of a slow site.

Various industry initiatives, including Google AMP (Accelerated Mobile Pages) and Facebook Instant Articles, aim to speed up mobile pages. But the most important and broader issue is making standard web pages load and start rendering faster. This means that the user, especially the mobile user, sees the initial page displayed while more content is loaded in the background.
​
For these reasons, since June of last year we decided to embark on a speed optimization project: to follow Google PageSpeed recommendations to make our sites load faster and score higher.

We have the only Google Preferred Website Platform that is fully aligned with the search giant’s best practices for creating websites with the best possible load times. From now on, every responsive website on our platform, both new and old, will be optimized for speed.
​
Accomplishing this goal meant making a lot of improvements and adjustments in the way our Rocket Driver sites are coded, but by far the biggest challenge was removing any render-blocking JavaScript or CSS.

Google Page Speed
​Fully Editable Powerpoint Presentation:

​

We’ve made sure that all the Rocket Driver sites now get a very high score on Google PageSpeed, but what does this mean to actual users? The good news is, since the Google PageSpeed score ensures that the initial rendering of a page happens really fast when we compared our sites before and after using another tool called webpagetest.org, we saw a huge improvement in initial rendering time.

As you can see in the table above, we improved start rendering time by anywhere from 100% to a whopping 500%! And that’s what really important to users. When browsing sites from a slow mobile connection, this optimization is even more dramatic.

We couldn’t resist testing sites of some other website builders in the market. To keep the tests as fair as possible, we took the first template we found and published it without adding content or making modifications that could reduce the PageSpeed score.

WordPress is obviously very fragmented, has many different versions, and many themes and theme developers, so page speed can vary drastically between themes. We picked the first theme offered for businesses on wordpress.com. 

The biggest challenge was making sure that most of our JavaScript and CSS code wouldn’t block the browser from rendering the initial content of the page. For the JavaScript part, we refactored our JavaScript framework so that none of it is required in order to render the page. After the refactoring, we moved all JavaScript towards the end of the tag. This ensures that the browser loads the code last, instead of first, prioritizing the content over the JavaScript execution.
​
The CSS part was trickier. The browser needs CSS definition in order to show the styling of the page elements. If we were to move all the CSS to the bottom of the page, the initial rendering of the page would look ugly, as elements would be rendered without styling, and only after a second or so, styling would be added. This is definitely not what we wanted to achieve here.
​
Instead, we found a way, when publishing a site, to identify which CSS rules are critical to the initial rendering and placed them at the head of the page. The rest of the CSS was pushed to the end of the body, as it is not required for the initial rendering.
​
This calculation is quite heavy and needs to be done at scale, as many Rocket Driver sites can be published at the same time. We used a relatively new service provided by Amazon Web Services called “Lambda” that helped us parallelize this process efficiently.
​
We also worked hard to optimize image compression and resizing (we create several sizes of every image uploaded to Rocket Driver). We also started using the most recommended lossy image compression to significantly reduce image size while keeping image quality very high.
​
Finally, we decided to make the entire process asynchronous (i.e., it runs in the background and allows you to keep working) so that publish time won’t take longer than it does today. Typically, sites are optimized for PageSpeed ~30 seconds after publishing is complete.