Optimierung von Bildern in Astro

Die Bildoptimierung in Astro ist die Sammlung von Werkzeugen und Entscheidungen, die Ihnen helfen, das richtige Bild in der richtigen Größe und im richtigen Format bereitzustellen, ohne unnötige Bytes zu versenden. In der Praxis bedeutet dies, Astros Bildpipeline zu verwenden, anstatt sich auf rohe <img>-Tags für jedes Asset zu verlassen, insbesondere wenn die Seite Produktfotografie, Heldenbanner oder Inhaltsbilder enthält, die die Ladezeit und die Stabilität des Layouts beeinflussen.

Für eine Händlerseite kann das den Unterschied zwischen einer Homepage ausmachen, die auf Mobilgeräten klar und schnell geladen wird, und einer, die beim ersten Laden stockt. Für einen Entwickler ist es der Unterschied zwischen dem manuellen Anpassen von Assets für jeden Breakpoint und dem Zulassen, dass Astro die Transformationsarbeit während des Builds übernimmt.

Wichtigste Erkenntnisse

• Astro kann lokale und autorisierte Remote-Bilder während des Builds verarbeiten, was manuelle Resize-Arbeiten reduziert.
• Bilder in src/ sind die beste Wahl, wenn Sie eine Optimierung wünschen; public/ ist für Dateien, die unverändert versendet werden sollten.
• Das Beibehalten von Astros Bild-Cache zwischen Builds kann die wiederholte Verarbeitung reduzieren und Bandbreite sparen.
• <Image /> ist die Standardwahl für die meisten optimierten Bilder; <Picture /> bietet mehr Kontrolle über Formate und responsive Quellen.
• Rohe HTML-Bild-Tags funktionieren weiterhin, aber sie bieten nicht die Optimierungspipeline von Astro.

Was ist das?

Die Bildoptimierung in Astro ist der Prozess, ein Bild-Asset aufzubereiten, um eine effiziente Bereitstellung im Web zu gewährleisten. Das bedeutet normalerweise, es auf die tatsächlichen Dimensionen, die das Layout benötigt, zu verkleinern, responsive Varianten für verschiedene Bildschirme zu generieren und Astros integrierte Komponenten oder Bildhelfer zu verwenden, sodass der Browser keine größere Datei herunterlädt als nötig.

Der wichtige Punkt ist, dass Astro nicht alle Bilder gleich behandelt. Ein lokales Bild, das in src/ gespeichert ist, kann importiert und transformiert werden. Ein Remote-Bild aus einer autorisierten Quelle kann ebenfalls verarbeitet werden. Eine Datei in public/ wird unverändert bereitgestellt, was nützlich ist, wenn Sie direkten Zugriff wünschen, jedoch die Optimierung aufgegeben wird.

Ein konkretes Beispiel: Stellen Sie sich eine Produktseite mit einem 2400px breiten Heldenbild vor. Wenn das Layout dieses Bild nur mit 1200px auf dem Desktop und viel kleiner auf Mobilgeräten anzeigt, ist es verschwenderisch, die Originaldatei überall bereitzustellen. Astro kann eine besser passende Version für jeden Kontext generieren, sodass der Browser ein passenderes Asset erhält, anstatt einer Einheitsgröße.

Das ist wichtig, weil das Gewicht von Bildern oft den Seiteninhalt dominiert. Eine Seite kann technisch gut strukturiert sein und dennoch langsam wirken, wenn die visuellen Elemente überdimensioniert sind. Die Bildoptimierung in Astro dreht sich nicht nur um Kompression; es geht darum, die Bereitstellung von Assets an das tatsächliche Design und die Geräteeigenschaften anzupassen.

Es verändert auch die Denkweise der Teams über den Inhalt. Wenn ein Bild Teil des Projektquellcodes ist, kann Astro an der Bereitstellungsstrategie teilnehmen. Wenn ein Bild nur eine statische Datei in public/ ist, zieht sich Astro zurück. Diese Unterscheidung ist nützlich, weil sie es Teams ermöglicht zu entscheiden, welche Assets eine Transformation verdienen und welche einfach, direkt und vorhersehbar bleiben sollten.

Ein hilfreiches mentales Modell ist, die Bildoptimierung als eine Routingentscheidung zu betrachten. Die Datei tritt entweder in Astros Verarbeitungspfad ein, umgeht ihn oder stammt aus einer Remotequelle, die zuerst vertrauenswürdig gemacht werden muss. Sobald Sie es so sehen, werden die Implementierungsentscheidungen klarer: Speicherort, Komponentenauswahl und Quellenautorisierung sind die drei Hebel, die das Ergebnis steuern.

