Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?
Journals>Web-Entwicklung>Website-Performance optimieren für PROs

Website-Performance optimieren für PROs

Hier Tipps für PRO-Webmaster welche die Ladezeiten ihrer Website verringern möchten.

Wenn ihr alle Tipps beachtet, könntet ihr die Ladezeit eurer Website sicher um 300% steigern (edit: verbessern)!

--

Damit ihr euren Erfolg messen könnt, geht ins Safari Develop-Menü und wählt "Web Inspector"


Uff, und zieht euch den neusten Safari Nightly Build dort wurde der Web-Inspector erheblich verbessert!

Wenn ihr eure Seite geladen habt, seht ihr unter Resources wie viel Zeit der Ladevorgang genommen hat und wie gross eure Dateien sind. Schreibt euch doch eure Ladezeiten und Grösse der Website auf!

Falls ihr das Debug-Menü im Safari nicht seht, in der Konsole folgendes eingeben:
defaults write com.apple.Safari WebKitDeveloperExtras -bool true


1. Bilder optimieren
- Für Fotos mit Digitalkamera: JPG statt PNG verwenden (Einsparung: z.T. 50% oder mehr)
- Für Design-Elemente mit weniger als 256 Farben: PNG-8 (Einsparung: ca. 80%!)
- Für abstraktere Grafiken mit mehr als 256 Farben (v.A. ursprünglich Vektor-Grafiken): PNG-24 >> PNGPong verwenden um PNG optimal zu komprimieren.

2. Design-Elemente komprimieren

Alle Design-Elemente die zusammen weniger als 256-Farben haben, per Photoshop in eine Datei packen. Per CSS background-position bei jedem Design-Element nur den Teil anzeigen, der nötig ist. Das ganze als PNG-8 abspeichern.

Statt 10 JPEGs mit je 6 Kilobyte (60 Kilobyte) habt ihr nur noch 1 Datei mit ca. 6 Kilobyte.

Einsparung: 10 HTTP-Requests à 20 Millisekunden (200 Millisekunden) und ca. 50 Kilobyte.

Auch Google hat es so gemacht:


3. CSS-Dateien optimieren:
- Mit dem Firefox-Plugin dust-me-selectors findet ihr alle CSS definitionen welche nicht gebraucht werden. Aber dust-me-selectors nicht blind vertrauen.. (Einsparung: ca. 20%)
- Mehrere CSS-Dateien in eine packen: (Einsparung: ca. 20 Millisekunden pro HTTP-Request)
- CSS-Compressor verwenden: (Einsparung: ca. 20%)

4. JavaScript-Dateien optimieren:
- Mehrere JavaScript Dateien in eine packen. (Einsparung: ca. 20 Millisekunden pro HTTP-Request)
- Verwendest du grössere JavaScript-Frameworks nur für 1 Effekt? Versuche die Funktionalität nach zu programmieren oder nur die nötigen Funktionen zu kopieren. (Einsparung: ca. 20 Kilobyte)
- Komprimiere dein JavaScript: (Einsparung: ca. 20%)
- Google Analytics-Script löschen und ein Serverseitiges-Script nutzen: (Einsparung. ca. 20 Kilobyte) .. dann hat Google auch nicht alle eure Besucher-Daten, aber OK Google-Analytics ist cool und nicht jeder kann darauf verzichten.


---

Für Profis:

5. Cache like mad!

Sendet bei Bildern, etc. welche sich nicht verändern und die z.B. von einem Script ausgeliefert werden unbedingt Cache-Header damit der Browser die Bilder nicht immer nachlädt:

z.B. im JavaCode
long now = System.currentTimeMillis();
long lifetime = 1 * 24 * 60 * 60;// in-seconds
resp.setDateHeader("Last-Modified", now);
resp.setDateHeader("Expires", now + (lifetime * 1000));

6. Browser informieren, wenn sich eine Datei nicht verändert hat:

