Skip to content

This Dot Blog

This Dot provides teams with technical leaders who bring deep knowledge of the web platform. We help teams set new standards, and deliver results predictably.

Newest First
New Core Web Vitals and How They Work cover image

New Core Web Vitals and How They Work

A guide to INP, the new Core Web Vital coming in March 2024. The what, why and how....

State of Web Performance February 2023 Recap cover image

State of Web Performance February 2023 Recap

In the most recent State of Web Performance event, our panelists discussed the current trends in web performance, the applicability of SPA architecture, the Performance Inequality Gap, how development teams can get better at testing on more devices, and much more. In this wrap-up, we will take a deeper look into these latest developments and explore what is on the horizon for web performance. You can watch the full State of Web Performance event on the This Dot Media YouTube Channel. Here is a complete list of the host and panelists that participated in this online event. Hosts: - Tracy Lee, CEO, This Dot Labs - Henri Helvetica, Dev. Community Manager, WebPageTest by Catchpoint Panelists: -Alex Russell, Product Manager on Microsoft Edge -Sia Karamalegos, Web Performance at Shopify -Estela Franco, Web Performance Specialist at Schneider Electric -Yoav Weiss, Software Engineer, Google Chrome's Speed Metrics team Updates from Panelists and What They Are Currently Working On The event started off with great conversation by getting updates from our panelists, and what they are currently working on. Our co-host Henri started by talking about how he likes to make sure developers are leveling up in their abilities. He stresses that performance literacy is of utmost importance. Estela continued the conversation by talking about how she is working to improve the web performance culture at her current company, and that she is trying to improve the web performance processes. Yoav talked about how he is excited about measuring soft navigations in SPAs. Sia just finished an internal hackathon at her place of employment. She mostly works with trying to make merchant websites faster. Alex spent about half his time on performance oriented things, and the other half is spent with first party teams at Microsoft trying to improve the state of web apps. After introductions, the conversation pivoted to the talking points for this event. Web Performance Culture Inside a Company Estela talked about working at Schneider Electric, and how she was brought in by management to improve web performance. The company is aware of the impact of web performance for users and customers. It helped her when getting involved with the different dev teams there. Having the management vision to work on that was really helpful. However, there was a struggle to keep different dev teams involved. A lot of the teams were aware of the importance of web performance, but web performance is more than just a performance score, and making sure the teams were aware of all that was involved was difficult at times. The environment overall has been beneficial by being the point of contact for changes made that may affect web performance. Sia saw that changes were more willing to be made on performance when it started to affect SEO. She was happy that it made them want to get on board no matter what the cause was. Innovations with Web Performance Yoav started this off by talking about aligning incentives. He spoke about how core web vitals creates a shared language that enables everyone to talk about the same things. It also aligns the long-term incentives of the platform with the short-term incentives of developers. He also talked about the concept of the "rage click", and how it isn’t a metric that is necessarily measured, but it is something that users can have a frustration with when the web performance affects how they interact with a site. Hardware and Web Performance Alex talked about how web performance doesn’t control the customer’s device, or the user’s hardware. It is also hard to detect software and it is often a poor response when it comes to software that isn’t liked. He explains that the web is the additive errors of a bunch of really hard problems coming together. He focuses on the complexity of what is coming down the wire. Frameworks and Web Performance Yoav talked about how people buy into a framework prematurely without knowing what the consequences would be for web performance. It usually happens that they are two years into using a framework, and then realize that a rewrite they did is a disaster from a performance perspective. He describes how it would be beneficial to protype in different stacks to see performance, but it isn’t being done. Sia added that a lot of this happened before people started really caring about web performance. She thinks that maybe now people may pause and consider the implications of some of the initial decisions being made. Estela agreed that teams don’t try different Frameworks first and pick the proper one because Frameworks are becoming more and more complex. It’s also hard to switch to a different technology in a timely manner. Browsers and Web Performance Alex spoke about his disappointment for the way browsers have behaved. Core vitals is a step up because it indicates that we are closing the circuit between what users actually experience. He talks about how the browser lacks in being the guarantor of solidarity between the decision-making wealthy class, and the people who are going to be excluded from these services. Yoav agreed that we could do a lot to incentivize developer behavior in the browser. Solutions to Support Web Performance Sia spoke about how performance would make you into a multi-million dollar company, but it could change how many extra millions you get. If you’re a Dev shop, there isn’t any prioritization on performance because they’re trying to get the client to pay for that feature. The client is the one who has to care about performance. Senior leadership in a large company has to care as well. Alex talked about HTML over the wire is really great for helping with web performance. He also mentioned SvelteKit, and how they are very responsible when it comes to web performance. Closing The conversation went in depth about the state of web performance, what is being done to help bring more awareness to it, and also how it can be improved. The panelists were very engaged, and brought many ideas to the table. It is always good to continue to have these discussions in order to stay current or talk about what needs to be done to keep things moving forward for the future of web performance. You can watch the full State of Web Performance event on the This Dot Media Youtube Channel....

