Google Page Speed
Sitejet has optimized websites published on the platform to score highly on the Google PageSpeed test. This test looks at many technical details of how webpages are built, and checks to see that they fit the best practices that enable websites to load quickly. 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 fastest.
Why Sitejet optimized for this
At Sitejet, we believe that website speed is one of the biggest issues facing the web today. Slow-loading 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 (search) relies on other people’s websites, it wants to make sure that webmasters/designers/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 website versions. It then uses 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 up. 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 formats. 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 to have 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 quality of the images. (2) Resizing images. You do not need to deliver an image that is very large (5000 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 minimal 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, specifically on the Google PageSpeed test. This means that we have looked at 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 setup their own redirects. The recommendation here is to make sure that you do not send links to your customers, partners, etc., that are not a real page 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 uncompressed by the browser.
- Leverage browser caching: Sitejet sets cache headers on all files loaded. This ensures that 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 re-download it from the website.
- 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 & resize process. Every image will be scaled down to a resolution which 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 remaining a 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 body content of the page.
- Reduce server response time: This check is mostly 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 checks poorly
While Sitejet wishes every website we run would always rank high, 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 the 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.
- Store front 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 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:
- Old code: <script src=”https://example.com/script.js”></script>
- New async: <script src=”https://example.com/script.js” async defer></script>
You’ll notice that the code above tells the browser to load this code ‘async’, which should help pass this Google PageSpeed test.
- 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 which leads to a smaller resolution and thus smaller downloads.
- Leverage browser caching: If you include some custom code in your website, it will often load from a 3rd party website. If this website does not enable caching, then Google will find this and recommend enabling browser caching. You should contact that 3rd party service to get them to implement this change on their server.
- Your page may be too large: If you have a lot of content on one page, it can cause the page to be large even after we run the optimization tool on your site.
Consider using less 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 publish. If you have placed custom code that uses jQuery into the header of the website. The reason we do this is because this code often requires jQuery or the dmAPI functions to exist, but because our optimization moves this code lower on the page, it will no longer work and thus break the code that’s been installed.