php-resource



Zurück   PHP-Scripte PHP-Tutorials PHP-Jobs und vieles mehr > Webmaster > Webmaster
 

Login

 
eingeloggt bleiben
star Jetzt registrieren   star Passwort vergessen
 

 

 


Webmaster Fragen rund um die Homepage. Hier könnt ihr eure Tips und Anregungen an andere Webmaster und Homepagebetreiber weitergeben.

Antwort
 
LinkBack Themen-Optionen Thema bewerten
  #31 (permalink)  
Alt 29-12-2009, 16:19
piratos
 Guest
piratos
Beiträge: n/a
Standard

Das Fehlverhalten betraf bereits vorkomprimierte Dateien und nicht die Fähigkeit von Chrome und Safari normale vom Server vorgenommene GZIP verarbeiten zu können - das konnten die schon immer sauber - das ist korrekt.

Headers wurden immer korrekt gesendet - alle anderen seinerzeit aktuellen Browser haben das prima verarbeitet.

Die damalige Versionen konnten die vorkomprimierte GZIP Datei nicht vollständig und sauber entpacken, sie hängten sich schlicht auf und nichts passierte mehr.

Die aktuelle Chromeversion jedoch kann es ohne jegliche Änderungen am Web selbst.

Damals war Safari Windows und Mac ebenfalls davon betroffen , die gleiches Verhalten zeigten (was auch diverse User berichteten). Man müsste mal checken ob die aktuelle Safari-Version sich dahingehend geändert haben.
Mit Zitat antworten
  #32 (permalink)  
Alt 29-12-2009, 16:24
TobiaZ
  Moderator
Links : Onlinestatus : TobiaZ ist offline
Registriert seit: Jan 2001
Ort: MUC und MGL, Germany
Beiträge: 34.421
Blog-Einträge: 1
TobiaZ befindet sich auf einem aufstrebenden Ast
Standard

Wo sollte für den Klient der Unterschied zwischen einer "vorkomprimierten" und einer "vom Server komprimierten" Datei liegen?
__________________
ERST LESEN: Unsere Regeln. | Ich hab schon Pferde kotzen sehn!

READ THIS: Strings richtig trennen/verbinden | JOINs, das leidige Thema | Wegwerf E-Mail Adressen

Ich werde keinen privaten 1:1 Support leisten, außer ich biete ihn ausdrücklich an.

Wenn man sich selbst als "Noob" bezeichnet, sollte man die Finger davon lassen.
Wenn man gewillt ist daran etwas zu ändern, lernt man Grundlagen!
Mit Zitat antworten
  #33 (permalink)  
Alt 29-12-2009, 23:13
piratos
 Guest
piratos
Beiträge: n/a
Standard

Zitat:
Wo sollte für den Klient der Unterschied zwischen einer "vorkomprimierten" und einer "vom Server komprimierten" Datei liegen?
Für den Klient ? Da sollte es keinen Unterschied geben.

Auch wenn die Altversionen von Chrome und Safari(neuere müsste ich noch checken) damit nicht arbeiten können , gibt es keine Probleme beim IE (auch ältere Versionen), beim FF , Konquerer und noch ein paar, selbst integrierte Browser von Programmierungebungen verarbeiten das einwandfrei.

Warum Alt Chrome damit nicht funktionierte - das ist nicht meine Aufgabe Bugs in Fremdsoftware zu ermitteln. Es ist immer ein einwandfreier Bug wenn alle anderen Browser damit sauber arbeiten können und eben der eine oder andere nicht.

Bei vorkomprimierten erspart sich der Server lediglich die Arbeit eine Komprimierung vornehmen zu müssen und damit wird die Sache fixer und belastet den Server nicht weiter - das macht sich bei reichlich Besuchern ziemlich bemerkbar.
Mit Zitat antworten
  #34 (permalink)  
Alt 29-12-2009, 23:26
TobiaZ
  Moderator
Links : Onlinestatus : TobiaZ ist offline
Registriert seit: Jan 2001
Ort: MUC und MGL, Germany
Beiträge: 34.421
Blog-Einträge: 1
TobiaZ befindet sich auf einem aufstrebenden Ast
Standard

Zitat:
Für den Klient ? Da sollte es keinen Unterschied geben.
Dann kann ich auch nicht nachvollziehen, warum die einen auf den alten Klients funktionieren sollen und die anderen nicht.
__________________
ERST LESEN: Unsere Regeln. | Ich hab schon Pferde kotzen sehn!

