Geschwindigkeit der Core-Module

[Samson1964]

Seitdem ich zu Contao umgestiegen bin, ist die Website deutlich langsamer geworden. Vorher hatte ich bis 23.8. eine Kombination aus PivotX und phpCMS zu laufen. Im Anhang findet ihr drei Diagramme vom Servermonitoring der letzten 365 Tage.

Hier ein paar Eckdaten zur Website:

Datenbank: 413 Seiten, 769 Artikel, 11.360 Inhaltselemente, 22.394 Dateien, 8.976 Nachrichten, 9.049 Tags, 1,4 Millionen Suchbegriffe im Index

Zugriffe: 135 GB Traffic im September (ca. 81 % aller auf dem Server gehosteten Domains)
16 Millionen Anfragen im September, zuvor 25-30 Millionen Anfragen je Monat (weniger unter Contao bedingt durch die andere Struktur und noch nicht alle Inhalte übernommen)
Rund 480.000 Dateien und 300.000 Seiten im September abgerufen.

Tarif/Hoster: Domainfactory
ManagedServer XL5

Einstellungen php.ini: max_execution_time = 720
memory_limit = 1000M

Erweiterungen: Unter Contao 3.1.2 sind installiert:
ajax 1.1.6 stable
avatar 2.0.4 stable
backend_user_online 3.1.0 stable
backend_websitepreview 2.1.0 stable
banner 3.0.0 rc1
botdetection 3.1.0 stable
chesstable
cron 3.1.0 stable
efg 2.0.1 stable
geshi 1.0.8 stable
image_sort_wizard 1.1.0 stable
includes 0.1.2 stable
jira_issue_collector_wizard 3.0.0 stable
lastlogin 3.0.0 stable
m17-sticky-backend-footer 2.0.4 stable
memberlist 1.3.0 stable
newspagination 1.5.0 rc2
om_searchkeys 1.0.2 stable
pgnviewer 1.0.0 rc1
photoalbums2 1.1.0 stable
simple_ajax 1.0.1 stable
sort_wizard 1.0.0 stable
survey_ce 3.0.0 stable
tags 3.0.1 stable
textwizard 3.0.0 stable
translation_fields 1.0.0 beta1
usemap 3.0.0 stable
visitors 3.1.4 stable
xls_export 3.0.0 stable

Performance-Killer sind aus meiner Sicht das Nachrichtenmodul und das Galerie-Inhaltselement. Auch die externe tags-Erweiterung macht Probleme, allerdings nur unter Version 3.1.3: Das Backend wird an einigen Stellen, wo höchstwahrscheinlich tags benötigt wird, deutlich langsamer und ich muß(te) bis zu gefühlten 30 Sekunden warten, bis die Backend-Seite geladen wurde. Unter 3.1.2 hat noch alles geflutscht. Deshalb habe ich 3.1.3 wieder gekillt.

Doch nun zu den beiden Core-Modulen.

Das Nachrichtenmodul lädt und parst in der Gesamtübersicht von Nachrichten unverständlicherweise auch die Inhaltselemente, die man ja in der Teaseransicht gar nicht zu sehen bekommen will. Am Sonnabendabend hatte ich in einer Nachricht ein Galerie-Inhaltselement eingebunden: 41 JPG's mit insgesamt ca. 120 MB und Auflösungen von jeweils 3200x2400. Contao braucht unheimlich lange, um die dafür nötigen Thumbnails zu erstellen. Das wäre nicht weiter schlimm, würden die Thumbnails nur einmal erstellt. Aber das wird immer und immer wieder hundertfach wiederholt. Als ich Sonntagabend nach Hause kam, hatte ich einige Mails wegen eines nicht erreichbaren Servers. Und das betrifft natürlich dann auch gleich alle Domains, wenn ein Prozess hängt. Nachdem ich die Galerie von der Nachricht in die Erweiterung photoalbums2 ausgelagert hatte, beruhigte sich der Server wieder und lief einigermaßen flüssig.

