Javascript

5 Tips to Improve Your Site's Web Performance

Oct 11, 2021

3 min read

5 Tips to Improve Your Site's Web Performance

When thinking about which framework to choose, we sometimes first consider which one is the fastest or the easiest to deploy. However, we should be thinking about which framework will promote the best web performance for our particular site.

According to a recent study:

"One second of delay reduces page views by 11%."

When we talk about performance on your site, we are considering a lot more than whether your user is using Windows, Mac, or Linux. We are also thinking about whether your users are using tablets, mobile devices, or even low performance networks.

This performance directly affects your product/website. Some examples of this could be:

Yelp reduced the first painting of content (75th percentile) by 45%, and the full Yelp page (75th percentile) by 25%. As a result, they saw a 15% improvement in their conversion rate.
SportsShoes.com found that faster-than-average mobile visits were 41% more likely to convert than slower-than-average visits.

1. Use next-gen image format like .WebP or .AVIF

Using a next-gen image format such as WebP, AVIF, or JPeg XR helps reduce pictuze size by 20-40% without compromising the quality.

This will result in improved image loading, especially if your site uses too many images or the ones it does use are heavy.

2. Minify HTML/CSS as much as possible.

Minifying your code is a process in which you remove all unnecessary characters in your source code. These characters can be whitespace, comments, line breaks, etc. While having white space or comments can be useful when developing, when loading your site, they can cause your source file to be heavier than it should be.

It is important to know that this process does not change the functionality of your code, but reduces the size and allows a more efficient loading of your site.

3. Use a proper CDN.

A CDN (Content Delivery Network) is a geographically distributed network that delivers the site and any other resources used within it, to users.

Basically, it does the delivery of HTML, CSS, images, and also Javascript through servers physically close to the user.

4. Use Fallback fonts

If you use a custom font, it might not be able to be downloaded or it could take a while to load. The site will use this fallback to properly display it.

5. Remove unused code from dependencies

Another place where optimizations can be made is in dependencies. Certain dependencies like React.js include propTypes even in the production bundle, where they are not needed. Lodash includes methods that you may not use, but that still increase the bundle size.

There are tools to remove this unused code from dependencies.

You can see them here: GoogleChromeLabs/webpack-libs-optimizations

Conclusion

With some changes, we can improve the performance of our sites. Regardless of the framework you use in yours, these tips can help you, and offer a much better user experience.

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

Daian Scuarissi

@asdaian @SDaian

New Core Web Vitals and How They Work

