Skip to content

Supporting Emergency Remote Operations with the PAM Stack

Supporting Emergency Remote Operations with the PAM Stack

This article was written over 18 months ago and may contain information that is out of date. Some content may be relevant but please refer to the relevant official documentation or available resources for the latest information.

On Friday, Donald Trump declared a State of Emergency in response to growing concerns about COVID-19. This declaration follows formal emergency classifications by nearly 30 states, including California, Washington, New York, North Carolina, and Arkansas, which many of the nation’s largest tech, pharmaceutical, and manufacturing/supply chain enterprises call home.

In order to maintain operations while protecting employees, and preventing the continued spread of COVID-19, many large companies, including Google, Amazon, LinkedIn, Spotify, and Airbnb, are asking employees to work remotely for the time being.

This has posed a number of problems for companies that are not equipped to maintain remote operations on a large scale for extended periods of time. Smaller companies that may not have the infrastructure needed to support fully remote operations, and lack the budget needed to make these rapid changes, will be most impacted by these challenges. And this anxiety may be amplified by the possibility that employees in enterprises both small and large may continue working this way indefinitely.

As someone who has managed remote teams for the past few years, I understand many of the challenges that remote workers face, as well as the policies and procedures needed to ensure that remote work remains manageable for employees, and efficient for businesses.

I believe the misconception that any work done exclusively on the computer can transition seamlessly from on to offsite belies the reality that remote structures radically change the culture and management style of businesses.

It is my hope that companies will not only continue to encourage their employees to remain at home for their health and safety, but will also invest in improving their emergency operational procedures. In doing so, they will be able to maintain efficiency, and implement an infrastructure that supports reactionary, company-wide remote work in a way that suits both employee and employer.

SUPPORTING LONG-TERM REMOTE OPERATIONS WITH THE PAMSTACK

If you are familiar with the change management work that I and Rob Ocel, an architect at This Dot have been doing over the past year, you may have already heard of the PAM Stack.

For those who haven’t heard of it, we generally define it as a modern architecture for building sustainable, inclusive development teams. Now, this system wasn’t exclusively built for remote teams, but applying the three guiding principles of the PAM Stack could significantly help leaders building management systems for employees who have recently transitioned to working off-site.

Its three guiding principles are: Process, Abstraction, and Mentorship.

PROCESS

When transitioning to temporary remote work, especially in response to national and international emergencies, company goals are bound to change. And these changes will trickle into every department.

If a company expects its employees to continue working under a drastically different operational culture, it is important that leadership establishes clear expectations and goals for their direct reports, and promotes transparency about those expectations to an appropriate degree. This can be supported by building out physical documentation that outlines departmental and even employee specific responsibilities.

Of course, these procedures will have to be tailored to accommodate each unique circumstance, but should be guided by documentation written ahead of emergencies, without the pressure imposed by reactionary operational changes.

Procedural documentation should also identify common points of error specific to the type of work being carried out, with consideration for what unique error points might arise due to the abrupt change from onsite to remote-only work. The inclusion of regular reviews, checklists, and metric keeping are all essential to maintaining better communication between employees within the same department, as well as positive interdepartmental communication.

ABSTRACTION

When managing a remote team, it is crucial to keep your tech stack as simple as possible. Development teams should only work with as diverse a tech stack as absolutely necessary in order to build and maintain their products, services, and proprietary internal tools.

Companies should also be careful to prevent the use of redundant operational assets, and ensure that all employees are sharing as many technologies as possible. This means sales and marketing teams across a company should use the same suite of products; documents, passwords, and databases should all be accessible through the same interfaces, respectively, and communication should be conducted over as limited a number of channels as possible.

Additionally, by using modern frameworks such as Vue, Angular, or React, teams equip their developers with powerful force-multipliers that abstract away irrelevant complexities, and will reduce the need for peer-to-peer reference due to the support of abundant educational resources, and documentation.

MENTORSHIP

According to a 2018 Spherion study, 35% of developers who do not receive mentorship look for new jobs within twelve months. Oftentimes, this is due to a feeling of isolation and immobility that may be exacerbated by an abrupt transition to remote-only work.

