50 kleine Tipps und Tricks zu den Chrome Developer Tools

Achtung: dieser Beitrag ist alt! Es kann gut sein, dass seine Inhalte nicht mehr aktuell sind.

Die Feature-Vielfalt der Developer Tools und die gute Integration in den Browser machen Chrome zur Zeit zur besten Debugging-Umgebung, die man sich als Webentwickler wünschen kann. Das eigentlich Tolle den Devtools sind die vielen kleinen Dinge, die das Leben leichter machen. Es ist sicher total nützlich, dass man JavaScript-Profiling betreiben kann und Performance-Daten exportieren kann, aber für den Alltag sind dann doch weniger die die Super-Nerd-Features und die Brot-und-Butter-Funktionen als die die Kleinigkeiten wichtig. Ich dachte ich schreibe mal alle dieser Kleinigkeiten auf, die mir so einfallen und von denen ich mir gewünscht hätte, dass man sie mir eher verrät. Falls euch eine Funktion oder eine Erweiterung fehlt: ab in die Kommentare damit!

Allgemeines

  1. Cache abschalten: In den Settings (Klick auf das Zahnrad-Icon unten rechts) kann man unter „Disable cache“ den Browser-Cache abschalten. Diese Abschaltung gilt nur, während der Web Inspector auch geöffnet ist.
  2. Zoom: Der Web Inspector ist eine ganz normale HTML-Seite, kann also auch gezoomt werden. Einfach reinklicken und die Tastenkombination für Textvergrößerung/verkleinerung bemühen.
  3. Inspektor inspizieren: Wenn der Inspektor eine normale HTML-Seite ist, können wir ihn auch inspizieren. Einfach einen Web Inspector öffnen, dann in einem anderen Fenster chrome://inspect aufrufen. Unter „Other“ findet ihr den geöffneten Inspector und könnt ihn inspizieren. Vor allem nützlich für Custom Styles …
  4. Custom Styles: Wenn der Inspektor eine normale HTML-Seite ist und wir ihn inspizieren können, können wir für ihn auch eigene Styles verwenden. Der Body des Inspectors hat die ID -webkit-web-inspector, was als Namespace für inspectorspezische Custom Styles genutzt werden kann. Ich persönlich nutze dies um die Schrift größer einzustellen.
  5. Themes: Wenn der Inspektor eine normale HTML-Seite ist und wir ihn inspizieren können und wir für ihn auch eigene Styles verwenden können, können wir auch komplette Themes benutzen. Die erste Anlaufstelle hierfür ist devthemez.com.
  6. Overrides: In den Settings (Zahnrad im Web Inspector unten rechts) gibt es die Overrides mit denen sich diverse Devices simulieren lassen. Diese Simulation macht aber mehr als nur den User Agent String auszutauschen: zum Beispiel wird auch der Viewport des Browsers auf die Maße des Geräts skaliert. Für den ersten Eindruck beim Resposive-Designen sehr praktisch. Ebenso kann man dort Fake-Sensordaten und Fake-Geolocation-Koordinaten wählen.
  7. Print Emulieren: Da wo auch die Overrides sind gibt es die Möglichkeit Chrome einen Media Type unter „Emulate CSS Media“ zu verordnen. So kann man z.B. die Printversion einer Seite gestalten, ohne ständig in die echte Druckansicht wechseln zu müssen. Klappt natürlich auch mit anderen Media Types.
  8. Keyboard Shortcuts: Unterscheiden sich von Betriebssystem zu Betriebssystem, sind aber unter „Shortcuts“ in den Settings einzusehen. Sollte man genau so auf dem Kasten haben wie die Shortcuts in Editor/IDE.