Core Web Vitals, introduced by Google in 2020, have been around for a while now. And after four years, a significant change is coming in March 2024. In this article, I will try to tell you everything you need to know to be prepared. But first, let's briefly talk about what Core Web Vitals are. What are Core Web Vitals? Web Vitals is a Google initiative that aims to provide developers with guidance on authoring the best user experience on the web as well as tools to assess and measure it. Core Web Vitals are a subset of Web Vitals and currently consist of three main metrics: - Largest Contentful Paint (LCP): This metric measures the time it takes for the largest content element to be rendered on the screen. It should reflect the _loading_ aspect of the user experience. - First Input Delay (FID): This metric measures the time it takes for the browser to respond to the first user interaction. It should reflect the _interactivity_ aspect of the user experience. - Cumulative Layout Shift (CLS): This metric measures the amount of unexpected layout shifts of visual elements on the page. It should reflect the _visual stability_ aspect of the user experience. Part of the Core Web Vitals are also the thresholds that define what is considered a good experience. These thresholds are currently set to: | Metric | Good | Needs Improvement | Bad | | ------ | -------- | ----------------- | -------- | | LCP | ≤ 2.5 s | 2.5 - 4 s | > 4 s | | FID | ≤ 100 ms | 100 - 300 ms | > 300 ms | | CLS | ≤ 0.1 | 0.1 - 0.25 | > 0.25 | While the reward of providing a good user experience should be enough for you to strive for great results in these metrics, that is not the only reason you should care about them. Google is reflecting these metrics in its search ranking algorithm as it wants it to "reward content that offers good user experience". What's Changing in March 2024? The change affects how _interactivity_ is measured. The First Input Delay (FID) has been deemed no longer sufficient to measure the interactivity aspect of the user experience. It will be replaced by the Interaction to Next Paint (INP) metric on March 12, 2024. INP, unlike FID, measures the response of all interactions up to a URL change. It then picks the slowest response from all interactions. (If there are more than 50 interactions, it picks a percentile instead, most often the 98th) making it much stricter than FID. Why the Change? There are three main reasons why FID is being replaced by INP: 1. FID is not strict enough: Upwards of 90% of websites meet the good threshold for FID nowadays, making it a poor differentiator between good and bad user experiences. 2. FID is not representative of the full interaction: FID only measures the first part of the reaction delay, up to the point before the response bubbles to JavaScript, not accounting for the (often quite long) time it takes for the JavaScript to process the response and for the browser to paint the next frame. 3. FID only measures the first interaction: According to Google, 90% of interactions happen _after_ the first load, making FID not representative of the full user experience. INP aims to address these issues by measuring the full interaction and by being stricter in its thresholds (according to Google, ~70% of websites should pass the good INP threshold now) and thus capturing a more representative picture of the user experience. How Does INP Work? As I previously mentioned, INP measures all interactions on the page and picks the slowest one or a percentile, which solves one of the issues with FID not representing the whole experience of interacting with a website. This way of measuring is not dissimilar to how CLS measures the unexpected layout shifts on the page as it also captures the full scope of the stay on the page. The interactions considered by INP are: - Mouse clicks - Touchscreen taps - Keyboard presses (including virtual onscreen keyboards) If an interaction is composed of multiple events, such as a keystroke, consisting of the keydown, keypress, and keyup events; INP groups them and measures the latency as the maximum duration of all the included events. Unlike FID, it captures not only the time taken by tasks blocked by the main thread (the _input delay_) but also the _processing time_ (events and JavaScript processing) and the _presentation delay_ (the time it takes for the browser to paint the next frame), making it a much better reflection of the full user experience, but also much harder to pass. So while FID reflects the first impression, INP should capture the overall _responsiveness_ of a page. For more information about interactions with comprehensive diagrams of what actually happens in the browser, check out the web.dev article on INP. Google defined the thresholds for INP as follows: | Metric | Good | Needs Improvement | Bad | | ------ | -------- | ----------------- | -------- | | INP | ≤ 200 ms | 200 - 500 ms | > 500 ms | How to Prepare for INP? Let's start with some general steps you should take to prepare for the new Web Vital: 1. Measure Start with measuring your INP score. The easiest way to measure it is using PageSpeed Insights, but if you need to measure it locally, you can use Lighthose user flows which already support INP. If your INP scores are _good_, you're fine and you can probably stop reading further. 2. Do not panic While, according to Tim Kadlec, only 17% of React websites and 11.8% of Next.js websites in the "top 100k" pass the _good_ INP threshold, so it's very likely that you will have to do some work to pass; framework authors have been working on improving their performance and things may be as hot as Tim paints them. According to Google’s stats, ~80-90% of desktop sites pass the _good_ INP threshold depending on the framework as of June 2023: | Technology | Passing on Mobile [%] | Passing on Desktop [%] | | ----------------- | --------------------- | ---------------------- | | Angular (v2.0.0+) | 28.6 | 83.6 | | Next.js | 28.5 | 87.3 | | Nuxt.js | 32.0 | 91.2 | | Preact | 48.6 | 92.8 | | Vue (v2.0.0+) | 50.3 | 94.1 | | Lit | 50.0 | 88.3 | 3. Optimize In case your INP scores are not _good_, you should start optimizing your website. Identify the pages that perform the worst and start with them. Focus on: - Code splitting and tree shaking to make sure only the necessary JavaScript is included. - Deferring non-critical JavaScript events until the main thread is idle. Consider also offloading heavy tasks to a Web Worker. - Debouncing or throttling frequently fired events. - Breaking up long JavaScript tasks into smaller ones. - Using passive event listeners. - Reducing the presentational delay e.g. by using the will-change CSS property, and preferring transform and opacity over the display and position properties in animations. - Eliminating third-party scripts. Very often, third-party scripts, be it for analytics, cookie consent, or other purposes, have a significant impact on performance. Considering which of them are not absolutely necessary, and either removing them or replacing them with a more performant solution is highly recommended. - Upgrading your dependencies to make sure you are taking advantage of the latest performance-improving features. If you want to read more about the general INP optimization tips, you can check out this Vercel article. While a lot of these optimizations, such as code splitting and tree shaking, are already taken care of by modern frameworks, I believe that it’s worth going through this list to see what you can do to make your website faster and thus a better experience for your users. We will explore concrete performance tips for popular frameworks in the next article. Conclusion The change in Core Web Vitals is coming and it's going to be a significant one. The new metric, Interaction to Next Paint, is going to be much stricter than the current First Input Delay and it's going to be much harder to pass. However, the good news is that framework authors have already been working on making the frameworks more INP-friendly, and while it may take some effort, you should be able to improve your INP score. INP, however, should not be just another Lighthouse threshold we have to satisfy. This change should encourage us to look beyond surface-level metrics and dive deeper into the nuances of user interaction. As we adapt to these changes, our focus should remain on the end goal: creating a good and inclusive user experience for our visitors....