Damit wären wir auch gleich beim Galerie-Inhaltselement. Für mich völlig unverständlich ist, daß der Cache entweder gar nicht oder nur mangelhaft genutzt wird. Irgendwo hatte ich mal gelesen, daß im Backend keine Grafiken gecacht werden, weswegen gerade dieses Inhaltselement aber auch der Dateimanager ein Ärgernis ist. Während ich im Backend auf die Anzeige der Seite warte, fehlt dem Frontend ein Serverprozess um den Besucheransturm zu bewältigen. Die Thumbnails im Dateimanager und in Inhaltselementen sollten deshalb grundsätzlich dauerhaft angelegt werden. Oder gibts hier wirklich Grafik-Junkies die dauernd an ihren Grafiken rumbasteln und alle paar Stunden neue Versionen auf den Server laden? Jede vernünftige Bildalbenverwaltung legt die Thumbnails dauerhaft an und generiert die nur auf Wunsch neu. Warum kann Contao das nicht?

Zurück zum Nachrichtenmodul: Hier gehört das Laden und Parsen von Inhaltselementen in der Normalansicht (Teaseransicht) abgeschaltet. Meine Startseite würde deutlich beschleunigt, wenn nicht im Hintergrund wertvolle Zeit für das Erstellen von Datenmüll investiert würde.

Zum Galerie-Element hatte ich vor einiger Zeit schon mal was auf Github geschrieben. Meinen dort genannten Patch kopiere ich nach jedem Update in den Contao-Core. Hat man nämlich mehrere Galerie-Elemente eingebunden, wird das Backend komplett lahmgelegt.

[Nina]

Jetzt mal nur aus Neugierde: Weshalb nutzt du derart riesige Bilder als Ausgangsbasis? Das kenne ich so nichtmal von ausgewiesenen Fotoblogs.

Zu deinem Thema: Hast du deine Tests auch mal gemacht als alle installierten Extensions deaktiviert waren? Einfach nur um sicher zu gehen, dass dir davon nichts in die Tests pfuscht?

Weshalb allerdings Contao auf der News-List auch die Inhalte der Detailseiten mitparsed, weiß ich nicht. Scheint mir auch nicht richtig zu sein, sofern sich auf der Seite kein entsprechendes Modul befindet.

[Kahmoon]

Hmm die Seite ist bei mir generell schrecklich langsam..auch wenn keine Nachrichten eingebunden sind!?

Edit:
Mein Firebug zeigt mir das einige MP3s auf jeder Seite geladen werden die gar nicht vorhanden sind. Daran rödelt er EWIG!

[Samson1964]

Also so riesig finde ich die Bilder nun wirklich nicht. Außerdem möchte ich doch schon eine möglichst große Auflösung für die Besucher anbieten.

Bei der Suche des Backend-Performance-Killers unter 3.1.3 hatte ich zuletzt alle Erweiterungen deaktiviert und bin so auf tags gestoßen. Von einer erneuten Deaktivierung erhoffe ich mir nichts, da ich News-Modul und Galerie-Element bereits als Killer ausgemacht habe. Ich werde diesen Versuch aber trotzdem nochmal an einer 1:1-Kopie der Website demnächst unternehmen. Helfen wird's wohl nichts, wenn das Galerie-Element trotzdem weiter bei jedem Aufruf Thumbnails erstellt.

P.S. Ich vergaß zu erwähnen, daß der Seitencache auf 12 Stunden eingestellt ist (vorher 6 Stunden und davor 30 und 0 Sekunden). Die Cacheexperimente machte ich im Zusammenhang wegen eines Bugs im Core bzw. einer Erweiterung: Bei Cachebenutzung wird irgendwo ein Teil der Request-Parameter gelöscht.

[Kahmoon]

Siehe mein Edit oben: Es wird ewig versucht irgendlweche MP3s zu laden die nicht vorhanden sind.

[psren]

3200x2400

Das passt ja auf keinen Bildschirm?!

Helfen wird's wohl nichts, wenn das Galerie-Element trotzdem weiter bei jedem Aufruf Thumbnails erstellt.

Werden die Thumbs nicht normal gespeichert und nur wenn die Bilder sich verändert haben neu generiert?

[Samson1964]

Hmm die Seite ist bei mir generell schrecklich langsam..auch wenn keine Nachrichten eingebunden sind!?

Das Nachrichtenmodul ist (im Wesentlichen) nur auf der Startseite eingebunden. Die anderen Einbindungen sind wegen sehr geringer Zugriffe zu vernachlässigen. Die Startseite trägt die Hauptlast der Zugriffe, ca. 6.000 Besucher am Tag. Und eine langsame Nachrichtenauslieferung wirkt sich natürlich auch auf andere Serverprozesse aus. Auf das überflüssige Parsen der Inhaltselemente von Nachrichten will ich nicht nochmal hinweisen.

