Site speed sits at the top of the UX hierarchy in terms of importance and is correlated with bounce rate, conversion rate, and, ultimately, your bottom line. Think about it, what value can a user gain from your site before it even loads? This means that we all need to turn our attention to speed and performance optimisation, and take a close look at the user experiences we’re providing online.
If you haven’t got round to reading the guide yet, we’ve broken down some of the key topics for you in this article.
Site speed impacts Google as well as users
Speed isn’t just important for user experience and conversions. It also impacts how a website will be crawled by Google. A slow loading site can also cost you in terms of rankings, crawl budget and crawl rate.
With Google’s Speed Update that rolled out last year, page speed is now being used as a factor in mobile rankings as well, when previously this was just the case for desktop. The fact is: if you have a site that loads really slowly, Google won’t rank it highly.
Another thing to consider is that response times affect how Google crawls your site. Googlebot will limit crawl frequency of slow loading pages so it doesn’t have to spend a long time trying to access pages, and so that it won’t overload your server which is struggling already.
With DeepCrawl you can examine fetch times within our performance reports to highlight problem pages that will cause an issue for Googlebot.
The different speed & performance metrics
With so many different acronyms like TTFB and FCP being thrown around, it can be easy to get lost. That’s why we designed a visual checklist of the different metrics which you can see in the full PDF. Here’s a list of the different performance metrics and definitions that we covered that you should know about.
Server Response Time
Measures the time needed for the required HTML to be loaded for the server to then start rendering it. Server Response Time looks at back-end latency.
“Highly variable server response time may indicate an underlying performance issue.”
Google PageSpeed Tools
Time To First Byte (TTFB)
Measures the time taken between the client making a request to the server and then receiving the first byte of data in the browser.
“TTFB helps enterprises identify weak points in the connection process.”
Measures the point when the DOM (Document Object Model) has been constructed by parsing all of the HTML and is ready.
“The DOM represents the document” (or page) “as nodes and objects. That way, programming languages can connect to the page.”
Measures the time taken for the initial HTML document and content of the DOM to be fully loaded and parsed, except for elements like images and iframes.
“One of the main reasons we’ve historically optimized for metrics like load and DOMContentLoaded is because they’re exposed as events in the browser and easy to measure on real users.”
When the browser starts to render the page and shows the first hint of content on the screen. This is a good front-end benchmark of when a page appears to be starting to load.
“First Paint is triggered when a render – any render – is detected in the browser. This could be something as subtle and uninformative as a change in background colour.”
First Contentful Paint (FCP)
When the browser renders the first element of content defined in the DOM, such as some text, an image or a section of navigation, for example.
“This timing aims to be more representative of your user’s experience, as it flags when actual content has been loaded in the page, and not just any change.”
First Meaningful Paint (FMP)
Marks the time when the biggest change in the above-the-fold layout has happened and the most important elements of a page are visible.
“The time at which the user feels that the primary content of the page is visible.”
When the most important element or key feature of your page has rendered and is usable. For example, the Hero Element on YouTube would be the main video.
“In the context of a single page or a single application, it’s generally best to consider FMP to be the moment when your hero elements are visible on the screen.”
The score given to a page based on a variety of different speed metrics, which basically times how long it takes to display the visible elements of a page in milliseconds.
“A page load performance metric that shows you how quickly the contents of a page are visibly populated.”
Visually Complete (VC)
When all above-the-fold content is visible in the browser. This will be when the user perceived the page to be loaded, as everything within their viewport has been rendered.
For Visually Complete, “content “below the fold” and non-visual content (like third-party tracking beacons) is excluded.”
Measures the time when a page has finished loading to the point that the user is able to start minimally interacting with it.
“The page responds, on average, to most user input in a reasonable amount of time.”
Time To Interactive (TTI)
Measures the point when a page is both visually rendered and able to respond to user actions or input more reliably.
“The time at which a page appears to be ready enough that a user can interact with it.”
TTI measures how long the browser takes to respond to interactivity, but the next metric measures how long the user has to actually wait for this delay.
First Input Delay (FID)
The time in between a user first interacting with your site and the browser being able to respond to the interaction. This measures the gap between the user’s readiness and the browser’s readiness.
Measures the time taken until the page can always be expected to be responsive to a user’s input and interactivity.
“The Consistently Interactive metric measures when a page is fully interactive”
These occur when a user is interacting with the browser and adding input which all has to be added to a queue in the main thread, because each task has to be executed one at a time.
“To the user this appears as lag or jank, and it’s a major source of bad experiences on the web today.”
Page Load Time
This is a broad metric that measures the time it takes for the entire content of a web page to be downloaded and displayed in the browser.
“There are many different factors that affect page load time. […] The hosting server, amount of bandwidth in transit, and web page design – as well as the number, type and weight of elements on the page. Other factors include user location, device and browser type.”
Fully Loaded “is measured as the time from the start of the initial navigation until there was 2 seconds of no network activity after Document Complete.”
Tracking performance metrics with DeepCrawl
If you want to see these metrics for your site, then read our guide to using custom scripts within DeepCrawl to track Chrome speed metrics. In this article we walk you through how you can take your site speed auditing to the next level, allowing you to gather speed metrics across every page on your site within one crawl.
That definitely beats manually inputting URLs into PageSpeed Insights every time you want to check page speed! Try it out and see how easy it can be to get performance data at scale.
The quickest wins for performance optimisation
When it comes to improving site speed, you’ll want to look for ‘low hanging fruit’ first. These are the opportunities that have minimal effort and high impact, and also have the lowest risk of breaking anything… You’ll also want to look for opportunities that will be the most effective.
- Implement caching to reduce the size (and delay) of initial requests.
- Split up code (CSS or JS) into different files so it can be loaded separately and in the order of highest to lowest priority, with the lowest priority files being loaded asynchronously.*
- Compress** and minify*** whatever HTML, CSS and JS you can where necessary.
- Inlining**** code is less expensive than creating external requests for things such as critical CSS. (It also has the potential to create caching issues, but the positives outweigh any negatives because it reduces the number of requests.)
- Look at performance on mobile vs desktop to see where the biggest improvements need to be made, prioritise the device that most of your customers are using.
- Where performance improvements can’t be made, let users know what’s going on within the interface so they know what to expect and when – this may help with bounce rate.
* Asynchronous loading happens independently of the main program flow without blocking it and preventing it to continue processing.
** Compression is needed to reduce the size of a requested file that is sent back to the browser by the server, which is done by zipping.
*** Minification “refers to the process of removing unnecessary or redundant data without affecting how the resource is processed by the browser.”
**** Inline code “executes independently” and “is primarily used to provide a functionality external to the primary program to which it is added.”
The most common issues that impact speed & how to fix them
Each website is a unique ecosystem and the biggest performance opportunities will vary for each one. However, there are some fairly universal issues that have the biggest impact on speed. Here are some of the most common speed traps for a website, and tips on how to fix them.
Images are the biggest contributors to page weight, and, therefore, slow loading sites. Not only can images be overly large in terms of their dimensions, but they can also be overly large in terms of their file sizes, meaning more and more time is being spent downloading and rendering them. Here’s how to optimise them:
- Compression: Reduce the size of an image file in terms of bytes without degrading image quality – use tools like TinyJPG.
- Specify Dimensions: This allows faster rendering and makes the browser’s job easier as it can lay out the rest of the page while images are loading.
- Update Image Formats: Avoid using outdated image formats with overly large file sizes such as .png, and use up to date formats like WebP, JPEG-XR, FLIF or BPG.
- Utilise a CDN: A CDN (Content Delivery Network) stores image files on different servers around the world which increases loading speed for users.
- Lazy-loading: This defers loading of non-critical, below the fold images, which will only be loaded when needed by the user.
Code file size
More lines of code means more time spent downloading. Strip down your code and send leaner, more compact pages to servers and browsers. Here’s how to optimise it:
- Minification: Remove any code or lines that don’t contribute to the page, such as legacy code, whitespace and comments. Try using HTMLMinifier, CSSNano or UglifyJS.
- Reduce On-page Resources: Remove redundant files and assets hosted on-page as this will reduce external requests.
- Concatenate: Combine sets of JS or CSS files where it makes sense to, and make sure you’re not serving the same scripts twice.
- Text Compression: Use more efficient strings and naming conventions, for example, to convey the same information with fewer characters.
Check the web fonts you’re using on your site; chances are you could be using non-standard formats which will increase load time. Here’s how to optimise them:
- Compression: Use GZIP compression, as some web font formats aren’t compressed by default and contain additional metadata which increases file size.
- Self-host Fonts: Self-hosting web fonts where possible reduces the number of external CSS requests needed.
- Match Fallback Font: Make sure the intended font matches the fallback font in terms of letter spacing and heights to reduce jarring text flickering.
- Use ‘font-display’: This allows text to be shown while the actual web font is still loading. Bastian Grimm recommends using “fontdisplay:optional.”
- Use ‘rel=preload’: Font requests are delayed by default until the render tree has been constructed, so use to get around this and request earlier loading.
Redirects aren’t only irritating for users, they also impact Google’s ability to access and crawl websites quickly and efficiently. Here’s how to optimise them:
- Avoid Client-side Redirects: Browsers can handle server-side redirects better than client-side redirects, and can process them more quickly.
- Audit Existing Redirects: Go into your .htaccess file and find unnecessary legacy redirects to remove, as browsers spend time checking all redirects that exist for a URL.
- Responsive Design: Having a responsive site means that the same content is used for mobile and desktop, so there won’t be any redirects between different page versions.
- Check Other File Types: Remember that redirects can exist in your CSS files, external scripts and on image URLs as well as in the HTML, so make sure you fix these too.
- Website Crawling: This will give you the most comprehensive view of redirect chains and loops on your site.
Read the site speed & performance guide in full
Our site speed and performance PDF goes into a lot more detail and includes insights on the topic from Google representatives and industry experts including John Mueller, Patrick Meenan, Barry Adams, María Camañes Forés and many more. The PDF also discusses how to proactively optimise for users, so be sure to read it in full.
Monitor your website’s performance with DeepCrawl
If you want to take your website’s performance to the next level, DeepCrawl can help. Our tool can help you monitor your site’s speed, indexability, content performance and overall technical health on an ongoing basis. Sign up for an account today to see the benefits for yourself.