If you're building for the web and your forms don't work for everyone, they simply do not work. Designing forms to be inclusive is foundational for good UX and accessibility, and not just a nice-to-have feature.

Most of the time, we treat forms as a mere visual task. What do I mean?

We align fields nicely, slap a button on the end, and maybe even throw in a toast message for submission warnings/errors. But then we fail to think about users who navigate the web with screen readers or with just the keyboard. And even for most parts, we forget about the cognitive load*, or error recovery* of our users?

In this article, we’ll explore how to create forms that work for everyone, whether they use screen readers, assistive devices, or just keyboard navigation.

What we'll cover:

• Semantic HTML and structure.

• The role of labels and descriptions.

• Managing focus and keyboard flows.

• Accessible error handling.

• Live regions, validation feedback, and assistive technology considerations.

Now, let’s get right to it! 😉

Use the Right Semantic HTML Always

Always start with a solid base: HTML. I don’t even know how you’d want to survive without that! 😅

Avoid throwing in the div element all over the place. Do your best to use the right elements designed for form controls all the time.

For instance;

Instead of

<div>
  <div>Email address</div>
  <input name="email" required />
  <button onclick="clickHandler()">Subscribe</button>
</div>

Why not do?

<form onsubmit="handleSubmit(event)">
  <label for="email">Email address</label>
  <input id="email" type="email" name="email" required />
  <button type="submit">Subscribe</button>
</form>

Why does this matter?

• <label> explicitly ties text to an input.

• <input> is natively focusable and announced by screen readers.

• <button> has default keyboard interaction (Enter/Space), unlike a div.

Labels Are Non-Negotiable, Use Them!

Every input needs a visible and accessible label. Not just a placeholder text, and definitely not just ARIA attributes. A real, on-screen label.

For instance;

Instead of

<input type="tel" placeholder="Phone number" />

Why not do?

<label for="phone">Phone number</label>
<input id="phone" type="tel" />

This is because, Placeholders;

• disappear on focus,

• are hard to read with low contrast,

• are not announced as labels by many screen readers, and many more!

If there’s any reason at all that’d make you want to use just placeholders for your inputs, for instance when the visual space is tight, then I suggest you consider other more intuitive ways of displaying your form labels. For example, you could consider using floating labels (like can be seen in MUI’s text field).

In all, always use a proper <label> under the hood.

Grouping and Context in Forms: fieldset vs legend

When you have related fields in your forms, like address, gender, or payment info, it’s always good practice to wrap them in a <fieldset> with a <legend>.

For instance;

<fieldset>
  <legend>Payment Method</legend>

  <label>
    <input type="radio" name="payment" value="card" />
    Credit Card
  </label>

  <label>
    <input type="radio" name="payment" value="paypal" />
    PayPal
  </label>
</fieldset>

This way, screen readers will announce the legend as context before reading out each input. This helps build comprehension, especially for users navigating by audio, and makes the user experience worthwhile.

Keyboard Navigation and Focus Management

The order in which users navigate through form elements using the Tab key is very important for ensuring a smooth and intuitive experience. When designing forms, it's necessary to structure them so that the tab order follows a logical progression that mirrors the visual layout. This means arranging input fields, buttons, and other interactive elements in a sequence that users would naturally follow, thus allowing users to move efficiently from one part of the form to another without unnecessary jumps or confusion.

To achieve this, ensure that all interactive elements are included in the tabbing sequence and that the focus moves in a sensible direction, typically top to bottom and left to right (or right to left, as the case may be). Use HTML to properly arrange elements in the DOM, and avoid using CSS alone to change the visual order, as it can disrupt the natural tab flow. Additionally, use the tabindex attribute to control the focus order without overriding the default flow unless absolutely necessary.

Users who rely on keyboards should be able to move through the form linearly using Tab, Shift + Tab, Enter, and Space.

• Do NOT remove outline styles with CSS. If you must style them, replace them meaningfully.

• Avoid tabindex="0" on non-focusable elements unless necessary.

• Never use tabindex to "fake" tab order. It often breaks assistive technology.

If you're building custom modals/dialogs/popups or dynamically-injected fields:

• Always trap focus within modals. Do not allow items outside of the modal to be focused on while the modal is still open and active.

• Return focus to the trigger (modal opener) when the modal closes.

• Auto-focus the first input responsibly.

Handling Errors Accessibly

Visual Feedback Isn't Enough

Red borders and inline error messages are helpful for sighted (and non-color blind) users, but not for screen reader users. We need to go further.

Use aria-describedby to associate error text with the input.

<label for="username">Username</label>
<input id="username" name="username" aria-describedby="username-error" required />
<p id="username-error" class="error">Username is required</p>

Screen readers will now announce the error message alongside the field when focus lands on it.

Use Clear Language

Avoid vague errors like:

• "Invalid input"

• "Something went wrong"

Instead, use:

• "Username must be at least 6 characters"

• "Email address is required"

Always be specific and human in your feedback. This way, your users get to easily understand what they’re doing wrong.

Live Validation Feedback (with ARIA)

If you're validating fields on input or blur, notify users using ARIA live regions.

<div id="password-feedback" role="alert" aria-live="assertive"></div>

Update this region dynamically when the validation state changes. This ensures that screen readers announce the changes as soon as they occur.

Also, while live regions are very useful, avoid overusing them as they can become noisy and overwhelming. Use them only when information must be passed across to the users in real time.

Handling Custom Components

If you’re building your own form elements (eg; select dropdowns, date pickers, toggles, etc), you take on the responsibility of replicating all native behaviors.

For example:

• A custom select should be operable via keyboard

• It should announce expanded/collapsed state

• It must be focusable and labeled correctly

This is not as easy as it looks. So, if you can, make use of native elements. Else, if you must go custom, then you need to study the WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) Authoring Practices Guide here: https://www.w3.org/WAI/ARIA/apg/

Do not Guess. Test with Screen Readers :)

The truth is that you’d never have any idea how your form behaves for 10 to 20% of your users if you’ve not tested your form with a screen reader.

You should try these out for a start:

• VoiceOver (Mac users): ⌘ + F5

• NVDA screen reading software (Windows users): Free, powerful, open-source

• JAWS screen reading software (Windows users): Industry-standard

• Chrome VoX extension (in-browser): Voice recognition tool for dictation

Go through your form and answer these questions:

• Can you tell what each field is for?

• Can you hear error messages?

• Does it follow logical order?

When you do this, you’ll most likely spot UX bugs that sighted users will never report.

In Conclusion

It's very important for us to note that accessibility isn’t just about compliance. It’s about building with empathy and respect for the people behind the screens. When your forms work for everyone, your product becomes more usable, more inclusive, and ultimately more successful and useful.

A form isn’t complete when it looks right. It’s only complete when it feels right for every user, on every device, and in every context.

Let’s build better and more accessible UIs!

References & Further Reading

• W3C Forms Tutorial

• ARIA Authoring Practices Guide

• Inclusive Components – Forms

• Gov.uk Design System – Forms

• Smashing Magazine – Accessible Forms

• WebAIM – Form Accessibility

• MUI Text Field (example of floating label)

* Cognitive load refers to the amount of mental effort being used in the working memory. When designing forms, it's crucial to consider how much information and how many tasks we are asking users to process at once. If a form is too complex or asks for too much information at once, it can overwhelm users, especially those with cognitive disabilities or those who are unfamiliar with the content. By paying attention to cognitive load, we can create forms that are not only more accessible but also more user-friendly for everyone.

