Wann ist es „richtig“, zu `contain` und `will-change` in CSS zu greifen?

Ich habe einige blinde Flecken in Bezug auf CSS-bezogene Performance-Dinge. Ein Beispiel ist die will-change Eigenschaft. Es ist ein guter Name. Sie sagen dem Browser, dass eine bestimmte Eigenschaft (oder die scroll-position oder der Inhalt) äh, *wird*, sich ändern.

.el {
  will-change: opacity;
}
.el.additional-hard-to-know-state {
  opacity: 0;
}

Aber ist das wichtig zu tun? Ich weiß nicht. Der Punkt ist, soweit ich das verstehe, dass es `.el` dazu bringt, auf der GPU statt auf der CPU zu verarbeiten/rendern/malen, was ein Geschwindigkeitsboost ist. So ähnlich wie der klassische `transform: translate3d(0, 0, 0);` Hack. Im exakten Fall oben scheint es meinem Gehirn nicht so vorzukommen, als ob es wichtig wäre. Ich habe im Kopf, dass `opacity` eines der „billigsten“ Dinge zum Animieren ist, daher gibt es keinen besonderen Vorteil bei `will-change`. Oder vielleicht ist es auf *manchen* Browsern oder Geräten spürbar, aber auf anderen nicht? Das ist schließlich Frontend-Entwicklung.

Es gab eine Welle von Artikeln über `will-change` um 2014/2015, die vor seltsamen Verhaltensweisen warnen, wie z. B. unerwartete Änderungen im Stapelkontext und die Vorsicht, es nicht „zu viel“ zu verwenden. Es gab auch Ratschläge, dass man diese Eigenschaft niemals direkt in CSS-Stylesheets verwenden sollte; man sollte sie nur in JavaScript anwenden, bevor sich der Zustand ändert, und sie dann entfernen, wenn man sie nicht mehr benötigt.

Ich habe keine Ahnung, ob das alles noch stimmt. Tut mir leid! Ich würde gerne eine Deep Dive-Analyse von 2022 zu `will-change` lesen. Wir sind in der Lage, solche Tests durchzuführen, also setze ich es auf die Ideenliste. Aber mein Punkt ist, dass es Dinge in CSS gibt, die explizit für die Leistung entwickelt wurden und die für mich verwirrend sind, und ich wünschte, ich hätte ein vollständigeres Verständnis davon, weil sie sehr wichtige Dinge zu sein scheinen.

Nehmen Sie „Wie ich Googles Datengitter mit einer Zeile CSS 10x schneller scrollen ließ“ von Johan Isaksson. Eine 10-fache Verbesserung der Scroll-Leistung ist eine massive Sache! Wissen Sie, wie sie es behoben haben?

[…] als ich die Seite „Top linking sites“ durchsah, bemerkte ich deutliche Scroll-Verzögerungen. Dies tritt auf, wenn Sie sich entscheiden, einen größeren Datensatz (500 Zeilen) anstelle der Standardergebnisse von 10 anzuzeigen.

[…]

Was habe ich also getan? Ich habe einfach eine einzige CSS-Zeile zu der `<table>`-Anweisung im Elements-Panel hinzugefügt und dabei angegeben, dass sie das Layout oder den Stil anderer Elemente auf der Seite nicht beeinflusst.

table {
  contain: strict; 
}

Die Eigenschaft `contain` ist eine weitere, die ich *irgendwie* verstehe, die ich aber immer noch als blinden Fleck bezeichnen würde, weil mein Gehirn nicht automatisch daran denkt, wann ich sie verwenden könnte (oder sollte?). Aber das ist schade, denn offensichtlich baue ich keine Schnittstellen, die so performant sind, wie sie sein könnten, wenn ich `contain` besser verstehen würde.

Da gibt es noch eine! Die Eigenschaft content-visibility. Das, was dem Verständnis am nächsten kam, war, nachdem ich Jake und Surmas Video dazu gesehen hatte, wo sie sie (zusammen mit `contain-intrinsic-size` und einigen seltsamen magischen Zahlen) verwendeten, um eine lange Seite *dramatisch* zu beschleunigen. Was mir nicht im Gedächtnis geblieben ist, ist, wann *ich* sie auf *meinen* Seiten verwenden sollte.

Sind alle drei dieser Funktionen Funktionen, die „da sind, wenn Sie sie brauchen“? Ist es in Ordnung, sie zu ignorieren, bis Sie Leistungsprobleme bei etwas (wie einer riesigen Seite) bemerken, und dann zu ihnen greifen, um zu versuchen, es zu lösen? Fast schon „verwenden Sie diese nicht, bis Sie sie brauchen“, sonst sind Sie im Bereich der vorzeitigen Optimierung. Das Problem dabei ist die klassische Situation, in der Sie die schlechte Leistung nicht bemerken werden, es sei denn, Sie testen aktiv auf den Geräten mit der geringsten Ausstattung.

Oder sind diese Funktionen „das ist, was modernes CSS ist, und Sie sollten sie so betrachten, wie Sie an `padding` denken“? Ich vermute, es ist eher so. Wenn Sie ein Element erstellen, von dem Sie *wissen*, dass es sich in bestimmten Bereichen nicht ändern wird, ist es wahrscheinlich sinnvoll, es zu „containen“. Wenn Sie ein Element erstellen, von dem Sie *wissen*, dass es sich in bestimmten Bereichen ändern wird, ist es wahrscheinlich sinnvoll, Browsern diese Information zur Verfügung zu stellen. Wenn Sie einen Teil einer Seite erstellen, von dem Sie wissen, dass er sich immer unter dem sichtbaren Bereich befindet, ist es wahrscheinlich sinnvoll, das Malen darauf zu vermeiden. Aber persönlich habe ich einfach nicht genug davon verstanden, um konkrete Ratschläge geben zu können.