Startseite mit 5 MB! Unsinnige Größe der Thumbnails

Shopware 5 Allgemein
1

Hallo,

leider finde ich den alten Beitrag nicht mehr, der sich etwa um dieses Thema dreht.

Nachdem ein SEO-Tool die Startseite mit 5 MB als zu groß ausgegeben hat, hab ich jetzt nach Ursachen gesucht. Die Startseite/Einkaufswelt hat 4 Spalten. 11 Banner 1-4 Felder groß (650 KB), einen Bannerslider 3Spaltenx2Zeilen mit 4 Bildern (552 KB) - zusammen etwa 1,2 MB. Dann ein größeres html-Feld mit Text und 2 Produktstreams.

Pagespeed zeigt nun noch wesentlich schlechtere Werte an, als bei früheren Prüfungen: Mobil 34/100, Desk 67/100

Problem sind die Bilder bzw. die Thumpnails, bei Desktop die 800er und bei Mobil die 1280er.

Beispiel Desktop:

Banner (1 Feld) 560x370 pix, 37,6 KB hochgeladen, führt zur Meldung, dass bei 800er Thumbnail 36,1 (84%) eingespart werden könnten.

Banner (1 Feld) 1220x740 pix, 91 KB hochgeladen, führt zur Meldung, dass bei 800er Thumbnail 76,2 (88%) eingespart werden könnten.

Das zweite Banner ist in doppelter Größe hochgeladen worden, damit es nicht ganz so unscharf wird.

Nun frag ich mich,

a) wie SW bei dieser Auflösung auf eine solche Dateigröße bei Thumbnails kommen kann?

b) wie kann die Seite 5 MB haben? Weil die TN die 4fache Speichergröße der Originaldatei haben?

Insgesamt könnten bei dieser Seite 360 KB eingespart werden. Das geht eigentlich noch.

Bei der mobilen Version könnten 1,5 MB!!! eingespart werden.

Hier gibt es eine separate Einkaufswelt 3 Spaltig. Gleicher Inhalt evtl. 1-2 Banner weniger und die Dateien eben auf das Seitenverhältnis der Kästchen abgestimmt.

Hier werden die 1280er Thumbnails moniert. Einsparung überall 98-99% möglich.

Wozu macht man sich die Mühe, die Dateien mit möglichst wenig KB hochzuladen?

 

Würde ich nun alle zukünftigen Banner mit 1280 pixel an der kurzen Seite anlegen und optimiert hochladen, wäre natürlich die Originaldatei bereits viel größer. Würden dann die Thumbnails (die Speichergröße) nochmals vergrößert? Wenn die Datei verkleinert werden würde für 800er, 600er etc. dürfte die Datei nur kleiner werden - normalerweise. Stimmt das so?

Nachtrag: Wenn ich Artikelbilder mit 1280x1280 Pixel hochlade, hat die Thumnail mit 1280x1280 trotzdem eine größere Speichergröße.

 

LG

 

2

Gib doch bitte einmal die kritische Seite an, dann kann man mehr sagen.

LG Kerstin

3

Welche Seite soll ich angeben? Es geht doch hier allgemein um die Erscheinungen meiner Startseite bzw. deren Einkaufswelt.

LG

4

Hallo,

es geht halt um die Adresse zu der Seite bzw. zu deinem Shop. Dann kann man auch mal prüfen, welche Art Bilder und Dateitypen du nutzt etc.
Das könnte man dann mit eigenen / anderen Seiten und Darstellungen abgleichen. Sonst wird das mit Tipps und Ursachenforschung natürlich schwierig.

Ich kenne Kunden, die die Einkaufswelten um 90% Ladegröße verringern konnten, alleine dadurch, dass ein anderer Bildtyp verwendet wurde. Beispielsweise JPG statt PNG.
Aber das muss man sich halt am besten ansehen - sonst ist das reines Raten :wink:

Sebastian

5

Alternativ die Bilder komprimieren via tinypng.com und diese manuell hochladen.

6

Der Tipp von Sebastian ist schon mal sehr wichtig: als Bilder keine png verwenden. Die sind riesig. Logo oder Schriftzüge können evtl. png sein.

Shopware verwendet für Bilder (z.B. Banner) in den Einkaufswelten prinzipiell immer Thumbnails mit 1280 Pixeln Breite. Das ist ok, wenn ein Banner über die ganze Breite geht. Wenn du allerdings viele schmalere Bilder hast, sind die Bilder dafür viel zu groß. Nach deiner Beschreibung ist das bei dir so.

