Vorschaubilder 400px

beats TEST blog

Mittwoch, 29. Januar 2020

Vorschaubilder 400px

Bild links mit Fliesstext
Bild links mit Fliesstext

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque ultricies, mauris id convallis vulputate, quam justo hendrerit dolor, a mattis libero justo sed purus. Vivamus quis lorem ut erat aliquam commodo. Vivamus sit amet diam sed turpis mollis imperdiet quis aliquam massa. Vivamus luctus, risus eu blandit fringilla, nunc risus scelerisque erat, ut rutrum augue enim id ante. Vivamus luctus massa gravida, placerat augue quis, mattis ante. Sed faucibus mattis varius. Cras quis ligula vel est ullamcorper maximus sit amet et nisl. Mauris dolor nisl, congue id magna sit amet, finibus rutrum odio.

Bild rechts mit Fliesstext
Bild rechts mit Fliesstext

Duis lacinia enim id eros blandit tincidunt. Maecenas venenatis est lectus, quis euismod massa fermentum ut. Cras in purus non ipsum ultricies porta et et ipsum. Integer pharetra rutrum lacinia. Duis tincidunt eu nisi at pretium. Ut egestas sem quis nunc vehicula hendrerit. Phasellus eget bibendum odio, in sollicitudin velit. Sed quis elit mattis, accumsan nisl a, congue lectus. In facilisis arcu efficitur tempor posuere. Vestibulum mollis vitae augue a viverra. Sed lorem metus, venenatis sit amet nisl sed, elementum porta orci. Nam sit amet diam egestas, accumsan erat viverra, efficitur sem. Sed varius tellus vel urna dapibus rhoncus. Sed quis eros in nunc efficitur gravida a in nisi.

Trackback-URL für diesen Eintrag

