A Basic Guide to Debugging Frontend Issues
The term "debugging" has a bit of a legendary origin story. It dates
back to 1947 when Grace Hopper, a pioneer in computer programming, was
working on the Harvard Mark II computer. The team encountered an error
that stumped them, until they opened up the machine and found an actual
moth causing the issue. They removed the moth and logged the first ever
"debugging" process. The moth itself was taped into the logbook, which
is now in the Smithsonian Museum. While we may not deal with literal
bugs in our machines these days, the term "debugging" has stuck around,
symbolizing the process of identifying and removing errors or "bugs" in
our code. So, the next time you're debugging, remember you're part of a
tradition that traces back to the very early days of computing!
In this post, we're about to introduce ourselves to the art of debugging frontend issues. We'll use the most powerful tool at our disposal - the browser developer tools. This guide will walk you through inspecting elements, analyzing network requests, and profiling JavaScript to identify and resolve common frontend problems.
This guide is written with the assumption that the reader is using Google Chrome's Developer Tools, which is what I usually use. However, many of the concepts and steps discussed here are also applicable to the developer tools in other modern browsers like Firefox, Safari, and Edge, though the exact interface and features may vary. It's always a good idea to familiarize with the developer tools in multiple browsers to effectively test and debug cross-browser compatibility issues. So, let's crack on!
Chapter 1: The Case of the Misbehaving Element
Picture this: your layout looks like a Picasso painting gone wrong, or a CSS rule seems to have taken a vacation. Don't panic! The browser's inspector tool is your best friend here.
Step 1: Right Click, Inspect
Fire up your site in the browser, then right-click the problematic element and hit 'Inspect'. This opens up the DevTools panel, showing you the HTML structure and CSS rules applied to the selected element. You can also hit the F12 key to bring up Chrome's DevTools.
![]() |
| Chrome's Developer Tools after hitting Inspect on a HTML element |
Step 2: Navigate the DOM
In the 'Elements' tab, you can navigate through your document's structure. Hover over different elements to see them highlighted on your page. Click to select an element and display its CSS rules in the 'Styles' panel.
Step 3: Modify Styles
Now, let's play! You can disable, edit or add new CSS rules right here in the 'Styles' panel. Clicking on color values or dimensions even brings up handy little editors. Try tweaking your styles until you figure out what's causing your issue.
Step 4: Pseudo States
Need to debug a hover state? Check the ':hov' checkbox in the 'Styles' panel. Now you can see and manipulate your element in its various states.
![]() |
| Handling pseudo states |
Step 5: Responsive Layout
Use the 'Toggle device toolbar' button to check your layout on different screen sizes. You can even simulate device-specific settings, like Apple's 'Dark Mode'.
![]() |
| Toggle device toolbar and responsive layout |
Chapter 2: The Mystery of the Missing Resource
Is your site taking forever to load? An image refuses to appear? It's time to inspect network requests.
Step 1: Open the Network Tab
In your DevTools, click on the 'Network' tab. Now refresh your page. You'll see a waterfall of requests, showing everything your page loads and how long it takes.
Step 2: Filter and Sort
The Network tab can be overwhelming, so use the filter options at the top. Want to see only images? Click 'Img'. Looking for a specific file? Type its name in the filter box. You can also sort by columns - try sorting by 'Size' or 'Time' to spot heavy or slow resources.
![]() |
| The Network tab, showing only images |
Step 3: Inspect a Request
Click on a request to see more details, like headers, response payload, or timing breakdown. For missing resources, check the 'Status' column - a 404 means your resource wasn't found at the specified URL.
Step 4: Replay XHR
For debugging AJAX requests, the 'Replay XHR' option is handy. It lets you re-send an AJAX request to see the response without refreshing the entire page.
![]() |
| Inspecting network requests options |
Chapter 3: The Enigma of the Sluggish Script
JavaScript issues can be trickier to solve, but fear not! The JavaScript Profiler and Console are here to help.
Step 1: Profile your Page
In the 'Performance' tab, click 'Start profiling and reload page'. After the page loads, click 'Stop'. You'll see a timeline of events and resources, including javascript execution..
![]() |
| The Performance tab in action |
Step 2: Analyze the Results
In the results view, you'll see a breakdown of where your page spends its time. You're looking for long, tall bars in the 'Main' section, indicating JavaScript activity. Click on one to see which functions were called and how long they took.
Step 3: Identify Bottlenecks
Look for functions that take a long time to execute - these are your potential bottlenecks. Click on the function name to jump to the corresponding code in the 'Sources' panel.
Step 4: Console Warnings and Errors
The 'Console' tab is your site's way of communicating with you. Errors will show up in red, complete with line numbers and sometimes even a stack trace. Warnings or debug messages can also provide clues about what's going wrong.
![]() |
| Errors, warnings and logging in the Console tab |
Step 5: Log More Information
If the problem isn't clear, try adding `console.log` statements in your code to log variable values or confirm that functions are being called. Just remember to remove or coment these out when you're done debugging! In some cases, I find it easier to execute logs directly into the Javascript console in Chrome.
Step 6: Debugging JavaScript
For trickier bugs, you might need to step through your code. Set breakpoints in your JavaScript files from the 'Sources' panel, then reload your page. Execution will pause at your breakpoint, letting you step through your code line by line and inspect variables at each stage.
Chapter 4: The Secret of the Storage
If your site uses local storage, session storage, cookies, or indexedDB, you can inspect these in the 'Application' tab. You can view, edit, and delete stored data, perfect for debugging issues related to persisted data.
Step 1: Open the Application Tab
In your DevTools, click on the 'Application' tab. Here you'll see a list of storage options on the left-hand side.
![]() |
| Inspecting cookies in the Application tab |
Step 2: Inspect the Storage
Click on a storage option to view the stored data. For example, if you click on 'Local Storage', you'll see a list of key-value pairs that are stored in the local storage.
Step 3: Modify the Storage
You can modify the storage data right from the DevTools. Just double-click on a value to edit it. You can also right-click to delete an item or clear all storage.
Conclusion: The Case Closed
Debugging frontend issues can feel like being a detective, searching for clues, and piecing them together to solve the mystery. But with the power of browser developer tools, you have everything you need to inspect elements, analyze network requests, and profile JavaScript. Remember, every bug is a chance to learn more about how things work (or how they don't work!). Embrace the challenge, trust your tools, and you'll become a master frontend detective in no time. Until our next coding adventure, happy bug hunting!








Comments
Post a Comment