Performance Analysis with Chrome DevTools cover image

Performance Analysis with Chrome DevTools

When it comes to performance, developers often use Lighthouse or similar performance analysis tools. But when the target site has protection against bots, getting information is not that simple. Chrome Devtools can help you with your performance analysis....

State of Web Performance: A look into the Interaction To Next Paint, Aurora, and the importance of learning web performance cover image

State of Web Performance: A look into the Interaction To Next Paint, Aurora, and the importance of learning web performance

In this article, we will cover the main topics discussed during this State of Web Performance event. We will recap the panelists' thoughts and address some of the questions raised during the event. Here is the complete list of hosts and panelists that participated. Hosts: - Rob Ocel, Team Lead & Software Architect, This Dot Labs, @robocell - Henri Helvetica, Dev. Community Manager, WebPageTest by Catchpoint, @HenriHelvetica Panelists: - Katie Hempenius, Developer Programs Engineer, Web Performance at Google @KatieHempenius - Alex Russell, Product Manager on Microsoft Edge, @slightlylate - Sia Karamalegos, Web Performance at Shopify, @thegreengreek - Mel Ada, Web Performance at Etsy, @mel_melificent - Annie Sullivan, Team lead for Core Web Vitals metrics / Google Chrome, @anniesullie Table of Contents - Updates to Web performance - Google Chrome - New API’s to help with image CDN’s - Aurora - Shopify - The panelists view on understanding performance - Questions from the chat - How much should performance initiatives rely on platforms & frameworks vs. the education of engineers on best practices and performance analysis? - Do Frameworks and abstractions influence performance? - As we push for new developers to learn performance, is it going to be confusing for the community to also understand Real User Monitoring (RUM)? - Should browsers be more aggressive in dealing with third parties? - Conclusion Updates to Web Performance Google Chrome Annie Sullivan started by sharing updates on web performance for the Google Chrome browser. The team at Google is working on the new Interaction To Next Paint (INP) metric, to help single-page apps detect transitions for better metric measurements and how they help with app performance. New API’s to help with image CDN’s Katie Hempenius then shared an experimental API that is coming to Angular to help with image CDNs and correct image sizes. Aurora Katie continued to share the work her team is doing with Aurora. Aurora is a collaboration between Google Chrome Team and framework authors to help build optimization into frameworks by default. This currently works with Next.js, Nuxt, and Angular to add performance features shipped by default. Shopify Sia Karamalegos shared that the team at Shopify is ensuring that educational resources are available for the community so developers can learn about best practices and web performance. The panelists view on understanding performance Alex Russell explained that handling performance is mostly cultural as it is not an education you can get or learn from a course. It is mostly about learning from the people you work with and hoping that will add the knowledge and values for your skillset. Annie Sullivan talked about her experience with working on the frontend of Google search. When it comes to performance, there are many best practices which all work but the approach should be to look at the bottle-necks of your project to identify the requirements of the framework or architect that may affect the performance of the app. Questions from the chat How much should performance initiatives rely on platforms & frameworks vs. the education of engineers on best practices and performance analysis? Sia Karamalegos pointed out that people don’t prioritize performance. But when you start measuring performance and have it influence other parts of the business then you start getting more motivation to fix those things. These are the incentives that make an impact and most times developers are focused on pushing out features to save time. This leads to developers ignoring the need to consider performance or training to learn how to measure performance unless it is specified on the ticket they are working on. Katie added that part of the updates coming to Google Chrome is to provide prescriptive details to point people in the right direction towards optimizations that will help specifically for the use-case of your business. Do Frameworks and abstractions influence performance? Alex Russell discussed that based on traffic, type of clients, bandwidth, and interactions on the application will influence trade-offs for frameworks or systems as you start to build or rebuild your application. Developers should always consider how much complexity is necessary for a project, and they should be aware that everything that comes with a framework is now owned by them. Katie Hempenius added that this type of complexity is hard to fix and this is where the need to have someone on the team who understands how the app fits together and how to make it better in terms of performance. As we push for new developers to learn performance, is it going to be confusing for the community to also understand Real User Monitoring (RUM)]? Katie Hempenius explained that once you have it in place, it can be clarified, rather than going in circles trying to predict how an element will perform in the field if you have the RUM data it can tell you the answer. It is recommended that people should use webvital.js with debugging data to get information about what element is the Largest Contentful Paint (LCP) element to allow them to run their own experiments. Should browsers be more aggressive in dealing with third parties? Katie Hempenius pointed out that if it is well executed, it could move the industry in a good direction. Annie Sullivan referred to the work she is doing with her team for SPA transition to help understand third parties better, and the potential to measure it better. Alex Russell mentioned that what you want is to build solidarity between folks who are making decisions and the people implementing it, and he made an example with the browser’s lock icon and how it creates solidarity and causes decision-makers to prioritize a particular behavior about their technology choices. There is a role for browsers to play to help surface whether or not most users are going to have a good time or bad time on this site and to use that as a way to signpost to everyone in the industry whether or not choices that were made in this particular location were appropriate. Sia Karamalegos mentioned that browsers can do more and it doesn’t take off the responsibility of an organization or a team to keep an eye on that. This is common when an organization has not done web performance, and uses 20 to 30 different third parties, ignoring the need to either optimize or remove. Even though browsers can do so much, the organization still needs to review those. Conclusion I hope you enjoyed that recap of the State of Web Performance event. Are you excited about learning web performance and improving your apps? Tell us what excites you on Twitter!...

