Javascript

Are Performance Issues Really Next.js’s Fault? What Vercel Should Actually Be Building

Feb 27, 2024

1 min read

Jay Phelps is a Senior Software Engineer at Netflix and shares his experiences and perspectives on the challenges and opportunities facing web developers. Along with Ben Lesh, Tracy Lee, and Adam Rackis, they talk about the impact of third-party services on performance optimization, what’s in store for React, and whether Next.js is really the best solution for software engineers.

Jay shares his thoughts on how the web platform (aka Chrome team) can improve performance, and why some of the issues facing Next.js developers are really not Next.js’ fault. He also shares his thoughts on what Vercel could focus on (or should focus on) and why Partytown is worth looking into for those building storefronts.

Download this episode here.

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.

Exploring the Hidden Gems of the Next Image Component: What You Might Be Overlooking

Welcome to a journey of discovery where we'll explore the often-overlooked capabilities of the Next.js Image component. At first glance, this component might seem like a straightforward tool, merely enhancing performance compared to a regular img tag. However, there's more to it than meets the eye. In this blog post, we'll uncover the magic of some features of the Next.js Image component. It's easy to use, yes, but it also packs a punch with features that go beyond simple image rendering. These hidden features can significantly impact your project, and missing them could mean not fully utilizing the component's potential. Let's dive into this exploration, unraveling the subtle yet powerful aspects of the Next.js Image component that are easy to overlook. So, without further delay, let's get started! Size First up, let's chat about width and height. These are rules for how big your image shows on the screen. You gotta use them most of the time. But hey, if you're pulling in an image directly into your code (that's what we call 'static importing') or you want your image to just fill up whatever space it's in (using the 'fill' prop), then you can skip these rules. Neat, right? But that's not all there's to it. You see, when Next.js fetches the image from the server, it does something behind the scenes. It doesn’t just grab any size of the image. Instead, Next.js is smart and picks the best size that fits the spot on your webpage. This means your images load faster and look just right, whether on a big desktop screen or a small phone screen. It's like having a personal assistant for your images, making sure they are always looking their best and not slowing down your site. Here's a part that's easy to miss: Next.js uses a feature called 'srcset' to decide which image size to download from the server. By default, Next.js uses the following default: ` So, imagine you have an image that's 75 pixels wide. Next.js will look at this list and pick the closest size. In our case, with these default settings, it would download the 96-pixel version. This occurs because Next.js selects the smallest available size from the list that exceeds the original's width, ensuring the image remains clear on all devices; even if your image is a bit smaller or larger, Next.js picks the nearest size from this list. This is important to know because if you are looking to get the most performant image possible, you should be aware of these size values. By understanding how Next.js selects the image size, you can better tailor your images to match these presets. This way, you ensure that your site is not only loading the appropriate image size for different devices but also optimizing for speed and efficiency. Keeping an eye on these sizes helps you balance between image quality and fast loading times, which is key for a great user experience on your site. Quality Now, let's highlight something about image quality. It's often overlooked, but by default, Next.js sets the image quality to 75. Sure, you can tweak this with the quality prop, but here's the catch: bumping up the quality to 100 will significantly increase the image's file size. This means your images will look super sharp, but they'll also take longer to load. It's all about finding that sweet spot where your images look great without slowing down your website. Remember, a faster site often means a better experience for your visitors. My advice is to always check what is better for you in each situation. Ask yourself: Consider whether it's more beneficial to opt for larger images at a slightly reduced quality, in alignment with the “srcset” configurations we explored, or if it's preferable to enhance the image quality, even if it means working with smaller dimensions? It's a balancing act. Usually, cranking up the quality to 100 isn't the best move because it makes the image file really big, which can slow down your site. It's all about making smart choices. Go for a quality that makes your images look good without burdening your site's load time. Sometimes, a slightly lower quality image, but well optimized, can be way more effective than a perfect but sluggish, high-quality image. Loader The loader prop in Next.js is a key player. It's not just about fetching images; it’s about fetching them smartly and securely. When using images from different places, like a CMS or your server, the loader prop helps you manage them efficiently and safely. For instance, say you have images on Contentful. Next.js doesn't automatically know the best way to fetch these, but with a custom loader, you can define this process. This loader optimizes your images, selecting the right format, width, and quality. Your images not only look great but load faster, too. Remember, when fetching images from external sources, it's crucial to use remotePatterns (inside your next.config file) for security reasons. This ensures your site stays safe while handling images from outside. This approach is scalable and saves time. You set up the loader once, and it works for all your images, making your site efficient and your code neat. Here’s an example: ` ` Placeholder Prop A little-known yet impactful feature of the Next.js Image component is the placeholder prop. It's all about improving the user experience while your images are loading. Imagine visiting a website and waiting for images to load – it can be a bit dull, right? The placeholder prop can make this wait a lot more pleasant. You can use this prop to display a blur effect or a solid color before the image fully loads. This creates a smoother visual experience. The blur placeholder is particularly popular because it gives a sneak peek of the image without revealing all the details. It's like a teaser, building anticipation for what's to come. Here’s how you can use it: ` In this example, blurDataURL is a small, low-quality version of your image that loads much faster. Once the actual image is ready, it seamlessly replaces the blur. This approach significantly enhances the perceived loading speed and keeps your users engaged. Incorporating the placeholder prop can make a big difference in how professional and polished your site feels, especially on slower connections where image load times are noticeable. Conclusion The Next.js Image component is a powerful tool that goes beyond simple image rendering. By understanding its hidden features and capabilities, you can optimize your project for performance and user experience. From utilizing the 'width' and 'height' properties to ensuring the right image quality and using the 'loader' prop for efficient image fetching, there are several aspects to consider. Additionally, the 'placeholder' prop can enhance the user experience by displaying a blur effect or solid color while images load. By exploring these often-overlooked features, you can unlock the full potential of the Next.js Image component and create a more engaging and optimized website....