Angenommen ihr liefert grosse Bilder per Script aus, o.Ä. welche sich nicht verändert haben unbedingt den NOT_MODIFIED_SINCE-Header statt dem eigentlichen Bild zurückgeben:
long ifModifiedSince = req.getDateHeader("If-Modified-Since");
if (ifModifiedSince != -1l) {
  try {
    resp.sendError(HttpServletResponse.SC_NOT_MODIFIED);
    return;
   } catch (Exception e) {
    e.printStackTrace();
  }
}

7. ZIP-Komprimierte Übertragung
Mit HTTP können sämtliche JavaScript, HTML und CSS-Dateien ZIP-Komprimiert übertragen werden. (Einsparung: ca. 30%)

Der Apple Web-Inspector gibt eine Warnung aus, falls das nicht der Fall ist.

8. Serverseitige Performance verbessern:
- Messt die Performance selbst mit einem kleinen Script, wenn es länger als 100ms dauert um nur das HTML zu generieren solltet ihr das verbessern. v.A. bei grossen Datenbanken gute Indexes setzen. Caching von oft benutzten Daten, etc.

9. Darauf achten, dass auf den Server "connection: keep-alive" aktiviert ist. Weil sonst bei jeder Resource die geladen wird, eine neue HTTP-Connection geöffnet wird. Vielleicht könnt ihr hier auch noch ca. 50ms sparen. Wenn ihr Bilder per Script ausliefert, setzt unbedingt die content-length, weil sonst connection:keep-alive nicht funktioniert....

10. Natürlich sämtlichen CSS-Code in die CSS-Datei auslagern, denn diese wird nur 1mal geladen und nicht bei jedem Refresh!

11. Verwendet das Firefox Firebug-Plugin , unter "Netzwerk" seht ihr welche Dateien jedes mal geladen werden, welche vom Cache, wie gross die Dateien sind, etc. Wenn keine Datei-Grösse neben der Resource steht heisst das "es wurde keine content-length" gesetzt, ergo funktioniert connection:keep-alive bei dieser Resource nicht!

---

Und die ganzen Einsparungen variieren natürlich... sind einfach meine Erfahrungen.



Vielleicht möchte jemand von euch mal meine Tipps ausprobieren . Das braucht schon einige Zeit aber es lohnt sich!

Kommentare

Mr. Krabs
Mr. Krabs31.08.08 15:26
So schlecht ich auch über dein Suxedoo-Journal geredet habe, so gut gefällt mir jetzt dieses Journal. Super Tipps Einige sind natürlich selbstverständlich, aber andere wiederum sind richtig effektiv.

Vllt könntest du noch das Tool pngcrush erwähnen, das optimiert PNGs und verringert deren Dateigröße. Das Tool wird mit den iPhone Developer Tools installiert und befindet sich in /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/

Danke für dieses Journal
Deux Strudel!
madox31.08.08 15:39
Uff, das PNGCRUSH scheint schon interessant zu sein. Aber etwas kompliziert zu bedienen. Denke mit Photoshop save for web and devices... und PNG-8 erreicht man dort auch relativ gute Datei-Grössen.

Oft kann man auch die Anzahl-Farben einfach reduzieren ohne einen visuellen Unterschied festzustellen. Sieht immer noch viel besser aus als mit JPEG-Artefakten.
Mr. Krabs
Mr. Krabs31.08.08 16:09
Es gibt auch ein Dashboard-Widget, das heißt PNGPong. Das übernimmt dir die Arbeit und du brauchst nicht im Terminal rumwuseln
Deux Strudel!
madox31.08.08 16:48
Ist ja geil .

Also habs kurz ausprobiert:

ORIGINAL PNG-24: 17 KB
Mit Photoshop (Save for web and devices): 11.5 KB
Mit PNGPong: 10.5 KB

Mit Photoshop (Nur PNG-8, aber kein sichtbarer Qualitätsverlust): 7 KB