This is a significant problem for leadership, since the cost of recruiting and training a new hire cost as much as double that developer’s annual salary. Unmanageable attrition will slow your team down, increase stress, and trigger panic hiring. All of these problems are tough enough for companies operating within their preferred work cultures, but may be even more difficult if encountered while a company is operating under an emergency procedure.

Despite the additional communicative challenges presented by remote work, companies should maintain strong mentorship programs in order to maintain employee engagement and reduce the feeling of isolation common among even remote workers who elect to work remotely, and may be worse for employees compelled into full time offsite work.

Of course this mentorship can be unstructured and organic- taking the form of natural conversations and friendships between developers on the same team. But teams should also incorporate an intentional program that includes pair programming, code reviews, and lunch & learns, all of which are still maintainable within remote work cultures.

PLANNING FOR AN UNCERTAIN FUTURE

It is my sincere hope that the threat presented by COVID-19 is managed as soon as possible, and I applaud any company that shoulders responsibility for combatting its spread through radically changing their operational structures.

However, I believe that companies not only need to prepare for the possibility that workers may be unable to return to their offices any time soon, but need to implement procedures that encourage a more seamless transition from onsite to offsite work in instances of natural disasters, pandemics, or other states of emergency in the future.

By adopting PAM Stack principles, companies are better able to maintain the health and wellbeing of not only their businesses, but more importantly, the human lives that depend on large, multinational companies being able to radically transform their operations without hesitation.

If there is any way that I or Rob could help you in this transition, please do not hesitate to reach out at hi@thisdot.co.

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.

You might also like

State of Headless CMS Wrap-up cover image

State of Headless CMS Wrap-up

We recently hosted State of Headless CMS where we were joined by some very talented people to talk about a growing ecosystem. There are a lot of problems that a headless CMS can solve when it comes to indie development, and even small restaurants and shops. Before we dive into the key points of the event, I'll give you a brief introduction to the hosts and panelists. Hosts - Jesse @jtomchak - Keionne @KeionneD Panelists - Kapehe - Senior DevRel, sanity.io - @kapehe_ok - Daniel Madalitso Phiri - DevRel, Strapi - @malgamves - Samuel Snopko - Head of Developer Relations, Storyblok - @samuelsnopko - Stefan Judis - Dev Rel, Contentful - @stefanjudis - Arisa Fukuzaki - Dev Rel Engineer, Storyblok - @arisa_dev There were a lot of great discussions during this event which is why I want to suggest that you head on over and watch The State of Headless CMS on Youtube to hear all of the great discussions. Who is a headless CMS for? Headless CMSs give developers the ability to use a CMS without being restricted to using the CMS platform itself. It's like using Wordpress, without having to actually use Wordpress itself. This enables developers to build more customized solutions for their clients. Some questions to ponder - What are some Headless CMS technologies that you're excited about? - How do we help the little shop manage their content? - What problems does Headless CMS solve for you? We want to give a huge shout out to our hosts and panelists for participating in the State of Headless CMS event....

International Women's Day Recap cover image

International Women's Day Recap