Konsole

  1. Omnipräsente Konsole: Eigentlich braucht es in den Devtools gar kein eigenes Konsolen-Panel, denn in jedem anderen Panel lässt sich am unteren Rand schon eine Konsole einblenden. Das funktioniert entweder mit einem Klick auf den entsprechenden Button (zweiter von links) oder mit einem beherzten Druck auf ESC
  2. Konsole für Frames: Konsolenbefehle lassen sich ganz einfach im Kontext eines (I)Frames ausführen. Unter jeder Konsole gibt es ein Menü, das standardmäßig auf „<top frame>“ steht. Hat man Frames in der Seite, kann man diese hier auswählen – und schon meint ein window in der Konsole das window-Objekt des Frames und nicht mehr das der Elternseite.
  3. Konsolen-Nachrichten behalten: In den Settings lassen sich Nachrichten in der Konsole mit „Preserve log upon navigation“ eine längere Lebensdauer einhauchen, so dass sie erhalten bleiben, wenn man durch die Gegend navigiert.
  4. $(): Wählt in der JavaScript-Konsole ein einzelnes Element anhand eines CSS-Selektors aus. Beispiel: $('body')
  5. $$(): Wählt in der JavaScript-Konsole mehrere Elemente anhand eines CSS-Selektors aus. Beispiel: $$('p.foo')
  6. $0: In der JavaScript-Konsole verfügbare Referenz auf den DOM-Knoten, der gerade im Elements-Panel angewählt ist. Beispiel: console.log($0)
  7. $1, $2, $3, $4: Element-Auswahl-History. $1 ist eine Referenz auf das Element, das vor $0 angewählt war, $2 ist eine Referenz auf das Element, das vor $1 angewählt war und so weiter.
  8. $_: merkt sich das Ergebnis des zuletzt in der Konsole evaluierten Ausdrucks. Tippt man beispielsweise 1 + 2 ein, erhält man nicht nur sofort 3 zurück, sondern dieser Wert ist dann auch für die spätere Verwendung in $_ zu finden.
  9. inspect(): Konsolen-Funktion, die das übergebene Element im Elements-Panel anwählt. Beispiel: inspect($2)
  10. console.dir(): während ein log() eines DOM-Knotens den Inhalt des Knotens anzeigt, zeigt dir() den Knoten als JavaScript-Objekt mitsamt sämtlichen Properties an. Beispiel: console.dir($0)
  11. console.count(): Wenn gezählt und ausgegeben werden soll, wie oft etwas passiert, reicht es, console.count() mit einen String als Identifikator zu füttern; den Rest übernimmt der Browser.
  12. Stringersetzung in console.log(): Es gibt mehrere Platzhalter für Stingersetzung, die in einen String als erstes Argument andere Variablen einbauen. Es gibt %s formatiert eine Ersetzung als String, %d und %i formatieren als Integer, %f als Fließkommazahl, %o als DOM- und %O als JavaScript-Objekt. Beispiel: console.log('Um %f gab es %d Elemente', Date.now(), document.childNodes.length)
  13. CSS in console.log(): Mit dem Platzhalter %c lassen sich CSS-Formatierungen in Konsolen-Output einbauen. Beispiel: console.log('%cRot %cGroß', 'color:red', 'font-size:2em')
  14. console.warn(): Zeigt Warnungen als solche an, d.h. garniert mit dem passendem Icon. Beispiel: console.warn('Vorsicht!')
  15. console.error(): Zeigt Fehler als solche an, d.h. mit dem passendem Icon und Stack Trace. Beispiel: (function foo(){ console.error('Fail'); })()
  16. Multi-console.log(): Die Log-Funktionen können mehre Dinge auf einmal ausgeben, wenn man ihnen einfach mehrere Arguments mitgibt (und die Ersetzungsmöglichkeiten nicht benutzt). Beispiel: console.log('Foo', 42, [])
  17. Gruppierungs-Funktionen: Konsolen-Meldungen aller Art lassen sich in übersichtliche, zusammenklappbare Gruppen zusammenfassen. Einfach mit console.group('Titel der Gruppe') beginnen, dann alles mögliche loggen und die Gruppe mit console.groupEnd() schließen. Gruppen können verschachtelt werden und mit console.groupCollapsed('Titel der Gruppe') lässt sich eine zu Beginn eingeklappte Gruppe eröffnen.
  18. Event-Überwachung: Wer nur wissen möchte, ob ein Event überhaupt stattfindet, braucht dafür keinen Code in irgendwelche Dateien schreiben, denn die Konsole tut es auch. So lässt man sich z.B. jeden Klick auf das Body-Element loggen: monitorEvents(document.body, 'click')
  19. Timing: Die Konsole hat eingebauter Timer-Funktionen. Mit console.time('Foo') startet man einen Timer mit der ID Foo, der sich mit console.timeEnd('Foo') wieder stoppen lässt. Ausgegeben wird dann die Zeit, die für zwischen time() und timeEnd() durchgeführten Operationen verbraucht wurde.