Diese Bilder solltest du, bevor du sie in den Mediaordner schiebst manuell auf eine geeignete Auflösung verkleinern. Ein Bild, das die Hälfte der Einkaufswelt einnimmt also  z.B. 640 Pixel. Der Medienmanager macht daraus dann Thumbnails, die vom Namen her zwar 1280 Pixel Auflösung haben, die tatsächliche Auflösung ist aber nicht höher als die des Originalbildes.

Das kannst du auch nachträglich machen, indem du die Originalbilder im Mediaordner mit entsprechend verkleinerten Bildern überschreibst und anschließend die Thumbnails neu generierst. Die Suche nach dem richtigen md5-Ordner ist zwar ein bisschen fummelig, wenn es nicht zu viele sind, aber durchaus machbar.

7

Die Domain möchte ich nicht öffentlich posten. Deshalb habe ich es oben auch so genau beschrieben…

Also:

Ich speichere jpg ab mit 72 dpi und 75% und lasse diese Dateien von optimizilla nochmals reduzieren. Das mache ich bei allen Bildern so.

Bei der Einkaufswelt speziell habe ich die Produkbilder exakt in der Größe erstellt die zu der “Feldzahl” passt. Also 2 Felder breit und 1 Feld hoch usw. Hier separat für das 3-spaltige Layout und für das 4-spaltige. Denn die Felder sind unerschiedlich groß und es soll nichts abgeschnitten werden. (Mobil verwende ich 3 Spalten, Tablet und Desktop 4 Spalten).

Wenn ich diese exakte Pixelzahl nehme sind alle Bilder in der Einkaufswelt unscharf. So bekam ich hier vor einem Jahr den Tipp, die Dateien in doppelter Pixelzahl anzulegen und da war das Ergebnis besser. Die Bewertung durch pagespeed war dennoch nicht so schlecht wie es jetzt der Fall ist. Wobei auch damals schon die 800er Thumbnails bei der Desktopversion und die 1280er bei der Mobilen bemängelt wurden.

Die aktuell verwendeten 11 Banner und 4 größere Bannerslider wurden von mir mit einer Größe von 1,2 MB insgesamt hochgeladen. Wie werden daraus 5 MB? Dass kann doch nur mit den Thumbnails zusammen hängen.

Beispiel an 2 kleinen Banern in der Desktopeinkaufswelt:

Banner (1 Feld) 560x370 pix, 37,6 KB hochgeladen, führt zur Meldung, dass bei 800er Thumbnail 36,1 (84%) eingespart werden könnten.

Banner (1 Feld) 1220x740 pix, 91 KB hochgeladen, führt zur Meldung, dass bei 800er Thumbnail 76,2 (88%) eingespart werden könnten.

Also die Dateien werden auf jeden Fall irgendwie größer nach dem Hochladen.

8

Also die Dateien werden auf jeden Fall irgendwie größer nach dem Hochladen.

Das ist normalerweise definitiv nicht so oder bei dir ist irgendein Sonder-Bug. Aus den gelieferten Zahlen kann man das auch nicht ablesen. Dass Einsparpotential besteht bedeutet ja nicht, dass sie vergrößert wurden. Prüf das noch einmal nach. (Im Sinne: Original ist 560 Pixel breit, Thumbnail 1280 Pixel oder so. Bzw. Original hat 0,5 MB, Thumbnail 0,7 MB). Dann kann man vergleichen.

9

Ich weiß nicht, wo ich diese Daten finde. Wearing-Sunglasses

Aber wenn von meiner Datei, die original 37,6 KB hat, google 36,1 KB einsparen will, dann wären weniger als 2 KB übrig. Es handelt sich hier nicht um Fotos, sondern um Grafiken mit Fotos und da ist 37,6 KB schon verwindend gering. Alleine das lässt darauf schließen, dass die Datei nach dem Hochladen oder besser gesagt die TN dazu größer wird.

Es gab auch eine ältere Diskussion dazu, bei der auch die Auskunft eines SW-Mitarbeiters in die Richtung ging. Nur finde ich die nicht mehr.

Jezt fällt mir ein, die TN-Größe sehe ich auch per ftp - melde mich…

10

So ich hab nun mal zwei Fälle zusammen gesucht.

Bei der mobilen Version sind es die 1280er Thumbnails von Produkbildern, die im Produktslider bzw. im Produktstream angezeigt werden.