[Samson1964]

Siehe mein Edit oben: Es wird ewig versucht irgendlweche MP3s zu laden die nicht vorhanden sind.

Das war mir mit HttpFox auch schon aufgefallen. Deshalb wollte ich mich mal unseren Werbepartner wenden. Im ersten Augenblick dachte ich an einen Hack.

[Zero]

Noch eine Zwischenfrage: Ist der Bypass Cache Aktiviert oder deaktiviert? Für so eine Seite darf das in keinem Fall aktiviert sein .

Edit: Siehe auch hier: https://contao.org/de/news/contao-fu...ptimieren.html

[Samson1964]

Danke für die Tips! Bypass Cache (hört sich schlimm an) habe ich jetzt auf false gestellt. Ich habe mir Page Speed installiert und die Kompression der Seiten und Skripte im Backend aktiviert. Ich werde die Entwicklung mal die nächsten Tage weiter beobachten.

Die standardmäßig mitgelieferte .htaccess ist doch sicher schon optimal eingestellt, oder? Ich habe dort erstmal nichts verändert. Mir schienen die Vorschläge schon umgesetzt in der Standard-htaccess.

[schumja]

Nicht bezüglich der Geschwindigkeit sondern allgemein zur Seite:

Erstmal freut es mich als Schachspieler dass die Seite mit contao läuft und die dwz-Abfrage besser funktioniert als vorher
Was bei der mobilen Ansicht allerdings suboptimal ist, ist dass das Menü sehr lang ist. Z.B. Bei der dwz kommt erst das Hauptmenü dann ein Menü, dann die wertungsordnung und dann noch was zur fide bevor der Inhalt kommt. Vielleicht kannst du den Inhalt noch weiter oben platzieren, da er so ein bisschen untergeht wie ich finde

Gesendet von meinem Xperia Z mit Tapatalk

[fabil]

Die standardmäßig mitgelieferte .htaccess ist doch sicher schon optimal eingestellt, oder? Ich habe dort erstmal nichts verändert.

Bei den meisten Hostern greifen diese Regeln, aber nicht bei jedem. Oft muss noch etwas angepasst werden. Als Beispiel musste ich bei meinem Hoster (Uberspace.de) den Bereich mit mod_deflate umschreiben, da dort in der if-Abfrage was anderes stehen musste.

Aber im Allgemeinen ist die .htaccess gut eingestellt.
Und diese wäre (ohne Veränderungen) sicherlich nicht der Flaschenhals an dieser Geschichte.

Aber aktuell finde ich die Startseite relativ schnell (656ms mit Chrome, bis die HTML-Datei geladen wurde).
Gesamte Zeit bis die Seite inclusive Bilder und sonstigen Dateien geladen ist: 2,26 Sekunden bei einer DSL 2000er Leitung.

[Zero]

Danke für die Tips! Bypass Cache (hört sich schlimm an) habe ich jetzt auf false gestellt.

Er ist sehr wichtig! Wird sehr häufig als nicht relevant angesehen. Meistens von den Leute, die nicht wissen was er macht. Gehasst wird er von den Entwicklern .

Diese Option "Bypass Cache" macht nichts anderes wie den internen Cache von Contao zu umgehen. Dieser besteht aus sämtlichen config und autoload Dateien aller Module. Diese werden dor zusammengeafsst und teilweise bereits optimiert gespeichert. Wenn also diese Option deaktiviert ist musst du in C3 einmalig den Cache erstellen. Dieser muss bei Manuellen Änderungen an Erweiterungen manuell gelöscht und erstellt werden. Übers Repo geht das automatisch.

Wenn du also viele Module, oder auch gleiche Module auf einer Seite einbindest, dann kann das je nach Modulen zu extremen Ladezeiten kommen, da der Interne Cache von Contao neu erstellt wird bei jedem Laden und somit ergab sich dann deine Ladezeit von 10 Sekunden, bis überhaupt mal das HTML an die Seite geschickt wird.

Deshalb: Bei Produktiven System den Bypass Cache nimal aktivieren. Immer deaktivieren!

[Samson1964]

Nicht bezüglich der Geschwindigkeit sondern allgemein zur Seite:

Erstmal freut es mich als Schachspieler dass die Seite mit contao läuft und die dwz-Abfrage besser funktioniert als vorher
Was bei der mobilen Ansicht allerdings suboptimal ist, ist dass das Menü sehr lang ist. Z.B. Bei der dwz kommt erst das Hauptmenü dann ein Menü, dann die wertungsordnung und dann noch was zur fide bevor der Inhalt kommt. Vielleicht kannst du den Inhalt noch weiter oben platzieren, da er so ein bisschen untergeht wie ich finde

Gesendet von meinem Xperia Z mit Tapatalk

Das mit dem übervollen und viel zu großem Menü in der Mobilansicht hatte ich schon von anderer Seite gehört. Ich hatte mich damit nur an einem Tag beschäftigt und danach nie wieder. Jetzt muß ich mich wohl doch mal ransetzen.

[Andreas]

Die Seite läuft bei mir gefühlt schnell, ich verbiete allerdings auch Resourcen von Fremddomains.

Mit 3200x2400 bietest du den Usern eine sehr gute Qualität an, wahrscheinlich sind die Bilder so, wie sie aus der Kamera kommen. Habe grad mal einen kleinen Test gemacht. 15 Bilder 27MB aus ner 2000€ Canon mit Xnview auf 4 MB komprimiert - die Qualität ist dabei sehr gut. Kommt natürlich drauf an, wozu du die Bilder anbietest. Ich habe einen 27" Monitor mit einer Aufllösung von 1920x1200px, also selbst darauf kann ich sie nicht in original Größe anzeigen. Zum professionellen Weiterverarbeiten musst du natürlich die Originale aus der Kamera anbieten.

Contao braucht nicht lange für die Thumbs, sondern der Server. Bedenke, dass 120MB JPEG Bilddaten ausgepackt werden müssen (vor der Verkleinerung werden sie ja ausgepackt, öffne mal eine JPEG mit Photoshop, da kannst du dir unten den Speicherbedarf anzeigen lassen.) Das können dann evtl. auch 1GB oder noch mehr an Daten sein, die umgerechnet werden müssen.

Die Thumbs, sowohl fürs BE als auch fürs FE sollten natürlich nur einmal erstellt werden. Vielleicht kannst du der Sache nochmal auf den Grund gehen, denn wenn die Thumbs tatsächlich erstellt werden obwohl sie schon vorhanden sind, müsste das unbedingt als Bug gemeldet werden.

Mit dem Parsen von nicht anzuzeigenden Elementen, meinst du da, dass wenn du die Variablen des Templates mit showTemplateVars() ausgibst, dass du da auch alle möglichen Arrays siehst, die über das Template gar nicht zur Ausgabe kommen sollen? Dazu habe ich nämlich mal vor gefühlten 4 Jahren ein Ticket geschrieben, woraufhin Andreas Schempp mir erklärte, dass das normal wäre. Bedenke aber auch, dass nicht jeder mit dem Listen-Modul nur den Teaser ausgeben möchte.

[Samson1964]

Die Seite läuft bei mir gefühlt schnell, ich verbiete allerdings auch Resourcen von Fremddomains.

Ist inzwischen bei mir auch gefühlt schnell, obwohl ich gerade in einer DSL-freien Zone nahe Berlin bin. Liegt vielleicht auch daran, daß die Komprimierung aktiv ist. Nachteil: Mein Browser zeigt mir den Original-Quelltext nicht mehr komplett an.

Mit 3200x2400 bietest du den Usern eine sehr gute Qualität an, wahrscheinlich sind die Bilder so, wie sie aus der Kamera kommen. Habe grad mal einen kleinen Test gemacht. 15 Bilder 27MB aus ner 2000€ Canon mit Xnview auf 4 MB komprimiert - die Qualität ist dabei sehr gut. Kommt natürlich drauf an, wozu du die Bilder anbietest. Ich habe einen 27" Monitor mit einer Aufllösung von 1920x1200px, also selbst darauf kann ich sie nicht in original Größe anzeigen. Zum professionellen Weiterverarbeiten musst du natürlich die Originale aus der Kamera anbieten.

Ich möchte schon, daß sich andere Webseiten an den Bildern bedienen, weswegen ich in den meisten Fällen die Originale gleich anbiete.

Contao braucht nicht lange für die Thumbs, sondern der Server. Bedenke, dass 120MB JPEG Bilddaten ausgepackt werden müssen (vor der Verkleinerung werden sie ja ausgepackt, öffne mal eine JPEG mit Photoshop, da kannst du dir unten den Speicherbedarf anzeigen lassen.) Das können dann evtl. auch 1GB oder noch mehr an Daten sein, die umgerechnet werden müssen.