Feb 14, 2024

6 mins

JavaScriptWeb PerformanceUXSEO

Performance Analysis with Chrome DevTools

When it comes to performance, developers often use Lighthouse, Perfbuddy, or similar performance analysis tools. But when the target site has protection against bots, getting information is not that simple. In this blog post, we are going to focus on where to look for signs of performance bottlenecks by using Chrome Devtools. Preparations Even when access to automated performance analysis tools is restricted, the Network, Performance, and Performance Insights tabs of Chrome Devtools can still be leveraged. To do that, some preparations can be made. When starting our analysis, I recommend opening the page we want to analyse in incognito mode. So we separate the analysis from our regular browser habits, cookies, and possible browser extensions. When we load the page for the first time, let's make sure we disable caching in the Network tab, so resources are always fetched when we reload. Some pages heavily rely on client-side storage mechanisms such as indexedDB, localStorage, and sessionStorage. Cookies can also interfere. Therefore, it's good to leverage the "Application" tab's Clear site data button to make sure lingering data won't interfere with your results. Some antivirus software with network traffic filtering can also interfere with your requests. They can block, slow down, or even intercept and modify certain network requests, which can greatly affect loading time and the accuracy of your results. If the site under analysis is safe, we recommend disabling network traffic filtering temporarily. We strongly suggest just looking at the page and reloading it a few times to get a feeling of its performance. A lot of things cannot be detected by human eyes, but you can look for flickers and content shifts on the page. These performance issues can be good entry points to your investigation. Common bottlenecks: resources Let's start at the Network tab, where we can identify if resources are not optimised. After we reload the page, we can use the filters on the network tab to focus on image resources. Then we can see the information of these requests, including the size of the images, the time it took to load each image, and any errors that occurred. The waterfall chart is also useful. This is where you can see the timing of each image resource loading. We should look for evidence that the image resources are served from a CDN, with proper compression. We can check the resources one by one, and see if they contain Content-Encoding: gzip or Content-Encoding: br headers. If these headers are missing, we found one bottleneck that can be fixed by serving images using gzip or brotli compression while serving them. Headers on resource requests can tell other signs of errors. It can also happen that images are served from a CDN, such as fastly, but if there are fastly-io-error headers on the resources, it can mean that something is misconfigured. We also need to check the dimensions of the images. If an image is larger than the space it's being displayed in, it may be unnecessarily slowing down the page. If we find such bottlenecks, we can resize the images to match the actual dimensions of the space where they are being displayed to improve loading time. Server-side rendering can improve your SEO altogether, but it is worth checking the size of the index.html file because sometimes it can be counterproductive. It is recommended to try and keep HTML files under 100kb to keep the TTFB (Time To First Byte) metric under 1 second. If the page uses polyfills, it's worth checking what polyfills are in use. IE11 is no longer supported, and loading unnecessary polyfills for that browser slows down the page load time. Performance Insights Tab The performance Insights Tab in Chrome DevTools allows users to measure the page load of a website. This is done by running a performance analysis on the website and providing metrics on various aspects of the page load process, such as the time it takes for the page to be displayed, the time it takes for network resources to be loaded, and the time it takes for the page to be interactive. The performance analysis is run by simulating a user visiting the website and interacting with it, which allows the tool to accurately measure the performance of the page under real-world conditions. This information can then be used to identify areas of the website that may be causing slowdowns and to optimize the performance of the page. Follow the steps to run an analysis: 1. Open the Chrome Devtools 2. Select the "Performance insights" tab 3. Click on the Measure page load button The analysis provides us with a detailed waterfall representation of requests, color coded to the request types. It can help you identify requests that block/slow down the page rendering, and/or expensive function calls that block the main thread. It also provides you with information on important performance metrics, such as DCL (DOM Content Loaded), FCP (First Contentful Paint), LCP (Largest Contentful Paint) and TTI (Time To Interactive). You can also simulate network or CPU throttling, or enable the cache if your use case requires that. DCL refers to the time it takes for the initial HTML document to be parsed and for the DOM to be constructed. FCP refers to the time it takes for the page to display the first contentful element, such as an image or text. LCP is a metric that measures the loading speed of the largest element on a webpage, such as an image or a block of text. A fast LCP helps ensure that users see the page's main content as soon as possible, which can improve the overall user experience. TTI refers to the time it takes for the page to become fully interactive, meaning that all of the necessary resources have been loaded and the page is responsive to user input. Performance Tab The "start profiling and reload page" button in the Performance tab of Chrome DevTools allows users to run a performance analysis on a website and view detailed information about how the page is loading and rendering. By clicking this button, the tool will simulate a user visiting the website and interacting with it, and will then provide metrics and other information about the page load process. Follow the steps to run an analysis 1. Open the Chrome Devtools 2. Select the "Performance" tab 3. Click on the button with the "refresh" icon A very useful part of this view is the detailed information provided on the main thread. We can interact with call stacks and find functions that might run too long, blocking the main thread, and delaying the TTI (Time To Interactive) metric. Selecting a function gives all kinds of information on that function. You can see how long that function was running, and what other functions it called, and you can also directly open that function in the Sources tab. Identifying long-running, blocking functions is crucial in finding performance bottlenecks. One way to mitigate them is to move them into worker threads. --- Chrome DevTools is a powerful tool for analyzing the performance of web applications. By using the network tab, you can identify issues with resources that might slow down page load. With the Performance insights and Performance tabs, we can identify issues that may be causing the website to load slowly, and take steps to optimize the code for better performance. Whether you're a beginner or an experienced developer, Chrome DevTools is an essential tool for analyzing and improving the performance of web applications....

