Google Core Web Vitals

Soll eine Webseite in Googles Suchmaschinenranking gut abschneiden, muss sie auch eine gute Performance aufweisen. Um die Webperformance zu messen, führte Google 2020 einen Maßstab ein: die Core Web Vitals. Wie wichtig diese einmal sein würden, verriet Google bei seiner ersten Vorstellung jedoch nicht. Der Einfluss auf den Rankingfaktor war zunächst auf die mobilen Suchergebnisse beschränkt. Seit Februar 2022 wendet Google sie auch auf Suchergebnisse am Desktop an.

Core Web Vitals Definition: Was ist das?

Die Core Web Vitals sind eine von Google definierte Sammlung von Metriken der Webperformance. Sie umfassen die Metriken Largest Contentful Paint (LCP), First Input Delay (FID) und Cumulative Layout Shift (CLS). Der Largest Contentful Paint bezeichnet die Zeit vom Beginn des Ladens der Seite bis zum Anzeigen des größten Inhaltselements im Viewport. Der First Input Delay gibt an, wie schnell eine Website auf User-Aktionen reagiert. Ein Maß für das Verschieben von Elementen während des Seitenaufbaus und beim Scrollen ist der Cumulative Layout Shift.

Wie der Test funktioniert

Erzielt eine Website in allen drei Bereichen schnelle Zeiten im normalen Betrieb oder bei synthetischen Tests, ist der Core-Web-Vitals-Test bestanden. Eine Ausnahme gibt es von dieser Regel: Liegen für FID nicht genügend Daten vor, LCP und CLS wurden aber bestanden, dann gilt der Core-Web-Vitals-Test auch als bestanden. Zu finden sind die Core Web Vitals in Googles PageSpeed Insights, Search Console und dem Chrome User Experience (CrUX) Dashboard. Die Daten lassen sich auch automatisiert für eine URL über die PageSpeed Insights-API oder die CrUX-API abfragen. Die Daten werden täglich gegen 4:00 UTC aktualisiert.

Die zugrunde gelegten Daten stammen aus dem CrUX-Report, der aus Google BigQuery kommt. Das bezieht die Performancedaten aus echten User-Sessions im Chrome-Browser. Die Core Web Vitals geben also ausschließlich die Performance der Website im Chrome-Browser an. Gut daran ist, dass es sich hierbei um echte User-Erfahrungen handelt.

Auf diese Weise erhaltene Daten nennt Google RUM Data (Real User Monitoring/ Measurements) oder Felddaten. Google zeigt sie erst an, wenn sie in statistisch signifikanter Menge vorliegen. Es kann also sein, dass es für eine URL keine RUM-Daten gibt. Als Fallback müssen dann Daten über Aufrufe der gesamten Domain, die Origin Summary, herhalten. Liegen auch hierfür nicht ausreichend Daten vor, wird nichts ausgegeben.

Einfach auswerten per Ampelfarben

Google teilt in den Core Web Vitals die Metriken in „Good“, „Needs Improvement“ und „Poor“ ein. Für die drei Metriken sind das zum gegenwärtigen Zeit- punkt die folgenden Schwellenwerte, ausschlaggebend ist das 75. Perzentil: Für LCP gilt ein Wert bis 2,5 Sekunden als gut, zwischen 2,5 und 4 Sekunden als durchschnittlich und alles über 4 Sekunden als schlecht. Der FID geht bis 100 ms als gut durch, bis 300 ms als durch- schnittlich. Ein Wert über 300 ms wird als schlechte Nutzererfahrung gewertet. Beim CLS wird ein Wert bis 0,1 als gut verstanden, bis 0,25 als durchschnittlich und darüber dann als schlecht.

LCP: Largest Contentful Paint

Der Largest Contentful Paint bezeichnet die Zeit vom Beginn des Ladens der Seite bis zum Anzeigen des größten Inhaltselements im Viewport. Das ist häufig ein Bild, kann aber auch Text sein. Bei Bil- dern werden <img>, <svg> mit <image> und bei <video> das Poster-Image (<video poster="url">) berücksichtigt. Via CSS muss ein Bild mit url() geladen werden, um für den LCP infrage zu kommen. Bei skalierten Bildern greift der kleinere Wert: Ein hochskaliertes Bild zählt nur mit seiner ursprünglichen Größe, ein herunterskaliertes Bild zählt mit seiner skalierten Größe.