READ THIS: Strings richtig trennen/verbinden | JOINs, das leidige Thema | Wegwerf E-Mail Adressen

Ich werde keinen privaten 1:1 Support leisten, außer ich biete ihn ausdrücklich an.

Wenn man sich selbst als "Noob" bezeichnet, sollte man die Finger davon lassen.
Wenn man gewillt ist daran etwas zu ändern, lernt man Grundlagen!
Mit Zitat antworten
  #35 (permalink)  
Alt 30-12-2009, 13:01
Benutzerbild von fireweasel fireweasel
 Registrierter Benutzer
Links : Onlinestatus : fireweasel ist offline
Registriert seit: Sep 2008
Ort: At home
Beiträge: 851
fireweasel wird schon bald berühmt werdenfireweasel wird schon bald berühmt werden
fireweasel eine Nachricht über AIM schicken fireweasel eine Nachricht über Yahoo! schicken
Standard

Zitat:
Zitat von piratos Beitrag anzeigen
Das Fehlverhalten betraf bereits vorkomprimierte Dateien und nicht die Fähigkeit von Chrome und Safari normale vom Server vorgenommene GZIP verarbeiten zu können - das konnten die schon immer sauber - das ist korrekt.

Headers wurden immer korrekt gesendet - alle anderen seinerzeit aktuellen Browser haben das prima verarbeitet.
Wenn ich mich recht erinnere, ist das so, dass einige falsch konfigurierte Server oder serverseitige Scripts eben nicht sauber funktionierten und entweder die Request-Header des Clients nicht korrekt auswerteten oder die Response-Body-Daten in einem anderen Kompressionsformat schickten, als sie im Transfer-Encoding-Header angaben.

Wenn das vom Server benutzte Kompressions-Format "GZIP" ist, muss das der Client auch in seinem "Accept-Encoding"-Headern erlaubt haben. Üblich (weil im HTTP-Standard irgendwo definiert) ist das ZLIB-Deflate-Verfahren und nicht "GZIP". Die meisten Webbrowser sind aber so tolerant, einen falschen Response-Header zu ignorieren und "detektieren" das tatsächlich verwendete Kompressionsverfahren direkt aus den ersten "Magic-Bytes" im Body.

Lange Rede, kurzer Sinn: Ein Client (oder Browser), der "falsch" komprimierte Daten nicht entpackt verhält sich korrekt (a.k.a. strikt "standardkonform"). Ein Browser, der versucht, das tatsächlich verwendete Kompressionsformat zu erkennen, verhält sich dagegen tolerant (benutzerfreundlich), aber nicht korrekt.

Zitat:
Die damalige Versionen konnten die vorkomprimierte GZIP Datei nicht vollständig und sauber entpacken, sie hängten sich schlicht auf und nichts passierte mehr.
Aufhängen ist auch keine Lösung ...
... und natürlich auch kein korrektes Verhalten.

Geändert von fireweasel (30-12-2009 um 13:05 Uhr)
Mit Zitat antworten
  #36 (permalink)  
Alt 30-12-2009, 14:26
piratos
 Guest
piratos
Beiträge: n/a
Standard

Ich habe eben mal den Safari 4.0.4 Windows getestet - der verarbeitet nun den damaligen Test ebenfalls einwandfrei.

Warte noch auf Rückmeldungen von Mac - Usern.

Für Pagespeed & Co. ist das allerdings absolut unwichtig.

Man muss eigentlich auch nicht weiter darüber diskutieren, denn Tatsache ist, das alle anderen Browser sofort damit klar gekommen sind, d.h. alles war korrekt in den Einstellungen, ansonsten hätten die wohl auch die Arbeit verweigert.

Wichtig ist das ein Webmaster umdenkt und sich überhaupt einmal mit den Möglichkeiten beschäftigt. Die Auswirkungen sind ja nicht nur messbar sondern auch klar zu sehen.
Mit Zitat antworten
  #37 (permalink)  
Alt 30-12-2009, 15:37
Benutzerbild von onemorenerd onemorenerd
  Moderator
Links : Onlinestatus : onemorenerd ist offline
Registriert seit: Mar 2005
Ort: Berlin
Beiträge: 9.471
onemorenerd wird schon bald berühmt werdenonemorenerd wird schon bald berühmt werden
Standard

Zitat:
Zitat von piratos Beitrag anzeigen
Warte noch auf Rückmeldungen von Mac - Usern.
Ich bin Mac-User und ich schrieb ja bereits, dass es funktioniert.

