Autor: Feng |. Geben Sie beim Nachdruck unbedingt die Originalquelle und den Autor des Artikels sowie die Copyright-Erklärung in Form eines Hyperlinks an: http://www.dbanotes.net/web/flickr_web_tech .html
Cal Henderson ist einer der Entwickler der berühmten Flickr-Website. In einem Artikel mit dem Titel „Serving JavaScript Fast“ stellte er Techniken zur Optimierung von Flickr-Site-Anwendungen vor. Ich hatte das Gefühl, dass ich von der Lektüre sehr profitiert habe. „Kauen Sie die Brötchen anderer Leute“, fassen Sie den Hauptinhalt des Artikels zusammen.
Flickr ist eine repräsentative Seite des Web 2.0. Neben der für allgemeine Websites üblichen Inhaltsoptimierung müssen die Netzwerkprobleme auch flexibel mit der Komplexität der Bereitstellung und Verteilung umgehen, die durch häufige Änderungen in JavaScript und CSS verursacht wird.
Die erste Frage beim Festlegen der Dateigrößenstrategie ist, ob das gesamte JavaScript und CSS in einer Datei zusammengefasst oder in mehrere Dateien aufgeteilt werden soll. Aus Sicht der Reduzierung von Netzwerkanforderungen ist Ersteres besser und Letzteres schlechter. Aus paralleler Sicht können sowohl IE als auch Firefox standardmäßig nur zwei Ressourcen gleichzeitig von einer Domain anfordern. Dies führt in vielen Fällen zu einer schlechten Erfahrung – alle Dateien müssen auf einer anständigen Flickr-Seite heruntergeladen werden verwendet einen Kompromiss: Teilen Sie JavaScript und CSS in mehrere Unterdateien auf und halten Sie gleichzeitig die Anzahl der Dateien so gering wie möglich. Dies bringt Komplexität in die Entwicklung, aber die Leistungsvorteile sind enorm.
Problem der Komprimierungsoptimierung Es besteht kein Zweifel daran, dass die Komprimierung von Websiteinhalten eine relativ häufige Methode zur Weboptimierung ist. Allerdings ist es nicht immer möglich, den gewünschten Effekt zu erzielen. Der Grund dafür ist, dass das Modul mod-gzip nicht nur CPU-Ressourcen auf der Serverseite, sondern auch CPU-Ressourcen auf der Clientseite verbraucht. Darüber hinaus werden die nach der Komprimierung durch mod_gzip erstellten temporären Dateien auf der Festplatte abgelegt, was ebenfalls zu schwerwiegenden Problemen führt Für Festplatten-IO wird das von Httpd 2.x und höher unterstützte mod_deflate-Modul verwendet. Komprimierungsvorgänge werden alle im Speicher ausgeführt. mod_deflate ist in Httpd 1.x nicht verfügbar, aber Sie können die Leistung indirekt verbessern, indem Sie eine RAM-Disk erstellen.
Natürlich ist mod_gzip nicht nutzlos für vorkomprimierte Dateien. Darüber hinaus müssen Sie bei der Verwendung der Komprimierung auch auf die Strategie achten, dass Bilddateien nicht komprimiert werden müssen Komprimierung kann keine großen Vorteile bringen. Neuere Versionen von mod_gzip können vorkomprimierte Dateien automatisch verarbeiten, indem sie die Option mod_gzip_update_static
konfigurieren Komprimierung Ein Hauptmittel ist die Inhaltskomprimierung, indem Sie Kommentare reduzieren, Leerzeichen zusammenführen, kompakte Syntax verwenden und andere Tricks verwenden (natürlich sind alle Google-Skripte sehr schwer zu lesen und sehr kompakt). Bei dieser Verarbeitung enthält JavaScript möglicherweise viele Klammern, die schwer zu analysieren sind. Flickr verwendet Dojo Compressor, um einen Analysebaum zu erstellen. Dojo Compressor hat einen sehr geringen Overhead und ist für Endbenutzer transparent. Die JavaScript-Verarbeitung ist relativ einfach. Durch einfaches Ersetzen regulärer Ausdrücke (z. B. Ersetzen mehrerer Leerzeichen durch ein Leerzeichen) können Sie aufstehen bis 50 % Kompressionsverhältnis.
Optimierung des Cachings Flickr-Entwickler haben die in der HTTP 1.1-Spezifikation definierten Etag- und Last-Modified-Mechanismen vollständig genutzt, um die Effizienz des Cachings zu verbessern. Es ist erwähnenswert, dass Cal einen E-Tag-Trick unter Lastausgleichsbedingungen eingeführt hat. Sie können Apache so einstellen, dass E-Tag über die Dateianpassungszeit und -größe abgerufen wird. Standardmäßig erhält Apache E-Tag über den Dateiknoten. Dies ist natürlich nicht perfekt, da es sich auf if-modified-sind auswirkt.
Flexibler Einsatz von mod_rewrite Es heißt, dass die Flickr-Website-Anwendung täglich erstellt wird (Daily Build). Ohne einen flexiblen Mechanismus wäre dies undenkbar. Darüber hinaus ist die Synchronisierung von Inhaltsänderungen auf Websites wie Flickr ein Problem. Ihre Waffe ist die flexible Verwendung von mod_rewrite. Durch die Konfiguration von URL-Rewriting-Regeln ist es einfach, zu verschiedenen Umgebungen zu wechseln. Es klingt sehr einfach, aber wie einfach ist es, es ohne bestimmte Web-Technologie-Kenntnisse zu machen?
Durch die Anwendung dieser Hauptmethoden haben wir ein traumhaftes und leistungsstarkes Flickr gesehen.
Übrigens: Da Flickr keinen Server in China hat, kann die Zugriffsgeschwindigkeit für Benutzer auf dem Festland nicht erwähnt werden :(
--Ende.
Dieser Artikel [Tipps zur Optimierung von Webanwendungen für Flickr-Entwickler] stammt von dbanotes.net