Jan 9, 2023

6 mins

DevToolsSEOWeb PerformanceWeb Development

Sharing Signals and Stores: Context API in SolidJS

Introduction Welcome to our latest blog post on SolidJS, where we delve into the world of the Context API. Context API is a popular and versatile feature in SolidJS, allowing developers to pass data and functions through the component tree without the need for props drilling. In this post, we will discuss how SolidJS implements the Context API, including the creation of contexts, sharing Signals and stores, and utilizing them within the components. Whether you are a seasoned developer, or just starting out, this post will provide valuable insights into the use of Context API in SolidJS and what are the advantages in the Reactivity ecosystem. So sit back, grab a cup of coffee, and let's dive in! What is SolidJS? SolidJS is a unique and powerful JavaScript framework that is quickly gaining popularity among developers. One of the key features that sets SolidJS apart from other frameworks is its reactive nature. How about reactivity? Reactivity is a programming paradigm through which the application automatically updates and re-renders when the data changes. This means that developers do not have to manually update the view when the data changes, saving a lot of time and effort. SolidJS achieves this reactivity by using a virtual DOM which is a lightweight representation of the actual DOM. This virtual DOM is then used to update the actual DOM, making the process of updating the view much faster and more efficient. Performance Another advantage of SolidJS is its performance. SolidJS is designed to be fast and efficient thanks to its use of a virtual DOM and a functional programming approach. By using functional components and immutability, SolidJS is able to optimize the process of re-rendering, resulting in a smoother and more responsive user experience. In addition to its reactivity and performance, SolidJS also has a small footprint and a simple API. The framework is lightweight and easy to learn, making it a great choice for developers of all skill levels. Signals: SolidJS Signals are a powerful feature that allow for easy communication between different parts of your application. They are similar to events or hooks in other frameworks, but with a few key differences. One of the key advantages of Signals in SolidJS is that they are fully reactive, meaning that they automatically update and re-render when the data changes. This makes it easy to create responsive and dynamic applications without having to manually update the view. To use Signals in SolidJS, you need to first create a signal by using the createSignal function. ` Store In SolidJS, a store works similar to other frontend frameworks. To keep things light, SolidJS creates underlying Signals only for properties that are accessed under tracking scopes. All Signals in Stores are created lazily as requested. The createStore call takes the initial value, and returns a read/write tuple similar to Signals. The first element is the store proxy which is readonly, and the second is a setter function. What About context? SolidJS provides a context API to pass data around without relying on passing props; this is useful in sharing Signals and Stores as described above. According to SolidJS docs: “Using Context has the benefit of being created as part of the reactive system and managed by it.” Getting Started: First, let’s create our context: ` Then we can consume our recently Context created: ` To use context, we'll first wrap our App component in order to provide it globally: ` We can now consume the context and our components will look like this: ` ` Conclusion In this article, we were able to use the contextAPI to share the props we want across the app, and benefit from the performance of Reactivity because of that. This will make our application more readable, but also brings some additional benefits to the app which are as follows: - avoid passing props down through multiple levels of the component tree. - reducing the number of re-renders that occur when props are passed down. - by isolating state and props to a specific context, you can make your code more organized and easier to understand. - components that use the Context API are more easily tested. Would you like to learn more about Signals and Stores, or SolidJS in general? You can see in detail how this was maximized in one of This Dot Labs' open source project starter.dev GitHub Showcases....

Mar 10, 2023

3 mins

SolidJS

Transforming Platform Engineering Through Chargeback Programs with Shuchi Mittal

Shuchi Mittal, the Head of Cloud enablement at Honeywell, discusses how she as a leader in platform engineering has been able to transform internal platform engineering teams at other organizations by providing teams with value-added services, and how they effectively managed costs. She talks about how to treat these teams as customers, and delivering services that meet the customer needs, but also charging them for their usage. By providing policy-compliant infrastructure and unique services tailored to their requirements, platform engineering teams can showcase their commitment to supporting the success of other teams within an organization. This approach not only fosters trust but also positions platform engineering as a strategic partner rather than just a service provider. By going beyond the basic infrastructure provisioning, the platform engineering team can offer services that help development and product teams streamline their processes and improve efficiency. Shuchi shares her work at Fiserv where she implemented a chargeback system to track usage and costs effectively, incentivizing better development practices. This not only helped in managing costs but also encouraged teams to optimize their resource utilization, leading to improved overall efficiency and more easily scalable systems. Her platform engineering team recognized the importance of effectively managing financial aspects to secure upfront investment for product development. By implementing a billing system based on gigabyte hours, they aligned costs with usage, enabling teams to have a clear understanding of their resource consumption. This approach not only provided transparency but also incentivized teams to adopt cost-effective practices. By strategically managing financial aspects, the platform engineering team gained the trust of stakeholders and secured the necessary resources to drive innovation and deliver value to the organization. Shuchi’s journey of platform engineering serves as a valuable example of how a team can transition from being a basic service provider to becoming an innovation partner within an organization. By building trust, offering value-added services, and strategically managing financial aspects, the platform engineering team successfully elevated their role and became a strategic enabler of innovation. Download this episode here....

Apr 16, 2024

2 mins

Engineering LeadershipSoftware Engineering

5 Tips to Improve Your Site's Web Performance

5 Tips to Improve Your Site's Web Performance

1. Use next-gen image format like .WebP or .AVIF

2. Minify HTML/CSS as much as possible.

3. Use a proper CDN.

4. Use Fallback fonts

5. Remove unused code from dependencies

Conclusion

Daian Scuarissi

You might also like

New Core Web Vitals and How They Work

Performance Analysis with Chrome DevTools

Sharing Signals and Stores: Context API in SolidJS

Transforming Platform Engineering Through Chargeback Programs with Shuchi Mittal

You might also like

New Core Web Vitals and How They Work

Performance Analysis with Chrome DevTools

Sharing Signals and Stores: Context API in SolidJS

Transforming Platform Engineering Through Chargeback Programs with Shuchi Mittal