Bringt also schon was . Und das Dashboard-Widget ist auch ziemlich brauchbar!
luxxe31.08.08 21:27
schönes journal! weiter so
Stefan S.
Stefan S.31.08.08 23:08
Danke!
MacRabbitPro02.09.08 10:06
Nix gegen diesen Journal-Artikel, aber es ist in der Tat so, dass es heutzutage bei 90% der Webseiten relativ sinnlos ist, sie durch Optimieren der Bilder, css Dateien oder den HTML Code selbst schneller machen zu wollen.

1. Sind die mittlerweile i.d.R die Bandbreiten entsprechend hoch
2. Die Client Systeme auf denen der Browser läuft seht leistungsfähig

Was man als Entwickler von Web Anwendungen viel mehr optimiert sind die Programme dahinter, welche den HTML Code, die Bilder, Java Script und die css Dateien generieren. Denn mal im Ernst, wie viele größere Webseiten sind den heute noch komplett statisch? Wohl keine würde ich sagen. Selbst Webseiten von kleinen Firmen kommen heute i.d.R von einem CMS.
Daher finden Optimierungen von Ladezeiten in der Praxis dadurch statt, dass man den Java/PHP/Ruby/Perl/C# oder sonstwas Code, der dahinter steckt optimiert bzw. die Datenbank sowie die Zugriffe darauf verschnellert.
Ganz im Ernst - ob ein .gif auf einer Seite 17k oder 15k groß ist, interessiert keine Sau.

Soviel zu diesem Thema - von einem Pro.
Mr. Krabs
Mr. Krabs02.09.08 12:17
MacRabbitPro:
Das mag sein, jedoch beschränkst du dich ja auf größere Seiten. Kleine, statische Seiten profitieren davon, aber Hallo! Und es gibt noch genug Gebiete, in denen man nicht mir DSL surfst. Oder man nimmt das immer mehr an Bedeutung gewinnende Mobilfunknetz als Beispiel. Da macht es schon was aus, ob man mit seinem iPhone eine optimierte Seite lädt oder nicht

Soviel zu diesem Thema - von einem der sich selbst nicht Pro nennt
Deux Strudel!
madox02.09.08 15:52
MacRabbitPro

Microsoft.com braucht bei mir 10 Sekunden zum laden, ich habe eine 30'000 kbit/s Glasfaser Leitung - und - sie - braucht 10 Sekunden.

Google.de benötigt bei mir 400 Millisekunden, klar hat Microsoft etwas mehr Bilder etc. aber es zeigt schon mal dass auch mit grossen Bandbreiten die Ladezeiten langsam sind.

v.A. auch die Latenz. Wenn du eine Seite in China abrufst und die zugriffszeit 300 ms benötigt .. spielts keien rolle ob du eine 1 Terabyte leitung hast oder 10'000 kbit/s... v.A. weil die meisten browser nur x resourcen zur gleichen zeit laden.

Und glaub mir ob eine Seite in 400ms lädt oder in 10 Sekunden spielt eine riesen rolle......
madox02.09.08 15:56
Ausserdem: Das iPhone, hier spielts doch eine Riesen rolle ob jetzt 800 kilobyte mehr geladen werden oder nicht!?
MacRabbitPro02.09.08 16:07
madox

Ich glaube nicht, dass du verstanden hast was ich gemeint habe.
Übrigens: Weder Google noch Microsoft sind statische HTML Seiten!
madox02.09.08 16:22
MacRabbitPro

Microsoft.com und Google.com sind die Startseiten praktisch statisch, und wenn die Ausführungsgeschwindigkeit deines Scripts auch nur 5% der Ladezeit ausmachen hast du wahrscheinlich keine Ahnung von Programmieren oder du hast keine Bilder und sonstige Resourcen auf der Seite.

