Tuning Frontend Performance on ScaleWP.io

Scalewp.io is a WordPress site I built a custom theme for in early 2016. Aside from WordPress core and plugin updates the site hasn't had any active development since. A couple weeks ago I took some time to tackle improving the performance of this site so it can last another two years (or more).

Spoiler Alert: After the improvements, which we will cover below, the mobile network performance improved by 4x, with time to first paint going from 2,910 ms to just 730 ms.

Baseline: Where are we starting from?

Before I began work I wanted to get a baseline of the current site performance in order to know the difference the improvements made. I used Google's Lighthouse tool for this and ran the test over a Verizon 4g hotspot. I did this with the Chrome browser, in incognito mode, to avoid extensions slowing down the page speed. Let's look at the results and highlight some areas to improve.

Lighthouse Results (pre-improvement)

  • First meaningful paint: 2,910 ms

  • Reduce render-blocking stylesheets: 770 ms

    • Main CSS file

      • 7.59 KB

      • Delayed first paint by 796 ms

    • Raleway font CSS file

      • 0.79 KB

      • Delayed first paint by 715 ms

  • Reduce render-blocking scripts: 1,004 ms

    • jQuery

      • 38.77 KB

      • Delayed first paint by 1,004 ms

  • Serve images as WebP: 480 ms

    • Main banner image

      • Size: 145 KB

      • Potential savings: 78 KB (54%)

  • Properly size images: 290 ms

    • Main banner image

      • Size: 145 KB

      • Potential savings: 56 KB (38%)

Removing Render Blocking Code

What is Render Blocking?

Code is considered rendered blocking when the browser must download and process it prior to creating the DOM and other parts of the page visible to the user. This delays time to first paint (when the page has something the user can look at) and time to first interactivity (when the site is usable). This can include everything from your own JS and CSS to third-party items, like social media. The more items that the browser has to process before page rendering starts, the slower your site will be and seem to users.


Scalewp.io was using jQuery, which WordPress loads by default in the <head>. The jQuery wasn't doing anything fancy—just checking/setting a cookie, adding/removing classes and adding smooth scrolling. I traded jQuery for Zepto, a lightweight alternative, which is 9.6 KB compared to jQuery at 38.7 KB. Additionally, I was able to use wp_enqueue_script to add Zepto before the closing <body> tag instead of in the <head> so it was no longer render blocking. This is a bigger win that just the reduced script size since it eliminates the need to connect and request an additional asset before rendering.


For the home page I wrote separate CSS for just the critical components. This CSS is inlined in the <head> and the main CSS file is deferred and loaded later so it doesn't block rendering of the first meaningful paint, allowing the user to see content faster. The minified critical CSS is 12 KB compared to the 51 KB full CSS file. The critical CSS also skips loading heavy items, like the large banner background image.

Here is what the page looks like with only critical CSS:

wpscale homepage with critical CSS

This version of the page will load initially with the full version being loaded after. It's interactive so users can click on links and start using the page while the banner background image and other items continue to load. This can also help protect against a broken external resource, such as third-party JavaScript or an API, from delaying the page render.

Image Optimization


WebP is a newer image standard that offers significant savings compared to other, older image formats. I converted the main theme images, including the large homepage banner background, to WebP. Currently browser support isn't all there yet so I added a WebP polyfill that loads for browsers without support. The polyfill is 69 KB. The main banner image alone is 142 KB in JPG format and 42 KB in WebP—a 100 KB difference. Browsers like Chrome that don't need the polyfill will see the full 100 KB savings and browser that need the polyfill will still get a 31 KB savings. Other theme images that are WebP will just add to the savings making the switch and use of polyfill worth the effort.

Correct Size

The home page had a large, full screen banner. Previously it only had a desktop size which was being served on mobile as well, requiring mobile visitors to download the large image. I created a mobile version of the image and used media queries to load it instead when the window is less than 480px. In WebP format, the mobile image is 8 KB compared to the 42 KB desktop version—that's an 81% savings.

Font Loading

Web Safe Fonts

Scalewp.io uses the Raleway Google Font in the regular and bold versions. Loading these fonts was render blocking, adding a 715 ms delay to the page load. The fonts were also being loaded externally from Google's CDN, requiring the browser to establish a separate connection thread, DNS lookup, negotiating HTTPS, etc., rather than just re-using the existing connection.

For pure performance, a web safe font is the best way to go. However, fonts play a large part in design and using only web safe fonts can feel like taking a step back in time.

To keep the aesthetics of the Google font and improve page load, I downloaded the font files (they are open source) and added them to my code repository so they can be served directly from Pantheon—which has its own CDN—under the same domain name using the already established connection.

Finally, I loaded a web safe font first, then deferred the Google font loading until after first paint on the homepage by leaving it out of the critical CSS. The result is a fast first paint and interactive page without completely losing the font. It does result in a flicker effect, which I am comfortable with as progressive enhancement. If you or your client dislike the flicker, you can consider loading the font earlier but beware of the performance trade off.


Now that we've optimized a lot of items on the site, let's take a look at the results.

Lighthouse Results (post-improvement)

Addtional post-improvement results screenshot

When served from Pantheon's full page cache and Global CDN the site is responding in 209 ms with a first paint taking 730 ms. Much better than the 2,910 ms we started out with. That's a decrease of 2,180 ms or 74.91%! If your site is feeling slow give some of these optimizations a try. These techniques can be applied to any page but you’ll get the most bang for your buck starting with business critical templates such as the homepage and landing pages.

Topics Website Technology, Development, Guides and Tutorials, Speed & Performance, Testing & Optimization, WordPress

Let’s get in touch