Dieser Link ist nicht aktiv. Er enthält eine kopierbare Trackback-URI, um manuell ein Ping- und Trackback zu diesem Eintrag für ältere Blogsysteme zu generieren; zB (immer noch valide) über das zur Verfügung gestellte Eintragsfeld des serendipity_event_trackback Plugins. Serendipity und andere Blogsysteme erkennen die Trackback-URL heutzutage aber automatisch anhand der Artikel-URL. Die Trackback-URI für ihren Link des Sender-Eintrages lautet daher wie folgt: »https://www.blog.dokumenzi.ch/2629-Vorschaubilder-400px.html«

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

  1. Beat Post author am :

    Um den skalierenden Effekt der Bilder zu sehen, muss man die Anzeige (Bildschirmgrösse) reduzieren.

  2. Beat Post author am :

    ? when magic happens... ? mit neuer /pure/style.css skalieren nun auch Bilder mit Kommentaren. ?

  3. Ian Styx am :

    Yeah!

    So ist das wenn Gott hinten sitzt! ?

  4. Beat Post author am :

    Ich habe da so eine Idee... ?

    Mir sind die Vorschaubilder mit 400px noch immer zu gross/breit. Ich könnte den Codeschnipsel doch insofern abändern, dass die Vorschaubilder ganz generell (und nicht nur für Displays unter 768px) auf 48% Screenbreite reduziert werden... ?

    Dann würde ich die 400px wirklich ernsthaft in Erwägung ziehen... ich müsste dann nur noch darauf verzichten, auf gleicher Höhe links und rechts ein Vorschaubild zu platzieren. So wie ich es z.B. hier (wieder) gemacht habe: https://www.beatsblog.ch/2589-Schnorchel-Trip.html

  5. Ian Styx am :

    Ja... das könntest du wohl...?

    zb bei 768px auf 60% dann bei 980px auf 68%, bei 1024px wieder auf 48% und dann über 1200 1440 sukzessive hoch (nicht geprüft).

    Warum müsste dann noch darauf verzichten, auf gleicher Höhe links und rechts ein Vorschaubild zu platzieren..?

    Update:
     

    @media screen and (min-width: 768px) {
    .post .serendipity_imageComment_left,
    .post .serendipity_imageComment_right,
    .post p .serendipity_image_left,
    .post p .serendipity_image_right {
        max-width: 42%; }
}

    in die user.css ginge auch.

  6. Ian Styx am :

    Übrigens: Wie heißt das Inselchen mit der Schaukel? Sieht genau so aus wie ich einen Strand liebe! Und muss ich mir dringend deshalb einmal vormerken.

  7. Beat Post author am :

    Ko Lon (https://www.cruiserisland-resort.com/)

  8. Ian Styx am :

    Ich habe gerade pure ein ähnliches update verpasst...

    Man muss bedenken, ist das link/rechts umflossene Image 400 default px oder sogar ein größeres Bild bis vielleicht 600px, so kann es jetzt langsam vom kleinsten mobile über 768px bis 1023px mitwachsen, sowie dann erneut noch einmal von 1024px auf 1600px erneut heranwachsen. Das müsste eigentlich so ungefähr alle Möglichkeiten erschlagen und du bräuchtest nicht in deinem child theme noch einmal extra etwas einfügen.

  9. Beat Post author am :

    Habe jetzt -so auf die Schnelle- das neuste /pure/style.css-File nicht gefunden. Also kein Update hier.

    Wir sind heute unterwegs nach Bangkok. Werde also kaum Online-Zeit finden.

    So als Laie frage ich mich natürlich, weshalb Du das Ganze so kompliziert und mit mehreren Abstufungen gemacht hast. Ich fand die Idee, generell maximal 48% der Beitragsbreite für ein Vorschaubild zu nutzen ganz smart (hat was symetrisches, halb Bild, halb Text). So würde es smooth von ganz gross bis ganz klein in etwa gleich aussehen. Aber: das sind nur meine Gedanken. Ich werde die neusten Stix-Daten bei Gelegenheit hochladen und mir Deine Lösung dann genau ansehen.

    Von wegen "zwei Vorschaubilder nebeneinander" -> bei 2 Vorschaubildern braucht es min. 800px Beitragsbreite. Erst ab da passen noch irgendwelche Buchstaben dazwischen. Hier, mit 2 Seitenleisten, muss dann die Anzeige min. 1'200px betragen, bevor erste Buchstaben zwischen die Bilder passen. Deshalb bin ich der Meinung, dass ich zukünftig diese Darstellungsform meiden sollte.

  10. Ian Styx am :

    Naja diese 48% für die links und recht umflossenen Images werden ja vom User Browser jeweils auf die content- (Beitrags)-breite berechnet. Um diesen zusätzliche Aufwand zu vermeiden, wo es voraussichtlich komplett unnötig sein wird diese Berechnung auszuführen, habe ich die Abstufung auf 100% gesetzt. Das ist auch für denjenigen, der sich später mal den code anschaut, an dieser Stelle verständlicher, was da beabsichtigt ist.

    Die "zwei Vorschaubilder nebeneinander" Ansicht kannst du ja leicht selbst verbessern/anpassen und damit "schöner/fließbarer" für den Text machen, in dem du zB 42% benutzt.

    Gute Reise

  11. Ian Styx am :

    Ich habe das alles generell nochmal überarbeitet, für die globale default/style_fallback.css und bis jetzt für die default, pure und dude themes. Ich nehme an, dass ich das auch noch für mindestens einen Teil der anderen core themes machen werde. Insofern müsstest du dann wieder zu Hause sowieso mal alles durchsyncen (auch für styx.doku).

    Als gute Größe hat sich ~46% herausgestellt und - je nach theme - bis ~48%.

  12. Beat Post author am :

    Ich habe alle drei Installationen mit den neusten Daten upgedatet. Das history-Plugin funktioniert jedoch nicht auf Anhieb. Ich kopierte manuell die Files /include/functions_entries.inc.php und /plugins/serendipity_plugin_history/serendipity_plugin_history.php. Danach löschte ich /templates_c/history_daylis.dat und dann funktionierte es wieder. Ist das noch nicht Teil des Kerns?

    Nachtrag: Komisch... das war nur hier so. Auf www.beatsblog.ch hat es ohne Intervention gleich funktioniert.

  13. Ian Styx am :

    Doch nicht dahingerafft... von Bangkok Nights... ;-)

    Ich weiß nicht warum. Warum hast du das neu aufgespielt? Da haben wir doch gar nichts mehr gemacht seit neulich..
    Beobachte das bitte weiter. Wäre ja schade wenn da noch irgendein Fehler sein sollte.

  14. Beat Post author am :

    Für Bangkok-Nights bin ich zu alt. doch klimatisierte Flugzeuge und eiskalte U-Bahnen haben mir einen kräftigen Schnupfen beschert. Deshalb verbringe ich den heutigen Tag im Hotel und vor dem PC ?

    Die Anzeige des History-Plugins war leer. Deshalb habe ich die oben genannten Masnahmen unternommen. Dann funktionierte es wieder. Ich werde das bei nächsten Updates im Auge behalten. Doch wie gesagt: Auf www.beatsblog.ch hat es sofort wieder funktioniert. Vielleicht war ich hier auch einfach zu hektisch... ev. hätte ein Refresh der Seite gereicht...

  15. Ian Styx am :

    Ich habe dem ckeplus Plugin dahingehend ein Update verpasst. Jetzt scaled alles auch korrekt in der wysiwyg-mode Ansicht des Editors auf mobile screens.

    Wahrscheinlich muss man seinen Browser sanft dazu überreden seinen Cache für diesen Fall neu zu laden.

    F12 - Dann Stilbearbeitung - in der (linken) Liste die wysiwyg-style.css finden und mit rechter Maustaste anklicken - Link in neuem Tab öffnen wählen und den neuen Tab ansehen. Wahrscheinlich steht die Version noch auf 1.10. Ein Mal reload per F5 und sie ist auf dem neusten Stand, v.1.11! Nun zurück zum Eintrags Editor Fenster und ebenfalls ein mal F5 drücken. Jetzt müsste alles am Platz sein und man kann sich zb einen Eintrag mit 400px left/right umflossenen Bildern auf seinem Mobile korrekt gescaled ansehen! ?
    (Analog/Angepasst für andere Browser als Firefox.)

  16. Beat Post author am :

    Du hast mich rumgekriegt. ?

    Habe auf www.beatsblog.ch die Vorschaubildgrösse nun auf 400px (längste Seite) umgestellt und die Thailand-Beiträge entsprechend editiert.

    Witzig ist, dass es in der mobilen Ansicht auf meinem Smartphone keinen sichtbaren Unterschied zu vorher gibt. Bei wenig über 400px Anzeigebreite skalieren die Vorschaubilder nun auf ca. 200px (so wie vorher).

    In der Desktop-Ansicht muss ich mich noch etwas an die grossen Vorschaubilder gewöhnen, doch das kommt schon.

  17. Ian Styx am :

    Wunderbar!

    Du wirst es wertschätzen lernen und besonders, wenn du auch mal einen Eintrag mit der Galerie Funktion machst.

  18. Beat Post author am :

    Galerie Funktion = ?

    Dafür muss ich wohl erst das Styx-Handbuch lesen? ?

  19. Ian Styx am :

    Nee! Das ist in der Toolbar der "bunte" Button neben dem "Bild" Button. Beste Bedingung für die Auswahl ist, dass man vorher in der Mediathek über den Sortierungsbutton (der neben Filter) eingestellt hat: Ja Ohne Dateien von Unterverzeichnissen. Und vielleicht, wie man in der info zur Galerie lesen kann, seine Mediathek auch dahingehend etwas restrukturiert hat, wenn man es öfter oder thematisch nutzen will. Empfehlenswert sind zB Strukturierungen nach Thema ähnlich den Kategorien mit verschachtelten Subordnern, oder mit Datierungen etc. jedenfalls etwas, was eine bewegliche und gute Struktur als Verästelung zulässt und man trotzdem Zusammenhängendes an einem Platz hat. ?

  20. Beat Post author am :

    Ja, jetzt erinnere ich mich wieder. Im letzten Oktober habe ich das mal mit S9Y und mit Styx getestet (https://www.s9y.dokumenzi.ch/Mehrere-Fotos.html). Mir fehlt bei dieser Funktion jedoch die Möglichkeit den Bildern Kommentare mitzugeben. Für eine reine Foto-Galerie ist es i.O., wenn man damit jedoch eine Art Geschichte erzählen will, dann braucht es Bild-Kommentare. Für mich ist das deshalb  eher nichts.

  21. Ian Styx am :

    Der Link beweist, das du das nicht wirklich getestet hast. Das sieht komplett anders aus wenn per row oder per col (recommended)  kreiert. Vielleicht lag das daran, dass du das mit so kleinen Bildern gemacht hast. Wie die Beschreibung (auch damals schon) besagt(e), müssen die Bilder mindesten 260px groß sein. Am besten geht es wie immer mit den 400px Vorschaubildern. Das ist eine Bilder-Galerie, da muss nichts per Bild kommentiert vorliegen, ähnlich der Goggle Bildervorschausuche - Mist, schlechtes Beispiel - nur ohne Kommentare - oder https://help.weblication.de/helpAssets/img/10x-de/weblic-liste-bildergalerie-var2.png oder so. Ich persönlich finde die Spaltenansicht besser, da sie die Bilder komplett selbst so anordnet das keine Überhänge usw entstehen. Bild zum großen Link geht ja trotzdem. Kommentiert kann eine Galerieansicht halt per darüber oder darunterliegendem Paragraphen.

  22. Ian Styx am :

    Ach entschuldige, das linkt ja auf s9y.dokumenzi.. Das ist nicht Styx!
    Die haben sich auch irgendwann mal danach an einer Galerie probiert... Das Ergebnis sieht man eben auch, alles etwas unausgegoren und unfertig.

    Styx ist komplett anders!

     

  23. Ian Styx am :

    Nochmal zur Ordnung in der Mediathek.

    Jahr 2020 ist gut, 20200125.jpg ist nicht so gut.

    Besser wäre 2020 / 01 / chinese_new_year.jpg. So dass die Struktur sich an Jahr / Monat (auch weil so schön kurz) orientiert, die eigentlichen Bilder aber semantisch benamt sind. Ab einer gewissen Menge hilft das sehr, weil man zB besser suchen kann, etc.. ?

  24. Beat Post author am :

    Häh? Kürzer als 20200125.jpg geht wohl nicht. 2020=Jahr, 01=Monat, 25=Tag. Mehr Ordnung brauche ich nicht. Ist Blog-Logik, strikt der Zeit unterworfen. Ich sehe überhaupt keinen Vorteil von sprechenden Bildnamen.

  25. Ian Styx am :

    Doch! 2020 / 0125.jpg, oder sogar 20 / 0125.jpg. ?
    Aber darum ging es auch nicht. Du hast 20200125.jpg im 2020 Order, also strukturell 2020 / 20200125.jpg. Ordner sind OK, Namen nicht so sehr, zB nach eniger Zeit, wenn einem oder anderen 20200125.jpg nichts (mehr) sagt. Auf den Fall habe ich hingewiesen und gemeint, dass es dann einfacher für die Suche usw wäre, ohne dass man sich immer erst die Vorschau ansehen muss um zu sehen was das eigentlich war. Aber das macht jeder so wie er will und wie  es ihm passt.

  26. Beat Post author am :

    zB nach eniger Zeit, wenn einem oder anderen 20200125.jpg nichts (mehr) sagt. Auf den Fall habe ich hingewiesen und gemeint, dass es dann einfacher für die Suche usw wäre, ohne dass man sich immer erst die Vorschau ansehen muss um zu sehen was das eigentlich war.

    Ich verstehe Deine Worte - den Sinn dahinter aber nicht.

    In meinem Blog gibt es mittlerweile über 3'000 Bilder. Trotzdem habe ich bisher noch nie (länger) nach einem Bild gesucht. Die Bilder stehen ja immer im Kontext zu einem Blogbeitrag. Falls, und ich betone: Falls, ich also je nach einem bestimmten Bild suchen würde, bemühe ich die Blogsuche mit den relevanten Suchbegriffen und werde innert Sekunden fündig. Ein Rechtsklick aufs Bild und schon kann ich die Grafikinfo ansehen. Ich habe bisher noch nie, nie, nie ein Bild in der Mediathek gesucht. Und ehrlich: Ich sehe auch kein Grund weshalb ich das tun sollte. Es dürfte etwas anderes sein, wenn in die Mediathek weitere Bilder hochgeladen werden, die nicht in Beiträge eingebunden werden. Das mache ich aber nicht. Das ist ja mein Blog und nicht meine Media-Cloud.

    Wir scheinen diesbezüglich einfach andere Ansichten zu haben. Das können wir auch einfach mal so im Raum stehen lassen.

  27. Beat Post author am :

    Bin wieder zuhause und am grossen Monitor beginnen sich die 400px-Vorschaubilder nun zu verschachteln (weil nicht genügend Text dazwischen ist. Das ist ziemlich unschön. Ich wusste mir nicht anders zu helfen, als horizontale Linien einzufügen, damit ein nächstes Bild dann wieder den vollen Platz kriegt. Siehe z.B.: https://www.beatsblog.ch/2589-Schnorchel-Trip.html

    Die Linie gefällt mir nicht sonderlich (ich weiss, ich könnte sie via CSS verstecken). Gibt es eine elegantere Lösung um einen neuen Absatz/Paragrafen zu starten? Ich versuchte es mit div und p, was aber nicht funktioniert hat.

  28. Ian Styx am :

    Welcome Back.
    Hoffentlich hast du damit die Schweiz nicht in "zukünftige" Quarantäne geschick! ?

    Im Grunde beschreibst du es genau richtig. Wenn ein Paragraph Text so klein/kurz ist (am großen Monitor), dass ein links/rechts zugesetztes Bild zu groß für ihn ist, helfen entweder nur leere Füllparagraphen, die natürlich auf kleineren Bildschirmen dann ihrerseits für Aufruhr sorgen, oder ein Element wie hr ( vielleicht sogar als style="visibility:hidden" ausgezeichnet, oder man eben baut zwei oder mehr ehemalige Paragraphen so zusammen, dass sie nur ein Paragraph sind und der ehemalige Trenner zwischen ihnen aus zwei br Elementen besteht. Das ist Shift-Enter im CKEditor. Das ist die hohe Kunst des Editing: Denke mit!

  29. Beat Post author am :

    ... ein gequältes Lächeln... die hohe Kunst des Editing wird mir verschlossen bleiben... ich habe dankbar Deine Anweisung übernommen.

    .post_content hr {
    visibility: collapse;
}

    ... mit kleineren Vorschaubildern hätte ich diese Probleme nicht. Ich habe noch immer Mühe mit diesen übergrossen Vorschaubildern. Ein wirklicher Vorteil hat sich mir bisher noch nicht erschlossen.

  30. Ian Styx am :

    Ich nehme das mal als leicht grummeligen Einwurf im Fieberwahn.. ?

    Was du vorher (und das Problem haben wir ja beseitigt) an den größeren Thumb Bildern bemängelt hast, dass sie auf kleineren Devices - solange die Breite des Gerätes nicht kleiner war - genau so groß blieben und damit der rechts/links umflossene Text "verlorenging", hattest/hast du doch andererseits und analog mit diesen Minis auch, wenn du einen Desktop benutzt. Dann sind sie zu mini und scalen sich auch nicht hoch, was ja verlustbehaftet wäre. Scalen geht eben nur abwärts gut. Aufwärts geht immer mehr Information verloren. Deshalb nutzt man nicht das untere Darstellungs Ende als thumb, sondern einen guten Mittelweg. Da haben wir uns mit Serendipity 2.0 damals auf 400 entschieden. wo vielleicht auch 360 gereicht hätten. Damit kann man leben.
    Das ist das Eine.
    Das andere ist, dass alle features (wie zb, die Galerie) und alle Mediatheks und andere Bildansichten des Systems auf die normal Vorgabe 400px abgestimmt sind. Sicher, es geht auch irgendwie mit weniger. Aber man hat Verluste, die bedeutend schwerer wiegen, als sich von "vorsintflutlichen" Miniansichten zu trennen.

  31. Beat Post author am :

    ? Ja, ja... Fieber und Trennungsschmerz... ?

    Ich bin halt vielleicht etwas festgefahren. Nach etwa 8 Jahren mit 150px und nochmal 8 Jahren mit 200px Vorschaubildern brauche ich halt etwas Zeit um mich an die neuen 400px Thumbs zu gewöhnen. Aber: Ich bemühe mich... ?

  32. Ian Styx am :

    Brav! ?

  33. Ian Styx am :

    Ich habe gerade mit einem eleganten Kniff das Verschachtelungs und overlap Problem gelost. Damit ist die Benutzung von hr Elementen und ihres collapses hinfällig. ?

  34. Beat Post author am :

    Falls dieser elegante Kniff in den Download-Daten vom 05.02. von 20:18 Uhr enthalten ist, so überzeugt mich das Resultat nicht wirklich.

    Vorschaubilder werden nun nicht mehr umflossen, sondern der Fliesstext bleibt immer gleich breit (fliesst also nicht mehr unter das Bild). Siehe z.B. https://www.beatsblog.ch/2595-schoene,-neue-Raeder.html

    Wenn ich hr lösche, verschachteln sich die Bilder wieder wie zuvor. Deshalb habe ich nach einem Test die hr's wieder eingesetzt und kann Dir darum kein Beispiel-Link angeben.

  35. Ian Styx am :

    Ops, ? ich sehe es. War wohl ein Schnellschuss! Schade!

    Entferne das overflow in #content p solange.

  36. Ian Styx am :

    Gefixt. Sollte jetzt sogar das image overlap Problem auch mit lösen, also bitte mal im user.css das https://www.blog.dokumenzi.ch/2630-Bilder.html#c6452 wieder löschen und nachkontrollieren.

  37. Beat Post author am :

    Danke! :applaus:

    Habe postcontent: inline-block aus der user.css gelöscht. Zusammen mit den neuen Daten sieht es jetzt ganz gut aus! ?

  38. Ian Styx am :

    Ja das sieht jetzt alles gut aus und es macht viel Spaß durch deine alten und neuen Einträge zu surfen!

    Ich wünschte ich hätte solch erworbene Kraft um solche Touren zu machen. Das muss klasse sein! Toll!

    Was mir dabei auffiel ist, dass die entries Liste auf beatsblog jetzt ziemlich flüssig läuft, egal wie weit man in die Vergangenheit geht und dort eventuell vielleicht sogar noch nie war. Die Einzelseiten allerdings haben immer noch diesen furchbaren Jetlag. Bist du dem schon auf die Spur gekommen?

    https://www.beatsblog.ch/2402-Tag-11-nach-Levanto.html
    50 Anfragen
    1,37 MB / 704,81 KB übertragen
    Beendet: 5,35 s
    DOMContentLoaded: 4,56 s
    load: 4,94 s

    Auf der entries Liste Seite ist das beispielsweise

    44 Anfragen
    1,54 MB / 1,24 MB übertragen
    Beendet: 1,93 s
    DOMContentLoaded: 1,18 s
    load: 1,88 s

    Schon ein ziemlich relevanter Unterschied.

  39. Beat Post author am :

    ? Danke für die Blumen! ?

    Bezüglich Geschwindigkeit: Ich habe vorgestern Abend in der Blog-Konfiguration die GZIP-Kompression eingeschaltet. Zusätzlich implementiere ich in .htaccess die APCU-Module:

    • Module mod_deflate.c
    • Module mod_expires.c
    • Module mod_headers.c

    Das hat dann doch einen guten Boost gebracht. Wenn dann keine grösseren Änderungen mehr anstehen, werde ich auch noch .js und .css minimieren.

    Der von Dir genannte Artikel (nach Levanto) ist einer dieser Artikel, in denen das Garmin-iframe eingebunden ist. Das braucht ziemlich Zeit, bis es geladen ist. (Auch deshalb werde ich diese iframes nicht mehr direkt einbinden, sondern auf die Garmin-Seite verlinken). Habe übrigens gerade gemerkt, dass das iframe nicht angezeigt wird (im Seitenquelltext wird es aber erwähnt), Komisch.

    Soweit bin ich also ganz zufrieden. ?

     

    A propos .htaccess -> Ich konnte meine Fotoalben nicht ansprechen und bemühte deswegen den Manitu-Support. Das war die Antwort:

    In Ihrer .htaccess-Datei befindet sich eine Zeile

    > RewriteRule (.*\.html?) index.php?url=/$1 [L,QSA],

    welche alle .html-Dateien, auch die des Fotoalbums, wieder "zurückgeleitet" werden. Ich habe diese Regel soeben einmal durch ein vorangestelltes "#" deaktiviert.

    Aktuell wird das Fotoalbum korrekt ausgeliefert. Können Sie bestätigen, dass die "restlichen" Komponenten Ihre Website weiterhin funktionieren?

    Interessanterweise macht diese Zeile hier, auf dem hosttech-Server, überhaupt kein Problem und das einzige installierte Fotoalbum (TREK 1120) läuft problemlos. Auf dem Manitu-Server muss aber allem Anschein nach diese Zeile raus. Na ja, nun funktioniert es.

    Zudem sind nun alle Uploads-Verzeichnisse mit 770er-Berechtigungen (und es funktioniert).

  40. Ian Styx am :

    noch .js und .css minimieren

    Also ehrlich... ich bin kein Freund von solchen Sachen, der Mehrwert durch eine geringere Größe wiegt IMHO nicht auf dass sie zwangsläufig unleserlich werden, außerdem sollte schon gzip für pressierte Ladung sorgen. Schau dir einfach mal die load Zeiten eines solchen stylesheets bzw js files ohne und mit einer minify Kompression an. Sie ist meist zu vernachlässigen. Und es ist nur komprimierte Luft. ?

    Das mit der htaccess ist interessant. Hast du wirklich überprüft ob diese drei zusätzlichen Module an sich für eine essentielle Beschleuning sorgen?

    Das auskommentierte Rule in der Styx htaccess ist nicht ratsam!
    In Unterordnern, die nicht Serendipity sind - also beispielsweise /touren/ - legt man einfach eine neue .htaccess an mit RewriteEngine OFF an

    <IfModule mod_rewrite.c>
RewriteEngine Off
</IfModule>

    und der Fall ist erledigt.

  41. Beat Post author am :

    Also ich testete auf: https://tools.pingdom.com/ die Seite: https://www.beatsblog.ch/categories/BLOG

    • ohne apcu: 57 Requests, 1,6MB Page Size, 1,35s Load time, Performance-Grade = C73
    • mit apcu: 57 Requests, 1,4MB Page Size, 1,27s Load time, Performance-Grade = B86

    Mit Google PageSpeed Insight (die gleiche Seite):

    • ohne apcu: Mobile= 76, Desktop= 94
    • mit apcu: Mobile= 81, Desktop= 96

    Nicht wirklich essentiell, doch immerhin. ?

    Danke für die Hinweise zur .htaccess - ich habe das jetzt wie von Dir vorgeschlagen umgesetzt und es scheint zu funktionieren. ?

     

  42. Ian Styx am :

    https://www.beatsblog.ch/2386-hoch-und-breit.html (ohne Garmin und auch nicht viel besser)
    48 Anfragen
    1,31 MB / 526,83 KB übertragen
    Beendet: 5,48 s
    DOMContentLoaded: 4,58 s
    load: 4,82 s

    Ich sags mal so - das müsst eine Angelegenheit von 0.50s sein, wenns hoch kommt mt allem Schnickschnack 1 - 1.5s.

  43. Beat Post author am :

    Es sieht so aus, wie wenn jede Single-Entry-View über 4 Sek. benötigt, bis sie vollständig geladen ist. Indexseiten brauchen im Schnitt um die 1,5 Sekunden. Das ist ziemlich verwirrend, denn die Index-Seite zeigt ja eigentlich 10 Single-Entries (ich habe ja keine erweiterten Beiträge).

    Das ist unschön, doch ich weiss auch nicht, was ich dagegen tun kann.

  44. Beat Post author am :

    Habe mal den Manitu-Support angeschrieben:

    Ich bin etwas verwundert, wie lange die Antwortzeiten für Seitenaufrufe meines Blogs benötigen. Ich habe verschiedene Seiten getestet, die Resultate sind immer in etwa gleich. Zur Dokumentation hier eine Beispielmessung mit Vergleich:

    I just tested https://www.beatsblog.ch/2531-TREK-1120-1-Jahr.html with the Full Page test in Pingdom Tools. This specific test was done on February 7. The web page took 4470 ms to load, used 55 requests, and weighed in at 849.6 KB. The Google Page Speed performance grade for this web page is 85/100. There’s a ton of more information you can check out here: https://tools.pingdom.com/#5c080910c4400000

    Nachfolgend eine Vergleichsmessung der identischen Seite bei meinem alten Hostinganbieter:

    I just tested https://www.blog.dokumenzi.ch/2531-TREK-1120-1-Jahr.html with the Full Page test in Pingdom Tools. This specific test was done on February 7. The web page took 696 ms to load, used 52 requests, and weighed in at 809.6 KB. The Google Page Speed performance grade for this web page is 79/100. There’s a ton of more information you can check out here: https://tools.pingdom.com/#5c080887c5c00000

    Von 696 ms zu 4470 ms ist doch ein riesiger Unterschied. Können Sie vielleicht eruieren, woher diese Verzögerungen kommen?

  45. Ian Styx am :

    Als kleiner Hinweis, dass es sich dabei um identische Blog und Versionssysteme aber unterschiedliche HTTP-Server mit leichtem nginx cache Vorteil handelt, wäre vielleicht noch zuträglich gewesen - ansonsten bin ich gespannt. Vor 2 Stunden hatte ich mal geschaut wer die anderen 35 User auf dem Server sind. Viele davon sind noch gar nicht aktiv, andere nutzen es einfach als nextcloud Server. So allgemein dürfte es also nicht am Betrieb oder fehlenden Ressourcen liegen.

  46. Beat Post author am :

    Manitu ist momentan relativ ratlos. Es ist aber auch komisch, dass die Verzögerung nur in der Single-Entry-Ansicht auftritt.

    Sie wollen jetzt selbst eine Serendipity-Styx-Edition Testinstallation aufbauen um der Sache besser auf den Grund gehen zu können.

    Abwarten...

  47. Ian Styx am :

    Man darf gespannt sein. ?

  48. Ian Styx am :

    Nicht das ich das wirklich verstehe..., aber in den Chrome Dev Tools unter Performance ist der längste Load bzw Warte / idle Strich (?) bei den woff2 raleway Google fonts Dateien. Und manche von ihnen sind grau, andere grün markiert.

    Ich interpretiere das so, dass gar nicht alle fonts gebraucht werden und man schon an dieser Stelle einiges kürzen könnte.

    Insgesamt wäre es ja mal interessant diese google fonts einmal zum intensiveren Testen des delays komplett herauszunehmen, bzw abzuschalten.

    (und die skins/moona-lisa/icons.png des cke)
    Beides zusammen sind schon fast eine Sekunde, wenn ich richtig rechne, nicht eingerechnet die Bearbeitung derselben bis Render fertig..

  49. Beat Post author am :

    Um schnell einen Eindruck zu kriegen: Könnte ich auf www.beatsblog.ch nicht einfach ma auf das pure-Theme wechseln und wäre somit die (in pure-beat eingebauten) Google-Fonts los? Dann Speed-Test machen und danach Theme wieder umstellen.

    Irritierend find ich trotzdem, dass ich hier auf www.blog.dokumenzi.ch diese Verzögerungen nicht habe... für mich als Laien scheint das schon irgendwie mit dem Hosting zu tun zu haben.

  50. Beat Post author am :

    Ich habe das rasch getestet. Die Seite: https://www.beatsblog.ch/2599-Sizilien-Planung-abgeschlossen.html

    braucht mit pure-beat-Theme 4,47 sec. und mit pure-Theme noch 4,10 sec. (davon werden 3,70 sec. als "wait" ausgewiesen.) Auch mit 2K11-Theme braucht die Seite 3.96 sec.

    Die Verzögerung scheint also nichts mit dem Theme zu tun zu haben.

    Diese Seite hier: https://www.blog.dokumenzi.ch/2629-Vorschaubilder-400px.html braucht gerade mal 900 msec., davon 277msec. "wait" ?

  51. Ian Styx am :

    Ja schon, aber es könnte/muss hier ein cache proxy (*) oder so für eklatante Beschleunigung sorgen...
    Die load chain sieht komplett anders aus und der Unterschied ist frappant! (* Varnish ist es glaube ich nicht, denn mit dem hat es ganz ander Aussetzer)

    Das wird sich aber in nächster Zeit noch weiter eruieren lassen wenn weitere Installationen auf verschiedenen Serverkonfigurationen dazukommen. Lokal ist das bei mir auch blitzschnell. An PHP 7.4 sollte es auch nicht liegen, denn so arg unterscheiden sich die 7er Versionen nicht in der Geschwindigkeit.

  52. Ian Styx am :

    https://www.beatsblog.ch/2598-endlich-mal-wieder-biken.html nur Wartezeit des Ladens 3910ms - rendering, parsing, composition, etc. geschieht erst danach und geht schnell.

    https://www.blog.dokumenzi.ch/2629-Vorschaubilder-400px.html mit über 50 Kommentaren Zeit des Ladens 293ms
    https://www.blog.dokumenzi.ch/1208-Schneetour.html 229ms Zeit des Ladens ist ca 17-fach kürzere Geschwindigkeit

  53. Beat Post author am :

    Die Situation ist immer noch die Selbe. Vom Manitu-Support habe ich nun seit 3 Wochen auch nichts mehr gehört. Da sollte ich wohl mal nachhaken.

    Hast Du irgendwas mitgekriegt? Hat vielleicht Manitu mit Dir diesbezüglich Kontakt aufgenommen?

  54. Ian Styx am :

    Nee, ich habe mit denen nichts zu tun.

  55. Ian Styx am :

    Hast du auch schon probiert die/deine APC etc Optimierungen mitsamt dem Google fonts zum testen abzuschalten?

    Ich finde diesen Delay immer noch ziemlich ridicullous - Frische 3.0 Installationen auf Debian Buster sind rasend schnell, natürlich ohne den Ballast von einem gut gefüllten Blog und deinen Seitengeschichten. Aber wie gesagt das sollte höchstens ~1 Sekunde betragen und nicht 4-5. Manitu sollte mal messen was da networkmäßig passiert. Ich kann mir das nicht erklären.

  56. Beat Post author am :

    Habe jetzt auf www.beatsblog.ch die Original .htaccess wieder aktiv (nach der Styx-Installation gesichert). Das macht (auf den ersten Blick) keinen Unterschied.

    Den weiteren Kontakt mit Manitu betreffend dieser Single-Entry-Performance-Geschichte habe ich noch auf meiner ToDo-Liste, doch im Moment gurkt mich das Thema etwas an . ?  Aber ja, ich muss das nocheinmal anpacken.

  57. Ian Styx am :

    zur Sicherung würde ich auf mal htmlcomments ausschalten

  58. Ian Styx am :

    auch die GZIP-Kompression?

    Wenn man aus dem Quelltext einer single Seite die einzelnen assets anklickt, sind die auch ziemlich schnell da - soviel zur Vermutung das irgendetwas schlecht oder schnarchlangsam lädt...

  59. Ian Styx am :

    und die drei Vorschaubilder... das Plugin mal deaktivieren.

    Alleine das hier https://www.beatsblog.ch/uploads/2017/20170215_901.styxThumb.jpg braucht lt. Chromium
    Duration 428.58 ms (100.25 ms network transfer + 328.33 ms resource loading)

    Vielleicht muss man die irgendwie cachen zb für eine Zeit lang.... ?!?

  60. Beat Post author am :

    Ich habe mal auf www.beatsblog.ch alle Seitenleisten-Plugins versteckt, den Template- und den Browser-Cache gelöscht und dann die Seite mit pingdom.com getestet. Die Ladezeit betrug 4,08 sec. davon 3.67 Wait. Alle Pugins wieder aktiviert und dann betrüg die Seitenladezeit 4.59 sec. davon 4.16 Wait. Sieht also nicht so aus, als ob die Seitenleisten-Plugins einen grossen Einfluss haben.

    Ich mache solche Sachen nicht gern, weil ich einfach zuwenig Ahnung davon habe. Für mich als Laie reicht der Vergleich zwischen hier und beatsblog.ch. Nehme ich z.B. die (zufällige) Seite /1230-zum-zweiten-Mal.html so dauert es auf beatsblog.ch 4.19 sec. davon 3.77 Wait und hier braucht der Seitenaufbau 0,52 sec. davon 0.18 Wait. Das sind einfach Welten! Klar: Welche Server- und Caching-Systeme jetzt wo und wie genau im Einsatz sind, übersteigt mein Wissen als Endkunde und ehrlich gesagt interessiert es mich auch nicht sonderlich. Da sollen Profis ran und dafür denke ich, dass möglichst identische Konfigurationen/Datenmengen zu Vergleichszwecken hilfreich sind.

    Und ja, ich trete mir jetzt in den Hintern und schreibe den Manitu-Support nocheinmal an.

  61. Ian Styx am :

    sehr wohl ..! Allerwerteste gehören getreten, auch Sattelfeste ? (*)

    ich kann mir auch nicht richtig erklären warum sehr viel mehr server- und db-load auf der list (entries) Seite so viel schneller läuft als ein single request, auch wenn in diesem ein paar zusätzliche JS mit entsprechenden requests geladen werden. Ich hatte halt das Chromium Audit tool entdeckt und ein wenig herumgespielt. Man muss halt den zusätzlichen CKE load und das horrible non Standard imagesidebar Plugin als mögliche Ursachen definitiv ausschließen können. Darum ging es mir (nur).

    (*) Der Renner mit dem roten Sattel ist ja interessant und hat mich wieder erinnert mal nachzufragen... Sind solche schmalen Dinger eigentlich geeignet für nicht so sattelfeste Hintern? Ich habe jedesmal Schmerzen nach einer Stunde Fahrt und meiner ist ein ganz normaler Fahrradsattel. Und nachdem ich letztens über die ulkigen BikeBalls lesen durfte fiel mir das jetzt quasi "siedendheiß" wieder ein... ?

  62. Beat Post author am :

    Letzte Woche hat der Manitu-Geschäftsführer nach einen Feedback gefragt (vermutlich ein Standard-Mail an alle Neukunden). Heute habe ich zuerst beim Support nachgefragt (und Ihnen die obige Messung mitgeschickt). Danach schrieb ich mein Feedback-E-Mail. Beides zusammen baut vermutlich nun etwas Druck auf. Mal sehen.

    Fahrradsättel ist ein Thema, zu dem es keine richtig/falsch oder gut/schlecht Antworten gibt. Jeder Arsch ist verschieden ?

    Es gibt niemanden, der untrainiert länger Fahrrad fahren kann, ohne Sitzbeschwerden zu kriegen. Es spielen viele Faktoren eine Rolle: Abstand der Sitzknochen, Sitzposition (aufrecht-gestreckt), Fahrergewicht, Einsatzzweck und sonst noch ein paar Dinge. Der rote Sattel auf dem Foto ist vermutlich der hässlichste Sattel, den ich kenne. Doch für meinen Freund ist genau dieser Sattel auch auf lange Distanzen bequem und nur das ist wichtig. Jeder halbwegs ambitionierte Biker hat wohl X Sättel getestet, bis er das passende/bequeme Modell gefunden hat. Das ist die traurige Realität.

    So zur Info ist diese Seite recht gut: https://www.sq-lab.com/ergonomie/sqlab-kontaktstellen/becken/

  63. Ian Styx am :

    Uff. Ja so ist das wohl. Danke. Eine Wissenschaft für sich!

    Ich sagte ja auch "..interessant.." ;-) Erinnert ein wenig an die Schnabelschuhe aus dem Mittelalter https://sattlerei.cz/de/kategorie/52-schnabelschuhe

  64. Beat Post author am :

    Ich schreib jetzt nicht, woran mich der rote Sattel erinnert... ?

Kommentar schreiben

Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.
▲