Od czasu utworzenia Internetu średnie rozmiary plików stale rosną. To, co zaczęło się jako kilobajty, rozwinęło się do megabajtów (tak, liczba mnoga), a nasze pliki wciąż rosną.
Chociaż na pierwszy rzut oka to zjawisko nie jest niepokojące, wpływ jaki wywiera na wydajność i łatwość konserwacji jest okropny. Dodajemy starzejące się urządzenia, ograniczenia przepustowości lub małe prędkości w ogóle ... i mamy znacznie większy problem.
Na szczęście mamy kontrolę nad nie tylko naszymi rozmiarami plików, ale także sposobem renderowania naszych stron w przeglądarce. Tego typu kontrola pozwala programistom internetowym, takim jak my, pomóc złagodzić ten problem i zoptymalizować nasz kod, aby uzyskać lepszą wydajność w tym procesie.
Całkowicie rozumiem brak zainteresowania, gdy większość połączeń internetowych w USA jest obecnie dość szybka. Mam na myśli, jeśli wszystko działa dobrze, po co zawracać sobie głowę?
Wydajność i optymalizacja to coś więcej niż to, jak szybko możemy pobierać treści. Istnieje również sporo korzyści związanych z SEO i UX, poświęcając czas na zapoznanie się z naszym kodem. Nie wspominając o tym, że zmniejszanie rozmiarów plików poprzez optymalizację naszego kodu w celu zwiększenia wydajności ma dodatkową zaletę obniżenia kosztów związanych z przepustowością jako hostów i zmniejsza wykorzystanie przepustowości (np. ISP / komórkowe limity danych) na poziomie użytkownika.
Kod modułowy zwykle dodaje wzdęcia w postaci większej liczby opcji. Tutaj chcemy myśleć modularnie, jeśli chodzi o łączenie jak największej liczby wspólnych elementów kodu. Jeśli możemy połączyć dwie klasy CSS w jedną i użyć mniej kodu, aby zapewnić ten sam wynik, powinniśmy.
Modułowość nie jest tak ważna, jeśli chodzi o podstawowy kod HTML i CSS, ale gdy przejdziemy do bardziej złożonego świata JavaScript, zbyt dużo wzdęcia może cię zranić - zwłaszcza na urządzeniach mobilnych.
Żądania zależności są zdecydowanie największym czynnikiem spowalniającym większość szybkości ładowania stron. Każde dodatkowe żądanie dodaje rozrost i kolejną warstwę złożoności do procesu parsowania i pobierania. Często łatwo jest zapomnieć, że liczenie obrazów z arkusza stylów również się liczy, więc należy je ograniczyć i zastosować, jeśli to możliwe, alternatywne metody optymalizacji, takie jak sprite lub SVG.
Chociaż jesteśmy na temat zewnętrznych zależności, jeśli twoja strona jest wystarczająco duża, aby wymagać minimum kilkudziesięciu żądań ... Być może nadszedł czas, aby rozważyć użycie CDN. Używanie CDN do rozpowszechniania treści nie zmniejszy rozmiarów plików i / lub czasów ładowania tak bardzo, jak usunięcie wszystkich dodatkowych żądań HTTP, ale prawdopodobnie może usunąć wszystkie wolne połączenia z serwera przynajmniej z równania.
Podczas porównywania baz kodu kodu rozwoju i poziomu produkcji powinna występować bardzo wyraźna różnica. Samo wykonanie tego kroku może czasami doprowadzić do największego spadku rozmiarów plików na całej płycie.
Dzisiaj jest typowo, gdy deweloperzy odwołują się do swojego środowiska "produkcji" lub "rozwoju", zwłaszcza w przypadku dużych projektów. Ale jest również przydatny na mniejszym końcu rzeczy. Największa różnica między tymi dwoma środowiskami jest widoczna przy kompresji obrazu i minimalizacji / kompresji kodu. Ostatecznie chcemy, aby nasze środowisko produkcyjne było możliwie jak najbardziej zwięzłe i szybkie, podczas gdy nasze środowisko programistyczne powinno być takie samo, tylko pomniejszone o optymalizację kompresji obrazu / kodu.
Korzystanie z wbudowanych narzędzi, takich jak kompresja "Save for web" Photoshopa, może być dobrym punktem wyjścia dla obrazów. Istnieje ogrom wiedzy badane gdzie indziej a także rozmowy na temat formatów obrazu, algorytmów kompresji, kontroli jakości i najlepszych praktyk.
W przypadku kodu najlepsze wykorzystanie kompresji zwykle zależy od języka, z którym pracujesz. Jest również wysoce dyskusyjne, czy kompresja kodu pomaga, czy też krzywdzi innych ludzi próbujących zrozumieć twój kod, ale to jest rozmowa na inny czas. Jeśli chodzi o zwykły HTML i CSS, używam takich usług jak Google htmlcompressor i Kompresor YUI dla CSS.
Czasami sam kod, który piszemy, jest najwolniejszym ogniwem w łańcuchu. Nieefektywne CSS lub nadęty JavaScript może zaszkodzić czasowi ładowania o wiele bardziej niż myślisz. To Mozilla post opisuje szczegółowo znaczenie pisania lean selektorów CSS i wyjaśnia, w jaki sposób renderują je przeglądarki. W skrócie, zapisanie dokładnej ścieżki w dół łańcucha selektorów jest znacznie mniej wydajne niż po prostu użycie najmniejszego, jednoznacznie identyfikowalnego selektora. Obaj kierują stylizację na ten sam element, ten drugi po prostu wykonuje pracę dużo, dużo szybciej.
JavaScript może być nawet gorszy niż słabo napisany CSS, w wielu przypadkach łatwo go przeoczyć. Ile razy kopiowałeś i wklejałeś zewnętrzną bibliotekę JS do swojego projektu, nie sprawdzając dokładnie samego źródła? Typekit jest świetnym tego przykładem, ponieważ gdy ich serwery utkną, może przynieść stronę internetową, używając swoich czcionek do kolan i powodując dodatkowe 30 sekund lub nawet minut dodatkowego czasu ładowania.
Na szczęście takie zdarzenia zdarzają się rzadko, ale nadal dobrą praktyką jest wywoływanie JavaScriptu, jeśli to możliwe, tak jak w przypadku Google Analytics. Dzięki temu przeglądarka będzie analizować pliki nagłówkowe (CSS, żądania HTTP itp.) I wyświetlać znaczniki, zanim JavaScript zacznie spowalniać działanie.
Zgodnie z naszym celem pisania krótszych selektorów CSS i ograniczania do minimum, pisanie wydajnego HTML powinno być również priorytetem.
Resetowanie CSS często dotyczy wszystkich popularnych elementów i wymusza na nich styl "zerowania". Więc nawet jeśli nie celujesz w dodatkowe div, prawdopodobnie nadal zwalnia to działanie, ponieważ musisz mieć jego margines bezpieczeństwa i margines bezpieczeństwa na minimalnym poziomie. Zazwyczaj dodatkowy element div lub dwa nie zaszkodzi. Dopiero gdy zaczniesz robić z tuzinami, szaleją. Wraz z wprowadzeniem kolejnych elementów do specyfikacji HTML5, mamy również znacznie większą elastyczność w tym obszarze.
Największe znaczenie dla Google miało połączenie kolektywnego kształtu internetu. Aby zajmować ważne pozycje w wynikach wyszukiwania, strony muszą teraz zwracać krytyczną uwagę na wiele różnych atrybutów dotyczących sposobu ich renderowania. Wywoływanie zbyt dużej ilości zasobów zewnętrznych, posiadanie absurdalnie dużych obrazów lub nawet źle napisanych skryptów JavaScript może spowodować obniżenie pozycji witryny w rankingu.
Na szczęście jest to z dobrą intencją, ponieważ ich wymagania co do dobrego rankingu wyszukiwania opierają się na dobrych praktykach rozwojowych. Google oferuje także bardzo szczegółowy przewodnik zoptymalizować różne aspekty witryny pod kątem lepszej SEO - która jednocześnie promuje fantastyczne praktyki programistyczne w tym samym czasie.
Optymalizując nasz kod, musimy nie tylko myśleć o rozmiarach plików, ale także zastanowić się, jak będzie on czytany; albo przez przeglądarki, albo nawet przez innych ludzi. Należy również wziąć pod uwagę korzystanie z urządzeń przenośnych, a wielu dostawców usług wymusza obecnie ograniczanie limitów danych.
Tak więc, chociaż może to zająć trochę czasu, aby przeprowadzić całą tę optymalizację, jest to z pewnością warte zachodu, ponieważ zapewnia nie tylko lepszą wydajność w przeglądarce i na urządzeniach mobilnych, ale ma również szansę na promowanie lepszych praktyk programistycznych, a nawet podniesienie poziomu swojej zawartości. w wyszukiwarkach takich jak Google.
Następnym razem, gdy przygotujesz się do uruchomienia, rzuć swoje obrazy do silnika kompresji ... Możesz być zaskoczony, ile megabajtów może zgasić!