Google PageSpeed

Duda 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 Duda optimized for this

At Duda, 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.
• Eliminate render-blocking JavaScript and CSS in above-the-fold content. This is by far the most important check that Google performs. This looks at the code in your website and makes sure that you are prioritizing content over other code. Often, website developers place heavy scripts & CSS files at the top of an HTML file. This makes the browser process/load these resources first, instead of loading content first. This check makes sure you prioritize content above the fold. (Note: Above-the-fold means the first content a user sees when loading a webpage. This is usually the header, navigation and topmost content of the body of the page.)
• Enable compression. This checks to make sure that your webserver compresses (makes smaller) the raw data (HTML, CSS and Javascript) before it transmits it over the internet to your browser. This results in big savings in the total size of your website.
• 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 JavaScript. Similar to minify CSS, minifying JS can save a lot of size on the individual file that gets downloaded by the browser.
• 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 Duda does

Duda 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. We have a great blog post written by our CTO that describes how we optimized for page speed. Here’s a rundown of how we handled each of these checks:

• Avoid landing page redirects. For most Duda websites, we pass this check 100%. This is not fully under Duda’s control, as we allow users to redirect to other pages via our URL redirect. 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.
• Eliminate render-blocking JavaScript and CSS in above-the-fold content. As part of the publishing of websites, Duda optimizes the structure of websites to conform to this recommendation. We do this by: (1) Calculating what we call ‘critical’ CSS. This means that we look at the website and see what CSS stylings are required to display the website. We then place this content inline within the website so that it loads first. (2) We then move all scripts to the bottom of the website, so that content is loaded first.
• Enable compression. Duda enables gzip compression for connections to our website. This ensures that the file is compressed, transferred over the internet, and then uncompressed by the browser.
• Leverage browser caching. Duda sets cache headers on all files we load. This ensures that browsers that download these files (CSS, JS, 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. As part of Duda’s publishing process, we minify all CSS resources. This ensures that they’re as small as possible once downloading.
• Optimize images. Every jpg or png image you upload to Duda, we run through an extensive image compression & resize process to do the best possible image handling we can. We run the following processes:
  • First, we run the image through a lossless compression algorithm and save it in our CDN. This reduces the base size of the image.
  • We then resize the image into five different versions. Learn more about this here.
  • After resizing, we run all images through a lossy compression algorithm. This slightly lowers the image quality, but results in big image size savings. In the clear majority of cases, the quality lost is not visible to the human eye.
  • After the lossy compression, we run the image through one more lossless compression to ensure that it is at the smallest possible size.

• Prioritize visible content. As part of the way Duda 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 Duda hosts all websites on our platform, we can make sure that all of the websites we host respond quickly. We use industry-leading Amazon Web Services which helps us maintain these standards.

What to do if your site checks poorly

While Duda 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 Duda 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:

• Eliminate render-blocking JavaScript and CSS in above-the-fold content:
  • Map element above the fold. If you place a map element at the top of your 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. Duda 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 in the body-end.html file 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 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.
• Optimize images: Today, Duda's image optimization works only on JPG & PNG images. If you are uploading a TIFF, GIF, or other image formats, Duda might not be able to optimize it and this could be the reason for this warning. We recommend running the image through an image optimization service, such as EzGif, Compressor.io or TinyPNG.Another check Google performs is to make sure that you don’t have large images that are resizing for small spots. Duda tries to help out with this, by placing smaller sized images in columns that have less sizing, but this process is not perfect. Sometimes you might need to download an image, resize it exactly for the column size you want to use, and re-upload that image. This is fairly a rare case.
• Resize images: While Duda optimizes images to make sure that they're compressed at a smaller size, Duda doesn't actually resize your image for you in the desktop version of your site. For example, if you use a 3000 x 3000 pixel image on a page and resize it using the editor's drag-to-resize feature to only 300px, it still means that it's loading the entire 3000 x 3000 px image. This can negatively affect your pagespeed score. You can fix it by resizing the image using the built in image editor or by resizing it in photo editing software and re-uploading it.
• 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.
• Current unfixable issues: To note, these are pagespeed issues reported by Google that cannot be fixed by yourself and must be processed as feature requests for Duda:
  • Leverage browser caching
  • Minify HTML / CSS / JS
  • Optimize CSS delivery

Cases where Duda does not optimize the site

There are a few cases where Duda does not attempt to optimize the website upon publish. If you have placed custom code that uses jQuery (($(‘#ex’)) or the JS API: dmAPI.runOnReady(‘code’,function(){}); 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.