Während des Ladens einer Seite kann es mehrere LCP Candidates geben, beispielsweise weil ein Bild erst nach dem Text gerendert wird. Dann ist der erste LCP Candidate der Textblock, und sobald der Browser das größere Element anzeigt, ist das Bild der nächste LCP Candidate. Für den Wert der Metrik zählt am Ende der letzte gemeldete LCP Candidate. Da- bei kann auch ein Element als LCP gelten, das im Verlauf des Seitenaufbaus wieder aus dem First-View verschwindet oder sogar ganz aus dem DOM entfernt wurde. Wenn nicht noch ein größeres Element auftaucht, bleibt das zuletzt gemeldete Element als LCP bestehen.

FID: First Input Delay

UPDATE (12.07.2023): Markiert als DEPRECATED für 03/2024 (Neuer Messwert: INP).

Der First Input Delay hilft festzustellen, wie schnell eine Website auf User-Aktionen reagiert. Dazu zählen Klicks, Taps und Tastendrücke, nicht aber Scrollen oder Zoomen. FID bemisst dabei nicht die Zeit bis zur Reaktion der Website auf eine Aktion des Users, sondern nur die vom Auslösen des Events bis zur nächsten Idle Time des Main Thread. Also bis zu dem Zeitpunkt, an dem der Main Thread Luft hat, auf das Event zu reagieren. FID berücksichtigt nicht, wie lange der Browser für die Reaktion auf das Event braucht oder wie lange es dauert, anschließend einen Re-Paint der Seite auszuführen.

FID ist eine Metrik, die sich nur in RUM Data findet, weil eine Aktion des Nutzers nötig ist. Webentwickler achten alternativ auf die Metrik Total Blocking Time (TBT). Das Verbessern der TBT sollte einen positiven Einfluss auf den FID-Wert haben (siehe Kasten „Exkurs: Total Blocking Time“).

CLS: Cumulative Layout Shift

Der Cumulative Layout Shift beschreibt das Verschieben von Elementen im View- port. Gemessen wird über die gesamte Session, also auch, wenn ein User über die Seite scrollt. Der CLS bewertet unerwartete Layout-Shifts. Interagiert ein User daher mit der Seite, woraufhin der Inhalt verschoben wird, zählt diese Verschiebung nicht zum CLS-Wert. Eine Verschiebung auf der Seite und eine Aktion des Users müssen innerhalb von 500 ms passieren, damit sie als zusammengehörig interpretiert werden.

Ein Layout-Shift wird aus zwei Faktoren berechnet: Impact und Distance. Impact beschreibt den Anteil des Viewports, der sich verändert. Angenommen, auf einer Seite ist ein Text, der die Hälfte des Viewports einnimmt. Kommt nun am An- fang der Seite nachträglich ein Element hinzu, das eine Höhe von 25 Prozent des Viewports hat, verändern sich dadurch 75 Prozent des Viewports. Der Impact- Faktor beträgt 0,75. Distance hingegen bezeichnet die Strecke, um die sich der In- halt verschiebt. Beim Beispiel von eben ist der Distance-Faktor 0,25, da der Text um 25 Prozent verschoben wurde. Insgesamt ergibt sich durch diesen Layout-Shift ein Beitrag von 0,75 × 0,25 = 0,1875 zum CLS- Wert des aktuellen Zeitfensters.

Ein Layout-Shift ist noch nicht der CLS-Wert. Diesen misst man über die ge- samte Session mit einer URL. Als Session zählt die Zeit vom Aufruf einer URL bis zu ihrem Verlassen. Wie die einzelnen Layout-Shifts zum finalen CLS-Wert führen, ist seit Frühjahr 2021 anders. Die alte CLS-Berechnung hat alle einzelnen Layout-Shifts einfach addiert. Das hatte Nachteile für besonders „langlebige“ Seiten, allen voran Single-Page Applications (SPAs).