Beispiel (Angabe in Byte):
Bild auf PC 968x700 pix, 72 dpi         99.500

unter media/image:
meindateiname.jpg                        101.967
meindateiname_200x200.jpg           11.772
meindateiname_600x600.jpg           69.271
meindateiname_1280x1280.jpg        154.122    149,2 KB (99 %) könnten eingespart werden

Bei der Desktopversion sind es die Einkaufsweltbanner, nicht die Produktstreams (obwohl es die gleichen sind) die bemängelt werden:
original auf PC 560x370 pix,         29.100
meindateiname_800x800.jpg        35.713    29,3 KB (83 %) könnten eingespart werden

Größer werden die Bilder wohl schon, aber nicht so, dass ich auf die 4-fache Größe käme. Ansich sind auch die Reduzierungsvorschläge von Google definitif nicht realistisch bei einer bereits komprimierten und reduzierten Datei. Aber irgendwie hat Google mit den Thumbnails scheinbar ein Problem.

Auf das Geschwindigkeitsproblem der mobilen Version hat mich die SEO-Agentur hingewiesen. Mein letzter Stand vor ein paar Monaten war 6x/100 bei google. Heute 31/100.

Zufällig wurde mir jetzt bei onpage.org die Startseite mit 5 MB angezeigt. Aufgrund dieser beiden Punkte suche ich jetzt den Fehler.

Da bei der Mobileversion die Bilder im Produktstream reklamiert werden, nehme ich die mal raus und belasse es bei den Bannern. Dann teste ich neu. Die Banner waren schon immer da, nur die Streams kamen kürzlich dazu.

11

Zumindest bei pagespeed habe ich wieder 67/100 und es wird kein einziges Bild bemängelt, wenn ich beide Produktstreams herausnehme. Stattdessen habe ich einen Bannerslider 2x3 Felder groß mit 4 aufwendigen Dateien gestartet - auch da wird nicht gemault.

Ob die 5 MB Meldung damit behoben ist, sehe ich erst beim nächsten Crawl.

Nun teste ich eine Kategorieeinkaufswelt, die nur einen Produktstream und ein kleines html-Feld hat dazu Kategorielisting. Problem: wieder die 1280er des Produktstreams. Ergibt bei Google 47/100 Punkten.

Aber irgendwie bräuchte die Produktstreams schon… ohne ist das echt bescheiden.

 

12

Da ich mich konkret mit dem selben Problem im Subshop rumschlage, habe ich eine konkrete Frage an die Entwickler:

Für die Einkaufswelten werden ja im Responsive 800x800 1280x1280 und 1920x1920 vorgegeben,
Müssen diese drei Größen zwingend an den ersten drei Stellen stehen?
Hintergrund: Füge ich noch weitere, kleinere Größen an, werden diese zwar im picture-tag aufgelistet, aber eben am Ende. Offensichtlich geht der Browser und PageSpeed aber davon aus, dass die Liste sortiert ist - sprich: zuerst wird 800x800 gefunden, das spätere 400x400 wird ignoriert - und ich komme bei PageSpeed nicht aus „orange“ raus.
Lösche ich aber für meinen Startseiten-Folder im Mediamanager die Größen und gebe noch 200x200 und 400x400 vor den anderen drei an, werde ich bei Pagespeed „grün“,

Hat es eine Auswirkung auf die Einkaufswelten - oder sonst wo - wenn ich VOR den drei Standardwerte noch kleinere setze?

Edit: In meinem Fall geht es um Banner … ggf. wäre es sinvoll, die Liste im Picture-Tag vor der Ausgabe der Größe nach zu sortieren.
Edit2: oben bitte picture durch img srcset ersetzen  Wink

13

Also bei sind es eindeutig nicht die Banner, sondern die Produktbilder im Artikelslider. Ich habe auch die Thumbnaileinstellungen nie geändert, da ich das insgesamt nicht verstehe. (Allerdings war ich immer der Meinung, dass Thumbnails Vorschaubilder sind und die logischerweise kleiner als das eigentliche Bild und nicht größer)

Zeigt Pagespeed bei dir in der Mobilen Ansicht keine zu großen Produktbilder an? Oder hast du keine Slider dort? Wenn du Slider hast und google meckert nicht, würdest du mir bitte sagen, in welcher Größe du die Bilder hochlädtst?