Eine schnelle Entscheidungsregel

Verwenden Sie die Verarbeitung von Astro, wenn das Bild die Seitenleistung, das Layout oder die visuelle Qualität über Geräte hinweg beeinflusst. Vermeiden Sie es, wenn die Datei unverändert bleiben muss, wie ein Favicon, ein rechtliches Asset oder ein direkter öffentlicher Download. Diese einfache Trennung hält den Workflow praktisch und verhindert, dass Teams Assets überkomplizieren, die nicht von einer Transformation profitieren.

Warum es wichtig ist – geschäftliche und technische Auswirkungen

Die Bereitstellung von Bildern beeinflusst sowohl den Umsatz als auch die Ingenieurzeit. Auf der geschäftlichen Seite verbessern schnellere Seiten in der Regel den ersten Eindruck, insbesondere für bildlastige Geschäfte, in denen Besucher die Qualität schnell beurteilen. Wenn eine Seite langsam lädt, weil das Heldenbild, die Galerie oder die Kollektionselemente zu schwer sind, könnten Benutzer die Seite verlassen, bevor sie die Produktdetails erreichen, die die Konversion vorantreiben.

Auf der technischen Seite reduzieren optimierte Bilder die Bandbreite, verringern die Belastung der Build- und Bereitstellungs-Workflows und vereinfachen das responsive Design. Anstatt mehrere Versionen desselben Assets manuell zu warten, kann das Team definieren, wie ein Bild verwendet werden soll, und Astro die Transformation übernehmen lassen. Das reduziert repetitive Arbeiten und macht den Code leichter nachvollziehbar.

Es gibt auch einen Wartungsaspekt. Händler und Entwickler akkumulieren oft im Laufe der Zeit inkonsistente Bildhandhabung: einige Assets stammen aus einem CMS, einige aus einem CDN, einige aus public/, und einige sind hartkodiert in Vorlagen. Ohne eine klare Optimierungsstrategie enden Teams mit gemischter Qualität, inkonsistenten Dimensionen und Layoutverschiebungen, die durch Bilder verursacht werden, die ankommen, bevor ihr Platz reserviert ist.

Eine praktische Regel ist einfach: Wenn das Bild zur Seiten-Erfahrung beiträgt, verdient es eine Optimierungsentscheidung. Diese Entscheidung könnte sein: „In Astro verarbeiten“, „Unverändert aus public bereitstellen“ oder „Remote belassen, aber zur Verarbeitung autorisieren.“ Der Punkt ist, absichtlich zu wählen, anstatt sich auf das zu verlassen, was im Moment am einfachsten ist.

Der geschäftliche Fall ist nicht nur Geschwindigkeit um der Geschwindigkeit willen. Eine bessere Bildhandhabung kann das Risiko von Absprüngen auf Mobilgeräten reduzieren, Produktseiten vertrauenswürdiger erscheinen lassen und verhindern, dass redaktionelle Inhalte zu einer Leistungsbelastung werden. Der technische Fall ist ebenso stark: weniger Ad-hoc-Bildvarianten, weniger Duplizierungen im Repository und ein klarerer Weg für zukünftige Mitwirkende, die wissen müssen, wo ein Asset hingehört.

Für Teams, die häufig neue Inhalte veröffentlichen, beeinflusst die Bildoptimierung auch das Vertrauen in die Bereitstellung. Wenn die Bildpipeline vorhersehbar ist, führt ein Inhaltsupdate nicht dazu, dass der Build unerwartet aufbläht oder ein Layout-Regression eintritt. Diese Vorhersehbarkeit ist wichtig für Händler, die häufig veröffentlichen, und für Entwickler, die einen stabilen Veröffentlichungsprozess wünschen.

Es ist auch erwähnenswert, dass die Bildoptimierung eine der wenigen Leistungsaufgaben ist, die gleichzeitig die wahrgenommene Qualität und die operationale Effizienz verbessern kann. Ein kleineres, besser zielgerichtetes Asset hilft dem Browser, schneller zu rendern, während ein zwischengespeicherter und wiederholbarer Build-Prozess dem Team hilft, schneller zu veröffentlichen. Dieser doppelte Vorteil ist der Grund, warum die Bildstrategie mehr Aufmerksamkeit verdient, als sie oft erhält.