Deshalb gönne ich den Skripten auch etwas mehr Zeit und Arbeitsspeicher.

Die Thumbs, sowohl fürs BE als auch fürs FE sollten natürlich nur einmal erstellt werden. Vielleicht kannst du der Sache nochmal auf den Grund gehen, denn wenn die Thumbs tatsächlich erstellt werden obwohl sie schon vorhanden sind, müsste das unbedingt als Bug gemeldet werden.

Das ständige Neugenerieren der Backend-Vorschaubilder in der Dateiverwaltung oder bei einem Inhaltselement Galerie nervt schon sehr. Ich hatte auch irgendwo gelesen, daß es für eingeloggte Backendbenutzer keinen Cache (für Bilder) gibt. Das nervt natürlich gewaltig, weil im Normalfall nur beim ersten Aufruf eine Thumbnailerstellung notwendig wäre. Wann ändert sich aber schon mal ein Originalbild?! Eigentlich bräuchte ja nur geprüft werden, ob das Originalbild jünger ist als das Thumbnail - und erst dann wird ein neues Thumbnail erstellt.

Bei der Synchronisation der Website (ich war schon lange ausgeloggt) bekam ich aber immer wieder Thumbnails angeboten, die sich hinsichtlich Bytegröße zur lokalen Version nicht geändert haben, dafür aber ein paar Minuten jünger waren. Und bei der nächsten Synchro eine halbe Stunde später gab es schon wieder neue Thumbnails in der gleichen Bytegröße mit neuerem Datum.

Mit dem Parsen von nicht anzuzeigenden Elementen, meinst du da, dass wenn du die Variablen des Templates mit showTemplateVars() ausgibst, dass du da auch alle möglichen Arrays siehst, die über das Template gar nicht zur Ausgabe kommen sollen? Dazu habe ich nämlich mal vor gefühlten 4 Jahren ein Ticket geschrieben, woraufhin Andreas Schempp mir erklärte, dass das normal wäre. Bedenke aber auch, dass nicht jeder mit dem Listen-Modul nur den Teaser ausgeben möchte.

Ich hatte mir am Anfang der Entwicklung ziemlich oft die Templatevariablen ausgegeben und dabei war mir das aufgefallen. Wenn wenigstens die Inhaltselemente mit einem Höchstmaß an Geschwindigkeit geparst würden, würde mich das gar nicht stören. Aber wenn schon ein einziges Galerie-Inhaltselement mit 41 Bildern ausreicht, um Contao an seine Leistungsgrenze zu bringen, dann läuft irgendwas falsch. Es ist doch normal in einer Galerie größere Auflösungen und ein paar mehr Bilder anzubieten. Den ganzen Sonntag letzte Woche war dadurch die Website nur schlecht erreichbar. Erst als ich die Galerie aus den Nachrichten entfernt habe, ging es wieder flüssig.

[Flex]

Die Größen bringen nicht Contao, sondern die GD Bibliothek an die Grenzen... eventuell testest du mal folgende Erweiterung.
https://contao.org/de/extension-list...Images.de.html

Gesendet von meinem Nexus 4 mit Tapatalk 4

[Andreas]

... daß es für eingeloggte Backendbenutzer keinen Cache (für Bilder) gibt. ...

Es gibt keinen Cache für die Thumbs, das sind Assets. Bis jetzt ist es allerdings so, dass die Thumbs immer neu erzeugt werden, wenn du "Internen Cache umgehen" angehakt hast. Das ist ab C3.2 anders https://github.com/contao/core/issues/6211 kannst du jetzt schon patchen, wenn du möchtest.

Ab C3.2 ist es allerdings verrückter Weise so, dass die Thumbs dann immer generiert werden, wenn du den Debug-Mode aktiviert hast. Zum Glück benutze ich den Debug-Mode nie. Irgendwie sieht es so aus, als würde der Prüfung, ob ein Thumb bereits erstellt wurde, selbst nicht getraut.

Solltest du "Internen Cache umgehen" nicht angehakt haben und die Thumbs werden trotzdem neu generiert, dann stimmt da irgendwas nicht.

[Zero]