Meine haben überwiegend 700x700pix, 72 dpi, jpg 75% komprimiert und dann noch mal durch optimizilla geschickt. Kleiner geht die Speichergröße nicht. Wenn daraus dann 1280x1280 Bilder gemacht werden, kann das eigentlich nicht “scharf” werden, die Speichergröße erhöht sich vermutlich deshalb auch.

Lade ich 1280x1280 hoch (abgesehen davon, dass ich gar nicht alle Bilder in dieser Größe habe), habe ich von vornherein eine deutlich größere Datei. Wie sich das auf die Thumbnails auswirkt, weiß ich nicht.

14

Allerdings war ich immer der Meinung, dass Thumbnails Vorschaubilder sind

Shopware verwendet den Begriff Thumbnail tatsächlich ein bisschen verwirrend für alles, was aus den Original hochgeladenen Bildern abgeleitet wird. Die Thumbnails 1280x1280 sind die angezeigten „richtigen“ Bilder.

Wenn daraus dann 1280x1280 Bilder gemacht werden…

Werden es nicht!!! Die Thumbnails erhalten nur den entsprechenden Namen, die Auflösung ist maximal so hoch wie die des Originalbildes. Hatte ich auch schon einmal geschrieben.Wenn das bei dir anders sein sollte, ist da etwas ziemlich im Argen.

Viele Grüße

15

Im Hauptshop habe ich einen echten Banner, einen Bannerslider, einen EKW-Banner und eine Textbox, weiter 2 Blog-Elemente, 2 Kat-Teaser und 2 Artikel
Alle Bilder habe ich in der Darstellungsgröße der Desktop-EKW hochgeladen.
Im Desktop hat PageSpeed Insights auf der Startseite NICHTS an den Bildern zu meckern. Insgesamt komme ich auf 87/100
Im Mobile wird an der EKW auch nichts gemeckert.

Der Subshop hat 6 quadratische Banner und unten eine Textbox.
Die Banner sind mit doppelter Größe, wie die Darstellung im Desktop wäre, angelegt - 760px
Hier wird ohne zusätzliche kleine Thumbnails gnadenlos abgewertet - Desktop und Mobile
Ich müsste für diese Bilder die Qualität der Thumbnails auf max 10 Stellen, damit zumindest für den Desktop das Gemaule aufhört.

Ganz übel werden die Einkaufswelten mit den 6 Bannern im Mobile wegen dem Nachladen der EKW-Elemente abgestraft, weil nur 1% des Seitenladens zur sofortigen Anzeige führt, der Rest wird nachgeladen.

Ob ich für den Hauptshop schon vorher besondere zusätzliche Thumbnails angelegt habe, muss ich erst mal nachgucken.
[Edit: nein - aber die Bilder sind ja demnach auch nur halb so breit und halb so hoch wie im Subshop]

P.S.:Die “DPI” im jgq haben hier keine Bedeutung. Sie sagen lediglich, wie groß das Bild ausgedruckt wird, wenn man diese DPI berücksichtigt.

 

[Edit2] Bilder werden nicht hochskaliert - sie werden dann mit den Originalabmessungen gespeichert - sie werden lediglich für die Darstellung als Thumbnails mit der großen Bezeichnung angelegt - sind aber nicht so groß.

16

Da auch ich von dieser Problematik weiss, habe ich die EKW auf der Startseite weg gemacht. Die Rankings wurden grottenschlecht. Als ich die Startseite als normale Website mit Text und paar kleinen Fotos aufgebaut habe, steigen die Rankings wieder nach vorne. Ich nehme die EKWs nun nur noch für Kategorieseiten, die nicht so sehr wichtig sind. Also von 150 Kategorien vielleicht 6 oder 7 EKWs. Dann passt das auch.

Ich habe bei meinem neuen Projekt nun auch komplett eigene Thumbs angelegt. Viel kleiner als die Original Thumbs. Die ersten Tests zeigen, dass diese für die Desktop, Tablet und Smartphone Ansicht locker ausreichen. Mit Photoshop extrem komprimiert, aber noch so, dass diese auch tatsächlich noch scharf bleiben. Optisch, in Listen, Kategoriebannern, Blog und Artikeldetail merkt man eigentlich überhaupt nicht, dass ich die Thumbs verkleinert habe. Alles passt sich automatisch responsive an.

Bei den Artikeln habe ich z.B. das Thumb 0 mit 140x140 gemacht. Dabei wirkt es auch nicht recht viel kleiner als die 200x200 Thumbs. Spart aber ne menge Ladezeit ein und der Shop ist momentan blitzschnell.