State of Web Performance Recap cover image

State of Web Performance Recap

We recently wrapped up our State of Web Perf event host by Rob @robocell and Jae @dulcedejae. There were many great topics proposed and questions asked. In this article, I'm going to give you a quick rundown of the event. However, I would strongly encourage you to watch State of Web Perf on Youtube. What is State of Web Perf "State of Web Performance" is an event hosted by This Dot Labs where you'll hear from a panel of various web performance experts. Key points Even though there are a lot of tools, libraries, frameworks, and methodologies, a continued focus on web performance means that things will continue to get better. An increased focus on reducing Javascript bundle sizes means the web will continue to prioritize web performance, although as developers, we should always be keeping performance and speed in mind. Javascript bundle sizes One of the stumbling blocks with measuring web performance is getting an idea of how big of a stumbling block bundle sizes actually are. With the availability of fast network speeds, are Javascript bundle sizes something to keep close to heart? Most would argue yes. Not only does it help your site load faster in all aspects, even those who may not have high-speed internet or a reliable data connection, can still experience your site. This does go without saying that bundle sizes aren't the only thing we need to worry about in web performance. Web builder performance issues More often than not, website builders struggle in the web performance department. If you've used one, you know. Mostly recently companies such as Shopify have been creating dedicated web performance departments focused on creating the most performant product. It's always a great idea to address web performance from the beginning that way you stay ahead of the game and won't struggle to fix performance issues later down the road. Things to consider 👉 Always be aware of the trade-offs when it comes to your webpage! 👉 Keep in mind the number of #npm packages, fonts, or images for example! 👉 Make good use of devtools to measure the web performance impact. 👉 The less JavaScript you have to render in the browser, the better your web performance will be! 👉 Lots of frameworks and libraries are working hard to address this issue 👉 Testing and user metrics are key components to measuring we performance Image handling Images are complicated. JPG and PNG used to be the most popular format for photos, but when it comes to photos on the web, it could be better. Web performance is a fast growing format that is great for the web. Following close behind is WebP. Definitely check them out if you'd like to improve photos on your website. This wraps up our State of Web Perf recap!...

3 Web Performance Concepts that Will Help Start a Conversation Around Performance cover image

3 Web Performance Concepts that Will Help Start a Conversation Around Performance

