General

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

Feb 9, 2022

4 min read

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!

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.

Tracy Lee

Partner, This Dot Google Developer Expert (Angular, TC39, Web) RxJS Core Team & Lead for RxJS Learning Team Contributor to Angular, RxJS, EmberJS

Key Strengths:

Teaching developer relations strategies
Influencer marketing
Developing brands
Community strategies and maintenance
Creating product launch strategies
Leading marketing operations efforts & standards
Effective conference presence & speaking strategies

@ladyleet @ladyleet

JSR - The cross-platform package manager for ESM

JSR - The cross-platform package manager for ESM Move over NPM, there’s a new package manager in town. JSR is a new open-source package registry for JavaScript and TypeScript. This particular release has caught my attention, and I’m excited to explore if and where JSR fits into our overflowing ecosystem. Setting the stage The JSR website has a page called Why JSR? I want to explore the _why_ a little bit further. I think that the _why_ points to JSR potentially being the future of the JavaScript ecosystem. NPM and JavaScript modules If you’ve found yourself confused about publishing and consuming packages and modules in the modern ESM era, you’re not alone. When NodeJS was created, there was no standard for JS modules. Node introduced CommonJS modules, and NPM provided a way to publish and consume these modules in our applications. It’s been years now since ES Modules became a standard and we are still in a weird module purgatory with no clear end in sight. JSR represents a fresh start, free from the baggage of the Node and NPM ecosystems. JavaScript runtimes and interoperability New JavaScript runtimes are popping up every year. WinterCG (_Web-interoperable Runtimes Community Group)_ was started to improve interoperability for the various runtimes with some standard APIs. Node has made steps towards this goal, but it might never get all the way there and NPM is coupled pretty tightly to that ecosystem. JSR supports several runtimes (depending on the package). This is a huge opportunity for it to become the package manager for the ecosystem at large. See cross-runtime support section for more details. NPM Compatibility JSR doesn’t end up being a complete departure from NPM since it includes an NPM compatibility layer. The docs highlight some limitations and provide deeper technical details on how this piece works. The simple overview is that you can install and use packages from JSR to a Node/NPM based project. The packages will get added to your package.json and node_modules directory. About the same as any package installed from NPM. JSR Overview At a high level, JSR is very similar to NPM. You can search for packages on the website. You can publish packages to their registry, and you can download packages from it as well. We touched on the two major features that set it apart from NPM: It only supports ESModules, and it has cross-runtime support. In the rest of the article we’ll explore the essentials (package management) and also some other really great features that feel like are bringing the JS package management ecosystem up to speed with our modern workflows. Native TypeScript I have to say I’m not surprised by this feature, considering JSR was developed by the same people behind Deno (a runtime that supports TS natively). It’s a great feature. If you haven’t figured it out yet TypeScript is a big deal and doesn’t seem to be fading away anytime soon. So what exactly does TS support look like in a package manager, though? If your runtime supports TypeScript natively (like Deno) - it can consume the TS files in your package directly. For environments that don’t, it will automatically compile your code to JavaScript and package it with type declaration files (.d.ts). Pretty, stinking, cool. The docs include a page called “about slow types”. It is probably worth a read on its own ,but the TLDR is that JSR will analyze your TS code and penalize you in certain ways if you have some type code that it considers to be slow. On the page, it outlines exactly what these penalties are, as well as what it considers slow types to be. Slow types will also come into play when we get into package scoring later in the article. Packages The docs have a page dedicated to packages. It covers some important stuff like deleting packages, versioning, documentation, and publishing. We’ll touch on some of it with an emphasis on the things that are done differently or better than with NPM. jsr.json file jsr.json is a configuration file that specifies a name, version, and exports of a package. It doesn’t include a list of dependencies like you would have in a package.json file. This is a configuration file for a package to be published to JSR. JSR dependencies are defined in an import map file or a package.json file, depending on the runtime. Adding packages to a project Adding packages to your project will vary depending on your target runtime. Here’s an example of installing it for Deno and NPM using various package managers. For Deno, an import map entry is created. For NPM, it gets installed as an NPM package using the JSR NPM compatibility layer. ` If the runtime has native JSR support, you don’t need to explicitly install packages. You can important them using the jsr: scheme. ` As you can see semantic versioning is supported and works similarly to NPM. Publishing packages If you want to publish a package to JSR, there are many important rules you need to be aware of. I recommend reading “Publishing packages” before moving forward with this. The main things to note are: ESModules only, npm packages are supported, JSR packages are supported, and node APIs are supported. So there aren’t many constraints. You just need to understand how exactly to do these things. IE: how do I use NPM dependencies, how do the imports work, etc? Once you’ve got all that down, you will be ready to publish your first package to JSR 😃 Documentation JSR emphasizes quality package documentation. It’s one of the factors in their package scoring algorithm, which we will discuss shortly. The important parts of a package’s documentation include: * a README.md file * symbol documentation - functions, interfaces, classes, etc * module documentation - docs for each exported module in a package The symbol and module documentation are written using JSDoc. The JSR website generates some nice documentation based on these 3 pieces on your package page. This means you can understand a package's entire public API without ever leaving jsr.io. Browser support The cross-runtime support is amazing, but I was curious where the original JavaScript runtime fit (the browser). According to the documentation: “You can use JSR with any tool that supports ES modules, and either has native support for JSR or supports npm packages using node_modules.” Since modern web browsers support ES modules, I will count this as JSR support. From what I can tell, though, there is one caveat. To include a module on a web page, we need a URL to download it from. Can we publish our package to JSR and use it to load a module via a script tag? According to the JSR usage policy, no. The “Unacceptable use” section states: “It is not acceptable to use JSR as a CDN for serving assets directly to web applications in a browser, except for development purposes.” So, it seems that this is a no-go for now. We will probably need to wait a bit for CDN services like jsdelivr to pull packages from the JSR registry, similar to what they do with NPM currently. Other notable features We’ve covered the most important bits about package management, TS support, NPM compatibility, etc. But there are still a few unique features that add an extra bit of sparkle to JSR. Scoring We mentioned earlier that documentation plays a part in a scoring algorithm. JSR analyzes all of the packages published to its registry and assigns them a score based on certain criteria: documentation, best practices, discoverability, and compatibility. This score is shown with every package listed on the website. You can also add a shiny badge to your README if you’re particularly proud of something. It’s still early on, so it’s likely this will evolve as time goes on. It’s an interesting gimmick, at the very least! Summary I am excited to have a new cross-platform compatible package manager that only supports ESM. As useful as NPM has been all these years, it carries a lot of baggage from “the olden days”. JSR’s native TypeScript support and reliance on modern standards is a breath of fresh air. It feels like I can publish a simple package without much ceremony. I’m excited to release my first package to JSR soon :)...