Auch habe ich überall den kompletten Balken mit Filter und Sortierung entfernt. Das bringt auch was.

Z.B. hat ein Kategoriebanner bei mir im Moment mit 600x100 px Breite ca. 20-30 KB. Weniger geht aber nicht, damit es noch scharf bleibt.

Es wäre gut, wenn man z.B. für Desktop und Tablet eine EKW anlegen könnte und bei Mobile die herkömmliche Website Ansicht verwendet könnte, solange man keine extra EKW für Mobile Geräte macht. Geht das irgendwie? Wenn ich eine EKW nur für Desktop und Tablet anlege, ist die Seite auf Mobile leer, wenn ich dort nicht auch extra eine EKW dazu mache.

Ebenfalls gut wäre es, wenn man in der Kategoriemaske ein Kategorietextfeld für Desktop und Tablet hätte (also das bisherige), und für die Mobile Off Canvas Ansicht ein extra Textfeld, damit man dafür einen speziellen Text separat für Smartphone machen kann. Also ohne die Nutzung von EKW. Somit wäre auch das Thema der doppelten Kategorietexte für Desktop und Off Canvas kein Problem mehr. Am Handy bräuchte man ja schliesslich nicht ganz so viel Text, weil es eh keiner liest. :slight_smile:

 

Viele Grüße

Matthias

 

17

Ich glaube ihr seid hier ein klein wenig auf dem Holzweg. Es ist mit den Einkaufswelten und den beschriebenen Methoden leicht möglich, google Pagespeed zufrieden zu stellen.

18

Wenn ich das hier so lese, sind die Ergebnisse/Einstufung von google bei den versch. Shops völlig unterschiedlich.

EKW-Banner:

Ich verwende in der EKW nur EKW-Banner, teilweise auch in doppelter Pixelzahl, aber die werden bei Mobile gar nicht bemängelt, aber bei Desktop die 800er Thumbnails dazu.

Produktslider:

In der mobilen Einkaufswelt werden nur die Thumbnails 1280x1280 der Produktslider bemängelt, und das sehr stark.

Bei der Desktop-EKW stören die Produktslider nicht.

Bei einer normalen Kategorie mit vielen Artikeln im Listing wird nicht gemeckert, weder bei Mobil noch bei Desktop, obwohl die Produktvorschau doch ähnlich der der Slider ist.

 

Zur Speichergrößenveränderung bei Thumbnails (@Gutverkaufen‍ ):

Du hast Recht, die Pixelzahl erhöht sich tatsächlich nicht, aber die Speichergröße erhöht sich. Die Differenz zwischen der Größe auf einem PC und der Originaldatei nach dem Hochladen lassen wir mal außen vor. Es ist auch logisch, dass bei Verkleinern auf 200 oder 600 die Speichergröße kleiner wird. Aber warum wird die Speichergröße bei 1280 größer, wenn die Pixelzahl gleich bleibt?

Gerade nochmal ein anderen Bild angeschaut, das bereits im Original etwas größer ist:
mein Bild auf PC 1050x700 pix         184.000 Byte

unter SW:
meindateiname_1280x1280.jpg        256.000 -> also ca. 70.000 Byte größer obowhl immer noch 1050x700 Pixel

 

@Kerstin83‍

Welche Methoden meinst du?

19

@Toric‍

Du musst Da aber auch auf die Thumbnailqualität achten.
Exportiere ich in Photoshop ein Bild als jpg, kann ich die Qualität bis 100 einstellen. Für die meisten Bilder reicht bei mir in der Regel ein Wert zwischen 45 und 60.
Die Werte für die Thumbnailsgenerierung dürften ein ähnliches Verhalten haben. Evtl. mal die Bilder einer EKW in einen separaten Ordner verschieben, und in dem mit der Qualität experimentieren.

Für Haupt- und Subshop bin für Desktop „grün“, für Mobile bleibe ich „orange“.
Und zwar wegen „rot“:

Behebung erforderlich:
JavaScript- und CSS-Ressourcen, die das Rendering blockieren, in Inhalten "above the fold" (ohne Scrollen sichtbar) beseitigen
Ihre Seite enthält 3 blockierende Skript-Ressourcen und 1 blockierende CSS-Ressourcen. Dies verursacht eine Verzögerung beim Rendern Ihrer Seite.
Keine der Seiteninhalte "above the fold" (ohne Scrollen sichtbar) konnten ohne Wartezeiten für das Laden der folgenden Ressourcen gerendert werden. Versuchen Sie, blockierende Ressourcen zu verschieben oder asynchron zu laden, oder laden Sie kritische Bereiche dieser Ressourcen direkt inline im HTML.
Entfernen Sie JavaScript, das das Rendering blockiert:
/modernizr/modernizr.custom.xxxxxx.js
/web/cache/1474547990_7be57ca708db8e6691e1d103cf408a79.js
/web/cache/1474547990_7be57ca708db8e6691e1d103cf408a79.css