Feb 9, 2024

5 mins

UXJavaScriptNextJS

Maximizing Routing Flexibility with Next.js Parallel and Intercepting Routes

Maximizing Routing Flexibility with Next.js Parallel and Intercepting Routes Introduction: Next.js, a powerful React framework, offers two essential features - Parallel Routes and Intercepting Routes - that enable developers to create highly dynamic and seamless user experiences in their applications. In this blog post, we will explore both Parallel Routes and Intercepting Routes, highlighting their functionalities, use cases, and how they can be combined to enhance application routing. What are Parallel Routes? Parallel Routes in Next.js allow the rendering of multiple pages within a shared layout. Rather than navigating to a completely separate page, Parallel Routes enable the simultaneous rendering of different pages based on certain conditions such as user roles or tab navigation. By leveraging named slots, defined using the @folder convention, multiple pages can be seamlessly integrated into a single layout, enhancing user experience and reducing code duplication. How to Use Parallel Routes: To utilize Parallel Routes in Next.js, you must define named slots for the desired pages within your application's folder structure. These slots are then passed as props to a shared parent layout component. For example, consider a social networking application where two pages, feed and notifications, must be rendered within a common layout. You can define Parallel Routes using the following structure: ` The layout component in app/layout.js will accept the @feed and @notifications slots as props and render them alongside the children prop. Here's an example of the layout component: ` It's important to note that slots do not affect the URL structure and are not considered route segments. This means the URL would be /mypage/@feed/views for a route like /mypage/views since @feed is a slot. Also, to prevent the application from rendering nothing or throwing an error, we could use the default.tsx file: ` In this example, the default.tsx file specifies the default content (or fallback) to render when none of the named slots match the current route. It acts as a catch-all for routes without a corresponding slot. Some Use Cases: *Conditional Routes:* Parallel Routes can conditionally render routes based on certain conditions, such as user roles. For example, you can render a different dashboard page for admins and users. This can be achieved by creating a layout component specific to the dashboard and checking the user role to determine which slot to render. *Tab Groups:* You can utilize Parallel Routes to create tabbed navigation within a section. This is especially useful for analytics or multi-page views. Adding a layout inside a slot allows users to navigate between different pages within that slot independently. *Loading and Error UI:* Parallel Routes can be independently streamed, allowing you to define custom error and loading states for each route. This enables better control over the user experience by providing distinct feedback for different app sections. *Modals:* Parallel Routes can be combined with Intercepting Routes to create modals with shareable URLs, preserved context on refresh, and customized navigation behavior. By intercepting certain routes and rendering them within a modal component, you can create a seamless modal experience. Understanding Intercepting Routes: Intercepting Routes in Next.js allows you to load content from another route within the current layout without changing the URL or refreshing the page. Using the (..) Convention: Intercepting routes are defined using the (..) convention, which is similar to the relative path convention ../ but for route segments. The convention allows for matching segments on the same level (.), one level above (..), two levels above (..)(..), or from the root app directory (...). For example, to intercept the photo segment from within the feed segment, you can create a (..)photo directory. Integrating Intercepting Routes with Parallel Routes - Modals: One powerful use case for Intercepting Routes is creating modals, which can be combined with Parallel Routes to solve common challenges such as making the modal content shareable through a URL, preserving context on page refresh, and handling backward and forward navigation. Let's make an example: ` Our folder structure will be: In this example, when a user clicks on a photo within the /gallery page, the route /photo/:photoId will be intercepted and rendered within the (..)photo directory, overlaying the gallery content. This means that the photo route is only one segment level higher despite being two file-system levels higher. In the example above, the path to the photo segment can use the (..) matcher since @modal is a slot and not a segment. Common Use Cases - Beyond Modals: Intercepting Routes can also be utilized in other scenarios. Some examples include opening a login modal in a top navbar while having a dedicated /login page, or opening a shopping cart in a side modal for better accessibility or creating wizards or multi-step forms within a single page. The possibilities are endless. Conclusion Next.js Parallel and Intercepting Routes offer powerful methods for enhancing the routing capabilities of your applications. With Parallel Routes, multiple pages can be seamlessly integrated within a shared layout, simplifying navigation and enhancing user experience. By incorporating Intercepting Routes, you can create dynamic overlays like modals, enabling content from different routes to be displayed within the current layout. By leveraging these features, you can unlock exciting possibilities and take your Next.js applications to new heights of user engagement....