Wie es funktioniert – erklären Sie den Mechanismus Schritt für Schritt

Die Bildoptimierung in Astro erfolgt über eine Build-Zeit-Pipeline. Wenn Astro ein Bild verarbeiten kann, liest es das Asset, transformiert es in das angeforderte Ausgabeformat und speichert das verarbeitete Ergebnis während der Builds in einem Cache-Verzeichnis. Dieser Cache ist wichtig, weil er es Astro ermöglicht, Arbeit wiederzuverwenden, anstatt dieselben verarbeiteten Assets jedes Mal neu zu generieren.

Die Quelle des Bildes bestimmt, was Astro damit tun kann. Lokale Bilder in src/ sind ideal, weil Astro sie direkt importieren und transformieren kann. Remote-Bilder können ebenfalls verarbeitet werden, jedoch nur, wenn sie von autorisierten Bildquellen stammen, die in der Konfiguration definiert sind. Wenn die Quelle nicht autorisiert ist, zeigt Astro das Bild dennoch an, jedoch ohne Verarbeitung.

Der Rendering-Pfad ist ebenfalls wichtig. In .astro-Dateien können Sie Astros <Image />-Komponente für optimierte Ausgaben verwenden oder <Picture />, wenn Sie mehrere Größen oder Formate wünschen. Sie können auch native HTML-Tags wie <img> verwenden, aber diese erhalten keine Astrov-Optimierung. In Markdown können Bilder verarbeitet werden, wenn sie auf lokale oder autorisierte Remote-Quellen verweisen, während Dateien in public/ unverändert bleiben.

Der praktische Ablauf

1. Sie platzieren das Bild am richtigen Ort, normalerweise src/, wenn eine Optimierung erforderlich ist.
2. Sie importieren oder referenzieren es mit der richtigen Astro-Syntax.
3. Astro generiert das transformierte Asset während des Builds.
4. Die verarbeitete Datei wird zwischengespeichert, sodass zukünftige Builds sie wiederverwenden können.
5. Der Browser erhält eine Version, die besser zum Anzeige-Kontext passt.

Dieser Ablauf ist der Grund, warum die Verzeichniswahl kein unwichtiges Detail ist. Sie bestimmt, ob Astro das Bild überhaupt optimieren kann. Wenn ein Team alles in public/ speichert, wählt es Bequemlichkeit über Verarbeitung. Wenn es die Assets in src/ behält, wählt es Optimierung und Kontrolle zur Build-Zeit.

Eine nützliche Art, es zu betrachten, ist, dass Astro die Bilder nicht „repariert“, nachdem sie bereitgestellt wurden. Es beteiligt sich an der Asset-Pipeline, bevor die Seite versendet wird. Das bedeutet, dass die Ausgabe durch den Speicherort, die gewählte Komponente und die Konfiguration, die Remote-Quellen autorisiert, geformt wird. Sobald diese Eingaben festgelegt sind, erhält der Browser eine passendere Datei, ohne dass das Team zusätzliche manuelle Arbeit leisten muss.

Ein zweiter Mechanismus, der erwähnenswert ist, ist die responsive Auswahl. Der Punkt ist nicht nur, eine Datei einmal zu verkleinern; es geht darum, dem Browser Optionen bereitzustellen, die zu verschiedenen Ansichtsgrößen und Gerätedichten passen. Deshalb kann dasselbe Quellbild unterschiedliche Ausgaben erzeugen, abhängig davon, ob es in einer schmalen Karte, einem breiten Heldenbild oder einer Inhaltskolonne verwendet wird. Der Layout-Kontext wird Teil der Optimierungsentscheidung.

Wo der Cache passt

Das Cache-Verzeichnis ist leicht zu übersehen, aber es ist einer der praktischsten Teile des Workflows. Wenn eine Seite häufig neu gebaut wird und dieselben Assets wiederverwendet werden, kann die Beibehaltung des Caches verhindern, dass Astro die bereits geleistete Arbeit wiederholt. Das ändert die endgültige Bildqualität nicht, kann jedoch die Build-Pipeline effizienter machen und unnötige Verarbeitungsüberhänge reduzieren.

Anwendungsfälle – wo Teams dies tatsächlich anwenden

Der häufigste Anwendungsfall ist eine inhaltsreiche Homepage oder Landingpage mit großen visuellen Assets. Händler möchten oft starke Bilder im oberen Bereich, aber dasselbe Heldenbild kann das größte Leistungsproblem auf der Seite werden. Die Bildoptimierung in Astro hilft, indem es ein einzelnes Design-Asset in eine besser passende Bereitstellungsstrategie für verschiedene Bildschirmgrößen verwandelt.