Da dürfte ich wohl ohne tiefere Umbauten kaum etwas ändern können

Besonder witzig ist der - wenn auch nur „orange“ -  da in einem Shop 66% und im anderen 1%
Der mit „mehr“ EKW und weniger Text hat 66, der andere nur 1%
 

Sichtbare Inhalte priorisieren
Für Ihre Seite sind zusätzliche Netzwerk-Roundtrips erforderlich, um die ohne Scrollen sichtbaren Inhalte ("above the fold"-Inhalte) darstellen zu können. Reduzieren Sie die zur Darstellung von "above the fold"-Inhalten erforderliche HTML-Menge, um eine optimale Leistung zu erzielen.
Die gesamte HTML-Antwort war nicht ausreichend, um den ohne Scrollen sichtbaren Inhalt zu rendern. Dies weist üblicherweise darauf hin, dass zusätzliche, nach dem Parsen des HTML geladene Ressourcen zum Rendern des ohne Scrollen sichtbaren Inhalts erforderlich waren. Priorisieren Sie den sichtbaren Inhalt, der zum Rendern ohne Scrollen erforderlich ist, indem Sie ihn direkt in die HTML-Antwort integrieren.
Nur etwa 1 % der Seiteninhalte, die in der endgültigen Version ohne Scrollen sichtbar sind, konnten mit der vollständigen HTML-Antwort gerendert werden siehe ScreenshotOriginal anzeigen.

Beides nur leicht angepasstes Responsive

An meinen Bannern gibt es nun garnichts mehr zumeckern, nachdem ich VOR den 800, 1280, 1920 noch 200 und 400 gesetzt habe.
Dann wird nämlich für Mobile auch wirklich nur das kleine Thumbnail gewählt.

Für andere Bereiche wird man vermutlich nichts kleines vor den Werten setzen können, da ja im Theme expliziet die Thumbnails 0 1 etc. für die Darstellung ausgewählt werden - was im srcset der EKW-Banner nicht der Fall ist.

Edit: PageSpeed ist wohl ein bischen doof zwischen den Augen, was das Protokoll betrifft.
Shops leiten direkt in der htaccess auf https um, wenn nur http aufgerufen wird.
Gebe ich bei pagespeed die Seite ohne extra https ein, brechen die Punkte ganz ein - das Tool schnallt nicht die Umleitung und ruft wohl jedes Element zunächst mit http auf und wundert sich üvber die Umleitung *Vermutung*

20

Wie schon gesagt, optimiere ich die Bilder bereits in PS bzw. einem andern Programm und speichere sie schon kleinstmöglich ab. Dann macht Optimizilla den Rest. Meine Bilder sind generell etwas größer als Fotos, weil s eben Grafiken/Montagen sind.

Meine Original-Datei scheint gar nicht das Problem zu sein, sondern das was die TN daraus machen.

Ich habe diese Einstellung bei EKW:
Thumbnailqualität 90
High-Resolution TN ja
HR-TN Qualität 60

TN Größen 800, 1280, 1920

Bei den Artikelbildern:
Thumbnailqualität 90
High-Resolution TN ja
HR-TN Qualität 60

TN Größen 200, 600, 1280

 

Welche TN finden nun bei den Bildern im Artikelslider bei der mobilen Version Verwendung oder sollten Verwendung finden? Lt Google sind es die 1280er und die sind zu groß, also bei gleicher Pixelzahl größer als das Original.

Da ist aus meiner Sicht zunächst zu klären, warum eine Datei mit 1050x700 Pixel hochgeladen zu einer 1280er TN wird mit 1050x700 Pixel aber 70KB größer. Da kann wohl nur SW etwas dazu sagen.

Welche TN finden im Kategorielisting bei den Produkten Verwendung? Die 1280er können es eigentlich nicht sein, denn dort meckert google nicht.

PS: die anderen beiden Meldungen habe ich auch bzw. hatte ich schon immer, aber mit Java und css befasse ich mich später. Erst will ich die Bilder in Ordnung bringen.