Once every while, I stumble upon some minor thing ingrained in modern browsers that make some specific problem so much easier. And while the usual Developer Tools offer tons of capabilities, these are so wildly spread and grouped that you easily get used to just ignoring most of them.
So this bunch of things come to my mind that seem not to be super-common knowledge. Maybe you benefit from some of it.
Disclaimer: The browsers I know of have their Dev Tools available via pressing F12 and a somewhat similar layout, even though particular words will differ. My naming here relates to the current Chrome, so your experience might differ.
Disabling the Browser cache
Your Browser caches many resources because the standard user usually prefers speed, is used that the browser endlessly hogs memory anyway, and most resources usually do not change that often anyway.
During development, this might lead to confusion because of course, you do change your sources often (in fact, that is your job), and the browser needs to know that fact.
For that, let it be known:
The "Network Tab" has a Checkbox "Disable Cache".
And the Dev Tools have to be open for it to work.
This is usually so much the default setting on my working machines that I need to remember myself on it when I troubleshoot something on someone else’s machine. Spread the word.
Also, browsers have a Hard-Reload-Feature, like under Chrome, to cleaning the Cache before the reload without having to do so for the whole browser.
Hard-Reload: Ctrl + Shift + R
I’ve read that this is also Chrome’s behaviour when pressing F5 while the Dev Tools are open, but anyway. Take extra care that your customer does not of that feature, because sometimes they might be frustrated about a failed update of your app that is actually just a cached version.
Inspect Network Requests
Depending on the complexity of your web app, or what external dependencies you are importing, it might be that the particular order and content of network requests is not trivial anymore.
Now the “Network” tab (you know it already) is interesting on its own, but remember that it only displays the requests since opening the Dev Tools, i.e. some Page Reload (hard or soft) might be required.
And – this appears somewhat changing between browser updates, don’t ask me why that is necessary – this is good to know:
- The first column of that list shows only the last part of each request URL, but if you click on it, a very helpful window appears with details of the Request Headers, Payload and Response
- make sure that in the filters above, the “Fetch/XHR” is active
- And then some day I found, that
Right-Clicking a request gives you options for Copy, e.g. Copy as fetch, to so you can repeat the exact request from javascript-code for debugging etc.
Inspecting volatile elements
The “Elements” tab (called “Inspector” in other browsers) is quite straightforward to find mistakes in styling or the rendered HTML itself – you see the whole current HTML structure, click your element in there and to the right, from bottom to top you see the CSS rules applied.
But sometimes, it can be hard to inspect elements that change on mouse interaction, and it is good to know that (again, this holds for Chrome), first,
There is a shortcut like Ctrl + Shift + C to get into the Inspector without extra mouse movements
Now think of a popup that vanishes when hovering away. You might do it by using Ctrl + Shift + C to open the Inspector, then using the Keyboard to navigate within (especially with the Tab and Cursor keys), but here’s a small trick I thought of that helped me a lot:
Add (temporarily) an on-click-handler to your popup that calls window.alert(...);
With that, you can open your popup, press Ctrl + Shift + C, then click the popup, and the alert() will now block any events and you can use your mouse to inspect all you want.
In easer cases you could just disable the code that makes the popup go away, but in that case I had, this wasn’t an option either.
Now that I think of it, I could also have used debugger; instead of the alert(), but the point is that you have to block javascript execution only after interacting with the popup element.
The performance API
I have no idea why I discovered that only recently, but if precision in timing is important – e.g. measuring the impact of a possible change on performance, one does not have to resort to Date.now() with its millisecond resolution, but
there is performance.now() to give you microsecond precision for time measurements.
It can afford that by not having the epoch “zero” of Jan 1th 1970 as reference, and instead, the moment of starting your page.
The Performance API has a lot more stuff – which I didn’t need yet.
A FPS Monitor, and a whole world of hidden features
If you do graphics programming or live data visualization of some measurement, it might be of interest to see that. There’s a whole hidden menu at least in Chrome, and you can access it by focussing the Dev Tools, then
- press Ctrl + Shift + P
- Enter “FPS” and select
- Now you have a nice overlay over your page.
Even if you are not in the target group of that specific feature, it might be interesting to know that there is a whole menu of many particular (sometimes experimental) features built into all these browsers. They differ from browser to browser, and version to version, and of course, plugins can do a lot more,
but it might just be worth the idea to think that maybe your work flow can benefit from any of that stuff.
Schneide Blog 