In 2021, This Dot Labs released PerfBuddy, the free online platform for testing web and mobile based sites. With the release of this tool, it was our sincere hope to simplify the conversation around web performance, helping team leaders develop easy to understand metrics that they can use to advocate for further investment into their various web technologies. But we also realize that many new to web development, or who work in software but not as developers, might need more clarification on some of the basic key terms to help them engage more actively in conversations surrounding web development. Below, I’ve defined three of the top terms in web performance to help readers better ascertain your site’s performance, and play an active role in refining their technologies to provide the best experience for their customers. First Contentful Paint Time (FCP) FCP, or First Contentful Paint Time, is a critical metric that measures the time that users must wait in order for a page to load its first visible element. For some sites, this could be the entire page. However, for others, the FCP time might measure the seconds between a user navigating to a site, and any responsive element, such as a loading bar, appearing in front of them. This is not a measurement of backend nor even frontend script loading speed, but a metric that affords development teams the ability to infer the quality of their site’s initial UX. According to metrics published by Akamai in 2018, sites are liable to lose nearly half of their visitors if their page takes more than three seconds to load. In fact, just a single second of load time delay can result in a 7% decrease in sales conversions for eCommerce platforms. This is especially true when considering mobile users, whose likelihood of leaving a page increases 90% when made to wait 5 seconds for a page to load And as more eCommerce shoppers turn to using their mobile devices- with 53% of users accessing shopping sites via mobile platforms on 2019’s Cyber Monday, representing a 40% YOY increase- teams need to be acutely aware of their cross platform performance with respect to FCP. Time to First Byte (TTFB) Not to be confused with FCP, TTFB, or Time to First Byte, refers to the amount of time that the browser waits in order to receive initial data from its server. In order for a site to display any information, a browser must make dozens, if not more, data requests. Issues related either to the quality of the host, site functionality, or complexity can all contribute to a site’s latency, or the amount of time it takes for data to be passed between the server and the browser. Of course, reducing site latency will improve user experience by decreasing FCP, and generally increasing browsing speed. However, ensuring low TTFB will also boost your SEO by making your site more quickly crawlable by leading search engines. Page Weight As developers add features and functionality to support more advanced user experience, web pages get heavier. As of 2020, the average desktop webpage weighs 2080 KB, up from an average of 1532 KB in 2017, with the weight of mobile web pages slightly lower, but still seeing a near 40% increase in size when compared to stats from just four years ago. eCommerce websites need to maintain acute awareness of their page weight, and ensure that their latency is not overly impacted by it, due to the tendency for shopping sites to be especially complex, supporting large catalogs of products along with other features to promote customer engagement. And as this era of advanced digital transformation continues to expand, eCommerce sites must develop strategies to meet market expectations for performance without over burdening their sites with heavy plugins and functionalities. Finding Your Path to Performance It starts with equipping yourself with the right tools to test your site’s speed and weight. There are countless platforms used for testing sites, however, there are only a handful that are capable of unlocking the insight that you need to support your most critical websites. Though PerfBuddy is a great place to start in order to identify potential roadblocks, it cannot do the work of actually improving site performance. By leveraging testing platforms such as Lighthouse, and continuously improving your performance metrics with assets such as DevTools, and strategies like Google’s PRPL, eCommerce retailers can ensure that their sites meet user expectations and promote their most critical business objectives. Need help? Contact This Dot Labs to learn more about how developing the tools and strategies to ensure optimal site performance can support scalable growth as you continue refining user experience!...

Avoid common pitfalls when using OnPush change detection in Angular cover image

Avoid common pitfalls when using OnPush change detection in Angular