Zitat:
Zitat von piratos Beitrag anzeigen
Man muss eigentlich auch nicht weiter darüber diskutieren, denn Tatsache ist, das alle anderen Browser sofort damit klar gekommen sind, d.h. alles war korrekt in den Einstellungen, ansonsten hätten die wohl auch die Arbeit verweigert.
1. Korrektheit ist doch kein Mehrheitsentscheid! Es gibt Definitionen - in diesem Fall RFCs, die festlegen was korrekt ist und was nicht.
2. Der Schluß "funktioniert in x Browsern, also muss alles korrekt sein" ist falsch. Richtig wäre: "funktioniert in x Browsern NICHT, also KANN da was nicht korrekt sein".
Mit Zitat antworten
  #38 (permalink)  
Alt 30-12-2009, 17:13
piratos
 Guest
piratos
Beiträge: n/a
Standard

Das sehe ich anders , man kann es auch so sehen wie du würde dann aber nie zu Potte kommen:

Zitat:
Chrome no longer applies gzip filters to file names with gz/tgz/svgz extensions. (Issue: 8170)
und damit wären wir beim Bug.
Mit Zitat antworten
  #39 (permalink)  
Alt 30-12-2009, 17:20
wahsaga
  Moderator
Links : Onlinestatus : wahsaga ist offline
Registriert seit: Sep 2001
Beiträge: 25.236
wahsaga befindet sich auf einem aufstrebenden Ast
Standard

Wir reden doch hier über HTTP - also was soll das mit „file names” ...?
__________________
I don't believe in rebirth. Actually, I never did in my whole lives.
Mit Zitat antworten
  #40 (permalink)  
Alt 30-12-2009, 17:52
piratos
 Guest
piratos
Beiträge: n/a
Standard

Jede URL ist für einen Browser ein filename (was sonst) den er verarbeiten muss.
Chrome und Safari haben auf solche die gepackt sind einen Filter angewendet der dann die Sache zum crashen gebracht hat.

Was mich interessiert ist die Frage was diese Teildiskussion denn nun bezüglich Pagespeed und Yslow gebracht hat.
Ich meine nichts, da man das wegen der extrem kleinen Marktanteile von Chrome und Safari auch in den Papierkorb hätte schmeissen können.

Echte Pagespeed oder Yslow Fragen habe ich hier noch nicht gesehen, scheint ja allen klar zu sein was zu machen ist, damit wäre ich dann zufrieden.

Geändert von piratos (30-12-2009 um 17:54 Uhr)
Mit Zitat antworten
  #41 (permalink)  
Alt 30-12-2009, 17:55
wahsaga
  Moderator
Links : Onlinestatus : wahsaga ist offline
Registriert seit: Sep 2001
Beiträge: 25.236
wahsaga befindet sich auf einem aufstrebenden Ast
Standard

Zitat:
Zitat von piratos Beitrag anzeigen
Jede URL ist für einen Browser ein filename (was sonst) den er verarbeiten muss.


/EOD
__________________
I don't believe in rebirth. Actually, I never did in my whole lives.
Mit Zitat antworten
  #42 (permalink)  
Alt 30-12-2009, 22:54
Benutzerbild von onemorenerd onemorenerd
  Moderator
Links : Onlinestatus : onemorenerd ist offline
Registriert seit: Mar 2005
Ort: Berlin
Beiträge: 9.471
onemorenerd wird schon bald berühmt werdenonemorenerd wird schon bald berühmt werden
Standard

Es geht nicht um Safari und Chrome sondern Webkit, vielleicht sogar KHTML und damit um so ziemlich alles außer Opera, Firefox und IE. Macht einen Marktanteil von circa 10 Prozent.

Über Pagespeed/Yslow gibt es nicht viel zu zu sagen. Man hat doch schon immer versucht, Webseiten möglichst schnell auszuliefern. Jetzt gibt es Tools, die einem zeigen wo man noch optimieren kann. Das ist keine große Sache.

Es lohnt sich viel mehr, über die konkreten Optimierungsmöglichkeiten zu sprechen. Kompression ist eine davon.