Ein zweiter Anwendungsfall ist redaktioneller oder Dokumentationsinhalt. Wenn eine Seite Artikel, Leitfäden oder Produktbildungsseiten veröffentlicht, erscheinen Bilder oft im Hauptinhalt. Diese Bilder können aus lokalen Dateien, Markdown oder einem CMS stammen. Astros Bildwerkzeuge helfen, diese Assets konsistent zu halten, insbesondere wenn derselbe Inhalt auf Desktop- und Mobil-Layouts funktionieren muss.

Ein dritter Anwendungsfall sind CMS- oder CDN-gesteuerte Seiten, bei denen die Bildquellen verteilt sind. In diesem Setup besitzt das Team möglicherweise nicht jede Datei direkt, benötigt jedoch dennoch einen zuverlässigen Weg, um zu optimieren, was der Browser herunterlädt. Astro kann mit Remote-Bildern aus autorisierten Quellen arbeiten, was es praktisch für Teams macht, die lokale Design-Assets mit externen Inhaltssystemen mischen.

Für Händler kommt die Entscheidung oft auf den Seitentyp an. Produktdetailseiten, Kategorieseiten und Landingpages profitieren normalerweise am meisten von einer Optimierung, da sie stark auf visuelle Elemente angewiesen sind. Für Entwickler hängt die Entscheidung oft von der Quellenbesitz und der Komplexität des Builds ab. Wenn das Team die Dateiquelle kontrollieren kann, kann Astro normalerweise mehr für sie tun.

Es gibt auch einen Workflow-Anwendungsfall, der leicht übersehen werden kann: wiederholte Builds. Wenn eine Seite häufig neu gebaut wird, kann die Bildverarbeitung zu einem versteckten Kostenfaktor werden. In dieser Situation ist das Beibehalten des Caches zwischen den Builds nicht nur eine nette Ergänzung; es kann die Bereitstellungspipeline daran hindern, dieselbe Arbeit immer wieder neu zu machen. Das ist wichtig für Teams, die häufig veröffentlichen, oder für Seiten, bei denen Inhaltsupdates im Laufe des Tages Builds auslösen.

Ein weiteres praktisches Szenario ist die Wiederverwendung von Vorlagen. Eine einzelne Produktkarte oder Artikelvorschau kann an vielen Stellen auf der Seite erscheinen. Wenn die Bildstrategie konsistent auf Komponentenebene behandelt wird, profitiert jede Instanz von denselben Optimierungsregeln. Das ist viel einfacher, als zu versuchen, jede Seite nachträglich von Hand anzupassen.

Ein letzter Anwendungsfall ist die Migrationsarbeit. Wenn ein Team von einem Legacy-Frontend zu Astro wechselt, wird die Bildhandhabung oft zu einem der ersten Bereiche, in denen Leistungsgewinne sichtbar werden. Die Migration muss am ersten Tag nicht perfekt sein; sie benötigt lediglich eine klare Regel, welche Assets optimiert, welche öffentlich sind und welche Remote-Quellen autorisiert sind.

Wie man es implementiert oder anwendet – praktische Anleitung

Beginnen Sie damit, Bilder in drei Gruppen zu klassifizieren: Bilder, die optimiert werden sollten, Bilder, die unverändert bereitgestellt werden sollten, und Bilder, die aus externen Systemen stammen. Diese einfache Trennung verhindert später viel Verwirrung. Wenn ein Bild dekorativ, statisch oder als direktes öffentliches Asset erforderlich ist, kann public/ in Ordnung sein. Wenn es Teil der tatsächlichen Seitenerfahrung ist, ist src/ normalerweise die bessere Standardwahl.

Entscheiden Sie als Nächstes, welche Rendering-Methode zur Seite passt. Verwenden Sie <Image /> für unkompliziert optimierte Bilder. Verwenden Sie <Picture />, wenn Sie mehrere Formate benötigen oder mehr Kontrolle über die Auswahl responsiver Quellen wünschen. Verwenden Sie HTML <img> nur, wenn Sie absichtlich keine Astro-Verarbeitung wünschen, z.B. für ein öffentliches Asset, das unverändert bleiben soll.

