Website Performance / Google PageSpeed
Websites built on Sitejet are optimized to score well on the Google PageSpeed test. This test checks certain technical details of a website to make sure they meet the best practices for fast load time. The most important check in the PageSpeed test examines how the website code is structured. Google checks to make sure that the code is structured in a way that allows the browser to load the content as quickly as possible.
Table of contents
Why Sitejet optimizes for this
At Sitejet, we believe that website speed is one of the biggest issues facing the web today. Slow websites have higher bounce rates, lower engagement, and give the entire web a negative reputation for being slow. We know that faster-responding websites provide a lot of value to site visitors by giving each person a better browsing experience.
Why Google built this tool
Google built the PageSpeed tool because it felt many websites load too slowly and are not getting content to users fast enough. Google knows that users are more likely to engage with websites that deliver visible content faster, enabling both Google and the website to provide a better overall experience. Usually, this means having a website load in under three seconds. Because Google’s core product, its search functionality, relies on other people’s websites, it wants to make sure that webmasters, designers, and developers build websites that load quickly.
What Google checks for
Google has a list of optimizations that it checks for on both desktop and mobile versions of a website. It then adds up the results of how well your site is optimized for each of these checks to come up with an overall score (out of 100) for your website speed. Here’s what Google checks for:
- Avoid landing page redirects: This means that you should not redirect users to another page of your website when they load it. For example, you should not redirect all visitors to a second version of your homepage.
- Leverage browser caching: The caching check makes sure that you tell the browser to save this content locally, instead of re-downloading it the next time you need to access it. This saves precious time that is often spent connecting and downloading content on page-reloads.
- Minify CSS: Minifying CSS means that you make the CSS file as small as possible by removing extra spaces, line breaks, and other formatting. Think of this as similar to compressing the file to save total size.
- Minify HTML: Similar to the above two, but removes extra spacing from the primary HTML of the website.
- Optimize images: The second most important check that Google performs, this makes sure that images you send to the browser are optimized, compressed, and not too large. Images account for roughly 65-70% of the total size/weight of a website. Optimizing images means that you compress the images and make them as small of a file size as possible before having the browser download them. There are two important items to do here: (1) Make sure that images are compressed. This requires running them through compression tools to make them smaller, without reducing the quality of the images. (2) Resizing images. There's no reason to deliver an image that is very large (5,000 pixels, for example) to a mobile browser, thus you should resize the image.
- Prioritize visible content: This makes sure that you place content at the top of the website HTML. Try not to load additional content that is not relevant to the first load of the website.
- Reduce server response time: This check looks at your server to make sure that it is responding very quickly to visitors coming to your website. Google requires that the user waits no longer than 200ms (1/5th of a second) to get content/HTML back from your server.
With the introduction of the open-source Lighthouse project in November 2018, Google page speed now looks at a wide range of website properties in addition to speed (such as SEO, Accessibility, PWA and Best Practices). In addition to the tests above, Lighthouse now checks for:
- First Contentful Paint: This is a metric that comes from a real browser loading a website. When you run a Lighthouse test, a real browser will go and visit your website, load it, and monitor the performance. The First Contentful Paint metric reports on how long it takes for any type of content to be displayed after a page has started to load. This can be an image, a background color, etc.., and time to First Contentful Paint is measured in seconds. The reason this is a valuable metric is that it is the first time a user knows that something on the website will load — it’s the first indication a website is loading.
- Speed Index: This is a metric that comes from an old web performance tool called WebPageTest. It’s been around since 2012 and is quite effective in determining how quickly a website loads its content. It works by taking screenshots of a website every 0.5 seconds as it loads. Using these screenshots, it calculates the percentage of content loaded onto the web page in 0.5-second increments and issues an overall speed score. The lower the number, the faster the website appears to load for the user. The goal with this test is to really understand how quickly the user sees content and if there’s anything blocking the website from displaying content as fast as possible.
- Time to Interactive: Another important metric is how quickly the user can interact with the page. For example, the user might want to click on a button or scroll the page. This is particularly important on mobile, where the user will directly touch a screen to interact with the page. The goal for web developers should always be to ensure a page is interactive whenever there is any content on it. This is a very tough challenge due to the way browsers work.
- First CPU Idle: This metric relates closely to time to interactive, as it is an indicator of how quickly all initial content/resources within the website are loaded and the CPU of the device enters an idle state (doing nothing). The reason this is reported on is that developers should focus on loading the minimum amount of content first. By sending a small amount, the CPU of the device will process all the code and get to an idle state faster.
- Estimated Input Latency: The final metric that Lighthouse reports on has nothing to do with the first load performance of your website. Instead, it attempts to give you a number (in milliseconds) in which your website responds to taps/clicks. The idea is that the faster your website responds, the more users will consider it speedy and are less likely to leave the site.
After performing these tests, Lighthouse will also give prioritized recommendations about how you can help improve the overall speed score. This appears on the second half of the page and gives very technical details about what you can do and the benefits these changes may provide.
What Sitejet does
Sitejet has optimized the websites built on our platform to score highly on the Google PageSpeed test in particular. This means that we have studied the tests listed above and optimized our websites for each one of them. Here’s a rundown of how we handled each of these checks:
- Avoid landing page redirects: For most Sitejet websites, we pass this check 100%. This is not fully under Sitejet’s control, as we allow users to set up their own redirects. The recommendation here is to make sure that you do not send links to your customers, partners, etc., that are not to real pages of your website.
- Enable compression: Sitejet enables gzip compression for connections to all websites. This ensures that the file is compressed, transferred over the internet, and then decompressed by the browser.
- Leverage browser caching: Sitejet sets cache headers on all files loaded. This ensures that the browsers that download these files (CSS, JS, and images) know how to temporarily store the file in the browser cache, so that the next time the browser needs to access that file, it is stored on the machine locally, instead of having to download it from the website again.
- Minify CSS, JS, and HTML: Resources like CSS, JS, and HTML are minified automatically. This ensures that they’re as small as possible once downloading.
- Optimize images: Every jpg or png image which is uploaded to Sitejet is run through an extensive image compression & resizing process. Every image will be scaled down to a resolution that is as close as possible to the actual display size: even from cropped images, only the cropped part will be downloaded. While scaling down, images are run through a compression algorithm, making sure to reduce the size of the image as much as possible, while still retaining sharp image quality.
- Prioritize visible content: As part of the way Sitejet builds every website, we structure the site to fit this recommendation by default. This means placing header content first, followed by the body content of the page.
- Reduce server response time: This check is more about making sure your website is not too slow, rather than fast enough. Since Sitejet hosts all websites on our platform, we can make sure that all of the websites we host respond quickly.
What to do if your site scores poorly
While Sitejet wishes every website we run would always rank highly, it’s not something we can promise. This is because our customers can add their own code, content, and designs to the website, so we don’t have full control over what they can or can’t add. For this reason, there are some scenarios in which Sitejet websites will not score in the high 90s. Here’s a list of errors/issues we see Google PageSpeed reporting to us, based on how a website was built:
- Map element above the fold. If you place a map element at the top of your Sitejet website, this will often come back as a negative on your PageSpeed rankings. To fix this, move the map element to the bottom of the page.
- Storefront above the fold. If you place a store at the top, it can often cause this warning to appear. Sitejet is working on a fix for this, but as of now, the only recommendation we have is to move the content lower on the page. One possible way of doing this is to add an image and helpful text above the store element so that the store itself is not in the ‘above the fold’ area of the website.
- Custom code/script in the header: If you placed custom code in the head section of the website, an error will often appear from Google that this is slowing down the page rendering. There are two options for fixing this: (1) Place the code on the bottom of the HTML of the website instead of the header. This moves the code to the bottom, thus forcing it to load later rather than earlier. (2) Make sure the script embedded here is loaded asynchronously. This means that the browser loads it in the background while continuing to load the rest of the website content. To enable async on scripts, you need to alter it like this:
You’ll notice that the code above tells the browser to load this code ‘async’, which should help pass this particular Google PageSpeed test.
- Old code: <script src=”https://example.com/script.js”></script>
- New async: <script src=”https://example.com/script.js” async defer></script>
- iframe embed: If you embed a custom iframe into a Sitejet website above the fold, it will most likely come back with this error message. Please move this content lower down the page, or remove it completely.
- Resize images: Reduce the display size of images within your website. This leads to smaller resolution and thus smaller downloads.
- Leverage browser caching: If you include some custom code on your website, it will often load from a third-party website. If this website does not enable caching, then Google will discover this and recommend enabling browser caching. You should contact the third-party service to ask them to implement this change on their server.
- Your page may be too large: If you have a lot of content on a single page, it can cause the page to be large even after Sitejet optimizes your site. Consider using fewer images or dividing up your content by moving content to other pages.
Cases where Sitejet does not optimize the site
There are a few cases where Sitejet does not attempt to optimize the website upon publication. For example, if you have placed custom code that uses jQuery into the header of the website, Sitejet will not attempt to optimize the site when you publish it. The reason we do this is that this code often requires jQuery or the dmAPI functions to exist, but because our optimization would move this code lower on the page, it would break the code that’s been installed and would no longer work.
Become a part of our Community!
Exchange ideas with other web designers about current developments, tips, and tricks and show your favorite sites. Get advice and talk to us about possible features you would like to see on Sitejet. You can join the Sitejetters community here.