By default, Angular provides two different change detection strategies: Default and OnPush. Each has his own advantages, but sometimes we run into pitfalls if we don't understand how to apply OnPush and how it works. First, we need to understand how Angular implements change detection. How Angular implements change detection? Like any other framework, Angular must have a way to synchronize its internal model state to the view. In particular, the framework by Google checks all components for changes in different occasions. These can include: - Network Requests - Mouse clicks - Mouse scrolls - Keyboard events, and more... In general, all componentes are checked. The Angular team spent a lot of effort on highly optimizing the change check internally. By default, it walks the application component's tree, an array, from start to finish. On its way, it searches for children and values that have to be compared and checked (e.g., *@Inputs()*, *@Outputs()*, and other template-bound references). But this comes with a downside. Angular cannot know which of the values is bound at some point, but us as developers, we can know when values change, and what value in an object changes, and this is where OnPush change detection comes in. OnPush change detection ` When the OnPush change detection is declared as we see above, the change detection doesn't run automatically anymore. Instead, it listens for specific changes, and only runs the change detection in those scenarios. It runs if an *@Input* changes, or if a component was marked for a check. Remember, when comparing @Inputs, they are compared by identities (**). OnPush and Object mutability For ex. we declare a parent component and a child component. ` If we click on changeDirector() button, we will change the name of the movie director, as we set previously the changeDetection, this will not update the director on the template. This occurs due to the fact: - we mutated the object directly - onPush works by comparing references of the inputs of the component - because we mutated an existing one, onPush change detector will not be triggered BUT, *we can avoid this situation, creating a new instance of the director instead of mutate the existing one.* ` We simply need to either avoid mutating objects directly or use an immutability library to freeze the view model data that we pass to our components. Let's see in action on Stackblitz. OnPush and event handlers If for example, we have an @Output event inside the director component, we will see that the director will show the new name and lastName information, but why is this? This occurs because the triggering of event handlers cause the onPush change detector to trigger, independent of whether the inputs have changed or not. We can then assume that OnPush is more than just checking input. Conclusion OnPush is defined this way. It runs only in certain scenarios, and we need to keep that scenarios in mind if we want our app works smoothly. Those scenarios include: - When a DOM event the component listens was received - When the | async pipe receives a new event - When a @Input() was updated by change detection - When explicitely registering the component to be checked using ChangeDetectorRef...

Testing with PerfBuddy: The Easy to Use, Free Performance Testing Tool from This Dot Labs cover image

Testing with PerfBuddy: The Easy to Use, Free Performance Testing Tool from This Dot Labs

We are encountering a peculiar time in the history of web development. Never have there been so many unique technologies, and advanced digital assets, all simultaneously converging to deliver the user experiences that the contemporary market demands. Not only are our codebase systems more customizable and extensible than before, but the rapid expansion of new development technologies is affording web platforms the opportunity to shape what customers will come to expect from their online browsing experiences. However, as our codebases become more complex, development teams will need to direct as much, if not more attention, to site performance as they do to functionality. Fortunately, This Dot Labs, is helping these teams quickly look under the hood with PerfBuddy, the free and easy-to-use browser-based performance testing tool. Getting Started With PerfBuddy You can begin testing your site’s performance with just one click! Simply copy/paste the page you are interested in testing, and press the “Start Test” button. No need to register or provide any further information! Let’s Look at a Report After a few moments, PerfBuddy will make your report available in the browser. The reports will show distinct metrics for both mobile and desktop, and include 1-100 point scores in the areas of Performance, Best Practices, Accessibility, & SEO. Below, you can find the clear and easy-to-read report for As you can see, Tesla’s desktop website is operating smoothly, but there are some areas where the site falls behind industry averages, resulting in suboptimal performance. This may not be as significant of an issue for a site that offers information about a very specific topic/product, but with many companies competing for the attention of the same potential customers, lower than average performance and SEO metrics can result in lost business! We were surprised to see the challenges facing Tesla’s mobile website, though their Best Practices score was perfect, and their Accessibility score was significantly higher than average. Site Loading Metrics As users continue reviewing their report, they can view site loading metrics for both desktop and mobile. Below, you can see metrics for desktop: And site loading metrics for mobile as well: Along with all of these metrics, users can look at simple definitions of each metric, with the option to learn more by following a link to explore external resources the developers found helpful and relevant. Performance Score Following site loading metrics, users can review specifics about their desktop site’s performance score, as seen below: And users interested in learning details about their score can review more specific metrics in the “Performance” section of the report where they can expand each metric to learn more and discover resources for increasing their performance metrics. And users can review the same metrics for their mobile performance as well: Best Practice Score Best practice scores, which evaluate performance optimizations against their potential impact on user experience, are made available for both desktop and mobile, and provides resources for optimizing site maps for large first-party JavaScript. Accessibility Score A site’s accessibility by web users with diverse abilities is a crucial aspect of optimal web performance. When thinking about Accessibility, we consider a site’s usability for those with vision, as well as motor-ability differences, including those using adaptive technologies to interact with a user interface. Fortunately, PerfBuddy evaluates a site’s accessibility, providing metrics that allow users to identify pain points that impede its performance for the widest possible user base. First, users can see an overall score for both desktop and mobile: As well as specific impediments that developers can improve in order to raise their accessibility score. In Tesla’s instance, both desktop and mobile suffer from the same nonoptimal features: SEO Score Finally, users can review their site’s Search Engine Optimization score, which provides specific site features that may be improved to increase their site’s search relevance for both desktop and mobile: And below these scores, users can expand various boxes to review the specific site features that can be changed to improve SEO as well as links to resources for how to effect these changes: PerfBuddy is Here to Help PerfBuddy was designed for developers by developers, and This Dot Labs is thrilled to make this accessible tool available to the web development community for free and without any commitments. It is our hope that developers are able to use PerfBuddy to improve their websites by leveraging the resources made available to them in their unique web performance reports, or utilize the reports’ clear and concise language to advocate for performance investment within their own organizations. However, some users may find that they need help implementing the improvements needed to boost their performance scores and improve the experience of their users, and so users are encouraged to reach out to the team at This Dot Labs if they need any help understanding their reports or implementing performance optimizations. Though there is a form for contacting the team on every report, users may also contact the team for further assistance by emailing

Improving Angular ngFor using trackById Directive cover image

Improving Angular ngFor using trackById Directive

Here's how you can improve your Angular app using trackBy in your *ngFor directive....

5 Tips to Improve Your Site's Web Performance  cover image

5 Tips to Improve Your Site's Web Performance

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. - 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....

Functional testing with Cypress cover image

Functional testing with Cypress

Have you ever needed to test the functionality of an app in a controlled environment? In this post we show you how to intercept network requests with cypress to simulate different scenarios...

Performance: Optimizing Images on Gatsby Sites cover image

Performance: Optimizing Images on Gatsby Sites

Performance: Optimizing Images on Gatsby Sites Our Labs website is written using Gatsby, and uses images in many places. We have images that are both statically hosted, and images that are hosted in Contentful. The Problem We found that many of our static images weren't compressed as optimally as they could be and were inflating page sizes. This example comes from a page with many images that are being used as-is with no post-processing in the site build. Some of the images are lossless compressed PNGs that can be JPGs instead, and some of them are already JPGs but their sizes far exceed the size of the container they're in. The Solution Instead of manually optimizing each static image we can let gatsby-image do this for us. Static Images The static images can be easily fixed by replacing all uses of with from gatsby-image. GQL queries will also need to be updated to return fixed or fluid images. gatsby-image doesn't take image urls directly like a normal tag does, but instead, takes a special fluid or fixed type that optimizes the images differently. The fixed type should be used when the width and height are known, and will not change. The fluid type should be used if the image will stretch to fill the container that it's in, depending on the screen size. Here's an example of an for avatars being replaced with a fixed image. ` The type of avatarUrl needs to be changed from a string to a sharp fixed image in the GQL query. This is also where optimization parameters such as size and quality can be configured. ` Here, just width and height are specified, but there are other useful parameters such as quality and toFormat, which can be useful if you want to make sure images are converted and compressed to your liking during the build. Here's an example that ensures images have a size of 160x160 and are JPGs with 80% quality: ` All static image paths returned by the query should be relative so that gatsby-image can find them. Absolute image paths will not work with it like they do with . Optimizing Images from Contentful While the gatsby-image package makes it very easy to optimize images when you're dealing with content templates, it doesn't work well on its own if you're dealing with markdown or pre-supplied HTML. Posts on our Labs blog are written in markdown, and are stored with Contentful, and we render posts by converting them to HTML with gatsby-transformer-remark. We're able to optimize these images using gatsby-remark-images-contentful. This plugin extends gatsby-transformer-remark to output images that use parameters from Contentful's Image API, and to generate different sized versions of images that are chosen based off of the size of the device. This plugin also adds a "blur up" effect as the image is downloaded, and holds the size of the incoming image to prevent a reflow. It's also notable that using this plugin will give us image lazy loading as well, which can speed up load times for image heavy pages substantially. Here's how we configured this plugin in gatsby-config.js: ` Before & After Results Here's an example of how our teams page has improved and went from a 856kB image weight to 300kB with these simple changes. Before After Here's an example of an image heavy blog post with images from Contentful that had its initial load size cut by _almost 50%_, from 6.1MB to 3.4MB. Before After The gains seen here come mostly from lazy loading provided by gatsby-image, so images are only downloaded once they're about to come into view; however savings also come from serving images of appropriate sizes, so a mobile device such as the Pixel 2 will have an initial load of 1.6MB. We don't forcefully format all blog post images to JPG currently as there may be legitimate reasons to not use them, e.g. you want to keep transparency or embed animated gifs. Closing Gatsby makes it easy to optimize your sites without expending too much effort. If you're already using Gatsby, I'd encourage you to make sure you're using it to its fullest potential....