Wenn Ihr Inhalt in Markdown lebt, überprüfen Sie, ob die Bildquelle lokal, remote oder öffentlich ist. Lokale und autorisierte Remote-Bilder können optimiert werden; öffentliche Bilder werden nicht optimiert. Wenn Sie mehr Kontrolle über Attribute oder komponentenbasiertes Rendering benötigen, kann MDX das bessere Inhaltsformat sein, da es Ihnen ermöglicht, Markdown mit Komponenten zu kombinieren.

Eine gute Implementierungssequenz besteht darin, zuerst mit den Seiten mit der größten Wirkung zu beginnen. Das bedeutet normalerweise die Homepage, Produktseiten und alle Artikelvorlagen, die sich über die Seite wiederholen. Sobald diese stabil sind, können Sie den Rest des Projekts um dieselben Regeln herum standardisieren. Dies vermeidet den häufigen Fehler, einmalige Seiten zu optimieren und gleichzeitig das Vorlagensystem inkonsistent zu lassen.

Eine praktische Implementierungscheckliste

• Legen Sie leistungsanfällige lokale Bilder in src/ ab.
• Halten Sie unveränderte Dateien, wie direkte öffentliche Assets, in public/.
• Autorisieren Sie Remote-Bildquellen nur, wenn die Seite sie wirklich benötigt.
• Bevorzugen Sie Astrov-Bildkomponenten gegenüber rohem <img> für optimierte Bereitstellung.
• Behalten Sie das Bild-Cache-Verzeichnis zwischen Builds bei, wenn Ihr Bereitstellungsprozess dies zulässt.
• Testen Sie die Seite in mobilen und Desktop-Größen, damit das Layout und das Bildverhalten dem Design entsprechen.

Ein weiteres Implementierungsdetail ist für Teams mit häufigen Builds wichtig: Cache-Beibehaltung. Da Astro verarbeitete Assets in einem Cache-Verzeichnis speichert, kann das Beibehalten dieses Caches zwischen den Builds die Build-Zeit verbessern und wiederholte Verarbeitung reduzieren. Das ist besonders nützlich, wenn die Seite viele Bilder enthält oder wenn dieselben Assets über mehrere Seiten hinweg wiederverwendet werden.

Wenn Sie zwischen einem lokalen Import und einer öffentlichen URL entscheiden, stellen Sie sich eine einfache Frage: Möchten Sie, dass Astro die Kontrolle über die Datei hat? Wenn ja, halten Sie es in src/ und verwenden Sie die optimierte Pipeline. Wenn nein, legen Sie es in public/ und akzeptieren Sie, dass es unverändert bereitgestellt wird. Diese Entscheidung ist oft wichtiger als die genaue Komponentensyntax.

Es hilft auch, eine Benennungs- und Eigentumsrichtlinie festzulegen. Zum Beispiel können Teams src/ für Assets reservieren, die zum Designsystem oder zu Seitenvorlagen gehören, während Inhaltsredakteure Artikelbilder über das CMS nur hochladen, wenn diese Quellen autorisiert sind. Das hält die Implementierung im Einklang mit dem Eigentum des Assets und wie oft es sich ändert.

Eine einfache Rollout-Reihenfolge

Wenn eine Seite bereits viele Bilder hat, versuchen Sie nicht, alles auf einmal zu konvertieren. Beginnen Sie mit den größten Dateien auf den sichtbarsten Seiten, gehen Sie dann zu wiederverwendbaren Komponenten über und überprüfen Sie dann die Inhaltsseiten. Diese Reihenfolge gibt dem Team schnelle Erfolge, während sie die Migration überschaubar hält. Es macht es auch einfacher zu erkennen, ob die Optimierungsregeln helfen oder ob ein bestimmtes Asset öffentlich bleiben sollte.

Häufige Fehler und Fallstricke

Der häufigste Fehler besteht darin, public/ als Standard-Speicherort für jedes Bild zu behandeln. Das ist bequem, umgeht jedoch die Verarbeitung. Wenn ein Team alle Produktfotografien dort ablegt, geben sie die Optimierungspipeline auf und enden oft damit, größere als benötigte Dateien zu versenden.

Ein weiterer Fehler ist die Annahme, dass jedes Remote-Bild automatisch optimiert wird. Astro verarbeitet nur Remote-Bilder von autorisierten Quellen. Wenn die Quelle nicht richtig konfiguriert ist, wird das Bild möglicherweise weiterhin angezeigt, profitiert jedoch nicht von Astros Transformationspipeline. Das kann ein falsches Sicherheitsgefühl erzeugen, wenn die Seite in der Entwicklung gut aussieht, aber in der Produktion schlechter abschneidet als erwartet.