Microsoft.com und Google.com cachen sowieso die Startseite, und sind deshalb eigentlich statisch. Keiner der beiden Seiten wird mehr als 10millisekunden brauchen um das HTML zu generieren und deshalb ist das nicht relevant...
MacRabbitPro02.09.08 16:37
madox

Alleine die Tatsache, dass Du bei der Seitengenerierung an "Skripts" denkst zeigt deinen Erfahrungshorizont.
Abgesehen davon ist die Google Startseite auch ein idiotisches Beispiel, weil die Seite einen Body hat, der aus einem Logo, einem Eingabefeld, 2 Buttons und ein paar Links besteht - also quasi leer ist.
Immerhin heißt der Journal-Artikel "Website-Performance optimieren für PROs" und Pros kosten pro Stunde (echte Pros bekommst Du i.d.R. nur zum Tagessatz, nicht pro Stunde) richtig Geld welches die Kunden bezahlen müssen und da kann ich Dir versichern, dass sich da niemand hinsetzt und Gifs um ein paar KB schrumpft - da liegen die Probleme im Normalfall richtig im Argen..
Aber möglicherweise kommen wir, was das "Pro" angeht, aus verschiedenen Welten. Mir vorzuwerfen ich könnte nicht programmieren - ach gottchen - solche Großmäuler haben wir als Praktikanten auf der Arbeit alle paar Monate mal, die können im Normalfall nach 2 paar Tagen unter dem Teppich aufrecht stehen - mit Hut!

madox02.09.08 16:51
MacRabbitPro

Es geht hier weder darum, wer besser programmieren kann, noch wie man ein Script optimiert. Sondern es geht rein um die Ladezeiten der Website bzw. Resourcen.

Natürlich kannst du auch deine "Scripts" oder deine tollen C#-Websites auf der Server-Seite optimieren, aber darum gehts hier *nicht*.

Und ich schreibe Script, damit mich die Leute verstehen. Ich weiss echt nicht wo dein Punkt ist...!? *Hast du im ernst das Gefühl du kannst besser programmieren nur weil ich Script schreibe statt Applikation oder sonst was!?"

Wer generiert schon bei jedem Seitenaufruf Bilder neu? Die wenigsten. Natürlich werden die generierten Bilder cached und sind deshalb für die Ladezeiten ausser beim ersten Generieren des Bildes gar nicht relevant.

Was ich hier versprochen habe, kannst du bei den meisten Standard-Websites ausprobieren und die Ladezeit wird (sofern es nicht schon relativ gut optimiert war) um ein vielfaches kleiner sein.

Wenn ich mir deine Seite ansehe .. sehe ich DYNDNS und Websites mit iWeb erstellt.... aber ich komme auch nicht grosskotzig daher wie du und behaupte jemand der mit iWeb Websites erstellt und sich keinen eigenen DNS leisten kann, nicht programmieren kann.
idolum@mac02.09.08 17:04
MacRabbitPro

Deine Einstellung in allen Ehren, aber ein 600x400 Pixel großes Bild mit 160 kb sind nun wirklich nicht Ladezeiten-freundlich, auch nicht mit DSL.



Aber bitte nicht streiten, wer jetzt Männlicher ist, nur weil der eine Scripts codet und der andere Applikationen programmiert.

Das ist irgendwie kindisch.
idolum@mac02.09.08 17:07
Also 160 kb auf der Startseite.
madox02.09.08 17:34
Und was ich noch hinzufügen möchte

Ich habe schon vor 7 Jahren in einem Kern-Team von 5 Leuten an Applikationen mit:
- 2.1 Millionen Zeilen Code
- ca. 100 Millionen Datensätzen verteilt auf 250 Datenbank-Tabellen entwickelt. (Für eine der grössten Schweizer Banken).

Und MacRabbitPro, du hast noch nicht mal eine Zeile Code von mir gesehen und fängst schon an mich als PHP-Script-Kiddie abzustempeln.