International Women's Day Event For this year's International Women's Day, we hosted a live event with Women Techmakers, featuring talks and a panel discussion on this year's topic: progress over perfection. It was a great conversation on what it's like to be a woman in tech, and how you can help yourself and others thrive in our industry. In case you missed it We have the full event on YouTube if you'd like to watch it yourself (which I highly recommend)! Here's a recap of everything that happened. Getting started in DevRel - Pachi Parra Pachi Parra was up first, sharing her journey into DevRel, and tips on how you can get started too! Some highlights include: - Roles that are available - What a day in the life might look like - Her journey into DevRel - What a DevRel professional actually does - things like public speaking, live coding, writing blogs, and giving talks at conferences. Her best tip for getting started? Find the type of content you like doing, and focus on doing that well! In DevRel, it's easy to spread yourself too thin between all the different types of content available, so focus on the one you like most, find a supportive community, and get yourself out there. :) Breathing Fire: Success and Growth as a Technical Woman - Stacy Devino Stacy Devino was up next, providing all kinds of insight into the cycle women go through in their career, as well as tips for each stage of the journey. She opened with an amazing quote: > Assume all women are technical and capable of breathing fire. - Jessie Frazelle Other highlights: - Igniting your world through learning, timing, your network, and leadership. - Staying warm by managing your focus and chores, recording your achievements, maintaining relationships, and researching ideas. - The key to avoiding burnout - keeping a long-term perspective, doing things for yourself, and allocating time for the things you enjoy and the people who support you. Riding the imposter wave to senior - Jessica Janiuk Jessica Janiuk wrapped up our talks today, providing insight into her journey through tech and the ways we can think about imposter syndrome and allowing ourselves to grow. Some highlights from her talk: - A few things to consider: what being "senior" means to companies and to yourself, if you're in the right place, and what you want in your career. - A great diagram of the imposter wave - the balance between our confidence and feeling like an imposter from this post by Ricardo Luevanos. - Considering how often we're comfortable, and that there's an inverse correlation between feeling comfortable and feeling like an imposter (they're opposite each other). - We have two choices: we can let it control us, or use that discomfort as a tool. - Looking back on our growth and realizing that our current lows are higher than our past highs. - Some senior advice: Be authentic, be proud of your work, have good mentors, remember that your work is not your life, and stay uncomfortable. She wrapped up with a brilliant reminder for us all: > You are capable. You are valid. You are important. Please take care of yourself. People care about you. If you're struggling, you're not alone. Panel Discussion We rounded out the day with a panel discussion featuring these accomplished women: - Erica Stanley - Amal Hussein - Deborah Kurata - Katerina Skroumpelou - Jessica Janiuk - Stacy Devino - Jae Bach Hardie - Linda Thompson The conversation flowed naturally, each panelist feeding off of each other's ideas, and we covered some very powerful and helpful tips and reminders for women in today's developer world. Here's a few of my favorite topics or ideas we talked about: What did you learn in the past year? - Have hobbies that don't involve tech. - Learning to let go of your previous tools. - How valuable close personal friends are - people you can trust and rely on. - Listen to yourself, and take time to introspect and evaluate. - Don't over commit! Finding a community and actively contributing to it - Women Techmakers! (Our joint sponsor) - Make use of social media. - "Reach one teach one" - always be willing to share your knowledge, and be the person you needed when you were getting started. - Engage people who align with your goals and values - reach outside your level of age, career scope, experience. - The interconnection between you and your people is not exclusive, it's inclusive! The more expansive your sphere is, the better you are at your job. - Also - we can find community in open source! The way people comment, commit, and support each other within a project counts too. Foundational knowledge vs tooling - Understand what problems you're actually solving and what to reach for, more than worrying about the specific tech stack itself. - This helps you build your own knowledge map, and pick up skills as you grow. - For more senior folks - realize when you've mastered something, and focus on clearing the road for those who come next. - Learning to delegate - if you always do something yourself, you're taking that opportunity away from someone else. - Knowing when to ask for help, and that asking is NOT a weakness or failure! It's a strength to know when you need to ask for help. Find your learning method - Ask multiple people if you need to until you find the answer that clicks for you! Ask why. - Not understanding the answer someone gives you is also not a failure - it's different viewpoints. - Also learn how the people around you learn - so you can help them in the way that best suits them. Communication and collaboration - Have compassion for everyone on your team. - When you collaborate, you get more done. - Being able to communicate and collaborate is a HUGE strength. Don't let anyone make you feel bad for being strong in those! - Being the person who's able to "glue" the team together is foundational to a strong team. Fighting stereotypes - Things that are commended in men and reprimanded in women, and fighting against those biases - Being authentic is the best way to lead your team - don't play into a stereotype you don't fit. - You don't have to sound "nice" or "pleasing" - you're still a strong woman and you're going to be judged a certain way, so don't compromise! - Unpacking all the social conditioning and learning to be comfortable with yourself all the time, in all the situations we find ourselves in. Wrapping Up The entire event was filled with wisdom, laughter, and camaraderie. We're so thankful to the ladies who came to speak with us, and hope to see you at the next one!...