Apr 5, 2024

3 mins

NextJSJavaScript

How to Leverage Apollo Client Fetch Policies Like the Pros

Apollo Client provides a rich ecosystem and cache for interfacing with your GraphQL APIs. You write your query and leverage the useQuery hook to fetch your data. It provides you with some state context and eventually resolves your query. That data is stored in a local, normalized, in-memory cache, which allows Apollo Client to respond to most previously run requests near instantaneously. This has huge benefits for client performance and the feel of your apps. However, sometimes Apollo's default doesn't match the user experience you want to provide. They provide fetch policies to allow you to control this behavior on each query you execute. In this article, we'll explore the different fetch policies and how you should leverage them in your application. cache-first This is the default for Apollo Client. Apollo will execute your query against the cache. If the cache can fully fulfill the request, then that's it, and we return to the client. If it can only partially match your request or cannot find any of the related data, the query will be run against your GraphQL server. The response is cached for the next query and returned to the handler. This method prioritizes minimizing the number of requests sent to your server. However, it has an adverse effect on data that changes regularly. Think of your social media feeds - they typically contain constantly changing information as new posts are generated. Or a real-time dashboard app tracking data as it moves through a system. cache-first is probably not the best policy for these use cases as you won't fetch the latest data from the upstream source. You can lower the cache time of items for the dashboard to avoid the staleness issue and still minimize the requests being made, but this problem will persist for social media feeds. The cache-first policy should be considered for data that does not change often in your system or data that the current user fully controls. Data that doesn't change often is easily cached, and that's a recommended pattern. For data that the user controls, we need to consider how that data changes. If only the current user can change it, we have 2 options: Return the updated data in the response of any mutation which is used to update the cache Use cache invalidation methods like refetchQueries or onQueryUpdated These methods will ensure that our cache stays in sync with our server allowing the policy to work optimally. However, if other users in the system can make changes that impact the current user's view, then we can not invalidate the cache properly using these strategies which makes this policy unideal. network-only This policy skips the cache lookup and goes to the server to fetch the results. The results are stored in the cache for other operations to leverage. Going back to the example I gave in my explanation cache-first of a social media feed, the network-only policy would be a great way to implement the feed itself as it's ever-changing, and we'll likely even want to poll for changes every 10s or so. The following is an example of what this component could look like: ` Whenever this SocialFeed component is rendered, we always fetch the latest results from the GraphQL server ensuring we're looking at the current data. The results are put in the cache which we can leverage in some children components. cache-only cache-only only checks the cache for the requested data and never hits the server. It throws an error if the specified cache items cannot be found. At first glance, this cache policy may seem unhelpful because it's unclear if our cache is seeded with our data. However, in combination with the network-only policy above, this policy becomes helpful. This policy is meant for components down tree from network-only level query. This method is for you if you're a fan of React components' compatibility. We can modify the return of our previous example to be as follows: ` Notice we're not passing the full post object as a prop. This simplifies our Post component types and makes later refactors easier. The Post would like like the following: ` In this query, we're grabbing the data directly from our cache every time because our top-level query should have fetched it. Now, a small bug here makes maintainability a bit harder. Our top-level GetFeed query doesn't guarantee fetching the same fields. Notice how our Post component exports a fragment. Fragments are a feature Apollo supports to share query elements across operations. In our SocialFeed component, we can change our query to be: ` Now, as we change our Post to use new fields and display different data, the refactoring is restricted to just that component, and the upstream components will detect the changes and handle them for us making our codebase more maintainable. Because the upstream component is always fetching from the network, we can trust that the cache will have our data, making this component safe to render. With these examples, though, our users will likely have to see a loading spinner or state on every render unless we add some server rendering. cache-and-network This is where cache-and-network comes to play. With this policy, Apollo Client will run your query against your cache and your GraphQL server. This further simplifies our example above if we want to provide the last fetched results to the user but then update the feed immediately upon gathering the latest data. This is similar to what X/Twitter does when you reload the app. You'll see the last value that was in the cache then it'll render the network values when ready. This can cause a jarring user experience though, if the data is changing a lot over time, so I recommend using this methodology sparsely. However, if you wanted to update our existing example, we'd just change our SocialFeed component to use this policy, and that'll keep our client and server better in sync while still enabling 10s polling. no-cache This policy is very similar to the network-only policy, except it bypasses the local cache entirely. In our previous example, we wrote engagement as a sub-selector on a Post and stored fields there. These metrics can change in real time pretty drastically. Chat features, reactions, viewership numbers, etc., are all types of data that may change in real time. The no-cache policy is good when this type of data is active, such as during a live stream or within the first few hours of a post going out. You may typically want to use the cache-and-network policy eventually but during that active period, you'll probably want to use no-cache so your consumers can trust your data. I'd probably recommend changing your server to split these queries and run different policies for the operations for performance reasons. I haven't mentioned this yet, but you can make the fetch policy on a query dynamic, meaning you combine these different policies' pending states. This could look like the following: ` We pass whether the event is live to the component that then leverages that info to determine if we should cache or not when fetching the chat. That being said, we should consider using subscription operations for this type of feature as well, but that's an exercise for another blog post. standby This is the most uncommon fetch policy, but has a lot of use. This option runs like a cache-first query when it executes. However, by default, this query does not run and is treated like a "skip" until it is manually triggered by a refetch or updateQueries caller. You can achieve similar results by leveraging the useLazyQuery operator, but this maintains the same behavior as other useQuery operators so you'll have more consistency among your components. This method is primarily used for operations pending other queries to finish or when you want to trigger the caller on a mutation. Think about a dashboard with many filters that need to be applied before your query executes. The standby fetch policy can wait until the user hits the Apply or Submit button to execute the operation then calls a await client.refetchQueries({ include: ["DashboardQuery"] }), which will then allow your component to pull in the parameters for your operation and execute it. Again, you could achieve this with useLazyQuery so it's really up to you and your team how you want to approach this problem. To avoid learning 2 ways, though, I recommend picking just one path. Conclusion Apollo Client's fetch policies are a versatile and helpful tool for managing your application data and keeping it in sync with your GraphQL server. In general, you should use the defaults provided by the library, but think about the user experience you want to provide. This will help you determine which policy best meets your needs. Leveraging tools like fragments will enable you to manage your application and use composable patterns more effectively. With the rise of React Server Components and other similar patterns, you'll need to be wary of how that impacts your Apollo Client strategy. However, if you're on a legacy application that leverages traditional SSR patterns, Apollo allows you to pre-render queries on the server and their related cache. When you combine these technologies, you'll find that your apps perform great, and your users will be delighted....