* Error recovery is an essential aspect of form design that ensures users can easily correct mistakes and complete their tasks without frustration. When a user encounters an error, the form should clearly indicate what went wrong and provide guidance on how to fix it via error messages displayed near the field where the error occurred. Effective error recovery means creating a supportive and inclusive environment where all users, regardless of their abilities, can complete forms successfully and with ease.

You don’t have to disable the “Focus” outlines on your HTML elements. Yes, you heard me right. Your users deserve better and I’ll tell you why 😇.

This is a trap that is so so easy to fall into. I promise you I have done this a lot of times than I’m proud to announce, hahaha.

You’re wrapping up a UI, and making it as sleek and as pixel-perfect as ever, only for you to tab through the page and then you notice those ugly blue outlines appear. By default you just find yourself running to your global CSS file to add this style;

*:focus {
  outline: none;
}

Problem solved? Nahhh, far from it. It isn’t just bad practice when you disable focus outlines. You end up excluding a lot of users from accessing your web app with ease.

In this article, we’ll get to understand why those button outlines matter, what happens when you remove them, and how to improve focus styles the right way.

What Are Focus Outlines and Who Needs Them?

Focus outlines are visual indicators that show which element is currently in focus, typically when navigating a site with a keyboard (tab, shift+tab, etc.).

Usually, browsers show these outlines as dotted or solid blue rings around buttons or links with the main purpose of aiding accessibility (a11y) and showing when a button or link is focused on.

You may not use the tab key to move through a page, but millions of users do, for instance:

• Users with motor impairments who rely on keyboards or assistive switches.

• Users with low vision who use screen magnifiers and need a visible target.

• Power users who navigate faster with keyboard shortcuts.

• Developers testing keyboard accessibility.

When you remove focus outlines, you end up making your site unusable for these users.

The Damage Caused by outline: none and How to Fix

When you hide focus outlines like this:

*:focus {
  outline: none;
}

You end up creating an invisible barrier without knowing it, thus limiting the ability of your users to use your web app. For instance, users try to move through your interface with the tab key but can't see where they are. Imagine trying to fill out a form without knowing which field you are in. That's what the experience feels like when people are using your app.

Worthy to note also is that, taking away focus outlines without adding something else is an accessibility violation under WCAG 2.1. This could affect your users, harm your reputation, or even cause legal issues for your company.

You can also try to press the tab button repeatedly on your app to move through the UI, and confirm if you can see where the focus is.

Instead of taking off the focus ring entirely, or even just leaving the default focus ring, you can make it more elegant and accessible by applying custom styles.

Here’s the right approach:

1. Customize, Do NOT Remove

You can style the focus ring to match your brand without eliminating it:

button:focus {
  outline: 2px solid var(--brand-color);
  outline-offset: 2px;
}

While doing this though, make sure it’s visible against your background and maintains at least a 3:1 contrast ratio.

2. Use :focus-visible for Smarter Styling

Modern browsers support :focus-visible, which is a property that distinguishes between mouse and keyboard focus.

button:focus {
  outline: none;
}

button:focus-visible {
  outline: 2px solid var(--outline-color);
}

This means that mouse users won’t see the ring, but keyboard users will still get a clear focus style. It’s the best of both worlds.

PS: Don’t forget to add a fallback for browsers that don’t support :focus-visible. There’s also a polyfill available if needed 🙂.

Why You as a Designer/Developer Should Not Remove It

Most designers and developers remove the default browser outline because it clashes with their custom design systems. But the hard truth is that it’s just a short-term visual fix with long-term usability costs.

On the other hand, a well-designed focus indicator would:

• Reinforce your brand.

• Show attention to accessibility.

• Make your interface more predictable.

While working on your UI, you can cross-check these bullet points to ensure you’re on the right path:

• All interactive elements (buttons, links, form inputs) must show focus.

• The focus indicator must be clearly visible on all backgrounds and themes.

• You may use :focus-visible to conditionally show outlines for keyboard navigation.

• Never hide focus styles globally.

• Test keyboard navigation e2e before tagging any page as completed.

Using Utility Class for Focus Styling

If you use Tailwind or similar utility-first CSS frameworks, you can define a reusable focus class:

.focus-ring {
  outline: 2px solid var(--outline-color);
  outline-offset: 2px;
}

Or with Tailwind directly:

<button class="focus:outline-none focus-visible:outline focus-visible:outline-blue-500 focus-visible:outline-2 focus-visible:outline-offset-2">
  Submit
</button>

In Conclusion

Don’t disable focus outlines just because they don’t match your brand. Create designs around them. Reinvent, customize, but never eliminate them. Always remember that how users use or are able to find their way around your web app is very important.

Focus indicators are lifelines for users who navigate differently from you, and their experience can be made good or bad by even a single line of CSS that you decide to add.

So the next time it crosses your mind to use outline: none, remember that it’s not just about the design. The experience of your users is key to building a great product!

References & Further Reading

• MDN on :focus-visible

• WCAG 2.1 on Focus Visible

Images are often times the heaviest of assets on web pages, and ironically, they're also the most neglected in performance workflows.

We spend a lot of time cleaning up our code, fine-tuning our scripts, bundling our CSS, and taking part in long debates about web rendering strategies but overlook the kilobytes (and in so many cases, megabytes) hiding in oversized jpegs or unnecessary image requests. If you're serious about Core Web Vitals, good user experience, and real-world performance, image optimization has to be a core part of your frontend workflow.

In this post, I’ll walk you through modern image optimization techniques majorly in these areas:

• Next-gen formats like AV1 Image File Format (AVIF).

• Lazy loading strategies (native and JavaScript-based).

• Best practices for responsive image delivery.

• CDN and tooling tips that actually move the needle.

Why Does Image Optimization Matter?

Let’s look at this from the numbers angle:

• Images account for approximately 50% of the total page weight on the average.

• Poorly optimized images increase the time to Largest Contentful Paint (LCP).

• They contribute heavily to Cumulative Layout Shift (CLS) if dimensions aren’t properly handled, as the pages will always tend to move once an iimage loads completely with it’s full dimensions.

We don’t just save bytes each time we make sure that images are optimized on our web pages and apps. We directly affect the user experience (especially on slow networks), perceived load time and also the bounce rate and SEO of our web apps.

Image Optimization Techniques

1. AV1 Image File Format (AVIF):

AVIF is a modern image format that offers superior compression compared to JPEG, PNG, and even WebP. It’s based on the AV1 video codec, and it supports HDR, transparency, and animations.

AVIF is really great and gets the job done, as can be seen below;

On the average, AVIF reduces image size by 30 to 50% compared to WebP, and even more compared to JPEG, without any noticeable loss in quality.

How to Use AVIF in HTML

Always use the <picture> element for graceful fallback to a more compatible image format:

<picture>
  <source srcset="/assets/banner.avif" type="image/avif">
  <source srcset="/assets/banner.webp" type="image/webp">
  <img src="/assets/banner.jpg" alt="Banner" width="1200" height="600" loading="lazy" decoding="async">
</picture>

PS: Always include width and height to prevent CLS.

2. Lazy Loading Images:

The simplest way to defer offscreen images is by using the native loading="lazy" attribute in our html code. It helps us to load only what’s crucial and visible first.

Lazy loading is supported by all modern browsers (including Chrome, Edge, Firefox, Safari ≥16).

<img src="/assets/gallery1.jpg" loading="lazy" alt="Gallery image">

When to Use JavaScript-Based Lazy Loading

If you need:

• Custom thresholds (e.g., preload 500px before viewport)

• Fade-in animations on scroll

• Compatibility with older browsers

You can use the IntersectionObserver API:

const images = document.querySelectorAll('img[data-src]');

const observer = new IntersectionObserver((entries, obs) => {
  entries.forEach(entry => {
    if (entry.isIntersecting) {
      const img = entry.target;
      img.src = img.dataset.src;
      img.removeAttribute('data-src');
      obs.unobserve(img);
    }
  });
}, {
  rootMargin: '200px'
});

images.forEach(img => observer.observe(img));

PS: IntersectionObserver is not compatible on older broswers. You can check here on caniuse.

Also worthy of note;

You can also set the decoding attribute of the image tag to “async”. It helps reduce render-blocking assets and improve paint times, by telling the browser to decode images asynchronously.

<img src="..." decoding="async" loading="lazy" />

3. Serving Responsive Images

Alternatively, you can also use srcset and sizes to deliver images of different formats/quality based on the screen width.

<img
  src="/images/photo.jpg"
  srcset="
    /images/photo-480w.avif 480w,
    /images/photo-800w.avif 800w,
    /images/photo-1200w.avif 1200w"
  sizes="(max-width: 600px) 480px, (max-width: 900px) 800px, 1200px"
  alt="Team photo"
  loading="lazy"
  decoding="async"
/>

What happens is that the browser selects the best image based on device width and device pixel ratio (DPR). So, in essence, users on smaller or slower devices don’t download large unnecessary assets thus saving them a lot of time to fully load the page.

4. Utilizing a Content Delivery Network (CDN)

A Content Delivery Network, commonly referred to as a CDN, is an essential component in modern web development for optimizing the delivery of content to users. By distributing copies of your website's static assets, such as images, stylesheets, and scripts, across a network of geographically dispersed servers, a CDN significantly reduces the physical distance between the server and the user. This results in faster load times, as the data travels a shorter distance.

You should use a CDN that supports Image Transformation. Some popular options include;

• Cloudflare: Easy auto-resizing and AVIF support.

• Vercel / Netlify (for Next.js/Gatsby projects): Built-in image optimization with AVIF + WebP fallback.

• Cloudinary: Image and video APIs for fast and scalable media management.

• Imgix: On-the-fly format conversion and smart cropping.

• ImageKit: Real-time image resizing, global CDN.

Example with ImageKit:

<img src="https://domain.imagekit.io/your-id/image.jpg?tr=w-800,f-avif" />

5. Dev Workflow & Tooling

You can also use these tools to optimize your assets locally;