Die neue CLS-Berechnung hingegen addiert Layout-Shifts in bestimmten Zeitfenstern. Ein solches Zeitfenster startet mit einem Layout-Shift und zeichnet weitere Layout-Shifts auf, bis entweder eine Sekunde kein Layout- Shift mehr stattgefunden hat oder der Zeitraum fünf Sekunden lang ist. Der CLS-Wert am Ende der Session ist dann der höchste CLS-Wert eines einzelnen Zeitfensters – eine Seite addiert also nicht mehr alle Layout-Shifts bis zum Verlassen auf. Diese Änderung der CLS- Berechnung hat fast einheitlich am ersten Juni 2021 in alle Tools von Google Einzug gehalten, die den CLS-Wert aus- geben und teils auch selbst messen.

INP: Interaction to Next Paint

Im März 2024 wird Google einen neuen Messwert einführen, der den bisherigen First Input Delay (FID) ersetzt: den Interaction to Next Paint (INP) Wert.

Der INP Wert misst die Zeit zwischen der ersten Interaktion des Nutzers mit der Seite (z.B. ein Klick oder eine Eingabe) und dem nächsten sichtbaren Update der Seite (z.B. eine Änderung der Farbe oder des Inhalts). Der INP Wert soll besser erfassen, wie flüssig und angenehm die Interaktion mit einer Seite ist. Je niedriger der INP Wert, desto besser.

Um einen guten INP Wert zu erreichen, sollten Webseitenbetreiber darauf achten, dass ihre Seite schnell lädt, keine Layoutverschiebungen hat und auf Nutzereingaben zügig reagiert. Dazu können sie verschiedene Optimierungsmaßnahmen ergreifen, wie z.B.:

• Das Laden von JavaScript und CSS Ressourcen verzögern oder minimieren
• Das Rendern von Inhalten priorisieren, die für den Nutzer sichtbar sind
• Das Verwenden von Web Workers oder Service Workers, um rechenintensive Aufgaben im Hintergrund auszuführen
• Das Implementieren von Caching-Strategien, um die Ladezeit zu reduzieren
• Das Nutzen von Performance-Tools wie Lighthouse oder PageSpeed Insights, um den INP Wert zu messen und zu verbessern

Der INP Wert ist ein wichtiger Schritt in Richtung einer besseren Nutzererfahrung im Web. Er wird ab März 2024 Teil des Google-Rankings sein und somit auch die Sichtbarkeit und den Erfolg von Webseiten beeinflussen. Daher ist es ratsam, sich frühzeitig mit dem Thema zu beschäftigen und die eigene Seite zu optimieren.

Analysieren und optimieren

Einen ersten Überblick verschafft PageSpeed Insights. Das Tool zeigt für die angegebene URL RUM Data an und führt auf Google-Servern einen Test mit Lighthouse aus (Lab Data). Anschließend präsentiert eine Seite die Mobil- und Desktop-Ergebnisse. Der untere Bereich des Lighthouse-Tests der Seite mit den Resultaten enthält einen Abschnitt „Empfehlungen“. Web-Devs sollten diese zwar nicht blindlings befolgen, oft haben sie aber ihre Berechtigung und geben gute erste Hinweise, wo etwas im Argen liegt.

Während der Entwicklung lassen sich Erfolge mit Lighthouse überprüfen – am besten mit der Standalone-CLI-Variante. Zwar existiert Lighthouse auch in den Developer-Tools des Browsers, doch die Version kann sich mit einem Browser-Update ändern, was die Vergleichbarkeit der Testergebnisse beeinträchtigen könnte.

Webfonts und LCP

Beim LCP ist von Bedeutung, in welcher Form er vorliegt. Häufig handelt es sich dabei um Text oder ein Bild. Bei Text kann ein hoher LCP-Wert am Einsatz von Webfonts und der Verkettung von Ressourcen liegen. Wenn der Browser das HTML-Dokument lädt, darin erfährt, dass es eine CSS-Datei gibt, und erst wenn diese geladen ist, herausfindet, dass Schriften mit einem bestimmten Webfont gerendert werden sollen, und dann erst anfangen kann, den Webfont zu laden, merken Leser schon an der Länge dieses Satzes, dass das nicht so schnell geht. Wenn der Verzicht auf Webfonts keine Option ist, sollten Entwickler dem Browser mittels Preload-Hint bereits im <head> des HTML mitteilen, dass ein Webfont geladen werden muss:

See the Pen
Preload Web Font from CDN by Daniel Kussin (@wmdkdkussin)
on CodePen.

Außerdem ist die Strategie beim Font-Loading entscheidend für die User Experience. Beim Definieren des Webfonts sind folgende Werte für Font-Display möglich:

