≡ Menu

Site Builder Performance Upgrades

The time it takes to load a web page is called the page download speed, or load time. Your site’s average load time is an important factor in Google’s site ranking algorithm. Web users expect pages to load quickly, and pages with longer load times tend to have higher bounce rates, and those sites are seen as less important. For more information on the effect of site performance and organic rankings and conversion, see Cloudflares article on Website Performance and Conversation Rates.

To measure site speed, Google released a SEO tool called Lighthouse back in 2018 that offers some insight on the performance of your website and its pages. This audit gives a mobile and desktop score across four areas: Performance, Accessibility, Best Practices, and SEO. For the sake of this article, we will be focusing on solely the “Performance” category of the testing and its associated fixes. So, let’s dive in!


This area is scoring based on factors such as:

  • How long it takes your webpage to first “begin” loading. This is known as the “first contentful paint” or “first meaningful paint”. This is usually based solely on the server and it’s performance, we will ignore this metric in this post since we can’t do anything about it in Site Builder.
  • How many render-blocking elements such as scripts, fonts, etc. are in the head and must finish loading before the browser can start to draw the page.
  • Are your javascript and other resources “minified” and compressed?
  • Do you defer “offscreen images”? Also called “lazy loading”
  • Do you serve properly sizes images? Are they properly compressed?

What Can We Do?

Call a web development professional! In all seriousness, you will need to, but lets go over some things in the meantime.

Header and Footer: Common Files/Scripts

We recently optimized the Site Builder site www.OhMyArthritis.com and will explain our process using it as an example. When we examined the common scripts, we found them to be dispersed throughout the header and footer. Remember that each separate request in the <head> to a script or file is going to add to our “render-blocking” scripts, and thus increase page load time.

To alleviate this and increase our improvements in lighthouse performance score, we needed to:

  1. LOAD. All of our libraries for our fonts, jQuery version, and other scripts locally rather than from an external URL
  2. COMBINE. There were 6-7 separate javascript files being loaded, we combined them all into one, which reduces the number of requests going over the network. While combining, we were able to eliminate multiple function and event listeners which also improves page scores.
  3. PRELOAD. By appending a special attribute to our javascript and style files, we can preload them from the head, which is not render-blocking, and then load them again after the entire page has loaded.
  4. MINIFY. All of the pre-existing javascript was not production ready as it was not minified. We ran all javascript libraries and common functions through a minification library which helps with browser render times and decreases page/file sizes.

Lazy Loading Images “Below The Fold”

There are a few ways to lazy load images when they become in view. One way is to use the new built-in native browser support (supported by modern versions of IE Edge, FireFox, Chrome, and Opera), the other two involve javascript libraries such as loZad and the intersection observer API. We opted for a hybrid approach using both the built-in browser support, and a fallback javascript library.

If lazy loading is not supported or recognized in the browser, then a javascript library (in this case LazySizes) takes care of it using regular JavaScript.

Image Optimization

To optimize our images and save on overall page load size, which is the biggest factor in speed and performance of a web page, we needed to:

  • Download all of the images use on our website
  • Process these through an image optimization library which, on average, saves anywhere from 25-45% of image file size (depending on what compression already existed)
  • Ensure no loss to visual quality and re-upload

Our entire image folder ended up being compressed by a total of 30%, and we ended up saving ~82mb off our total image folder size! Mark that up in the win column.


One interesting I noticed while auditing using the Lighthouse performance tool, was that it was all over the board in terms of numbers. This made it difficult to focus on the metrics we can control. First paint and other server-response times ranged from 6s to 43s during testing. To alleviate an unsatisfying / inaccurate report on our performance work, I took 3 tests before (for mobile and desktop) and after our upgrades mentioned above. This gave us a good mean, average score.

We wanted to test a set of pages that would cover all features that exist on the site. To accomplish this we chose to test:

  1. The Homepage
  2. A Category Page
  3. Two Product Pages
  4. A Content Page


  1. Homepage
    • Mobile: 14
    • Desktop: 22
  2. Category Pages
    • Mobile: 20
    • Desktop: 11
  3. Product Page
    • Mobile: 20
    • Desktop: 11
  4. Content Page
    • Mobile: 24
    • Desktop: 2


  1. Homepage
    • Mobile: 42
    • Desktop: 48
  2. Category Pages
    • Mobile: 39
    • Desktop: 41
  3. Product Page
    • Mobile: 39
    • Desktop: 20
  4. Content Page
    • Mobile: 37
    • Desktop: 27


You can see there was a definite improvement across the board, we are happy! Don’t mind the size of the scores during testing, there are some scripts and other things that are causing other issues at the moment which is drastically bringing down the numbers.

You can see we took our render-blocking resources line item from in some cases taking 3s+ to an average of 0.84s!

Average page load time across all pages, current vs previous month.


I did a little more research after re-testing and found that Google released an update to Lighthouse at the beginning of June which adjusted the weights of the different metrics (https://web.dev/lighthouse-whats-new-6.0/), and other developers and marketers were experiencing lower-than-normal scores as well.
There were still a couple of items that were glaring when taking a closer look at the numbers:
  1.  Third-Party Scripts: Facebook, Hotjar, Hubspot, Pinterest, Bing Ads, Tawk.to, analytics, etc. were contributing a half-second to the initial load time.
  2.  Script Execution Time:  LeadFlows, collectedforms.js, facebook, getsitecontrol.com were contributing about a second of execution time.
Other than the above – this was really the best we could offer in terms of performance upgrades. We are in the green at 2.3s for Time To Interactive on the homepage, which is a good sign in terms of server performance of which we don’t have control over in NetSuite.
One method to boost server performance without directly touching the server itself is through implementing CloudFlare, a content delivery network service. For more on that service please see our other article which explains it in much greater detail, Make Your Netsuite Site Builder Site Secure – HTTPS Throughout.


The entirety of what has been explained thus far is just scratching the surface on a 3-phase performance optimization project and there is much, much more that can be done. Over time, it’s only natural your website begins to accumulate a staggering amount of marketing tracking scripts (FB Pixel, lead forms, etc), javascript libraries, fonts, and other random additions to your templates by marketers, developers, and admins alike. Through this performance process it also doubles as a time to ask yourself  “is this needed?”, performance is almost always clean. 

Contact us for a Quote

We have become expert at getting the most out of Site Builder, and are happy to supply examples & references. Contact us for a quote to optimize your Site Builder site – the improvements will pay for themselves through better organic rankings and conversion rates!

The following two tabs change content below.

Kevin Carpenter

Web Developer
I have been developing websites of all kinds for over 10 years. After having graduated with a degree in Psychology / Human Computer interaction from Lewis & Clark College in Portland, OR, I coupled my educational background with my web development skills to specialize in creating user-friendly web environments. I have experience in over 8 CMS platforms primarily: Netsuite, Craft CMS, ExpressionEngine, Magento and Wordpress. I have completed 120+ web projects over the last several years ranging in size from $5k through $2m. I am here to assist you in whatever solution your business or personal web needs require.
0 comments… add one

Leave a Comment