Elemente

  1. Suche: Das Elements-Panel hat seine eigene Suchfunktion, mit der sich schnell das komplette DOM durchforsten lässt. Einfach im Web Inspector mit der entsprechenden Tastenkombination die Suche öffnen und z.B. nach „<div“ suchen. CSS-Selektoren funktionieren in der Suchbox auch: „div div“ findet nur Div-Elemente, die mindestens einen Div-Vorfahren haben. XPath funktioniert auch.
  2. Drag & Drop: Wenn das Layout mal schnell rearrangiert werden soll reicht es schon, in Elements-Panel die Elemente an die richtige Stelle zu ziehen.
  3. Element-Status erzwingen: Im Kontextmenü von Elementen gibt es unter „Force Element State“ die Möglichkeit, Elemente dauerhaft in z.B. den :hover-Status zu versetzen.
  4. Metrics editieren: Die Werte der Metrics-Box können nach einem Doppelklick direkt bearbeitet werden, ohne dass man den Umweg über CSS nehmen muss.
  5. Style-Änderungen speichern: Änderungen an bestehenden Style-Regeln oder Metrics können einfach persistiert werden, denn der Inspector baut die Änderungen automatisch in die entsprechenden Einträge im Sources-Panel ein. Dort kann man nach den Änderungen einfach die betroffene CSS-Datei heraussuchen und speichern.
  6. DOM-Breakpoints: Im Kontextmenü von Elementen gibt es unter „Break on …“ die Möglichkeit, Breakpoints für Modifikationen an diesem Element zu setzen, dass der Debugger anhält, wenn auf diesem Element Attribute oder Kindelemente verändert werden. Diese Breakpoints lassen sich dann in der rechten Leiste unter „DOM-Breakpoints“ wieder entfernen. Zum Test einfach mal einen DOM-Breakpoint für Attributänderungen setzen und in der Konsole $0.classList.add('foo') ausführen

Network

  1. Timeline sortieren: Klar, im Network-Panel kann man die Requests nach ihrer Gesamtzeit oder alphabetisch sortieren. Aber auch die Sortierung nach einzelnen Zeitverbrauchsmerkmalen ist drin! Hierzu einfach auf den Header der „Timeline“-Spalte klicken und dort wahlweise nach Latenz, Dauer oder Start- und Endzeiten der Requests sortieren.

Debugging

  1. debugger-Statement: Ein in JavaScript-Code fest eingebauter Breakpoint. Klappt nicht nur in Chrome, sondern in den meisten Browsern. Beispiel: if(shouldNeverHappen){ debugger; }
  2. Conditional Breakpoints: Ob ein im Browser gesetzter Breakpoint tatsächlich das Programm anhält, kann man vom Ergebnis einer JS-Expression abhängig machen. Einfach einen Breakpoint setzen, Kontextmenü öffnen und „Edit Breakpoint“ auswählen, die Expression der Wahl eintippen und fertig – das Programm wird nur gestoppt, wenn besagte Expression true zurückgibt.
  3. Breakpoint Actions: Man kann in Conditional Breakpoints jede JS-Expression verwenden die man möchte, das Programm stoppt nur, wenn true zurückgegeben wird. Ein console.log() würde mit seinem Rückgabewert undefined das Programm nicht stoppen, aber es würde ausgeführt werden. So kann man console.log()-Aufrufe in Code einbauen, ohne einen Editor zu bemühen! (Quelle)
  4. Pretty Print: Wenn ihr im Sources-Panel ein mini­fiziertes Stück JavaScript-Code aufruft, kann es der Web Inspector de­obfukskieren. Dazu einfach den Button mit den Schweif­klammern unten links bemühen.
  5. Break on Exception: Der Pause-Button direkt neben Pretty Print veranlasst den Browser, die Webseite im Falle einer unbehandelten Exception einzufrieren, so dass man leicht nachvollziehen kann, was gerade schief gelaufen ist.
  6. Error.stack: Error-Objekte haben in JavaScript eine Eigenschaft namens stack, die man direkt nutzen kann um Stack Traces als Plaintext einzusammeln. Diese kann man dann anzuzeigen oder loggen. Beispiel: try { existiertNicht(); } catch(err) { console.log(err.stack); }
  7. Watch Expressions: Öfter dabei ertappt, die immer gleichen Befehle in die Konsole zu scheiben? Welchen Wert hat x jetzt, welchen Wert hat x jetzt? Das geht auch einfacher: Im Sources-Panel können unter „Watch Expressions“ mehrere Ausdrücke zur Überwachung hinterlegt werden. Diese dann alle auf einmal nach einiger Zeit oder einem Reload zu aktualisieren ist dann nur noch die Sache eines Klicks auf den Refresh-Buttons.
  8. Breakpoints für XHRs und Events: Im Sources-Panel gibt es auch die Möglichkeit Breakpoints für XHRs (entweder alle Requests oder nur Requests an bestimmte URls) und Events einzurichten. Hierzu einfach die jeweiligen Panels unter der Debugger-Steuerung bemühen.