• auto (Standard): Der Browser entscheidet selbst.
• block: Der Browser wartet, bis die Webfont geladen wurde, und zeigt bis dahin keinen Text an. Dieser wird aber mit einer unsichtbaren Schrift gerendert und nimmt bereits Platz im Layout ein.
• Aufrufen der eigenen Seite mit Googles swap: Der Text wird kurze Zeit (~100 ms) nicht angezeigt, falls der Webfont noch nicht bereitsteht. Danach gibt der Browser ihn mit einer verfügbaren Fallback- Schrift aus. Sobald jedoch der Webfont geladen ist, wird der Text erneut damit gerendert.
• fallback: Der Text wird kurze Zeit (~100 ms) nicht angezeigt, falls der Webfont noch nicht bereitsteht. Ist dieser auch danach nicht verfügbar, zeigt der Browser den Text in einer Fallback- Schrift an. Kann der Webfont in wenigen Sekunden (~3 s) geladen werden, wechselt der Browser die Darstellung erneut, ansonsten bleibt es bei der Fallback-Schrift.
• optional: Der Text wird kurze Zeit (~100 ms) nicht angezeigt, falls der Webfont noch nicht bereitsteht. Ist er auch danach nicht verfügbar, rendert der Browser den Text mit einer Fallback-Schrift.

Aus Performanceperspektive ist optional der beste Fall, da der Browser hier am schnellsten Text darstellt und er anschließend konstant bleibt. Betrachten Web-Devs den eigenen Webfont jedoch als optional, müssen sie sich fragen, ob er nicht gleich ganz verzichtbar ist. Es gibt aber auch legitime Szenarien. Landen User zunächst bei einem Consent-Overlay, ist der Webfont vielleicht nicht wichtig, der Browser lädt ihn in Ruhe im Hintergrund. Beim nächsten Seitenaufruf ist der Webfont bereits im Cache und wird sofort gerendert.

Ansonsten bieten sich fallback oder swap an, wenn der Webfont notfalls verzichtbar ist. Auch sollte beachtet werden, dass ein Webfont eine andere Laufweite als die Fallback-Schrift haben kann. Sind User bereits am Lesen der Inhalte, wenn der Webfont endlich geladen ist, kann es passieren, dass sie die aktuelle Textpassage erneut suchen müssen. Für block braucht es einen sehr guten Grund. So- wohl aus Sicht der Webperformance als auch für die User Experience ist diese Strategie die schlechteste, da bis zum Laden des Webfonts kein Text gelesen werden kann. Tut sich dabei ein Problem auf, kann das auch „nie“ bedeuten.

LCP als Bild

Im Falle eines Bildes gibt es mehrere Ursachen für einen erhöhten LCP-Wert, etwa die schiere Bildgröße: Wurde eventuell ein Format ohne gute Kompression verwendet? Ist das Bild zu groß in die Seite eingebunden und lediglich per CSS herunterskaliert? Am besten prüfen Webentwicklerinnen die ausgelieferte Bilddatei, das Dateiformat und die Kompression. Liefern sie beispielsweise am Smartphone auf einer Fläche von 400 × 300 Pixeln eine Grafik aus, die 2000 × 1500 Pixel groß ist und als PNG mehrere Hundert Kilobyte mitbringt, haben Entwickler hier bereits eine große Stellschraube gefunden. JPEG oder WebP bieten weitaus bessere Kompression. Und dank des Tags <picture> oder des Attributs srcset im <img>-Tag lassen sich gezielt passende Bilder für die jeweiligen Endgeräte, Pixeldichten und Auflösungen ausgeben.

See the Pen
Ein `<picture>`-Tag bietet dem Browser verschiedene Bildgrößen an by Daniel Kussin (@wmdkdkussin)
on CodePen.

Beispielsweise bietet ein <picture>-Tag dem Browser ein Bild in verschiedenen Größen für unterschiedliche Breakpoints an und innerhalb jedes Breakpoints noch eine Variante für Displays mit einer Device Pixel Ratio (DPR) von 2. Das folgende Beispiel bietet ein und dasselbe Bild in verschiedenen Formaten an, wobei die moderneren bei kleinerer Dateigröße dieselbe Qualität bieten können. Da der Browser das erste Format nimmt, das er kennt, muss die Reihenfolge vom modernsten zum ältesten gehen. Entwickler können für ein responsives Bild das <img>-Tag mit srcset- und sizes-Attributen verwenden und dem Browser sogar einen responsiven Preload-Hint mitgeben. Safari unterstützt das bisher leider noch nicht.