May 17, 2024

7 mins

GraphQL

What’s New with Astro in 2024 with Matthew Phillips, CTO of Astro

In the latest episode of the Modern Web Podcast, Tracy Lee, Adam Rackis, Ben Lesh, and guest Matthew Phillips explore the concept of "Islands" in web development using Astro. They discuss how Astro allows developers to create self-contained interactive elements that enhance the user experience. One of the standout features of Astro is its framework-agnostic approach, which enables seamless integration of components from different frameworks like React or Vue. This flexibility allows developers to leverage the best features of each framework without being tied down to a single technology stack. The conversation covers the technical aspects of Astro, including client directives that enable selective rendering of components based on conditions like viewport visibility. This capability ensures that only the necessary components are loaded, improving performance and reducing unnecessary resource consumption. Matthew also touches on the challenges of collecting metrics and the importance of type safety in software development. These considerations highlight the attention to detail and focus on optimization that Astro brings to the table. The discussion shifts to the development of server actions in Astro, emphasizing the simplified implementation of remote procedure calls (RPC). This feature allows developers to easily create server-side functionality and interact with databases. The introduction of AstroDB, a database integration tool, further enhances the capabilities of Astro. With AstroDB, developers can seamlessly connect their applications to databases, making data management and retrieval a breeze. Throughout the podcast, Matthew shares his insights on different frameworks and the need for innovation in web development. They discuss potential paradigm shifts in the industry and highlight the importance of staying up to date with cutting-edge tools. Recommendations are made to explore tools like Astro, AstroDB, Solid, and SvelteKit for those interested in the evolving web development landscape. Download this episode here....

May 17, 2024

2 mins

AstroReact

Are Performance Issues Really Next.js’s Fault? What Vercel Should Actually Be Building

You might also like

Exploring the Hidden Gems of the Next Image Component: What You Might Be Overlooking

Maximizing Routing Flexibility with Next.js Parallel and Intercepting Routes

How to Leverage Apollo Client Fetch Policies Like the Pros

What’s New with Astro in 2024 with Matthew Phillips, CTO of Astro

You might also like

Exploring the Hidden Gems of the Next Image Component: What You Might Be Overlooking

Maximizing Routing Flexibility with Next.js Parallel and Intercepting Routes

How to Leverage Apollo Client Fetch Policies Like the Pros

What’s New with Astro in 2024 with Matthew Phillips, CTO of Astro