How to Provide Value to Your Organization in a Developer Relations Role cover image

How to Provide Value to Your Organization in a Developer Relations Role

A few years ago, a multi-billion dollar corporation we all know and love hired what could be perceived as every developer with Twitter influence on the market into a Developer Relations role. Suddenly, everyone you spoke to worked at the said corporation. While many of us were excited to see the value of Developer Relations recognized by a prominent tech organization, many were also left scratching their heads at the alignment, or lack thereof, between what those hired Developer Relations professionals did to “evangelize or build” and how it related to their employer. A majority of those DevRel professionals were not even creating value in communities related to that organization’s products. An insider look will tell you that the reason is that those hired were just told to “keep doing what they were doing” and not given any additional direction or focus outside of that. Without clearly defined expectations, DevRel professionals cannot provide value to your organization. This is not sustainable and no one wants this. Below is a list of four ways that those in developer relations can deliver value to their organizations. Aligning with your Organization's Goals and Objectives DevRel professionals recognize that all activities should be tangentially related to providing value to the organization and ensure that these activities contribute to the organization's goals and objectives. The best way to align DevRel efforts with organizational goals is to make sure you understand what the strategic objectives of your organization are. Is it product awareness? Is it customer satisfaction? Is it revenue growth? Is it pushing new concepts in a market? Is it fostering innovation? Depending on the objective, you will be able to better tailor your DevRel efforts to the organization. Product Awareness as a Goal For example, if the current goal of the company is product awareness, Developer Evangelism is the best way to provide value. Twilio is still the canonical example of evangelism done right. In the beginning, Twilio needed to spread awareness of their product, and show developers how easy it was to use. They did this by showing up at events with developer-centric swag, creating the best tutorials for developers to follow, giving workshops on how to use Twilio APIs, giving talks about how to use Twilio, and creating a strong community of Twilio adopters that shared their use cases around the internet. Through this, the perception was that Twilio was the best solution, and considered the easiest, most obvious tool choice to use when developers were trying to build unique communication features and capabilities like voice, text, chat, video, and email into their applications. Customer Satisfaction as a Goal If the organizational goal is customer satisfaction, then Developer Community and Developer Experience are the two areas a DevRel professional should key in on. By building a community and creating customer feedback loops where developers can share struggles, and their issues can be heard and resolved directly by engineers and product in a quick manner, customer satisfaction will increase because you are helping solve the pain points of using the product. Creating a community allows other developers adopting the product to bond and share solutions in an open forum. Currently, most organizations choose Discord as a way to engage developers and build community. As a DevRel professional, you are in a unique position to help with the Developer Experience in a way that engineers may not be able to. For example, the customer satisfaction metrics may be affected by a lack of documentation, which can easily be solved by improving the documentation where you see the pain points. This does not require engineering or product to get involved and can often solve developer problems overnight. There may be an issue with the migration of one technology to another. Many Developer Relations professionals have built excellent migration tools to help developers ease this pain. Having the flexibility to work outside of the product roadmap and engineering sprints can serve as an invaluable resource for organizations and serving their needs, and the needs of their users. Revenue Growth as a Goal If the goal for your organization is revenue growth, then helping get developers into the top of the sales funnel is key to providing value to your organization. This does not have to be done in a way that compromises the other principle of DevRel or the core value either. One example I’ll bring up again is Test Automation University by Applitools. By providing a free resource that was able to garner the interest of over 150,000 developers through a DevRel initiative (shout out to Angie Jones for leading this initiative), Applitools was able to collect the email addresses of all these individuals and engage them. Since our focus is DevRel and contributing to the top of the funnel, I won’t speak to the “right way” sales or marketing should engage these developers, but I will say it is critical for DevRel to educate and advocate for marketing and sales to engage with these developers the right way that does not erode brand trust. Delivering Value to Your Organization Delivering value to an organization while upholding the core value of authenticity is not difficult. The hardest part is advocating internally to stakeholders within the organization on the approach to developers and helping them understand the “why” behind the DevRel strategy you are employing. Balancing authenticity and providing value to both the community and to organizations allows DevRel professionals to thrive and achieve mutual success for both developers and the organizations they support. Through living these core values and principles, Developer Relations is the way to forge a path of innovation, collaboration, and long-term success in the technology....