Aber du hast natürlich in einigen Punkten auch recht:
- Ich bin grossmäuliges PHP-Script-Kiddie
- Ich mache sinnlose Dinge macht wie Ladezeiten-Optimierung (was heutzutage nicht mehr notwendig ist).
- Und solange ich keinen Tagessatz von 1500 EUR habe, habe ich hier eigentlich auch gar nichts zu sagen.
- Ein echter PRO hat ein PRO im Nickname und besitzt iWeb-Websites und verschwendet keine 12 EUR für eine eigene Domain. Madoxes sind definitiv keine PROs sondern höchstens auf praktikanten Niveau.

Aber allgemein sollte man aufpassen, dass man keine flame oder troll-wars mit madoxes beginnt!!

Jungs um ehrlich zu sein, ich habe die letzten 33 Stunden keine Minute geschlafen und vielleicht schreibe ich etwas daneben heute ... bin auf die idee gekommen mal kurz für 4 Stunden über nacht nach london zu fliegen um mir den big ben anzusehen. Da ich aber sowieso keine Koffein-Tabletten habe und mir alle RedBulls ausgegangen sind, versueche ich mal heute etwas früher zu bett zu gehen und keine flame-wars mehr zu beginnen...
MacRabbitPro02.09.08 17:40
madox
Es geht hier weder darum, wer besser programmieren kann, noch wie man ein Script optimiert. Sondern es geht rein um die Ladezeiten der Website bzw. Resourcen.

Und genau darum ging es mir auch. Meine Aussage wollte darauf hinaus, dass solche Optimierungsbemühungen zwar nett, aber in der Praxis im Pro-Umfeld (was immer das eigentlich ist?) vollkommen egal sind.
Denn ob die Ladezeit einer Seite 200ms oder 400ms beträgt ist für den Anwender uninteressant. Aus Sicht des Users laden solche Seiten "sofort".
Ich wollte daher nur einwerfen, dass im Pro Bereich (und ich verstand darunter Leute bzw. Firmen die für Web Anwendungs-Entwicklung bezahlt werden), im Normalfall die Optimierung von langsamen Webseiten auf der Seite des Application Servers stattfindet.
Dies hat Dich aber zu der Aussage veranlasst, dass das sehr wohl wichtig ist, und wenn meine Seiten zu langsam wären, es nur daran liegt, dass das Skript (ok - Progamm) dahinter Schrott ist. Na Prima.
So - bleiben wir doch mal bei Google. Du hast deren Homepage als Beispiel erwähnt. Hast Du nur eine ungefähre Vorstellung davon was bei denen ab geht, wenn Du einen Suchgriff eingibst und suchen lässt? Weisst Du wie groß deren DB Cluster ist? Da geht der Pank ab! Da steckt das Optimierungs-Knowhow der Google Ingenieure drin und wenn Du an der Stelle was gut machst, kannst Du noch einen Blumentopf gewinnen. Die pups-Homepage interessiert dagegen nicht nicht Bohne.
Natürlich kann man sich den Spass im privaten Bereich machen, die Bilder mit Poposhop noch mehr einzudampfen und 5 unnötige Einträge aus den css Files zu entfernen - aber im Pro Bereich tut das niemand - das ist bei Tagessätzen von ab 1000 EUR einfach zu teuer.
Alle Systeme die ich beruflich schon Optimiert habe waren nie wegen zu großer Bilder zu langsam. Sondern weil auf einer 500 Gigabyte Datenbank unoptimiert herum selektiert wird und beim Request noch Daten von ein paar SAP R/3 Systemen abgeholt werden. Bei der letzten Optimierung bei der ich vor ein paar Wochen beteiligt war haben wir z.B. eine Seite aus einem Kundensystem (Intranet, J2EE App mit SAP Anbindung) optimiert und haben die Ladezeit der fraglichen Seite von 15 Minuten (!!) auf 15 Sekunden (!!!!) verbessert.
Dass sind so die Probleme die einem im Pro Bereich begegnen. Bilder verkleinern? Irrelevant! Aber just 4 fun zum Hobby - klar, warum nicht?