See the Pen
Untitled by Daniel Kussin (@wmdkdkussin)
on CodePen.

Wird das LCP-Bild hingegen mit CSS als background-image: url() geladen, erfährt der Browser erst sehr spät von der Existenz eines Bildes und fängt daher erst spät an es zu laden. Das ist ähnlich wie bei den Webfonts. Auch hier hilft ein Preload-Hint.

See the Pen
Preload Image from CDN by Daniel Kussin (@wmdkdkussin)
on CodePen.

Allerdings sind Preload-Hints nur in geringem Umfang empfehlenswert. Ein Preload-Hint gibt einer bestimmten Ressource sehr hohe Priorität und verhindert, dass der Browser in der Zwischenzeit etwas anderes lädt. Daher sollten Webentwickler in Erwägung ziehen, den Code auf ein Bild-Tag im HTML umzuziehen.

See the Pen
Beispiel eines responsiven Preload-Hints für ein Bild by Daniel Kussin (@wmdkdkussin)
on CodePen.

Bildformate und Bildgrößen im Vergleich

Alle Dateien wurde mit Adobe Photoshop und mit der Funktion „Für Web speichern“ erstellt.

CLS verbessern

Häufig sind Layout-Shifts nur ein Symptom anderer Performancedefizite und Webentwicklerinnen können mit einer Optimierung gleich mehrere Metriken verbessern. Zum Beispiel Webfonts. Hat der Webfont eine andere Laufweite als die Fallback-Schrift, verursacht das erneute Rendern des Textes mit dem Webfont einen Layout-Shift. Verbessern Entwickler das Laden des Webfonts für den LCP, ist womöglich auch der Layout-Shift durch den Webfont behoben.

Viele Layout-Shifts lassen sich durch das Einhalten einfacher Regeln umgehen: Bilder und iFrames sollten Größenangaben mit width und height bekommen. Bei Elementen mit variabler Größe, etwa unterschiedlichen Werbeformaten, hilft ein Container, der den am häufigsten benötigten Platz frei hält. Ist von einem Element nur das Seitenverhältnis und nicht die Größe bekannt, hinterlegt man eine aspect-ratio-Angabe mit CSS. Es sollte möglichst nichts nachträglich per JavaScript ins DOM eingefügt wer- den, das Elemente im Viewport verschiebt. Generell sollten Entwickler die Größe von Elementen nicht nachträglich mit JavaScript verändern.

In den Developer-Tools des Browsers lässt sich die Netzwerkgeschwindigkeit künstlich drosseln. Ein Blick auf den Aufbau einer Seite mit einer 3G-Verbindung zeigt, wo sich Elemente verschieben. Das ist ein gutes, einfaches Mittel, um potenziellen Layout-Shifts auf die

Spur zu kommen. Alternativ kann man  in den Chrome Developer-Tools via Strg + Shift + P unter „Layout Shift Regions“ auch das Anzeigen von Layout- Shifts einschalten.

FID: Die häufigste Ursache ist zu viel JavaScript

Die häufigste Ursache für einen schlechten FID-Wert ist JavaScript – viel JavaScript. „Long Running Tasks“ mit über 50 ms Dauer sind der Feind schnell reagierender User-Interfaces. Der „Performance“-Tab der Developer-Tools des Chrome-Browsers protokolliert den Aufbau der Seite. Long Running Tasks sind an einem roten Fähnchen am Task erkennbar.

Webentwickler verzweifeln bei der Analyse einer Seite, die zehn JavaScripts von verschiedenen Domains lädt. Die Suche ist daher einzugrenzen. Am besten blockieren Entwicklerinnen temporär JavaScript von Third-Party-Domains, auf das sie keinen Einfluss haben, und konzentrieren sich auf ihr eigenes JavaScript. Minifiziertes und obfuskiertes JavaScript erschwert die Analyse ebenfalls. Entwickelt man JavaScript isoliert für einzelne Komponenten, lässt sich dabei bereits auf lange Skriptlaufzeiten achten und jede Komponente für sich optimieren. Lange, einzelne Tasks lassen sich in kleinere, asynchrone Aufgaben aufteilen, sodass der Browser Reaktionen auf User-Aktion zwischenschieben könnte.