Next.js Rendering Strategies and how they affect core web vitals cover image

Next.js Rendering Strategies and how they affect core web vitals

When it comes to building fast and scalable web apps with Next.js, it’s important to understand how rendering works, especially with the App Router. Next.js organizes rendering around two main environments: the server and the client. On the server side, you’ll encounter three key strategies: Static Rendering, Dynamic Rendering, and Streaming. Each one comes with its own set of trade-offs and performance benefits, so knowing when to use which is crucial for delivering a great user experience. In this post, we'll break down each strategy, what it's good for, and how it impacts your site's performance, especially Core Web Vitals. We'll also explore hybrid approaches and provide practical guidance on choosing the right strategy for your use case. What Are Core Web Vitals? Core Web Vitals are a set of metrics defined by Google that measure real-world user experience on websites. These metrics play a major role in search engine rankings and directly affect how users perceive the speed and smoothness of your site. * Largest Contentful Paint (LCP): This measures loading performance. It calculates the time taken for the largest visible content element to render. A good LCP is 2.5 seconds or less. * Interaction to Next Paint (INP): This measures responsiveness to user input. A good INP is 200 milliseconds or less. * Cumulative Layout Shift (CLS): This measures the visual stability of the page. It quantifies layout instability during load. A good CLS is 0.1 or less. If you want to dive deeper into Core Web Vitals and understand more about their impact on your website's performance, I recommend reading this detailed guide on New Core Web Vitals and How They Work. Next.js Rendering Strategies and Core Web Vitals Let's explore each rendering strategy in detail: 1. Static Rendering (Server Rendering Strategy) Static Rendering is the default for Server Components in Next.js. With this approach, components are rendered at build time (or during revalidation), and the resulting HTML is reused for each request. This pre-rendering happens on the server, not in the user's browser. Static rendering is ideal for routes where the data is not personalized to the user, and this makes it suitable for: * Content-focused websites: Blogs, documentation, marketing pages * E-commerce product listings: When product details don't change frequently * SEO-critical pages: When search engine visibility is a priority * High-traffic pages: When you want to minimize server load How Static Rendering Affects Core Web Vitals * Largest Contentful Paint (LCP): Static rendering typically leads to excellent LCP scores (typically < 1s). The Pre-rendered HTML can be cached and delivered instantly from CDNs, resulting in very fast delivery of the initial content, including the largest element. Also, there is no waiting for data fetching or rendering on the client. * Interaction to Next Paint (INP): Static rendering provides a good foundation for INP, but doesn't guarantee optimal performance (typically ranges from 50-150 ms depending on implementation). While Server Components don't require hydration, any Client Components within the page still need JavaScript to become interactive. To achieve a very good INP score, you will need to make sure the Client Components within the page is minimal. * Cumulative Layout Shift (CLS): While static rendering delivers the complete page structure upfront which can be very beneficial for CLS, achieving excellent CLS requires additional optimization strategies: * Static HTML alone doesn't prevent layout shifts if resources load asynchronously * Image dimensions must be properly specified to reserve space before the image loads * Web fonts can cause text to reflow if not handled properly with font display strategies * Dynamically injected content (ads, embeds, lazy-loaded elements) can disrupt layout stability * CSS implementation significantly impacts CLS—immediate availability of styling information helps maintain visual stability Code Examples: 1. Basic static rendering: ` 2. Static rendering with revalidation (ISR): ` 3. Static path generation: ` 2. Dynamic Rendering (Server Rendering Strategy) Dynamic Rendering generates HTML on the server for each request at request time. Unlike static rendering, the content is not pre-rendered or cached but freshly generated for each user. This kind of rendering works best for: * Personalized content: User dashboards, account pages * Real-time data: Stock prices, live sports scores * Request-specific information: Pages that use cookies, headers, or search parameters * Frequently changing data: Content that needs to be up-to-date on every request How Dynamic Rendering Affects Core Web Vitals * Largest Contentful Paint (LCP): With dynamic rendering, the server needs to generate HTML for each request, and that can't be fully cached at the CDN level. It is still faster than client-side rendering as HTML is generated on the server. * Interaction to Next Paint (INP): The performance is similar to static rendering once the page is loaded. However, it can become slower if the dynamic content includes many Client Components. * Cumulative Layout Shift (CLS): Dynamic rendering can potentially introduce CLS if the data fetched at request time significantly alters the layout of the page compared to a static structure. However, if the layout is stable and the dynamic content size fits within predefined areas, the CLS can be managed effectively. Code Examples: 1. Explicit dynamic rendering: ` 2. Simplicit dynamic rendering with cookies: ` 3. Dynamic routes: ` 3. Streaming (Server Rendering Strategy) Streaming allows you to progressively render UI from the server. Instead of waiting for all the data to be ready before sending any HTML, the server sends chunks of HTML as they become available. This is implemented using React's Suspense boundary. React Suspense works by creating boundaries in your component tree that can "suspend" rendering while waiting for asynchronous operations. When a component inside a Suspense boundary throws a promise (which happens automatically with data fetching in React Server Components), React pauses rendering of that component and its children, renders the fallback UI specified in the Suspense component, continues rendering other parts of the page outside this boundary, and eventually resumes and replaces the fallback with the actual component once the promise resolves. When streaming, this mechanism allows the server to send the initial HTML with fallbacks for suspended components while continuing to process suspended components in the background. The server then streams additional HTML chunks as each suspended component resolves, including instructions for the browser to seamlessly replace fallbacks with final content. It works well for: * Pages with mixed data requirements: Some fast, some slow data sources * Improving perceived performance: Show users something quickly while slower parts load * Complex dashboards: Different widgets have different loading times * Handling slow APIs: Prevent slow third-party services from blocking the entire page How Streaming Affects Core Web Vitals * Largest Contentful Paint (LCP): Streaming can improve the perceived LCP. By sending the initial HTML content quickly, including potentially the largest element, the browser can render it sooner. Even if other parts of the page are still loading, the user sees the main content faster. * Interaction to Next Paint (INP): Streaming can contribute to a better INP. When used with React's <Suspense />, interactive elements in the faster-loading parts of the page can become interactive earlier, even while other components are still being streamed in. This allows users to engage with the page sooner. * Cumulative Layout Shift (CLS): Streaming can cause layout shifts as new content streams in. However, when implemented carefully, streaming should not negatively impact CLS. The initially streamed content should establish the main layout, and subsequent streamed chunks should ideally fit within this structure without causing significant reflows or layout shifts. Using placeholders and ensuring dimensions are known can help prevent CLS. Code Examples: 1. Basic Streaming with Suspense: ` 2. Nested Suspense boundaries for more granular control: ` 3. Using Next.js loading.js convention: ` 4. Client Components and Client-Side Rendering Client Components are defined using the React 'use client' directive. They are pre-rendered on the server but then hydrated on the client, enabling interactivity. This is different from pure client-side rendering (CSR), where rendering happens entirely in the browser. In the traditional sense of CSR (where the initial HTML is minimal, and all rendering happens in the browser), Next.js has moved away from this as a default approach but it can still be achievable by using dynamic imports and setting ssr: false. ` Despite the shift toward server rendering, there are valid use cases for CSR: 1. Private dashboards: Where SEO doesn't matter, and you want to reduce server load 2. Heavy interactive applications: Like data visualization tools or complex editors 3. Browser-only APIs: When you need access to browser-specific features like localStorage or WebGL 4. Third-party integrations: Some third-party widgets or libraries that only work in the browser While these are valid use cases, using Client Components is generally preferable to pure CSR in Next.js. Client Components give you the best of both worlds: server-rendered HTML for the initial load (improving SEO and LCP) with client-side interactivity after hydration. Pure CSR should be reserved for specific scenarios where server rendering is impossible or counterproductive. Client components are good for: * Interactive UI elements: Forms, dropdowns, modals, tabs * State-dependent UI: Components that change based on client state * Browser API access: Components that need localStorage, geolocation, etc. * Event-driven interactions: Click handlers, form submissions, animations * Real-time updates: Chat interfaces, live notifications How Client Components Affect Core Web Vitals * Largest Contentful Paint (LCP): Initial HTML includes the server-rendered version of Client Components, so LCP is reasonably fast. Hydration can delay interactivity but doesn't necessarily affect LCP. * Interaction to Next Paint (INP): For Client Components, hydration can cause input delay during page load, and when the page is hydrated, performance depends on the efficiency of event handlers. Also, complex state management can impact responsiveness. * Cumulative Layout Shift (CLS): Client-side data fetching can cause layout shifts as new data arrives. Also, state changes might alter the layout unexpectedly. Using Client Components will require careful implementation to prevent shifts. Code Examples: 1. Basic Client Component: ` 2. Client Component with server data: ` Hybrid Approaches and Composition Patterns In real-world applications, you'll often use a combination of rendering strategies to achieve the best performance. Next.js makes it easy to compose Server and Client Components together. Server Components with Islands of Interactivity One of the most effective patterns is to use Server Components for the majority of your UI and add Client Components only where interactivity is needed. This approach: 1. Minimizes JavaScript sent to the client 2. Provides excellent initial load performance 3. Maintains good interactivity where needed ` Partial Prerendering (Next.js 15) Next.js 15 introduced Partial Prerendering, a new hybrid rendering strategy that combines static and dynamic content in a single route. This allows you to: 1. Statically generate a shell of the page 2. Stream in dynamic, personalized content 3. Get the best of both static and dynamic rendering Note: At the time of this writing, Partial Prerendering is experimental and is not ready for production use. Read more ` Measuring Core Web Vitals in Next.js Understanding the impact of your rendering strategy choices requires measuring Core Web Vitals in real-world conditions. Here are some approaches: 1. Vercel Analytics If you deploy on Vercel, you can use Vercel Analytics to automatically track Core Web Vitals for your production site: ` 2. Web Vitals API You can manually track Core Web Vitals using the web-vitals library: ` 3. Lighthouse and PageSpeed Insights For development and testing, use: * Chrome DevTools Lighthouse tab * PageSpeed Insights * Chrome User Experience Report Making Practical Decisions: Which Rendering Strategy to Choose? Choosing the right rendering strategy depends on your specific requirements. Here's a decision framework: Choose Static Rendering when * Content is the same for all users * Data can be determined at build time * Page doesn't need frequent updates * SEO is critical * You want the best possible performance Choose Dynamic Rendering when * Content is personalized for each user * Data must be fresh on every request * You need access to request-time information * Content changes frequently Choose Streaming when * Page has a mix of fast and slow data requirements * You want to improve perceived performance * Some parts of the page depend on slow APIs * You want to prioritize showing critical UI first Choose Client Components when * UI needs to be interactive * Component relies on browser APIs * UI changes frequently based on user input * You need real-time updates Conclusion Next.js provides a powerful set of rendering strategies that allow you to optimize for both performance and user experience. By understanding how each strategy affects Core Web Vitals, you can make informed decisions about how to build your application. Remember that the best approach is often a hybrid one, combining different rendering strategies based on the specific requirements of each part of your application. Start with Server Components as your default, use Static Rendering where possible, and add Client Components only where interactivity is needed. By following these principles and measuring your Core Web Vitals, you can create Next.js applications that are fast, responsive, and provide an excellent user experience....

Let's innovate together!

We're ready to be your trusted technical partners in your digital innovation journey.

Whether it's modernization or custom software solutions, our team of experts can guide you through best practices and how to build scalable, performant software that lasts.

Prefer email? hi@thisdot.co