Und aus meinen drei armseligen privaten Webseiten zu schließen was ich beruflich mache - naja....
Mehr Zeit wie ein bisschen iWeb geklicke werde ich privat sicher nicht in eine Webseite investieren. Ich würde HTML sowieso vorwiegend generieren wenn möglich - den ganze Kram von Hand zu tippen - reine Zeitverschwendung!

.... aber Immerhin kann man einem Profil hier mehr entnehmen als Deinem!
MacRabbitPro02.09.08 17:44
Ich habe schon vor 7 Jahren in einem Kern-Team von 5 Leuten an Applikationen mit:
- 2.1 Millionen Zeilen Code
- ca. 100 Millionen Datensätzen verteilt auf 250 Datenbank-Tabellen entwickelt. (Für eine der grössten Schweizer Banken).


Und - habt ihr bei dem Projekt zur Optimierung die Gifs verkleinert?
madox02.09.08 17:59
Das im PRO-Bereich vieles auf dem Server abläuft welches gut optimiert sein muss, stimmt schon.

Es geht hier um Websites im INTERNET welche für jeden zugänglich sind und vielleicht 100'000 oder 1 Million Page-Impressions haben (und keine internen web-basierte SAP-Anbindungen o.Ä). Und da spielen solche Dinge eine grosse Rolle. Wenn du mit einer schnellen Website irgendwie die Anzahl Impressions um 15% erhöhen kannst, hast du 15% mehr Umsatz.

Wenn du irgendwelche SAP-Anbindungen programmierst (was mich nicht interessiert und auch die anderen Benutzer nicht) .. ist das natürlich ganz etwas anderes.

Ausserdem steht ja im Journal man soll auch Server-Seitige optimierungen machen wie gute Indexes etc... nur gehe ich da nicht näher darauf ein weil das den Rahmen sprengen würde.
Und aus meinen drei armseligen privaten Webseiten zu schließen was ich beruflich mache - naja....
aber ich komme auch nicht grosskotzig daher wie du und behaupte jemand der mit iWeb Websites erstellt und sich keinen eigenen DNS leisten kann, nicht programmieren kann.

Habe ja genau das Gegenteil gesagt, so etwas würde ich nicht behaupten.
madox02.09.08 18:23
MacRabbitPro
Hast du schon einmal eine Website im Internet gemacht ausser deine iWeb oder dyndns-Seite...?

Falls ja, bitte poste deinen Link.

Falls nicht:
"Es geht hier um das World Wide Web - bzw. DAS Internet. Ich wünsche eigentlich gar keine Beteiligung mit deinen Comments wenn du keine Erfahrung mit Internet-Websites hast (weil es total am Thema vorbei geht)."
MacRabbitPro02.09.08 18:30
madox

Also zuerst einmal funktionieren "Intranet" Seiten mit der gleichen Technik wie Internet Seiten - nur dass Intranet Seiten einen geschlossenen Benutzerkreis haben - aber das braucht ich Dir nicht zu erzählen - damit kennst Du Dich aus. Abgesehen davon poste ich keine Kundenwebseiten weil ich dass nicht darf (Corporate Policy). Aber wenn Du im Internet unterwegs bist und Webseiten von großen Firmen besuchst oder deren Content Systeme (z.B. Online-Shops) benutzt, hast Du sicher auch schon einmal eine unserer Anwendungen benutzt, denn fast alle großen Unternehmen sind Kunden von uns - wenn auch nicht alle bez. Web-Technologie.
madox02.09.08 18:58
MacRabbitPro

Also kurz gesagt: Nein!?

Du machst einfach das Shop Background-System o.Ä. und HTML/CSS Umsetzen macht jemand anderes in deiner Firma oder der Firma des Kunden...?