Außerdem ist das Differenzieren zwischen kritischem und unkritischem JavaScript wichtig. Es ist völlig unnötig, mit JavaScript eine Bildergalerie im unteren Bereich der Seite aufzubauen und gar Bilder zu laden, die der User im ersten Viewport noch gar nicht sieht. Stattdessen lässt sich ein Intersection Observer einrichten, der beispielsweise eine Bildschirmseite vor dem Erreichen der Bildergalerie anspringt und das JavaScript erst anstößt, wenn es wahrscheinlich ist, dass ein User tatsächlich die Bildergalerie sieht.

Web-Devs können im <script>-Tag im <head> auch die Attribute async und defer verwenden, um den Aufbau der Seite nicht durch JavaScript blockieren zu lassen. Mit async lädt der Browser das JavaScript und führt es aus, wann es passt. async sollte nicht genutzt werden, wenn das JavaScript auf bestimmte DOM-Elemente angewiesen ist oder auf das Vorhandensein anderer JavaScript- Dateien aufbaut. Bei defer lädt der Browser das JavaScript ebenfalls, wann es passt. Die Ausführung findet jedoch erst nach dem Parsen des Dokuments statt und vor dem DOMContentLoaded- Event. Die Reihenfolge von Skripten wird eingehalten.

Wissen Developer sicher, dass innerhalb von maximal zehn Sekunden eine Verbindung zu einer Dritt-Domain benötigt wird, zum Beispiel der Abruf einer Datei von einem CDN durch das JavaScript, können sie den Browser die Verbindung mit einem Tag im <head> bereits aufbauen lassen:

See the Pen
DNS-Preconnect zu einem CDN by Daniel Kussin (@wmdkdkussin)
on CodePen.

Soll lediglich die DNS-Abfrage vorab erfolgen, hilft ein DNS-Prefetch, wobei Firefox leider bisher kein HTTPS unterstützt:

See the Pen
DNS-Prefetch zum einem CDN by Daniel Kussin (@wmdkdkussin)
on CodePen.

Das Ausgliedern in Web Worker ist interessant, wenn signifikante Teile in JavaScript nicht mit dem DOM interagieren. Die laufen dann nicht auf dem Main Thread.

Fazit

Zum Schluss noch ein paar generelle Tipps zur Performanceoptimierung: Es ist darauf zu achten, dass der Server Dateien komprimiert überträgt, etwa mit gzip, und sinnvolle Cachezeiten angegeben werden. Wo es sinnvoll ist, sollten Entwicklerinnen Dateien wie Webfonts selbst hosten, um dem Browser zusätzliche Verbindungen mit DNS-Abfrage und TLS-Handshake zu ersparen. Ressourcen sind regelmäßig zu überprüfen: Wurde diese eine Komponente eventuell schon längst im CMS gelöscht, das CSS und JavaScript wird aber immer noch ausgeliefert? Insbesondere Third-Party-JavaScript ist immer mal wieder infrage zu stellen. Eventuell ist es gar nicht mehr in Verwendung. Prinzipiell gilt: Je weniger unnötige Dinge dem Browser vor die Füße geworfen werden, umso besser kann er sich um die nötigen Dinge kümmern.

Bevor Entwickler Optimierungen livestellen: messen! Ist nach der Optimierung keine Verbesserung messbar, sollte der Code nicht ausgespielt werden. Optimierungen sind eine nach der anderen vorzunehmen und nicht zehn auf einmal. Dabei hilft das Speichern und Visualisieren der gemessenen Daten, um negative Trends frühzeitig erkennen zu können. Für Lighthouse-Tests sollte man eine stabile Umgebung schaffen, sodass Testergebnisse vergleichbar sind. Nach dem Deployment sind die RUM-Daten der nächsten Wochen im Auge zu behalten. Denn letztlich geht es darum, die Seite bei den echten Nutzerinnen und Nutzern des Angebots schnell zu machen.

Quellen & Hilfreiche Links

1. Core Web Vitals für gesunde Webseiten von Hilko Holweg (weiterführende Listings)
2. Site Speed Monitor von DebugBear