Troubleshooting Web Applications

As web developers the ability to troubleshoot a web application is a very important part of the development process. To be able to see what’s happening and understand what may be causing a certain behavior is key and should be employed during the entire development process, not only when something is broken. In this series I will outline my process of troubleshooting web applications.

First off the tools. While there used to be a hand full of tools you might use now you only need one, and that’s Google Chrome Developer Tools. This will show you everything you need to know about your web app, except what’s happening on the backend. However we can see what the backend is sending the frontend which also helps the development/troubleshooting cycle, I’ll get to that in a minute. Let’s get started.

Elements Tab

This tab is extremely handy. Let’s go through the parts here. There are more than I list here but these are the ones I use the most. The numbers below correspond to the numbers in the screen shot to the right.

  1. This is a handy button. Click the button, and then on the left hover over an element in your app it’ll turn blue. Then click the element and it’ll select it in the elements panel. This functionality is extremely useful when something is buried deep in the DOM
  2. Here you can navigate the DOM and select an element. Once selected the representative element on the left will turn blue and then you can do all sorts of cool things with it.
    1. You can drag/drop it into a different location.
    2. Double-Click an attribute and edit that attribute. Also add and remove attributes.
    3. Add, Remove and Edit the styles in the right side panel.
    4. Also, an extremely useful feature is once an element is selected, you can open the JavaScript console and access the JavaScript properties of the selected element. Just type $0.[propertyName] to see a single property, or just $0 to see all the properties.
  3. The Styles tab is another really useful tool. It allows you to change the style rules of the selected element. If for example you have an element that don’t look quite right and it needs some tweaking. You can fix the display here in the tools and once you get it looking the way you want, just copy/paste the styles into your editor’s stylesheet. If you’ve setup a workspace for your app and did a little configuration (beyond the scope of this article) your changes will even persist in your project, way cool.
  4. This little widget shows the CSS Box Model. You can see the margin, border and padding sizes and also the size of the element. This comes in handy when something is taking up space and you can’t figure out why.
  5. Use the console to execute JavaScript against the selected element. I’ll cover the console more in depth in a moment.
  6. Here you can see the styles that are actually being used for the selected element, however, you can’t edit the values in this panel. Let’s say you’ve applied a width of 10px to an element. However that element is the entire width of the screen. Here you can see what value is applied to the width and it even shows where that width is coming from.
  7. Another handy button, click this button and the display of your app on the left will change to that of a mobile device. Once in that view you can pick from a few different devices or define your own. This is great for checking out the display on the different devices.


Network Tab

This tab also has a lot of useful features. Use this to see the network requests your app is making and the responses you get back from the server. When working with a custom REST api, this tool is invaluable.

  1. Here you can disable your cache so you always see your latest changes during the development process
  2. Filter the requests to only show you requests coming from your app via AJAX/XHR requests. You can also select All, JS, CSS, Img, Media Font, Doc, WS, Manifest, Other. This makes it easier for you to find what you may be looking for. Me personally, I leave mine on “XHR” so I see what my app is requesting.
  3. You can also simulate an offline condition. This is useful if you’re using a service worker to provide offline access
  4. Here we have each network request. If something you need isn’t listed in this view you can right-click the column headers and add a column with what you need. For example, Method isn’t there by default, so I added it. But this shows you the name of the file or the URL of the request, the method used (GET, PUT, POST, etc.), the status of the request and the file which made the request, how big the response was and how long it took the request to complete. You can double-click the request and see the headers, the response and a preview of the response with JSON being “prettified” in the preview.

Console Tab

This tab provides a JavaScript console for experimenting with JavaScript in the context of your application. Any console logging you included in your application will show up here as will any errors and warnings.

  1. Filter the output of the console to certain levels. This is handy if you have a very busy console log
  2. Click this button to clear the content of the console
  3. You can configure the console so that it behaves a certain way. The two I use the most are:
    1. Enable “Preserve log”. This is really handy if you’re in a loop that keeps refreshing the page or a redirection loop or something of that nature. You can include logging in your code and see exactly what is going on and it won’t get cleared every time a redirect/refresh happens.
    2. You can log the XMLHttpRequests to see which order things happen in. If you do this, it’ll provide a link to that request in the network panel
  4. As stated earlier, you can select an element in the Elements tab and the use of “$0” will give you access to that element’s API
  5. You can also just type JavaScript here to come up with a solution just for testing an idea. This is very handy to figure something out or just try an idea.

Sources Tab

This tab provides a LOT of functionality here that is WAY beyond the scope of this article. But just to highlight a few things that I use but there is a lot more. To delve deeper into this tab I recommend to find a tutorial somewhere on YouTube or something.

  1. This lists the files the browser knows about. If the file hasn’t been loaded yet it will not be listed. You can also link this to your local file system and then any changes you make will be persisted to disk which is really handy.
  2. This is the code for the selected file. Again, if you’ve linked this to your local file system, you can make changes to the code here and it will be persisted to disk. Click the line number to add a break point to use the debugger
  3. Here you can see any web/service workers under “Threads”. You can also see the call stack if you’ve placed a breakpoint. A lot of other data is also listed here which is beyond the scope of this article.

Application Tab

This tab contains items for the Application itself. Service Worker(s), manifest.json, local and session storage, cache, etc. This tab is used mostly once an application is ready for production or in a production environment.

  1. This is the menu to see various items. The main things here are the cache, clear storage (removes cached files and images and the application cache)
  2. Here you can interact with the Service Worker for your application if you have one. It allows you to test sending notifications, sync requests, updating,  stopping and unregistering the Service Worker
  3. Visit this area to clear the application cache, local files and images and restart the Service Worker
  4. This shows the application cache. If your manifest.json is properly configured and your application has a Service Worker this allows you to see what is pre-cached when the application is first loaded by the browser and then the other items fetched from the server
  5. The manifest shows you the status of your manifest.json file. It also allows you to test adding the app to your homescreen.


There is a whole lot more out there for troubleshooting web applications so this article barely scratches the surface. If you really want to dig in and understand what your app is doing learn about the Performance tab. Here you can see how much time it takes for certain tasks to run, all the way down to function calls. Me personally, while I’ve tried to learn this I’ve never really had the time to actually sit down and learn about using that tab.

Another tab which I’ve started using is the Audits tab, here is where the LightHouse tool is now built into the browser. This will test about 4 different aspects of your application (Progressive Web App, Performance, Accessibility and Best Practices) and provide a very detailed report. Definitely a tab to spend some time on. Just be aware you may get your feelings hurt on the performance and best practices audits.

So, until next time…. Happy Coding!

Share This:

Leave a Reply

Your email address will not be published. Required fields are marked *