Kompression kann man in gängigen Webservern einfach zuschalten. Der Server komprimiert die Daten dann on-thy-fly beim Ausliefern. Damit er das nicht jedes mal erneut machen muss, kann man statische Dateien einmalig komprimieren. Aber dann muss man den Server auch so einstellen, dass er solche Dateien nicht erneut komprimiert und vor allem die richtigen HTTP-Header sendet.
Außerdem muss man zusätzlich die unkomprimierten Dateien vorhalten, falls ein Browser keine Komprimierung unterstützt.
Wenn man im Zuge der Performanceoptimierung auch einen Caching Proxy installiert, kann man den Webserver on-thy-fly komprimieren lassen und der Caching Proxy sorgt dafür, dass das nicht immer wieder geschehen muss.
Mit Zitat antworten
  #43 (permalink)  
Alt 31-12-2009, 12:08
piratos
 Guest
piratos
Beiträge: n/a
Standard

Man sollte sich davor hüten Browserbugs durch ständige Ausklammerung und Aktionen in seinen Scripten zu umgehen auch wenn man das könnte.
Bugs zu beseitigen ist immer eine Sache des eigentlichen Anbieters.
Es ist nicht die Aufgabe eines Webprogrammierers seine Ressourcen für diese Anbieter zu verschwenden um deren Bugs zu umgehen.

Es ist allein das Interesse des Browseranbieters mit seinem Produkt Marktanteile zu gewinnen und dann müssen die auch ran - so einfach ist es.

Man kann den am besten zu einer Korrektur zwingen wenn man das eben nicht macht und somit einen Anteil der User dieses Produktes dazu bringt zu meckern bzw. den Bug zu melden.
Kein User sieht Webkit der sieht Chrome oder Safari oder was auch immer und wird sich dann an seinen Anbieter halten.

Marktanteile werden zudem nicht nach der Verwendung von individuell geänderten Kits gemessen.

Die andere Seite der Medaille ist ständig Uraltbrowser unterstützen zu wollen nur weil die Netznutzer zu faul sind ein Update zu installieren (was auch aus Sicherheitsgründen äußerst bedenklich ist).

Auch da ist meine Meinung die - lasst diese Surfer in das Messer laufen.
Solange man darauf eingeht wird diese spezielle Gruppe nichts ändern, das machen sie erst dann wenn nichts mehr so richtig läuft.

Zitat:
über die konkreten Optimierungsmöglichkeiten zu sprechen. Kompression ist eine davon.
Das wäre der Ansatz - Kompression hilft ist aber bei vielen aber bei weitem nicht überall möglich, das ist das grundsätzliche Problem, wer kann sollte es machen.
(warum man hier allerdings Kompression nicht verwendet ??? )

Die nächste großartige Möglichkeit ist die einen Browsercache zu verwenden,wenn möglich .

Was jeder Webmaster machen kann ist und was sofort etwas bringt:

1. Backgroundimages in einem Sprite zusammenfassen.
2. die Regel "Use efficient CSSselectors" befolgen, das bringt richtig etwas
3. Keine CSS Elemente laden die man nicht benötigt
4. CSS vor JS laden
5. JS nach Möglichkeit in eine Datei fassen
6. JS nach Möglichkeit vor </body> laden und nicht im Meta - Teil
7. Alle Möglichkeiten prüfen um die Anzahl von HTTP Request's zu reduzieren
8. Abhängigkeiten von externen Inhaltseinbindungen auflösen, da man voll von denen abhängig wird.

Ich empfehle den FF mit Yslow und Pagespeed zu verwenden, Yslow ist die Sache für's grobe, Pagespeed für's feine.
Optimal dazu ist der DEV Teil vom Browser Chrome bei dem man an Hand der Timeline richtig gut sehen kann, wo das Rad gebremst wird.

Aber - man muss sich im klaren sein - alle Maßnahmen selbst wenn sie zu 100% Pagespeed und Yslow 100 sind liefern keine Garantie dafür das die Website Leistung laut Google Webmastertools besser als der Schnitt ist.

Sie helfen garantiert die Leistung zu verbessern, können aber die Generierungsprozesse langsamer Titel nicht ändern und sie können natürlich auch nicht lahmen Servern Flügel zu verleihen.
In der Praxis wird man allerdings eher auf lahme Generierungsprozesse stoßen als auf lahme Server.
In der Praxis werden die meisten Domains auf shared Webservern liegen, da besteht noch das Problem das man keine Ahnung hat wie der durch das Angebot und die Besucher der Nachbarn belastet werden - das kann enorm schwanken.
Mit Zitat antworten
  #44 (permalink)  
Alt 31-12-2009, 14:18
Benutzerbild von onemorenerd onemorenerd
  Moderator
Links : Onlinestatus : onemorenerd ist offline
Registriert seit: Mar 2005
Ort: Berlin
Beiträge: 9.471
onemorenerd wird schon bald berühmt werdenonemorenerd wird schon bald berühmt werden
Standard