Es gibt keinen Cache für die Thumbs, das sind Assets. Bis jetzt ist es allerdings so, dass die Thumbs immer neu erzeugt werden, wenn du "Internen Cache umgehen" angehakt hast.

Wenn man es genau nimmt sind die assets der Cache für Bilder, JS und CSS Dateien . Diese werden in der Regel nur einmal erstellt und dann nach einer bestimmten Zeit oder Änderung wieder. Es sei denn man hat "Internen Cache umgehen" aktiviert (C3.1). Dann werden die Bilder jedesmal generiert.

Und wenn ich richtig liege, dann lag das Geschwindigkeits Problem daran, dass der Interne Cache umgangen wurde. Somit wurden Bilder neu erstellt und sämtliche config, dca usw Dateien neu eingelesen/und zusammengefasst dadurch kamen dann die Ladezeiten von bis zu 10-15 sekunden zustande.

[Dexter Paris]

Dieses Verhalten von Contao, dass die Grafiken hinter Nachrichten-Teasern immer wieder neu generiert werden, habe ich bereits vor einigen Wochen beschrieben:

Vgl.: https://community.contao.org/de/show...96-Bildercache

Nochmals merke ich an, dass bei »Internen Cache umgehen« kein Haken gesetzt!

Für mich persönlich macht dieses Verhalten die Nachrichten-Erweiterung unbrauchbar, wenn dadurch Contao bzw. der Server ständig in die Knie geht!

Ich würde folgende Logik von Contao bzw. einem CMS generell erwarten:

1. Grundeinstellung

Wenn man eine Nachricht mit sämtlichen gewünschten Inhaltselementen neu anlegt, werden die darin enthaltenen Bilder einmal für den Cache erzeugt.

2. Beim Editieren eines Inhaltselements

Sobald ein bildhaltiges Inhaltselement geändert wird, sollte der entsprechende Bilderchache neu angelegt werden, und zwar nur dann!

Denkbar wäre auch ein Button »Bildercache neu generieren« …

3. Globale Neuberechnung

Gibts ja bereits in der Systemwartung unter »Bildercache leeren«. Allerdings sollte das Neugenerieren zyklisch erfolgen, so das die Ausführungszeit gar nicht überschritten werden kann …

Aus meiner Sicht würde ich das als Bug bezeichnen!

[Andreas]

Es wird in der Systemwartung zwar Bildercache genannt, aber das hat nichts zu bedeuten. Container für Inhaltselemente werden auch Artikel genannt und Member werden manchmal auch Frontend-User genannt.

Warum ist das kein Cache? Am FE wird es deutlich. Die Thumbs einer Galerie könnten auch die Originalbilder sein mit CSS runter skaliert. Sowas macht man aber nicht, man erzeugt für die Vorschau kleine Bilder. Diesen Service übernimmt Contao, damit man das nicht manuell mit Photoshop machen muss . Am Ende sind es auf jeden Fall statische Bilder, die im FE angezeigt werden sollen. Sowas kann man nicht Cache nennen. Im BE ist es genauso, für die Bilder werden von Contao automatisch kleine Vorschaubilder generiert, das ist kein Cache.

Den einzige Sinn die Bilder erneut zu generieren, den ich mir vorstellen kann, hat mir Tristan Lins genannt: während der Entwicklung welche die Bildbearbeitung betreffen. Und dann kann man bei der Erstellung noch den Parameter force benutzen, der das Erstellen erzwingt.

Der Cron-Job sollte nur das Entfernen nicht mehr benötigter Thumbs übernehmen. Seit Bilder als Ressourcen in der DB verwaltet werden, dürfte Contao das ja auch übernehmen können.

[FloB]

Ich möchte schon, daß sich andere Webseiten an den Bildern bedienen, weswegen ich in den meisten Fällen die Originale gleich anbiete.

Das würde ich dann aber per Link machen. Nur weil eventuell ein paar die Bilder verwenden wollen (<1% der Besucher), solltest du nicht gleich allen ein riesiges Datenpaket aufdrücken. Probleme bereitet das sonst insbesondere Nutzern mit langsamen Anschlüssen (<6 Mbps) und begrenzten Datenvolumen (beides insb. bei Mobilfunk inkl. Tethering). Wenn du eine hochauflösende Version (per Link) anbietest, sollte sich niemand daran stören, dass standardmäßig "nur" höchstens z. B. 1200px in Breite & Höhe ausgeliefert werden.