Apr 12, 2024

6 mins

JSRJavaScript

Understanding Vue.js's <Suspense> and Async Components

In this blog post, we will delve into how and async components work, their benefits, and practical implementation strategies to make your Vue.js applications more efficient and user-friendly. Without further ado, let’s get started! Suspense Let's kick off by explaining what Suspense components are. They are a new component that helps manage how your application handles components that need to await for some async resource to resolve, like fetching data from a server, waiting for images to load, or any other task that might take some time to complete before they can be properly rendered. Imagine you're building a web page that needs to load data from a server, and you have 2 components that fetch the data you need as they will show different things. Typically, you might see a loading spinner or a skeleton while the data is being fetched. Suspense components make it easier to handle these scenarios. Instead of manually managing loading states and error messages for each component that needs to fetch data, Suspense components let you wrap all these components together. Inside this wrapper, you can define: 1. What to show while the data is loading (like a loading spinner). 2. The actual content that should be displayed once the data is successfully fetched. This way, Vue Suspense simplifies the process of handling asynchronous operations (like data fetching) and improves the user (and the developer) experience by providing a more seamless and integrated way to show loading states and handle errors. There are two types of async dependencies that can wait on: - Components with an async setup() hook. This includes components using with top-level await expressions. *Note: These can only be used within a component.* - Async Components. Async components Vue's asynchronous components are like a smart loading system for your web app. Imagine your app as a big puzzle. Normally, you'd put together all the pieces at once, which can take time. But what if some pieces aren't needed right away? Asynchronous components help with this. Here's how they work: - Load Only What's Needed: Just like only picking up puzzle pieces you need right now, asynchronous components let your app load only the parts that are immediately necessary. Other parts can be loaded later, as needed. - Faster Start: Your app starts up faster because it doesn't have to load everything at once. It's like quickly starting with the border of a puzzle and filling in the rest later. - Save Resources: It uses your web resources (like internet data) more wisely, only grabbing what’s essential when it's essential. In short, asynchronous components make your app quicker to start and more efficient, improving the overall experience for your users. Example: ` Combining Async Components and Suspense Let's explore how combining asynchronous components with Vue's Suspense feature can enhance your application. When asynchronous components are used with Vue's Suspense, they form a powerful combination. The key point is that async components are "suspensable" by default. This means they can be easily integrated with Suspense to improve how your app handles loading and rendering components. When used together, you can do the following things: - Centralized Loading and Error Handling: With Suspense, you don't have to handle loading and error states individually for each async component. Instead, you can define a single loading indicator or error message within the Suspense component. This unified approach simplifies your code and ensures consistency across different parts of your app. - Flexible and Clean Code Structure: By combining async components with Suspense, your code becomes more organized and easier to maintain. An asynchronous component has the flexibility to operate independently of Suspense's oversight. By setting suspensible: false in its options, the component takes charge of its own loading behavior. This means that instead of relying on Suspense to manage when it appears, the component itself dictates its loading state and presentation. This option is particularly useful for components that have specific loading logic or visuals they need to maintain, separate from the broader Suspense-driven loading strategy in the application. In practice, this combo allows you to create a user interface that feels responsive and cohesive. Users see a well-timed loading indicator while the necessary components are being fetched, and if something goes wrong, a single, well-crafted error message is displayed. It's like ensuring that the entire puzzle is either revealed in its completed form or not at all rather than showing disjointed parts at different times. How it works When a component inside the boundary is waiting for something asynchronous, shows fallback content. This fallback content can be anything you choose, such as a loading spinner or a message indicating that data is being loaded. Example Usage Let’s use a simple example: In the visual example provided, imagine we have two Vue components: one showcasing a selected Pokémon, Eevee, and a carousel showcasing a variety of other Pokémon. Both components are designed to fetch data asynchronously. Without , while the data is being fetched, we would typically see two separate loading indicators: one for the Eevee Pokemon that is selected and another for the carousel. This can make the page look disjointed and be a less-than-ideal user experience. We could display a single, cohesive loading indicator by wrapping both components inside a boundary. This unified loading state would persist until all the data for both components—the single Pokémon display and the carousel—has been fetched and is ready to be rendered. Here's how you might structure the code for such a scenario: ` Here, is the component that's performing asynchronous operations. While loading, the text 'Loading...' is displayed to the user. Great! But what about when things don't go as planned and an error occurs? Currently, Vue's doesn't directly handle errors within its boundary. However, there's a neat workaround. You can use the onErrorCaptured() hook in the parent component of to catch and manage errors. Here's how it works: ` If we run this code, and let’s say that we had an error selecting our Pokemon, this is how it is going to display to the user: The error message is specifically tied to the component where the issue occurred, ensuring that it's the only part of your application that shows an error notification. Meanwhile, the rest of your components will continue to operate and display as intended, maintaining the overall user experience without widespread disruption. This targeted error handling keeps the application's functionality intact while indicating where the problem lies. Conclusion stands out as a formidable feature in Vue.js, transforming the management of asynchronous operations into a more streamlined and user-centric process. It not only elevates the user experience by ensuring smoother interactions during data loading phases but also enhances code maintainability and application performance. I hope you found this blog post enlightening and that it adds value to your Vue.js projects. As always, happy coding and continue to explore the vast possibilities Vue.js offers to make your applications more efficient and engaging!...

Apr 24, 2024

6 mins

VueWeb PerformanceUXJavaScript

This is the Worst Thing a DevRel Team Could Do

At its core, a successful Developer Relations (DevRel) program focuses on forming strong connections within its target audience to ensure that developers can easily connect with the company or organization behind the product they’re using. Great teams in DevRel build genuine relationships, earn trust, and actively engage with developers. DevRel takes a different approach from traditional marketing strategies. Instead of just chasing numbers and leads for sales, it puts emphasis on making developers happy and retention. This creates a cycle of feedback between users and a company, helping to better understand their needs and fostering a sense of community among users. There have been organizations that consider DevRel a revenue-driving function, but this is where challenges arise, since DevRel teams cannot consistently show value in this area and meet the expectations of stakeholders expecting this based on where their focus and the profession lies. When DevRel professionals are forced to be revenue drivers, the breakdown between developers and that company is inevitable. Developers can smell hidden agendas from a mile away. They realize when their needs are being overlooked in favor of sales initiatives. *“Companies fail at DevRel when they try to turn them into sales teams. This hurts customer trust.” - Michael Liendo, Senior Developer Advocate at AWS. * Developers care about education, resources, opportunities, and the overall experience of a product or platform. When they are a target for sales pitches, they leave or shut down. Their focus is getting the job done, and they talk to companies to solve problems in their development lifecycle, not to be on the receiving end of a pitch. Furthermore, since all successful DevRel teams are focused on building authentic relationships with developers, strategic partnerships with other organizations will be hard to come by or have dismal retention numbers since no one wants to be associated with trying to sell to developers. Good DevRel teams are focused on helping developers and understand that being helpful goes a long way to help the sales cycle. Many DevRel efforts also focus on providing value to a community before asking for something in return. The trust and authenticity of brand building in this area and those initiatives - the loyalty a DevRel team is trying to generate - many times does not make direct corollary sense from a monetary perspective, and sales organizations often overlook the non-monetary value and impact these efforts generate and how they correlate to long-term growth for an organization. In DevRel, genuine connections matter more than immediate revenue. When teams prioritize developers' needs over sales, trust grows, fostering lasting relationships that drive long-term success. Treating DevRel as solely a sales function erodes trust and misses the true value of building authentic partnerships and community loyalty. Interested in learning more about launching your own DevRel program, feel free to reach out!...

Mar 6, 2024

2 mins

DevRel

How to Make Coding Both Your Hobby and Profession with Jason Lengsdorf @ CityJS Conf 2024

Join us backstage at CityJS Conf for this conversation with Jason Lengsdorf. In this discussion, we explore strategies for reducing stress and anxiety among engineers, ensuring they maintain relevance in the dynamic world of coding. Jason emphasizes the importance of self-assurance and the role of play in fostering continual engagement with evolving technologies. Moreover, we get a sneak peek into Jason's latest venture, "Web Lunch," a platform where he converses with developers who have found harmony between their careers and personal satisfaction. Coding isn't just a job; it's a passion and a lifestyle. Jason highlights the significance of pursuing work that excites and challenges us, echoing the sentiment that coding can be both a career and a hobby. By infusing enjoyment and creativity into our coding endeavors, we can shape our professional trajectories in alignment with our values and interests. This approach not only minimizes regret but also maximizes happiness and fulfillment in our careers. Central to our discussion is the pivotal role of effective leadership in creating a supportive and encouraging work environment. Leaders who prioritize the well-being and happiness of their team members foster a culture of collaboration and empowerment. Through mentorship, guidance, and opportunities for growth, these leaders enable developers to align their personal goals with organizational objectives, leading to increased job satisfaction and professional fulfillment. Adaptability is key to sustained success in software engineering. Jason emphasizes the value of remaining open-minded and continuously learning, even when it means stepping out of our comfort zones. Embracing discomfort is an integral part of personal growth, allowing us to overcome obstacles and unlock our full potential. By nurturing a spirit of curiosity and adaptability, developers can navigate the complexities of their careers with resilience and enthusiasm....

Apr 25, 2024

2 mins

JavaScriptMentorship

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

First Contentful Paint Time (FCP)

Time to First Byte (TTFB)

Page Weight

Finding Your Path to Performance

Tracy Lee

You might also like

JSR - The cross-platform package manager for ESM

Understanding Vue.js's <Suspense> and Async Components

This is the Worst Thing a DevRel Team Could Do

How to Make Coding Both Your Hobby and Profession with Jason Lengsdorf @ CityJS Conf 2024

You might also like

JSR - The cross-platform package manager for ESM

Understanding Vue.js's <Suspense> and Async Components

This is the Worst Thing a DevRel Team Could Do

How to Make Coding Both Your Hobby and Profession with Jason Lengsdorf @ CityJS Conf 2024