Deine http://homepage.mac.com/rhasemann/ Seite mit 3 klitze-kleinen Bildern lädt in 7 Sekunden, bei einer 30'000 kbit/s Verbindung. Also gleich viel Inhalt wie die Google Startseite welche in 400ms lädt. (Ja ist klar, ist nur eine trash-seite von dir..)

Was wäre, wenn das eine Shop-Seite eines Kunden von dir wäre mit 60 Bildern und 4-5 JavaScript-Dateien, 3 CSS-Dateien... Wären es dann 20 Sekunden?

Wären es schon, aber zum Glück bist du nicht für diesen Bereich zuständig.
MacRabbitPro02.09.08 19:12
madox

Sorry, aber drehst du jetzt ganz ab? Ich habe Dir gerade versucht zu erklären, dass ich via Arbeitsvertrag verpflichtet bin keine Kunden-Informationen weiter zu geben.
Wie Du vielleicht gesehen hast liegt meine Seite mit den Bildern bei Apples MobileMe (kostest übrigens mehr als 12 EUR pro Jahr) und MobileMe ist bekanntlich (leider) für seine langsame Geschwindigkeit bekannt. Für den Download Speed kann ich nix.
Ansonsten kann ich Dir sagen dass ich beruflich alles mache - von statischen HTML Teilen über Java Script für Aktionen im Frontend, die Entwicklung auf dem Application Server (Java/JSP/EJB - das ist die meiste Arbeit) bis hin zum DB Design und den entsprechenden Generierungsskripten.
madox02.09.08 19:19
Aber nachdem du in den letzten 10 Posts damit angegeben hast, wie gut du bist (und wie unnötig solche optimierungen sind) ... könntest du wenigstens Angeben wie lange ein page-load ist (cache leeren im web inspector schauen) einer durchschnittlichen Shop-Lösung von dir!?
MacRabbitPro02.09.08 19:31
madox

Ich weiss zwar nicht was dir das bringt - letztendlich hängt die momentane Geschwindigkeit sehr von der Performance des Produktivsystems des Kunden sowie der momentanen Last des selbigen ab.
Aber ich habe mal gerade bei einem nachgeschaut zu dem ich Zugang habe und da lag die Antwortzeit eben zwischen knapp einer und drei Sekunden. Das liegt so auf dem üblichen Niveau solcher Systeme (wie Amazon & Co).
Und nun?
Außerdem ist das keine Shop-Lösung von "mir". Eine Person kann in einem Arbeitsleben solche System nicht erstellen dazu sind die Systeme viel zu groß.

madox02.09.08 19:40
OK, möchte dich nicht weiter stressen. Aber mit Antwortzeit meinst du schon den Download der kompletten Website mit allen Resourcen und nicht bis das HTML ausgeliefert wurde...?!

1 Sekunde ist optimal denke ich, .. Amazon hat 5 Sekunden.
MacRabbitPro02.09.08 19:48
Ja klar - 1-3 Sekunden war es bis alles komplett geladen war (HTML, CSS, JavaScript, Bilder). Ich denke dass Amazon sicher im Schnitt mehr Last hat als die Seite die ich gerade getestet habe.
madox02.09.08 20:00
Gut bei 1 Sekunde gibts ja nichts zu mäckern.

Aber Amazon ist schon schrecklich, irgendwie vor dem Source
50 leere zeilen nur mit spaces ausgefüllt... und im rest vom source nochmals 500 leere zeilen nur mit spaces ... 90% vom CSS direkt im HTML integriert, etc. Aber die werden schon wissen was sie tun
MacRabbitPro02.09.08 20:03
madox

Das ist halt typisch generierter Code - was da raus kommt sieht oft aus wie das letzte "Gematsche". Ungefähr so, als wenn man ein Dokument in Word als HTML abspeichert - nee obwohl - das ist NOCH schlimmer!
Weitere Kommentare anzeigen

Kommentieren

Sie müssen sich einloggen, um diese Funktion nutzen zu können.