• Squoosh (https://squoosh.app): Great for manual optimization + AVIF/WebP conversion.

• Sharp (Node.js): Useful in build scripts

    import sharp from 'sharp';
    sharp('image.jpg')
      .resize(800)
      .toFormat('avif')
      .toFile('image.avif');
  

• Next.js <Image /> component: This handles all your AVIF/WebP conversion, resizing, lazy loading, out of the box! Also, you can install sharp and Nextjs will automatically use it to optimize your images during build.

6. Accessibility & SEO Considerations

Most importantly, let’s not forget our SEO and a11y considerations:

• Always add width/height attributes or use aspect-ratio containers to prevent CLS.

• Always add alt text for screen readers.

• Use descriptive filenames (for instance, company-logo.avif vs image1.avif)

In Conclusion

Image optimization is not just a "nice-to-have" as some may think. It is a foundational step in delivering fast, accessible, and exciting experiences to our users, especially for those on slow networks say in remote areas, or thise using mobile devices.

Whether you're working with static sites, SPAs, or full-blown server-rendered apps, getting your image strategy right will pay off in Core Web Vitals, SEO rankings, and real-world UX.

In summary, If you're not optimizing your images, you're leaving performance gains on the table!

For instance, if you have ever wondered:

• Why is my Lighthouse score so low?

• Why did Google Search Console flag my site for poor performance?

• How do I actually fix the layout shift on my page?

This article aims to break these all down for you, with real examples, and actionable tips. 😉

So, What Really Are Core Web Vitals?

Core Web Vitals are important metrics that help us measure the user experience (UX) of a website or page, so we can have an idea of how good or bad the UX is. They focus on three main areas; loading performance, interactivity, and visual stability. These metrics help ensure that websites are fast, responsive, and visually stable for users.

They include:

• LCP (Largest Contentful Paint): this measures how fast the page takes to load.

• FID (First Input Delay): this measures how quickly a page becomes interactive.

• CLS (Cumulative Layout Shift): this measures the visual stability of a page.

These metrics aren’t just random. They represent actual user pain points such as these for the cases above respectively:

• LCP: “The page took too long to load”.

• FID: “I tapped on a button but nothing happened”.

• CLS: “The page layout keeps jumping/skipping”.

And, Why Do They Matter?

• Ranking factor: Google uses Core Web Vitals for Search Engine Optimization (SEO). Pages with low scores might rank lower.

• Perception: A page that "feels" fast performs better, even if it isn't technically faster.

• Retention & UX: Poor scores means higher bounce rate, which also means a long list of users will most likely be lost.

Let’s Go!

1. Largest Contentful Paint (LCP)

LCP measures how long it takes for the biggest content element at the top of the page (like a main image, <h1>, or video thumbnail) to load completely.

To achieve a good LCP score, aim for under 2.5 seconds load time, measured at the 75th percentile across both mobile and desktop.

PS: It’s not when the page starts loading, but when it feels meaningfully loaded.

What Counts as “Contentful”?:

The largest visible element/tag within the viewport:

• <img>

• <video>

• <h1> or any large text block

• Background images via url() (excluding CSS gradients or pseudo-elements)

For instance, if your homepage has a large hero image and title, and that image takes 4 seconds to appear due to render-blocking CSS or JS, your LCP is 4s. That is too slow to even imagine, for real.

How to Improve LCP:

Tools to Measure:

• Chrome DevTools (LCP marker, under the Performance tab)

• Lighthouse (Performance tab)

• PageSpeed Insights

• Web Vitals extension

• web-vitals npm package

2. First Input Delay (FID)

FID measures the time between user interaction and the browser responding.

• Applies to first interaction, for instance, tap, click, or keypress (excluding scroll).

• It’s not about visual feedback. It’s about when the JavaScript event handler starts.

To achieve a good FID score, aim for under 100 milliseconds.

Why Does It Matter?:

Just imagine that your page looks ready, but the JS thread is still blocked and parsing about 1mb of bundled code. Then a user taps the “Add to Cart” button but nothing happens for a full second.

Now that’s a really poor FID, which would in essence translate to poor UX.

How to Improve FID:

Tools to Measure:

FID can only be measured in real-world situations and is not available in lab tools like Lighthouse. To measure, use Real User Monitoring (RUM) tools designed to capture real-world user interactions and provide insights into how users experience your website, or Web Vitals API to track it in production.

3. Cumulative Layout Shift (CLS)

CLS measures how much the page layout shifts during the entire lifespan of the page, especially while it’s still loading. It quantifies unexpected movement of elements.

For instance, think of:

• Images loading and pushing content down.

• Ads injecting a weird space on a page.

• Fonts swapping and resizing.

To achieve a good CLS score, aim for under 0.1.

Imagine if:

A user gets on a page with the intention of tapping a “Pay Now” button, but just before they tap the button, the page jumps because an image or banner loaded. And then, they accidentally click the “Subscribe to newsletter” button. As simple as it sounds, it is really bad and can even get worse!

How to Fix CLS:

CLS Components:

Cumulative Layout Shift is calculated as the sum of all layout shift scores that occur throughout the entire lifespan of a page. This metric is crucial for understanding how much the page layout changes unexpectedly while the page is loading or even after it has fully loaded.

To break it down further, a single shift score is determined by multiplying two factors: the impact fraction and the distance fraction.

• Impact fraction represents the portion of the viewport that is affected by the shift. For example, if the shift impacts 25% of the viewport, the impact fraction would be 0.25.

• Distance fraction measures how far the elements on the page have moved relative to the viewport.

Mathematically;

• CLS = sum of all layout shift scores.

• A single shift score = impact fraction × distance fraction.

By understanding and addressing these components, developers can effectively reduce CLS and improve user experience. It is important to ensure that all elements on a page load smoothly and predictably, minimizing any unexpected movements that could disrupt user interactions.

How to Measure Core Web Vitals

Lab Tools (Good for Debugging)

• Chrome Lighthouse (DevTools)

• WebPageTest

• PageSpeed Insights

• Lighthouse CI for CI/CD pipelines

PS: I wrote about lighthouse here and the DevTools here.

Field Tools (Good for Real User Monitoring)

• Core Web Vitals report in the Google Search Console.

• Chrome UX Report (CrUX).

• Web-vitals JS Library (npm i web-vitals or yarn add web-vitals).

• Analytics tools: GA4, SpeedCurve, New Relic, Datadog, Vercel Analytics.

CWV in Frameworks Like Next.js (React)

If you’re using Next.js, you can measure Core Web Vitals natively with the reportWebVitals function llike this:

// _app.tsx
export function reportWebVitals(metric) {
  if (metric.name === 'LCP' || metric.name === 'FID' || metric.name === 'CLS') {
    fetch('/analytics', {
      method: 'POST',
      body: JSON.stringify(metric),
    });
  }
}

You can also hook this into your analytics or logging dashboard.

In Conclusion

As frontend developers, our job doesn’t stop at pushing pixel perfect screens. We are always tasked with delivering great user experiences, and have a very important role to play in user retention at any business we find ourselves in. If our pages shift, lag, or behave weirdly, users would always notice and would be scared away.

So let’s stop guessing and start measuring! Let’s build fast, ship smooth, and think like our users always.

It’s customer first! 😇💪

References & Further Reading

• Mastering Chrome DevTools for Frontend Development and Debugging

• Using Lighthouse to Audit Performance & A11y

• Web Vitals

• Cumulative Layout Shift (CLS)

• Get started with Google Search Console

• PageSpeed Insights

• web-vitals JS package

You want your user experiences (UX) to be fast, accessible, and reliable though. Hence, the need for tools like Lighthouse. Whether you're refining your Core Web Vitals or ensuring your product is usable by everyone (including those relying on screen readers or keyboard navigation), Lighthouse is a developer’s flashlight into the dark corners of user experience.

What then is Lighthouse?

Lighthouse is an open-source auditing tool built to help you automated tool to help you improve the quality of your web apps. It lets you run tests against any webpage at all, and returns a detailed report with scores on:

• Performance

• Accessibility (A11y)

• Best Practices

• SEO

• Progressive Web App (PWA) readiness

Each section gives a numeric score out of 100, but more importantly, it tells you why something is lacking and how to fix it.

Lighthouse can be run in the Chrome DevTools, as a node module, or from the command line. Let’s check them out;

1: Chrome DevTools

• Navigate to your site in Google Chrome browser.

• Right-click on anywhere on the page, and then click on “Inspect”. Click on the “Lighthouse” tab at the top panel.

• Choose the categories you want to audit the site in. This could be performance, accessibility, best practices and/or SEO.

• Click "Analyze page load” button.

• Wait a few seconds for the analysis to complete, and then check out your full report.

2: Command Line

If you want more control or to automate audits, you can use:

npm install -g lighthouse
lighthouse https://your-site.com --view

This gives you a local HTML report in your browser which you can then proceed to review.

Auditing Performance with Lighthouse

Performance isn’t just about speed. It’s also about interactivity. Lighthouse looks at metrics like:

• First Contentful Paint (FCP) – how fast the first element shows.

• Largest Contentful Paint (LCP) – how quickly the main content loads.

• Time to Interactive (TTI) – how long it takes before the page responds to user input.

• Total Blocking Time (TBT) – the length of time the page is unresponsive due to heavy JS.

• Cumulative Layout Shift (CLS) – how visually stable the page is.

Common Fixes:

• Compress and lazy-load assets like images, gifs, videos, etc.

• Minify CSS and JS files.

• Use a Content Delivery Network (CDN) to store and fetch assets.

• Code-split your bundles.

• Preload only assets that are critical to the page functionality

Lighthouse runs its audits against the current page and then opens up the results of the report in the DevTool tab. These results come with recommendations/suggestions which would go a long way to help you rank up the scores. Take note of each report and fix in your codebase, one at a time.

Auditing Accessibility (A11y) with Lighthouse

The importance of accessibility (or A11y), a very important pillar in frontend development, is so commonly overlooked by a lot of engineers today. Yet, it’s one of the most critical things to factor in when building for great UX.

Lighthouse helps us run checks to answer questions like:

• Are buttons and links labeled?

• Do images have alt text?

• Is the contrast ratio sufficient?

• Can the page be navigated with a keyboard?

• Are ARIA (Accessible Rich Internet Applications) roles properly used?

These aren’t just technical checkboxes but are properties that when not properly checked, can directly impact the experience of users with disabilities.

Recommended Workflow:

To maximize Lighthouse, you can follow these steps;

1. Run a Lighthouse audit on Accessibility for a start.

2. Fix low-hanging issues like color contrast or missing labels.

3. Use tab navigation to test the keyboard navigation flow.

4. Run a screen reader (like VoiceOver or NVDA if you have access to one) to simulate non-visual access.

5. Re-run Lighthouse and aim for a 90+ score.

PS: Passing Lighthouse doesn’t mean your site is fully accessible, it’s just a starting point. Always test manually as it matters a lot.

Integrating Lighthouse Into Your Dev Process

If you’re building at scale or on a team, then you should do these:

• CI Integration: Use Lighthouse CI to catch regressions during builds.

• Custom Configs: Tailor Lighthouse runs with custom configs to align with your team’s goals.

• Performance Budgets: Set performance thresholds and fail builds that exceed them.

In Conclusion

Lighthouse isn’t just a tool. It goes a long way to help you spot real issues, track progress, and build empathy for anyone using your site. It always has a way to force you to think about quality across the board in any page/site you’re building by giving really helpful recommendations.

Do not fail to also test manually to ensure your users always have a great experience!

References & Further Reading

• Lighthouse on Chrome DevTools Docs

• Google Web.dev: Measure Performance

• Accessibility Insights Developer Tools

• Using Lighthouse CI

In this article I’d be speaking mainly to the Chrome DevTools as it’s my favorite and go to anytime anyday! I love the Chrome DevTools because it has a lot of potential, and as you may also have observed, gets new features so much frequently than a lot of, if not all, other browsers.

Over time, with more than half a decade spent on building responsive and intuitive web applications, I’ve come to rely a lot on Chrome DevTools not just to inspect elements or observe warnings and errors in the console, but to really debug logical flows, styles and performance of my apps. Whether it’s an element that just refuses to center or a page that overflows or behaves weirdly during scroll, DevTools has the answers you need if you know where to look.

I will do my best to break down how I use Chrome DevTools to debug my projects from a real-world developer’s lens.

Debugging Styles?: The Element Panel is Your Best Friend

Let’s say I’m working on a page and the layout breaks, or something just seems off. The “Elements” panel is my first stop.

1. Inspect the DOM

• Right-click any part of the UI and then click on Inspect.

• Make sure you’re in the Elements tab in the developer tools section.

• You should see a live view of the DOM with the ability to expand and collapse nodes, like your JSX or HTML, depending on what you’re building with.

2. Style Live-Editing

• Just below or on the right of the Elements tab (depending on how your dev tools is aligned), under the "Styles" tab, you can:

  • View applied CSS, inherited rules, and overridden styles (crossed out).

  • Directly edit styles, toggle declarations, or add new rules and see their effects play out in real time.

• Hover over any property in the DevTools, and you’d see visual guides like padding, margins, etc., in real-time on the page.

3. Box Model Visualizer

• Scroll to the bottom of the Styles tab, and you’d see the Box Model. It gives you access to a visual breakdown of the margin, border, padding, and content dimensions.

• Also, hovering over each part of the box model shows you visual guides on the page in real time.

• this helps me quickly spot issues with spacing or overflow.

4. Computed Styles

• Most of the time, styles are deeply nested or dynamically applied, hence “computed”.

• This "Computed" tab shows the final rendered value for every CSS property and is great for confirming what’s actually being used in rendering the components.

Debugging Performance?: The Lighthouse and Performance Tabs

Now, if your app feels sluggish or slow, it’s time to switch gears and speed things up!

1. Run a Lighthouse Report

Start with an audit:

• Open the DevTools and go to the “Lighthouse” tab.

• Generate a report for performance, accessibility, best practices, and SEO categories by clicking on the “Analyze page load” button.

• It would give you a quick snapshot of the following metrics:

  • First Contentful Paint (FCP)

  • Largest Contentful Paint (LCP)

  • Total Blocking Time (TBT)

  • Cumulative Layout Shift (CLS)

  • Speed Index (SI)

• Also, you’d get insights on how to optimize for these:

  • Time to Interactivity

  • Javascripts minification

  • Unused JavaScript or CSS

  • Image optimization tips

  • Third party usage

This isn’t just about scores. I use it to find low-hanging fruits that I can touch up easily to help speed up my UI and give better experiences to my users.

2. Record a Performance Trace

   

For more indepth debugging, you’d need to:

• Click on the “Performance” tab.

• Then, click Record, interact with your page, and then stop recording.

  

  

• You’ll get a frame-by-frame timeline of the following:

  • Scripting, rendering, painting activities

  • Long tasks (usually caused by expensive JS execution)

  • FPS (frames per second) and dropped frames

This helps me track down why a button takes 2 seconds to respond or why animations feel broken.

You can also control the Environment settings such as the CPU and network speed just to test for those scenarios.

3. Layout Shift Debugging

Want to check if things jump around while loading?

• The Performance tab highlights Cumulative Layout Shifts (CLS).

• You’ll literally see when and where a layout reflow happened.

Other Tools I Also Use Frequently

• Network tab: Here, you can check what’s loading, what’s slow, what’s failing, etc. You can filter the network requests by a couple of flags like Fetch/XHR requests, CSS, JS, Font, etc. I also throttle the network speed so as to test how my app performs on slower network speeds.

  Another thing I also do is to enable the “Preserve log” checkbox. This helps me refresh the page without having to worry about losing any of the logs from previous loads.
  Then, sometimes, I disable cache just to be sure I’m getting fresh requests loaded.

  

• Application tab: I use this to view the localStorage, sessionStorage, cookies, IndexedDB, shared and cached storages, Essentially, you can view everything storage here, lol, which is so helpful for debugging auth and caching. Service workers and background services are also accessible here.

  

• Rendering tab: You can access a list of stats and emulations here, by clicking on the 3 dots at the top right and then “Run command”. You can enable Paint flashing, Layout shift regions, FPS meter for live visual insights, etc.

  

• Console tab: This tab is definitely one of every developer’s favorite, lol. You get to log anything to the browser console (console.log) and see the logs here. This helps a lot with verifying what is and what is not.

  

• AI assistance tab: You get to ask questions here, as much as you’d like. Although it’s still experimental, this tab can be very useful.

  

  You can select any item at all in either of the listed tabs and ask AI about them. For instance, you can do this in the network tab;

  

In Conclusion

The DevTools is more than an inspector, it’s an amazing tool for debugging your web apps. And now, with AI, the DevTools has got even more resourceful with AI insights and “Ask AI” features. Once you get comfortable using it intentionally, you’ll start solving UI issues faster, with more confidence, and fewer logs to the console. 😉

If you’re just getting started, don’t feel overwhelmed. Start by inspecting and editing styles live. Then build up to using the Performance tab and Lighthouse. It’s one of those skills that compound over time.

And remember, the best way to learn how to use the DevTools is to break stuff and fix it using the DevTools. 😄

Up next, I will be writing about how to use some other browser extensions like the React Developer Tools, Redux DevTools, etc to supercharge your browser DevTools. These would give you access to other features that’d help you inspect and profile the behaviour of your components and redux states.

See you in the next one! 💪

Growing up, everyone around me noticed I had a deep level of curiosity, which increased as I became older. A good number of the gadgets in the house then didn’t have the opportunity to stay whole long enough to see me grow up, because I had dismantled them one way or the other just out of curiosity to see how they really worked and if I could assemble them again. And of course, I couldn’t assemble all successfully. I still remember that big radio, and really hope my dad doesn’t come across this post. 😆

One of the curiosities I also noticed had grown in me as I found myself in the tech space was how the web really worked. One thing I was really sure of was that it isn’t magic at all even though it felt and still feels almost magical!

I mean, come to think of it; you just get to type a web address, hit enter, and in milliseconds, a web page appears.

PS: A web or website address is essentially the address of a resource or set of files on the internet. It’s called a Uniform Resource Locator (or URL for short).

As a frontend engineer too, understanding the steps behind loading a web page helps you level up and gives you a clearer picture of performance issues, rendering strategies, browser behavior, and even security implications.

I’ll do my best to break down this process in as much simple terms as I can. Don’t worry at all, I’ve got you covered 😇💪

Step 1. You type a URL or web address into your browser’s address bar and then hit enter

Let’s say you visit: https://example.com

This is not just a random string, as you may have guessed rightly. Every part of it has its own function. Let’s break this down even more;

1. https : Scheme / Protocol

• This part tells the browser what protocol it should use to access the resource.

• In this case, the browser is to use the HTTPS (HyperText Transfer Protocol Secure), which is basically a secure version of the HTTP (HyperText Transfer Protocol → http://); or in more technical terms, HTTP with encryption via TLS (Transport Layer Security).

  PS: HTTP is a set of rules that govern how web browsers and servers communicate, enabling the display of web pages and other content (*more info at the references section).

• It ensures the data being shared or looked up is:

  • Encrypted (no eavesdropping by a 3rd party)

  • Authenticated (you’re talking to the real site, even though this is not a 100% assurance today 🥲)

  • Tamper-proof (the data can't be altered in transit)

2. example.com : Domain Name

• This is the hostname or domain, which users can remember and type easily.

• The domain is mapped to an IP address via a DNS lookup (*more info in next step).

Let’s break it down even further:

Combined, example.com is the fully qualified domain name (FQDN).

A full URL actually goes way beyond just the above. It can include the following:

When all put together this gives us an even longer URL:

https://www.example.com:443/about?user=gospel#section

Step 2. DNS Lookup: Translating the domain to the actual address

Let’s just say the domain name (web address) above you typed into your search bar (example.com) is the name of a utility store. Computers do not understand what names are, and so do not know what example.com is. What they understand is numbers, and hence we need to map the domain to a number (also known as an IP address). The IP (Internet Protocol) address can be said to be the store’s real street address. The computer needs this street address to get to the store you’re searching for.

In essence, your browser asks a DNS (Domain Name System) server (like a phonebook) to resolve the domain to an IP address, e.g., 93.184.216.34.

*The IP addresses associated with example.com are: 93.184.216.34 and 2606:2800:220:1:248:1893:25c8:1946. These are the IPv4 and IPv6 addresses respectively.

Worthy of note: There’s a term called DNS prefetching. It’s a process that you can use to speed up DNS look up for known domains.

Step 3. Establishing a TCP connection (with TLS if HTTPS)

On getting the IP address, your browser establishes a TCP (Transmission Control Protocol) connection with the server hosting the website. TCP is a fundamental protocol that ensures reliable and ordered delivery of data over the internet. This step is very important because it sets up a communication channel between your device and the server, allowing data to be exchanged accurately.

The process begins with a three-way handshake, which is a series of steps that both your browser and the server must complete to establish a connection. First, your browser sends a SYN (synchronize) packet to the server to initiate the connection. The server then responds with a SYN-ACK (synchronize-acknowledge) packet to acknowledge the request. Finally, your browser sends an ACK (acknowledge) packet back to the server, confirming that the connection is established and ready for data transmission.

If you’re using https://, then an additional of security is added through TLS (Transport Layer Security). This involves exchanging cryptographic keys and certificates to encrypt the data being transmitted, ensuring that sensitive information remains secure and private.

This step is often overlooked, but it can add latency or delays especially on mobile or slow networks.

Step 4. Sending the HTTP request

Now the browser finally sends an HTTP GET request for /.

Example:

GET / HTTP/1.1
Host: example.com
User-Agent: Chrome/124

This includes headers with info like cookies, cache rules, accepted formats, and authentication tokens.

Step 5. The server responds

The server then receives the request, processes it (maybe querying a database or rendering just HTML which is short for HyperText Markup Language), and finally sends back a response to your browser. This HTML document is the backbone of the web page, containing the structure and content that the browser will render for the user.

Example:

HTTP/1.1 200 OK
Content-Type: text/html

The response body includes the raw HTML of the page. This is where the browser begins to display the web page.

Step 6. Your browser renders the HTML (DOM creation)

As your browser receives the requested web page as HTML data, it parses content line by line, thereby building the DOM (Document Object Model). The DOM is a tree-like structure that represents the web page's content and structure. This process helps the browser understand how to display the page.

Also, along with the HTML content, the browser receives external resources (like CSS - Cascading Style Sheets, JS - JavaScript, fonts, images, etc.) which it adds to the list of resources for download.

PS: The browser might stop rendering if it comes across CSS or synchronous JS, which can delay the web page from loading in time.

Step 7. CSSOM and Render Tree construction

In this step;

• The browser parses all CSS into the CSSOM (CSS Object Model).

• Then combines it with the DOM to form the Render Tree.

• This tells the browser what to draw and how to draw it.

Step 8. Layout and paint

Now with the render tree ready:

• The browser calculates where each element goes → Layout.

• Then it paints pixels to the screen → Paint.

• The GPU (Graphics Processing Unit) in your device may then start working to put together layers and handle animations.

Step 9. JavaScript execution & event binding

JS files execute during or after parsing, depending on whether they’re defer, async, or blocking.

Also, these take place;

• Event listeners are attached.

• Components are initialized (React, Vue, etc.).

• Client-side rendering (CSR) may then start here.

Step 10. The page becomes interactive (DOMContentLoaded & Load Events)

• DOMContentLoaded: When HTML and DOM are fully parsed.

• load: When everything including images and styles are fully loaded.

This is the final step and at this point the web page has completely loaded and is fully interactive. At this point you now have access to the full contents of the web page you requested on your browser. ☺️

So, what can slow it down? (For devs 😀👌)

How long it takes to load a web page completely play very important roles to how good or bad the experiences of your users/customers turns out. This can be affected by;

• Large CSS or JS files; these block render, especially when they are not deferred.

• Unoptimized images; these increase the web page’s load time due to the longer time it takes the broswer to download the content.

• Third-party scripts; these delay interactivity, as the scripts have to run from top to bottom.

• Multiple server requests; these add latency.

TIP: You can use Lighthouse or PageSpeed to audit or check the performance of your web pages and optimize based on the recommendations.

In Conclusion

A whole lot goes into achieving this “magic” of looking up website addresses and giving us web pages with content that bring value to us. 🔥

Also, for frontend web engineers, understanding how the web works and how to easily optimize for the best user experience (UX) can give us the knowledge we need to build faster, more accessible, and more resilient web apps.

So the next time someone says that a web page is slow, you’ll know exactly where to look! ☺️

References and Further Reading

• What is HTTP and how does it work?

• What is an IP Address – Definition and Explanation

• What is DNS?

• Document Object Model (DOM)

• An Introduction and Guide to the CSS Object Model (CSSOM)

• JavaScript execution model

Making a choice, when it comes to the right rendering strategy to use, all depends on context or use case.

Ask yourself:

• How often does this content change?

• Who needs to see it; users, crawlers, or both?

• What’s more important; speed, SEO, or freshness?

Once you have the answers to these questions, then the right strategy to use at that point in time presents itself. No need to over-engineer. KISS!

You are not alone! 😇

If you’ve tried building or optimizing a frontend web app and felt overwhelmed by all the rendering options (CSR, SSR, SSG, ISR) thrown at you, I’m here to promise you that you are not alone. 😄

This list sounds intimidating at first but once you understand them, their strengths, tradeoffs, and use cases, they become your secret weapon for performance, SEO optimization, and good user experience.

Let’s take a deep dive and get you closer to shipping better web experiences! 😉👍

What is Web Rendering?

Web rendering refers to how the content of your web app or site is bundled into HTML and delivered to the user; either by the browser, the server, or during build.

Different strategies affect performance, SEO, caching, and the user experience as a whole. These strategies include:

1. Client-Side Rendering (CSR)

What:
In this strategy, the entire web app is rendered with JavaScript by the browser. The browser loads a page that is blank or has little content, then JavaScript kicks in, fetches data, and renders everything.

When to use:

• Your content is private or personalized (e.g. dashboards, admin panels).

• SEO doesn't matter much (e.g. internal tools, web apps behind auth).

• You want fast initial page loads after the first visit (thanks to caching).

Cons:

• Slower initial load (especially on low-end devices).

• SEO-unfriendly (unless paired with dynamic rendering or pre-rendering hacks).

Example (Next.js):

'use client';

export default function DashboardPage() {
  const [data, setData] = useState([]);
  useEffect(() => {
    fetch('/api/data').then(res => res.json()).then(setData);
  }, []);

  return <div>{/* render data */}</div>;
}

PS: CSR is generally not recommended for good SEO.

2. Server-Side Rendering (SSR)

What:
Here, HTML is generated on the server-side at the time of request by a user. The server fetches the data needed and returns fully rendered HTML to the client.

When to use:

• You need up-to-date content on every visit.

• SEO is important and the data changes frequently (e.g. product pages with live inventory).

• You’re dealing with user-specific content visible to crawlers (e.g. account previews).

Cons:

• Slower response compared to static pages.

• Server load increases with traffic; the higher the number of active users, the higher the load on the server.

Example (Next.js):

// pages/products.tsx (Pages Router)

type Product = {
  id: string;
  name: string;
  description: string;
};

type Props = {
  products: Product[];
};

export default function ProductListPage({ products }: Props) {
  return (
    <div>
      <h1>Product List</h1>
      <ol>
        {products.map(item => (
          <li key={item.id}>{item.name}: ${item.description}.</li>
        ))}
      </ol>
    </div>
  );
}

export async function getServerSideProps() {
  const response = await fetch('https://example.com/api/v1/products');
  const products = await response.json();

  return { props: { products } };
}

3. Static Site Generation (SSG)

What:
In this case, the HTML is pre-rendered during build. It’s fast, SEO-friendly, and is great for pages that don’t change often.

When to use:

• Your content is mostly static (e.g. blog posts, landing pages).

• You want a really fast performance with CDN-level caching.

• You don’t mind rebuilding your site each time you want updates to reflect.

Cons:

• Not great for real-time data unless paired with revalidation or client-side fetching. This can be seen in the next rendering strategy (ISR).

Example (Next.js):

// pages/posts.tsx (Pages Router)

type Post = {
  id: string;
  title: string;
};

type Props = {
  posts: Post[];
};

export default function BlogPostsPage({ posts }: Props) {
  return (
    <div>
      <h1>Blog Posts</h1>
      <ol>
        {posts.map(item => (
          <li key={item.id}>{item.title}</li>
        ))}
      </ol>
    </div>
  );
}

export async function getStaticProps() {
  const response = await fetch('https://example.com/api/v1/blog-posts');
  const posts = await response.json();

  return { props: { posts } };
}

4. Incremental Static Regeneration (ISR)

What:
This is a hybrid approach for rendering web pages. The pages are generated statically at build time, and then updated under the hood after a set intervals (or when needed).

When to use:

• You want the speed of SSG but with updatable content.

• SEO matters, but you don’t want to rebuild your whole site each time you want changes to reflect.

• You're working with CMS-driven or eCommerce content (like product details).

Cons:

• Slightly complex when it comes to handling stale vs. fresh data.

• More difficult to debug when compared to pure SSG or SSR.

Example (Next.js):

// pages/posts.tsx (Pages Router)

type Post = {
  id: string;
  title: string;
};

type Props = {
  posts: Post[];
};

export default function BlogPostsPage({ posts }: Props) {
  return (
    <div>
      <h1>Blog Posts</h1>
      <ol>
        {posts.map(item => (
          <li key={item.id}>{item.title}</li>
        ))}
      </ol>
    </div>
  );
}

export async function getStaticProps() {
  const response = await fetch('https://example.com/api/v1/blog-posts');
  const posts = await response.json();

  return {
    props: { posts },
    revalidate: 60, // Regenerate every 60 seconds
  };
}

In Summary… When Should I Use What?

References & Further Reading

• Next.js Rendering Docs

• Google: Rendering on the Web

• When to Use Static Generation vs. Server-side Rendering

• Caching strategies

PS: Like, comment and share if this helps you. Also, comment areas that may not be so clear to you yet (whether implementation wise, or you want examples in other frameworks) and I’ll do my best to drop more notes on that.

Also worthy of note;

• You can use a mix; In frameworks like Next.js, you can mix strategies per route. For instance, /about can be SSG, /dashboard can be CSR, and /product/[id] can use ISR.

• You should measure first; Don’t blindly choose SSG for SEO. Sometimes SSR + cache does the job better.

Thank you and see you in the next one! 😉😇

"Put things where they’re used." That’s the golden rule of collocation in frontend development, and once I embraced it fully, my Next.js projects became easier to scale, debug, and maintain.

TLDR;

Collocation makes it easier to find everything related to a feature, component or page in your code, whether you want to make an update or remove an entire feature. Your project’s features are more modular and reusable, and onboarding a new developer to your codebase becomes less stressful. 😉

What is Collocation?

Collocation in frontend web development simply means placing related files and logic close to each other, or in the same folder or context where they are actually used.

So instead of scattering styles in one folder, components in another, and tests in another, you keep everything related to a single feature or component tightly grouped.

Think of it like packing for a trip. You don’t keep your toothbrush in your garage and your passport in the kitchen. You group things by purpose. It’s the same idea here, just that we’re now “packing” our code ☺️.

Why Collocation Matters on the Frontend

In a modern frontend stack, especially with frameworks like Next.js, collocation is not just a pattern. It’s a best practice. Why?

• Discoverability: Easier to find everything related to a component or page.

• Cognitive simplicity: No need to mentally map files across the entire tree.

• Testing is easier: Test files sit next to the components they test.

• Scoped styles and logic: CSS Modules, hooks, and utils don’t leak across the app.

• Encapsulation: Your features are modular and reusable.

A Typical Next.js Project Without Collocation

Here’s a simple (and painful) structure I’ve seen too many times:

/components  
  Navbar.tsx  
  Button.tsx

/styles  
  Navbar.module.css  
  Button.module.css

/pages  
  index.tsx  
  about.tsx

/tests  
  Navbar.test.tsx  
  Button.test.tsx

Now imagine maintaining this at scale. 🥲

With Collocation

Here’s how I typically structure my Next.js apps now using collocation:

my-next-app/
├── src/
│   ├── app/                 # Top-level route components
│   │   └── login/
│   │       ├── layout.tsx
│   │       └── page.tsx
│   │   └── assets/                # Global static assets (images, fonts)
│   │       ├── logo.svg                
│   │       └── favicon.ico
│   │   ├── layout.tsx
│   │   ├── loading.tsx
│   │   └── page.tsx
│   ├── components/            # Shared components
│   │   └── Button/
│   │       ├── Button.tsx
│   │       ├── Button.module.css
│   │       └── Button.test.tsx
│   ├── features/              # Feature-specific modules
│   │   └── auth/
│   │       ├── components/
│   │       │   ├── Login.tsx
│   │       │   ├── Login.module.css
│   │       │   └── Login.test.tsx
│   │       ├── hooks/
│   │       │   └── useAuth.ts
│   │       ├── services/
│   │       │   └── authService.ts
│   │       └── types.ts
│   ├── hooks/                 # Global reusable hooks
│   │   └── useMediaQuery.ts
│   ├── layouts/               # Layout components (e.g., MainLayout)
│   │   └── MainLayout.tsx
│   ├── types/                 # Global type declarations
│   │   └── index.d.ts
│   ├── utils/                 # Utility functions
│   │   └── formatDate.ts
│   └── middleware.ts          # Middleware component
├── .gitignore
├── package.json
├── tsconfig.json
├── next-env.d.ts
└── next.config.mjs

Let’s break it down:

• Each route (like /login) has its own folder with its page component and supporting components in the features folder. Now, this is because I prefer not to have my component and logic files in the app folder. You can also decide to move you feature-specific folder to the feature/route folder in the app directory if you prefer them that close.

  Like this;

    /app/login/
      page.tsx
      layout.tsx
      Login.tsx
      Login.module.css
      Login.test.tsx
      useAuth.ts
  

• Styles, tests, and local hooks sit right next to the components they belong to.

• Shared UI components or layout wrappers go into components folder.

• Shared utils go in utils.

It’s clean, it’s local and, it scales!

Bonus: A Vite App With Collocation

my-vite-app/
├── public/                    # Static assets
│   └── favicon.svg
├── src/
│   ├── assets/                # Global static assets (images, fonts)
│   │   └── logo.svg
│   ├── components/            # Shared components
│   │   └── Button/
│   │       ├── Button.tsx
│   │       ├── Button.module.css
│   │       └── Button.test.tsx
│   ├── features/              # Feature-specific modules
│   │   └── auth/
│   │       ├── components/
│   │       │   └── LoginForm.tsx
│   │       ├── hooks/
│   │       │   └── useAuth.ts
│   │       ├── services/
│   │       │   └── authService.ts
│   │       └── types.ts
│   ├── hooks/                 # Global reusable hooks
│   │   └── useMediaQuery.ts
│   ├── layouts/               # Layout components (e.g., MainLayout)
│   │   └── MainLayout.tsx
│   ├── pages/                 # Top-level route components
│   │   └── Home/
│   │       ├── Home.tsx
│   │       └── Home.module.css
│   ├── routes/                
│   │   └── index.tsx
│   ├── types/                 # Global type declarations
│   │   └── index.d.ts
│   ├── utils/                 # Utility functions
│   │   └── formatDate.ts
│   ├── App.tsx                # Root component
│   ├── main.tsx               # Vite entry point
│   └── vite-env.d.ts          
├── .gitignore
├── index.html
├── package.json
├── tsconfig.json
├── tsconfig.node.json
└── vite.config.ts

A Collocation Example in Code

Say I have a Hero section in my homepage. Here’s what that folder might look like:

Hero.tsx

import styles from './hero.module.css';
import { useHeroData } from './useHeroData';

export default function Hero() {
  const { title, subtitle } = useHeroData();
  return (
    <section className={styles.hero}>
      <h1>{title}</h1>
      <p>{subtitle}</p>
    </section>
  );
}

useHeroData.ts

export function useHeroData() {
  return {
    title: 'Welcome to My Site',
    subtitle: 'Frontend, Fast, and Beautiful',
  };
}

Everything lives in one place. If I ever need to update or remove the Hero, I know exactly what to touch.

Also, if I need to remove an entire feature, I know where to go and not leave any unused code behind.

Pro Tip: Collocation ≠ Coupling

A lot of people confuse collocation with tight coupling. Nope.

You can still keep components modular and testable while collocating. You're just being smarter at putting tools next to the task.

PS: Coupling speaks to how much one component or module depends on another in a project. For your components to be tightly coupled means that you have components that are heavily connected or dependent on one another and changing one often breaks the other.

I’ll be writing more about this later! 🙃

Summary

Collocation is like flossing; everyone agrees it’s good for you, but only a few people do it consistently. Once I made it a rule in my Next.js workflow, things got really smoother.

🥂 Fewer bugs.
👌 Fewer mental jumps.
💪 Better developer experience.

If you’re starting a new project, collocate from day one. If you're refactoring an old one, do it incrementally and I promise you won’t regret it!

• Use python3 and pip3 — don’t rely on python or pip

• Use Homebrew to install Python if needed: brew install python3

• Run pip in scripts using python3 -m pip

• Use venv for project-level dependency management

Have you tried installing Python3 on your Mac, or more so tried to use pip, and then you face the annoying moment where it’s not clear which Python version is in play or even worse, you accidentally install a package into the wrong interpreter or you followed the official docs and installed everything correctly but don’t know how to use the commands?

I faced this same challenge while at a codelab, and just like you I had to use most of my time for building to try to figure out how to get pip working to even start with.

Here’s how to get pip working cleanly with Python3 on macOS, without pulling your hair out 😊;

👉 Step 1: Check your Python 3 install

macOS used to ship with Python2 by default, so running python might still point to that legacy version.

Open your Terminal and run:

python3 --version

You should get something like:

Python 3.13.5

PS.: Python 3.13 is the latest stable release at the time of writing this post.

If that doesn't work, install the latest Python3 using Homebrew:

brew install python3

This gives you:

• python3

• pip3

Or you could just download the Python3 installer here; Python3 installer.

Ready to go.

👉 Step 2: Always use pip3, not pip

Don’t trust pip alone unless you’re absolutely sure it’s mapped to Python 3. Instead, just use:

pip3 install some-package

This avoids surprises and keeps everything clean.

👉 Step 3: Installing packages inside scripts?

PS.: Do this only where necessary.

When automating with Python, do this to make sure the right pip is used:

import subprocess
import sys

subprocess.check_call([sys.executable, "-m", "pip", "install", "some-package"])

This runs pip for the currently running Python interpreter, whether it's the global python3 or inside a virtualenv.

👉 Step 4: Use virtual environments (seriously)

They’re lightweight and essential for managing project dependencies:

python3 -m venv venv
source venv/bin/activate
pip install some-package

Now you’re isolated from system Python and global packages.

🥂 Bonus: Official Python 3 Docs

If you want to dig deeper into pip, venv, or the Python standard library:

👉 Python 3 Documentation

If this helps you, please don’t forget to like, share and comment to help others facing same blocker.
Follow for more tips! 😉

To start with, I didn't want to mention the name Web3 as I think the topic has been over-flogged and abused a lot, but let's take a look at it from this angle - which is this; how really does web3 work? what really is this ownership thingy that has received so much of am emphasis in a short space of time?

Just before we go on ahead though, and just in case this is your first time reading any of my blog posts, you might be wondering where part 1 of this series is (I mean, for there to be a part 2 there must have been a part 1 right?). If this is you, then here it is Blockchain for noobs: part 1.

Let's take a look at a dapp (decentralised app) that allows users to create posts and reply them.

1. Instead of the usual authentication flow (OAuth, Auth2 etc) where you would want to sign up or log in to the app with your email address and password, or with your social accounts, here you would authenticate by connecting your crypto wallet (a user is represented by their wallet).

2. When you create a post or send in a reply, a new file is created and stored on a decentralised file storage system like the IPFS (InterPlanetary File System).

3. Also, a token that represents the file (post) is 'minted' on the dapp blockchain and allocated to your wallet address. The file stays in your wallet and as such you 'own' it, hence the much mentioned term 'ownership'.

4. You can transfer ownership of your files (posts) to other wallets. This is done via transaction calls.

I guess we now have a new question to answer - "what really is this ownership and how does it help me as a user?".

Well, I'd explain this too and I'll be as brief as I can so I don't bore you with the long stories 😉

The idea of ownership proposes that whatever you create (be it a post, an art, or a visual content on a dapp) or get transferred to your wallet via any successful transaction lives in your wallet and are 'owned' by you. They're recognised as assets which gain value over time (and can also lose value too, so you know it's not a bed of roses 🥲).

This is in contrast to web2 which we are so familiar with whereby whatever you create lives in the database of the app or centralised data centres of companies such as Amazon, and as such you don't really 'own' them per se.

Humans are subjective in their judgement/recording of facts and as such, the society can't trust humans to keep 100% accurate records. Also, humans are naturally selected to be self-interested, biased and manipulative.

All these and more make the quest for a way to keep records that are objective and immune to human bias a very highly prioritizes one, and the answer has been seen to be embodied in blockchain technology with the main aim being to remove humans from the equation altogether and replace them with math.

This brings us to various definitions of Blockchain and it's concepts which we will be taking a look at.

1. The blockchain is a decentralised ledger or digital list of who owns what in a network. This can be anything at all, thus making the applications of the blockchain limitless.
2. Decentralised means every user in the network has an up-to-date copy of the ledger. This makes the records unchangeable. If someone for instance tampers with the ledger, the rest of the network will reject it. It's important to note that this has been the original vision for the internet from the beginning.
3. New records (blocks, thus the name "blockchain") encrypted with cryptography. Cryptography is impossibly complicated math that takes a lot of computing power.
4. This computing power is provided by "miners" who get paid in cryptocurrency (like Bitcoin) for securing the ledger. This makes the cryptocurrency scarce thereby giving it economic value.

PS: This is the beginning of a series of articles I will be publishing around Blockchain technologies, enjoy! :)