Coding

  1. Deus Ex HTML: Ihr braucht mal schnell eine HTML-Seite um etwas zu testen? Einfach einen neuen Tab öffnen und data:text/html,<!doctype html> in die Adresszeile schreiben.
  2. Hot Swapping: Im Browser durchgeführte Änderungen an einer JavaScript-Datei greifen sofort und ohne speichern und neuladen der Seite. Einfach im Sources-Panel die Datei öffnen, etwas ändern und die Änderungen anwenden (Speichern-Hotkey). Zum Testen einfach mal auf dieser Seite die Funktion foo verändern!
  3. Snippets: Falls ihr öfter mal das gleiche JavaScript in den Devtools abfahren möchtet, könnt ihr im Browser entsprechende Snippets vorrätig halten. Diese lassen sich im Snippets-Tab unter Sources wie jeder andere Codeschnipsel direkt anlegen und bearbeiten.
  4. Diffs: An den Sources rumgebastelt aber keine Ahnung mehr alles genau verändert wurde? Kein Problem: Im Kontextmenü des Texteditors gibt es den Punkt „Local Modifications“, über den sich ein schönes Diff abrufen lässt.

Erweiterungen und Libraries

  1. LiveReload: Ich hoffe einfach mal, dass dass schon von euch allen benutzt wird. Wenn nicht: ihr macht was falsch.
  2. CoffeeConsole: Eine kleine CS-Konsole direkt im Web Inspector
  3. Log: Einfaches formatiertes Consolen-Logging via JS-Library. Unterstützt (ein wenig) Markdown!
  4. Tincr Vereinfacht das In-Browser-Editing mit einer praktischen Autosave-Funktion. In dem Moment, in dem ihr in Chrome etwas ändert, wird die betroffene Ressource automatisch gespeichert.

Kommentare (5)

  1. ben_

    20. Juni 2013, 15:53 Uhr

    "Die Feature-Vielfalt der Developer Tools und die gute Integration in den Browser machen Chrome zur Zeit zur besten Debugging-Umgebung, die man sich als Webentwickler wünschen kann."

    Wenn man außen vor läßt, dass das NSA-Prism-Plugin vom Hersteller gleich mitgeliefert wird und nicht deinstallierbar ist, schon … ;]

  2. Peter Kröner

    20. Juni 2013, 15:56 Uhr

    Regierungsorganisationen haben doch immer die älteste IT. Warum selbst IE-Tests machen, wenn man es auch der Stasi überlassen kann?

  3. Andy

    21. Juni 2013, 00:18 Uhr

    Supercoole Liste, hab einiges neues entdeckt!

    Was allerdings bei mir nie geklappt hat, ist das man Änderungen im CSS irgendwie speichern kann. Ich muss die immer noch rauskopieren und in meinem Editor einfügen zum speichern. Direkt über Chrome gehts nicht. Was mach ich falsch?

  4. Peter Kröner

    24. Juni 2013, 09:25 Uhr

    Weiß nicht? Vielleicht geht aus irgendeinem Grund der Hotkey nicht und die musst es über „Save as“ im Kontextmenü (im Sources-Editor) versuchen?

  5. Hans Christian Reinl

    4. Juli 2013, 13:40 Uhr

    Man macht meiner Meinung nach nicht unbedingt etwas falsch, wenn man LiveReload nicht nutzt.

    Zum einen kann man sich einen Refresh sparen, wenn man am programmieren eines größeren Features ist, bei dem man nur sicher gehen will, dass die Änderungen nicht verloren gehen. Zum anderen möchte man eventuell Bandbreite sparen – gerade wenn man in Osnabrück – auf dem Land – wohnt, kann dies wichtig sein.
    Ein weiterer Grund kann sein, dass man gegen einen entfernten Development-Server arbeitet (also nicht die eigene Maschine), auf den die Änderungen erst geladen werden müssen, bevor man den aktuellen Stand checken kann.

    Im Allgemeinen finde ich persönlich es nervig, wenn der Browser ohne mich zu Fragen die Seite refresht. Deshalb habe ich mich in der Entwicklung gegen LiveReload entschieden.
    Es mag jedoch genügend Punkte geben, die dafür sprechen.

Die Kommentarfunktion ist seit Juli 2014 deaktiviert, weil sie zu sehr von Suchmaschinenoptimierern für manuellen Spam mißbraucht wurde. Wenn du Anmerkungen oder Fragen zum Artikel hast, schreib mir eine E-Mail oder melde dich via Twitter.

Folgt mir!

Kauft mein Zeug!

Cover der HTML5-DVD
Infos auf html5-dvd.de, kaufen bei Amazon

Cover des HTML5-Buchs
Infos auf html5-buch.de, kaufen bei Amazon

Cover des CSS3-Buchs
Infos auf css3-buch.de, kaufen bei Amazon