Seit der Gründung des Internets sind die durchschnittlichen Dateigrößen stetig gewachsen. Was als Kilobyte begann, hat sich zu Megabytes (ja, Plural) entwickelt, und unsere Dateien wachsen nur noch.
Dieses Phänomen ist zwar nicht auf den ersten Blick beunruhigend, aber die Auswirkungen auf die Leistung und Wartbarkeit sind gravierend. Fügen Sie alternde Geräte, Bandbreitenbeschränkungen oder langsame Geschwindigkeiten im Allgemeinen hinzu ... und wir haben ein viel größeres Problem.
Zum Glück haben wir nicht nur die Kontrolle über unsere Dateigrößen, sondern auch, wie unsere Seiten im Browser gerendert werden. Diese Art der Kontrolle gibt Webentwicklern wie uns die Möglichkeit, dieses Problem zu lösen und unseren Code für eine bessere Leistung im Prozess zu optimieren.
Ich verstehe völlig das mangelnde Interesse, wenn die meisten Internetverbindungen in den USA heutzutage ziemlich schnell sind. Ich meine, wenn alles gut funktioniert schon, warum?
Bei Leistung und Optimierung geht es um mehr als nur um das schnelle Herunterladen von Inhalten. Es gibt auch eine Reihe von SEO- und UX-Vorteilen, die sich durch die Betrachtung unseres Codes ergeben. Nicht zu vergessen, die Verringerung der Dateigrößen durch Optimierung unseres Codes für eine bessere Leistung hat den zusätzlichen Vorteil, dass wir unsere Bandbreitenkosten als Hosts senken und die Bandbreitennutzung (denken Sie an ISP / Mobilfunk-Datenobergrenzen) auf Benutzerebene ebenfalls verringern.
Modularer Code fügt normalerweise Blähungen in Form von mehr Optionen hinzu. Hier wollen wir modular denken, um so viele gängige Teile unseres Codes wie möglich zu kombinieren. Wenn wir zwei CSS-Klassen zu einem kombinieren können und weniger Code verwenden, um das gleiche Ergebnis zu erzielen, sollten wir.
Modularität ist nicht so wichtig, wenn es um einfaches HTML und CSS geht, aber wenn Sie in die komplexere Welt von JavaScript kommen, kann Ihnen zu viel Blähung schaden - besonders auf Mobilgeräten.
Abhängigkeitsanforderungen sind bei weitem der größte Faktor bei der Verlangsamung der meisten Seitenladegeschwindigkeiten. Jede zusätzliche Anforderung fügt dem Parsing- und Download-Prozess eine aufgeblähte und eine weitere Komplexitätsebene hinzu. Es ist oft leicht zu vergessen, dass auch das Aufrufen von Bildern aus Ihrem Stylesheet zählt. Achten Sie also darauf, diese zu begrenzen und alternative Optimierungsmethoden wie Sprites oder SVG zu verwenden.
Wenn es um externe Abhängigkeiten geht, wenn Ihre Website groß genug ist, um mindestens ein paar Dutzend Anfragen zu stellen, ist es vielleicht an der Zeit, ein CDN in Erwägung zu ziehen. Die Verwendung eines CDN zum Verteilen Ihres Inhalts verringert die Dateigrößen und / oder Ladezeiten nicht so sehr wie das Entfernen zusätzlicher HTTP-Anforderungen insgesamt, aber es kann wahrscheinlich alle langsamen Serververbindungen aus der Gleichung entfernen.
Es sollte einen sehr starken Unterschied geben, wenn Sie Ihre Codebasen für Entwicklung und Produktion vergleichen. Wenn Sie diesen Schritt alleine durchführen, kann es manchmal zu der größten Abnahme der Dateigrößen auf der ganzen Linie kommen.
Heutzutage ist es typisch, dass Entwickler sich auf ihre "Produktions-" oder "Entwicklungs" -Umgebung beziehen, besonders bei großen Projekten. Aber es ist auch nützlich für das kleinere Ende der Dinge. Der größte Unterschied zwischen den beiden Umgebungen kann mit der Bildkomprimierung und der Minimierung / Komprimierung von Code gesehen werden. Am Ende wollen wir, dass unsere Produktionsumgebung so schlank und schnell wie möglich ist, während unsere Entwicklungsumgebung die gleiche sein sollte, nur ohne die Bild / Code-Komprimierungsoptimierung.
Die Verwendung der integrierten Tools wie Photoshop "Save for Web" -Komprimierung kann ein guter Ausgangspunkt für Bilder sein. Es gibt eine Fülle von Wissen zu sein anderswo erforscht ebenso mit Gesprächen über Bildformate, Komprimierungsalgorithmen, Qualitätskontrolle und Best Practices.
Bei Code hängt die optimale Komprimierung in der Regel von der Sprache ab, mit der Sie arbeiten. Es ist auch höchst umstritten, ob die Komprimierung von Code anderen Leuten hilft oder schadet, die versuchen, Ihren Code zu verstehen, aber das ist eine Konversation für eine andere Zeit. Wenn es um HTML und CSS geht, verwende ich Dienste wie Googles HTML-Komprimierer und das YUI-Kompressor für CSS.
Manchmal ist der Code, den wir gerade schreiben, das langsamste Glied in der Kette. Ineffizientes CSS oder aufgeblähtes JavaScript kann Ladezeiten mehr als Sie denken, beeinträchtigen. Dies Mozilla Post geht sehr detailliert auf die Wichtigkeit ein, schlanke CSS-Selektoren zu schreiben und zu erklären, wie Browser sie rendern. Kurz gesagt, ist das Schreiben des exakten Pfades entlang einer Kette von Selektoren viel weniger effizient als einfach die Verwendung des kleinsten eindeutig identifizierbaren Selektors. Beide lenken das Styling auf das gleiche Element, letzteres erledigt die Aufgabe viel schneller.
JavaScript kann sogar schlechter als schlecht geschriebenes CSS sein, und in vielen Fällen wird es leicht übersehen. Wie oft haben Sie eine externe JS-Bibliothek in Ihr Projekt kopiert und eingefügt, ohne wirklich auf die Quelle selbst einzugehen? Typekit ist ein wunderbares Beispiel dafür, denn wenn ihre Server zum Stillstand kommen, kann es eine Webseite mit ihren Schriften in die Knie zwingen und zusätzliche 30 Sekunden oder sogar Minuten zusätzliche Ladezeit verursachen.
Zum Glück passieren solche Ereignisse selten, aber es ist immer noch eine gute Praxis, wenn möglich, wie bei Google Analytics, JavaScript möglichst zuletzt aufzurufen. Auf diese Weise kann der Browser die Kopfdateien (CSS, HTTP-Anforderungen usw.) analysieren und das Markup anzeigen, bevor JavaScript die Vorgänge zu verlangsamen beginnt.
Im Einklang mit unserem Ziel, schlankere CSS-Selektoren zu schreiben und Aufblähung auf ein Minimum zu beschränken, sollte das Schreiben von effizientem HTML ebenfalls eine Priorität sein.
CSS-Resets zielen oft auf alle gängigen Elemente ab und erzwingen das Zurücksetzen von Stilen auf ihnen. Selbst wenn Sie dieses Extra-Div nicht anvisieren, verlangsamen Sie es wahrscheinlich immer noch, indem Sie Padding und Margin auf ein Minimum zurücksetzen müssen. In der Regel wird ein extra Div oder zwei nicht wirklich etwas verletzen. Nur wenn du anfängst, mit Dutzenden von ihnen zu enden, werden die Dinge verrückt. Mit der Einführung von mehr Elementen in die HTML5-Spezifikation haben wir auch in diesem Bereich viel mehr Flexibilität.
Google hat es sich zur Priorität gemacht, das Internet kollektiv in Form zu bringen. Um prominente Positionen in ihren Suchergebnissen einzunehmen, müssen die Seiten nun vielen verschiedenen Attributen, wie sie gerendert werden, kritische Aufmerksamkeit schenken. Zu viele externe Ressourcen anzurufen, absurd große Bilder zu haben oder sogar schlecht geschriebenes JavaScript zu verwenden, kann eine Website im Ranking nach unten ziehen.
Zum Glück ist dies alles gut gemeint, denn ihre Anforderungen an ein gutes Suchranking basieren auf guten Entwicklungspraktiken. Google bietet auch ein sehr detaillierte Anleitung Optimieren Sie verschiedene Aspekte Ihrer Website für besseres SEO - was gleichzeitig fantastische Entwicklungspraktiken fördert.
Bei der Optimierung unseres Codes müssen wir nicht nur über Dateigrößen nachdenken, sondern auch darüber nachdenken, wie diese gelesen werden. entweder von Browsern oder sogar anderen Menschen. Mobile Nutzung sollte ebenfalls in Betracht gezogen werden, da viele Diensteanbieter heutzutage sehr einschränkende Datenbeschränkungen durchsetzen.
Obwohl es möglicherweise zusätzliche Zeit in Anspruch nimmt, diese Optimierung durchzuführen, ist es sicherlich ein lohnendes Unterfangen, da es nicht nur eine bessere Leistung im Browser und auf Mobilgeräten bietet, sondern auch bessere Entwicklungspraktiken und sogar einen höheren Rang erzielen kann auf Suchmaschinen wie Google.
Das nächste Mal, wenn Sie sich auf den Start vorbereiten, werfen Sie Ihre Bilder in eine Komprimierungs-Engine ... Sie werden überrascht sein, wie viele Megabyte sie abschöpfen können!
Ausgewähltes Bild, Modulares Geschwindigkeitsbild über Shutterstock.