Zitat:
Zitat von piratos Beitrag anzeigen
Man sollte sich davor hüten Browserbugs durch ständige Ausklammerung und Aktionen in seinen Scripten zu umgehen auch wenn man das könnte.
Bugs zu beseitigen ist immer eine Sache des eigentlichen Anbieters.
Es ist nicht die Aufgabe eines Webprogrammierers seine Ressourcen für diese Anbieter zu verschwenden um deren Bugs zu umgehen.
...
Die andere Seite der Medaille ist ständig Uraltbrowser unterstützen zu wollen nur weil die Netznutzer zu faul sind ein Update zu installieren (was auch aus Sicherheitsgründen äußerst bedenklich ist).
Selbstverständlich. Jeder vernünftige Mensch teilt diese Ansicht.
Aber in der Praxis steht im Anforderungskatalog, in welchen Browsern es laufen muss. Wenn ein Entwickler auf einen Browserbug stößt, muss er einen Workaround suchen. Er kann nicht einfach die Anforderung ignorieren, um so Druck auf den Browserhersteller auszuüben.

Wenn man sein eigenes Süppchen kocht, kann man so idealistisch sein.
Aber wenn man jemandem rechenschaftspflichtig ist, hat man nach seinen Anforderungen zu arbeiten. Die kann man bestenfalls mitbestimmen, aber am Ende zählt immer Wirtschaftlichkeit vor Idealismus.
Mit Zitat antworten
  #45 (permalink)  
Alt 31-12-2009, 14:22
unset
  Moderator
Links : Onlinestatus : unset ist offline
Registriert seit: Jan 2007
Ort: Düsseldorf
Beiträge: 3.782
unset befindet sich auf einem aufstrebenden Ast
Standard

OffTopic:
The Guide is definitive. Reality is frequently inaccurate.
Mit Zitat antworten
Antwort

Lesezeichen


Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)
 

Ähnliche Themen
Thema Autor Forum Antworten Letzter Beitrag
Google map API DeeAge PHP Developer Forum 3 02-05-2008 21:34
google down? Lennie Off-Topic Diskussionen 36 06-03-2008 18:03
Google und das W3C TobiaZ Out of Order 5 27-07-2005 12:31
msn vs. google Abraxax Out of Order 4 06-09-2003 15:01
Google URL BielWeb PHP Developer Forum 5 16-12-2002 13:29

Themen-Optionen
Thema bewerten
Thema bewerten:

Forumregeln
Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are an


PHP News

ebiz-trader 7.5.0 mit PHP7 Unterstützung veröffentlicht
ebiz-trader 7.5.0 mit PHP7 Unterstützung veröffentlichtDie bekannte Marktplatzsoftware ebiz-trader ist in der Version 7.5.0 veröffentlicht worden.

28.05.2018 | Berni

Wissensbestand in Unternehmen
Wissensbestand in UnternehmenLebenslanges Lernen und Weiterbilden sichert Wissensbestand in Unternehmen

25.05.2018 | Berni


 

Aktuelle PHP Scripte

Top-Side Guestbook

Gästebuch auf Textbasis (kein MySQL nötig) mit Smilies, Ip Sperre (Zeit selbst einstellbar), Spamschutz, Captcha (Code-Eingabe), BB-Code, Hitcounter, Löschfunktion, Editierfunktion, Kommentarfunktion, Kürzung langer Wörter, Seiten- bzw. Blätterfunktion, V

22.10.2018 webmaster10 | Kategorie: PHP/ Gaestebuch
ebiz-trader 6.0 - Das professionelle PHP Marktplatz Script ansehen ebiz-trader 6.0 - Das professionelle PHP Marktplatz Script

Mit unserer Lösungen können Sie nahezu jeden B2B / B2C Marktplatz betreiben den Sie sich vorstellen können. Ganz egal ob Sie einen Automarktplatz, Immobilenportal oder einfach einen Anzeigenmarkt betreiben möchten. Mit ebiz-trader können Sie Ihre Anforder

11.10.2018 Berni | Kategorie: PHP/ Anzeigenmarkt
PHP Server Monitor

PHP Server Monitor ist ein Skript, das prüft, ob Ihre Websites und Server betriebsbereit sind.

11.09.2018 Berni | Kategorie: PHP/ Security
 Alle PHP Scripte anzeigen

Alle Zeitangaben in WEZ +2. Es ist jetzt 01:53 Uhr.