Ein dritter Fallstrick ist die Mischung von rohen HTML-Tags und optimierten Komponenten ohne Plan. <img> ist in .astro-Dateien gültig, aber es löst keine Astro-Optimierung aus. Das ist in Ordnung, wenn es beabsichtigt ist, wird jedoch problematisch, wenn Entwickler erwarten, dass Astro das Asset behandelt und es stillschweigend nicht tut.

Es gibt auch ein Inhaltsworkflow-Problem. Teams vergessen manchmal, dass Markdown, MDX, .astro-Dateien und öffentliche Assets sich unterschiedlich verhalten. Wenn das Inhaltsteam ein Bild an den falschen Ort hochlädt, funktioniert die Seite möglicherweise weiterhin visuell, während die Optimierungsgewinne verloren gehen. Deshalb sollte die Speicherentscheidung Teil des Inhaltsworkflows sein und nicht nur der Codeüberprüfung.

Ein weiterer subtiler Fallstrick ist, alles übermäßig zu optimieren. Nicht jedes Bild benötigt die gleiche Behandlung. Kleine Symbole, Logos und wirklich statische Assets sollten möglicherweise in Ruhe gelassen werden, wenn die Optimierung Komplexität hinzufügt, ohne signifikante Einsparungen zu erzielen. Das Ziel ist nicht, jede Datei denselben Weg zu zwingen; es ist, den richtigen Weg auf das richtige Asset anzuwenden.

Ein letzter Fehler ist, das Cache-Verhalten während der Bereitstellung zu ignorieren. Wenn das Cache-Verzeichnis bei jedem Build verworfen wird, kann die Seite dieselben Bilder immer wieder neu verarbeiten und einen der größten Effizienzgewinne von Astro verlieren. Das bricht die Seite nicht immer, kann jedoch die Builds langsamer und weniger vorhersehbar machen, als sie sein sollten.

Wie man die häufigsten Fehler behebt

Wenn Bilder unerwartet unoptimiert sind, überprüfen Sie zuerst den Speicherort der Datei, dann die verwendete Komponente und schließlich die Autorisierung der Remote-Quelle. Wenn die Builds langsamer als erwartet sind, bestätigen Sie, dass der Cache erhalten bleibt. Wenn das Layout um Bilder herum verschiebt, stellen Sie sicher, dass die Komponente oder Markup den richtigen Platz für das Asset reserviert, bevor es lädt. Diese Überprüfungen lösen die meisten Probleme, ohne dass eine vollständige Neuschreibung der Seite erforderlich ist.

Best Practices und schnelle Checkliste

Die beste Bildstrategie in Astro beginnt mit Konsistenz. Entscheiden Sie, wo optimierte Bilder gespeichert werden, wie Remote-Quellen autorisiert werden und welches Komponentenmuster das Team standardmäßig verwenden sollte. Sobald diese Regeln festgelegt sind, wird die Implementierung viel einfacher, über Seiten und Mitwirkende hinweg zu wiederholen.

Verwenden Sie das einfachste Werkzeug, das dennoch die Bedürfnisse der Seite erfüllt. Wenn ein standardisiertes optimiertes Bild ausreicht, ist <Image /> normalerweise die sauberste Wahl. Wenn die Seite mehrere Quellenoptionen oder eine feinere responsive Kontrolle benötigt, wechseln Sie zu <Picture />. Wenn ein Asset niemals transformiert werden sollte, belassen Sie es in public/ und behandeln Sie es als bewusste Ausnahme.

Behalten Sie auch den Build-Workflow im Auge. Wenn die Seite häufig neu gebaut wird und dasselbe Bildset wiederverwendet, kann die Beibehaltung des Caches Zeit sparen. Das ist kein Detail nur für den Frontend-Bereich; es betrifft die Bereitstellungseffizienz und wie schnell Teams Änderungen versenden können.

Es hilft auch, die Entscheidungsregeln im Repository zu dokumentieren. Mitwirkende sollten wissen, wann sie aus src/ importieren, wann sie einen öffentlichen Pfad verwenden und wann eine Remote-Quelle eine Autorisierung benötigt. Diese kleine Menge an Dokumentation verhindert später viele inkonsistente Verhaltensweisen, insbesondere in Teams, in denen sich Inhalte und Entwicklungsverantwortlichkeiten überschneiden.

Verwandte Begriffe und weiterführende Literatur

• Astro Themes
• Astro Themes