Optymalizacja plików JavaScript i CSS w Drupalu

1. Gdzie zaczyna się witryna?
2. Analiza sytuacji
3. Pliki CSS
4. Internet Explorer Limited
5. Ograniczenie protokołu HTTP
6. Podsumowanie analizy
7. Rodzaje optymalizacji
8. Przegląd istniejących kompresorów JavaScript.
9. Rozwiązania problemu
10. Standardowe funkcje Drupala
11. Jak optymalizować pliki js i css w rdzeniu Drupala?
12. Wady metody optymalizacji rdzenia Drupala
13. Optymalizacja JavaScript w rdzeniu Drupala
14. Korzystanie z kompresji HTTP
15. Dodatkowe moduły
16. Moduł CSS Gzip
17. Moduł Równolegle
18. Moduł IE CSS Optimizer
19. Moduł IE Unlimited CSS Loader
20. Moduł CSSTidy
21. Testowanie szybkości ładowania strony
22. Warunki testowe
23. Wykres ładowania strony w różnych trybach
24. Analiza wyników badań
25. Migruj javascript do stopki

Gdzie zaczyna się witryna?

• W przypadku przeglądarki strona zaczyna się od strony żądania GET.
• Serwer wysyła kod HTML dla tego żądania.
• Przeglądarka analizuje kod i rozpoczyna pobieranie wszystkich zewnętrznych plików (JS, CSS, Flash itp.) W kolejności, w jakiej pojawiają się w kodzie.
• Zazwyczaj przeglądarka wykorzystuje nie więcej niż 2 strumienie do załadowania plików zewnętrznych, a CSS i JS są ładowane ogólnie w jednym strumieniu.
• Czas dla każdego żądania zależy od wielkości zwróconej odpowiedzi, obciążenia serwera i aktywności na każdej maszynie między przeglądarką a serwerem.
• Im większy rozmiar pliku , tym dłużej będzie on dostarczany do przeglądarki.
• Im więcej plików , tym dłużej będzie ładowana cała strona.

Jak przeglądarka renderuje stronę?

Do pełnego obciążenia JS od HEAD użytkownik widzi „białą stronę”. Po załadowaniu wszystkich skryptów zewnętrznych wykonanie JS rozpoczyna się w kolejności na stronie (od góry do dołu), a użytkownik już zaczyna widzieć zawartość strony, a gdy CSS i obrazy są ładowane, strona jest całkowicie narysowana.

Aby zwiększyć szybkość ładowania strony, potrzebujesz:

• Zmniejsz rozmiar skryptów, aby przyspieszyć odpowiedź strony głównej
• Zmniejsz liczbę plików (obrazy są scalane w sprity, a JS i CSS są agregowane)
• Użyj kompresji HTTP
• Zwiększ liczbę hostów, z których ładowana jest statyka, aby przeglądarka mogła zwiększyć limit jednoczesnych połączeń
• Umieść JavaScript na stronie stopki, aby były ostatnio ładowane, a użytkownik może już korzystać ze strony.

Optymalizacja grafiki i tworzenie sprite'ów to zadanie dla projektanta, a my będziemy pracować nad optymalizacją plików JavaScript i CSS w Drupalu.

Zobaczmy, jak wygląda sytuacja z tymi plikami w Drupalu.

Analiza sytuacji

Javascript

Możesz sam sprawdzić rozmiar swoich plików JS za pomocą polecenia:

znajdź. -name '* .js' -exec ls -l {} | awk '{s + = 5 $} END {print s}'

W naszym projekcie oprócz plików jądra jest jeszcze ponad 1300 ( ! ) Plików JS, które znajdują się w dodatkowych modułach i motywach.
Całkowity rozmiar wszystkich plików JS wynosi 14 746 899 bajtów.
W rdzeniu Drupala 6 znalazłem następujące pliki Javascript:

1. modules / comment / comment.js
2. modules / profile / profile.js
3. modules / openid / openid.js
4. modules / taxonomy / taxonomy.js
5. modules / system / system.js
6. modules / block / block.js
7. modules / color / color.js
8. modules / user / user.js
9. misc / autocomplete.js
10. misc / drupal.js
11. misc / collapse.js
12. misc / batch.js
13. misc / farbtastic / farbtastic.js
14. misc / form.js
15. misc / tableselect.js
16. misc / ahah.js
17. misc / tabledrag.js
18. misc / textarea.js
19. misc / progress.js
20. misc / tableheader.js
21. misc / teaser.js
22. misc / jquery.form.js
23. misc / jquery.js

Dobrze, że nie wszystkie są załadowane na tej samej stronie, a niektóre nie są w ogóle używane. Prawidłowe skonfigurowanie warunków łączenia plików JS i CSS na stronie leży w świadomości programisty modułu, dzięki czemu niepotrzebny kod nie zmniejsza szybkości ładowania strony.

Pliki CSS

W twoim projekcie liczba i całkowity rozmiar będą różne.
Polecenie do samodzielnego sprawdzania rozmiaru plików CSS:
znajdź. -name '* .css' -exec ls -l {} | awk '{s + = 5 $} END {print s}'

W naszym projekcie oprócz plików jądra jest jeszcze około 450 dodatkowych modułów i motywów.
Całkowity rozmiar wszystkich plików CSS wynosi 1 674 779 bajtów.
Jeśli chodzi o pliki CSS w rdzeniu Drupala 6, oto one:

1. modules / locale / locale.css
2. modules / aggregator / aggregator-rtl.css
3. modules / aggregator / aggregator.css
4. modules / update / update.css
5. modules / update / update-rtl.css
6. modules / poll / poll.css
7. modules / poll / poll-rtl.css
8. modules / comment / comment-rtl.css
9. modules / comment / comment.css
10. modules / tracker / tracker.css
11. modules / forum / forum-rtl.css
12. modules / forum / forum.css
13. modules / book / book.css
14. moduły / książka / book-rtl.css
15. modules / profile / profile.css
16. modules / search / search-rtl.css
17. modules / search / search.css
18. modules / openid / openid.css
19. modules / node / node-rtl.css
20. modules / node / node.css
21. modules / taxonomy / taxonomy.css
22. modules / system / system-menus-rtl.css
23. modules / system / admin-rtl.css
24. modules / system / admin.css
25. modules / system / maintenance.css
26. modules / system / defaults-rtl.css
27. modules / system / defaults.css
28. modules / system / system-rtl.css
29. modules / system / system-menus.css
30. modules / system / system.css
31. modules / block / block.css
32. modules / color / color.css
33. modules / color / color-rtl.css
34. modules / help / help.css
35. modules / help / help-rtl.css
36. modules / dblog / dblog.css
37. modules / dblog / dblog-rtl.css
38. modules / user / user.css
39. modules / user / user-rtl.css
40. misc / print-rtl.css
41. misc / farbtastic / farbtastic.css
42. misc / print.css
43. tematy / bluemarine / style.css
44. tematy / bluemarine / style-rtl.css
45. tematy / garland / print.css
46. tematy / garland / style.css
47. themes / garland / minnelli / minnelli.css
48. tematy / girlanda / kolor / podgląd.css
49. themes / garland / style-rtl.css
50. themes / garland / fix-ie.css
51. themes / garland / fix-ie-rtl.css
52. themes / pushbutton / style.css
53. themes / pushbutton / style-rtl.css
54. themes / chameleon / common-rtl.css
55. tematy / chameleon / style.css
56. tematy / kameleon / marvin / style.css
57. tematy / kameleon / marvin / style-rtl.css
58. themes / chameleon / common.css
59. themes / chameleon / style-rtl.css

Całkowity rozmiar plików CSS jest o rząd wielkości mniejszy niż rozmiar plików JS. Ale musisz wziąć pod uwagę, że na stronie jest znacznie więcej plików CSS niż plików JS - około 2 razy więcej. Ponadto style są zazwyczaj ładowane dla wszystkich stron (są to style motywów) i tylko style modułów mogą być ładowane dla określonych stron. Zatem zarówno pliki stylów, jak i skrypty wymagają naszej uwagi w tym samym stopniu.

Internet Explorer Limited

Przeglądarka IE 6-8 ma limit liczby i rozmiaru plików CSS :

• Wszystkie tagi dodające style po pierwszych 31 tagach są ignorowane.
• Wszystkie reguły CSS po pierwszych 4,095 regułach są ignorowane.
• Na stronach używających reguły @import do importowania zewnętrznych arkuszy stylów, które importują inne zewnętrzne arkusze stylów, arkusze stylów z poziomem zagnieżdżenia większym niż 3 są ignorowane.

Ograniczenie protokołu HTTP

Zastanawiam się, czy przeglądarki mają limit liczby połączeń AJAX?

Zgodnie ze specyfikacją HTTP 1.1 przeglądarka musi ustanowić nie więcej niż 2 jednoczesne połączenia (a to dotyczy IE6 / 7) do tego samego hosta. W Firefoksie i Operze to ustawienie jest konfigurowalne i domyślnie wynosi co najmniej 4. Według niektórych danych w IE8 - 6 połączeń z jednym hostem.

Źródło informacji: Podnoszenie network.http.max-persistent-connections-per-server?

• Firefox 2: 2
• Firefox 3 beta 4: 4
• Opera 9.26: 4
• Opera 9.5 beta: 4
• Safari 3.0.4 Mac / Windows: 4
• IE 7: 2
• IE 8: 6

Podsumowanie analizy

• Większość plików JS i CSS nie jest zoptymalizowana.
• Jest dużo plików, a ich łączne rozmiary są znaczne.
• Mamy problemy z przeglądarką IE, która ogranicza liczbę plików CSS na stronie.
• Problemy z szybkością ładowania strony ze względu na dużą liczbę zewnętrznych plików i ograniczenie przeglądarek do liczby jednoczesnych połączeń z serwerem.

Zrozumiemy terminologię.

Rodzaje optymalizacji

Minimalizacja skryptów polega na usunięciu wszystkich nieistotnych znaków z kodu w celu zmniejszenia rozmiaru pliku skryptu i przyspieszenia jego ładowania. W zminimalizowanym kodzie, wszystkich komentarzach i nieznaczących odstępach, podziałach wierszy, znaki tabulacji są usuwane. W przypadku JavaScript zmniejsza to czas ładowania strony, ponieważ zmniejsza się rozmiar pliku. Dwa najbardziej popularne narzędzia do minimalizacji JavaScript - Jsmin i Kompresor YUI .

Zaciemnienie to alternatywny sposób skrócenia kodu źródłowego. Ponadto, podobnie jak minimalizacja, usuwa białe znaki i wycina komentarze, ale dodatkowo zmienia sam kod. Na przykład podczas zaciemniania nazwy funkcji i zmiennych są zastępowane nazwami krótszymi, co czyni kod bardziej zwartym, ale mniej czytelnym. Zazwyczaj technika ta jest wykorzystywana do komplikowania programu inżynierii odwrotnej. Ale zaciemnienie pomaga również zredukować kod tak bardzo, jak nie można tego zrobić poprzez minimalizację. Z wyborem narzędzi do zaciemniania JavaScript nie jest tak jasny, ale myślę, że najbardziej powszechnym narzędziem do tego jest Dojo Compressor (ShrinkSafe).

Minimalizacja JavaScript jest bezpiecznym i dość prostym procesem. Z drugiej strony, zaciemnianie, ze względu na swoją złożoność, może wprowadzać błędy do kodu. Zaciemnianie wymaga również edycji kodu, aby wyróżnić funkcje API i inne elementy, które nie powinny być zmieniane.

Agregacja - To jest połączenie kilku plików na stronie w jeden. Agregacja jest tak bezpieczna jak minimalizacja, ponieważ kod się nie zmienia. Czasami „scalanie” plików może się nie powieść z powodu niepoprawnych komentarzy na końcu plików. Agregacja pozwala zmniejszyć liczbę plików podłączonych do strony. Począwszy od Drupala 6, agregacja plików CSS i JS jest wbudowana w jądro, a przed tą wersją trzeba było zainstalować dodatkowy moduł.

Kompresja HTTP - jest to sposób na kompresję treści (głównie tekstowych), które są przesyłane z serwerów internetowych przez Internet do przeglądarek. Główną zaletą kompresji jest zmniejszenie liczby przesyłanych bajtów, a tym samym osiągnięcie większej wydajności. Kompresja HTTP wykorzystuje publicznie dostępne algorytmy kompresji do kodowania HTML, XML, JavaScript, CSS i innych formatów plików po stronie serwera. Ta metoda dostarczania skompresowanej treści jest oparta na standardach i jest zawarta w HTTP / 1.1, a wszystkie nowoczesne przeglądarki obsługują protokół HTTP / 1.1. W ten sposób mogą automatycznie rozpakować skompresowane pliki po stronie klienta. Oznacza to, że nie jest potrzebne żadne dodatkowe oprogramowanie ani udział użytkownika po stronie klienta.

Żądanie serwera bez kompresji

Wniosek do serwera i serwera daje skompresowaną zawartość

W przypadku kaskadowych arkuszy stylów można zastosować tylko minimalizację, agregację i kompresję HTTP. Zaciemnianie plików CSS nie jest używane. Jednak w przypadku plików JavaScript odpowiednia jest każda z metod.

Przegląd istniejących kompresorów JavaScript.

Możesz porównać współczynnik kompresji tego samego pliku za pomocą usługi online: Kompresor JavaScript i narzędzie do porównywania .

• Jsmin - tradycyjny kompresor, napisany kilka lat temu przez Douglasa Crockforda (Douglas Crockford). Narzędzie jest bezpieczne (szczególnie, jeśli sprawdziłeś przy użyciu swojego kodu) Jslint ), ponieważ narzędzie nie próbuje zmienić nazw zmiennych.
• Dojo shrinksafe - To bardzo popularny kompresor JavaScript napisany w Javie. Analizuje kod za pomocą biblioteki nosorożec i zmienia nazwy zmiennych lokalnych.
• Packer napisane przez Deana Edwardsa. Kolejny bardzo popularny kompresor JavaScript, który potrafi wykonać jeszcze bardziej normalną kompresję i dodaje dekompresję w trakcie wykonywania JavaScript.
• Kompresor YUI - To najnowszy kompresor napisany przez Juliena Lecomte, którego celem jest połączenie bezpieczeństwa JSMin z najwyższym poziomem kompresji osiągniętym przez Dojo Shrinksafe. Podobnie jak Dojo shrinksafe, jest napisany w Javie i jest oparty na bibliotece. nosorożec .

Współczynnik kompresji wszystkich sprężarek jest inny, ponieważ metody kompresji są różne. Kompresja małych plików z reguły zapewnia bardzo małą kompresję, a pliki większe niż 10 KB są bardzo dobrze skompresowane. Poniższy diagram pokazuje zależność współczynnika kompresji od rozmiaru pliku:

Szczegóły testowania stopnia kompresji różnych sprężarek - w artykule JavaScript: zbierać lub nie zbierać? . Wykorzystano diagram z tego artykułu.

Rozwiązania problemu

Mamy więc wystarczająco dużo plików, które można skompresować i musimy dowiedzieć się, co Drupal może nam zaoferować (w jądrze i dodatkowych modułach) i znaleźć najbardziej optymalne rozwiązanie.

Zacznijmy od analizy tego, co już mamy po wyjęciu z pudełka.

Standardowe funkcje Drupala

Rdzeń Drupala 6 implementuje agregację plików JavaScript i CSS oraz kompresję HTTP.
Na stronie „Wydajność” („Wydajność” - admin / ustawienia / wydajność ) można włączyć / wyłączyć optymalizację plików CSS i JavaScript:

Jeśli optymalizacja plików CSS i JS jest zablokowana, oznacza to, że pamięć podręczna zagregowanych plików nie może być zapisana w plikach. Sprawdź, czy ścieżka do folderu plików i uprawnienia do zapisu dla tego folderu na stronie System plików (System plików - admin / ustawienia / system plików ) są poprawne.

Jak optymalizować pliki js i css w rdzeniu Drupala?

Aby rozpocząć korzystanie z tej funkcji, musisz włączyć optymalizację plików JavaScript lub CSS na stronie dostrajania wydajności.
Następnie podczas zmiany strony z funkcji template_preprocess_page () fukntion zostanie wywołany drupal_get_css () . Jest to ta funkcja, która wykonuje główną pracę dla plików CSS.

Jak działa ta funkcja drupal_get_css () ?

• Optymalizacja CSS nie jest wykonywana, gdy witryna jest w trybie konserwacji („Konserwacja”) lub uruchomiona jest aktualizacja (update.php).
• Linia w postaci parametru jest dodawana do zoptymalizowanych plików, co pozwala kontrolować buforowanie plików przez przeglądarkę. Po uruchomieniu update.php lub po zresetowaniu pełnej pamięci podręcznej ta linia zmienia się, co powoduje, że przeglądarki ponownie ładują nowe wersje plików, ponieważ uważają, że adres URL się zmienił.
• O tym, czy plik będzie uczestniczył w optymalizacji, decyduje czwarty argument funkcji. drupal_add_css () - $ preprocess, który określa, czy ten plik będzie uczestniczył w optymalizacji, jeśli zostanie uwzględniony. Domyślnie plik będzie uczestniczył w optymalizacji.
• Najpierw generowane są 2 listy plików, które nie uczestniczą w optymalizacji CSS - osobno (1) dla modułów i oddzielnie (2) dla tematów.
• Następnie utwórz nazwę pliku, w którym będzie przechowywany zoptymalizowany CSS, a funkcja zostanie wywołana drupal_build_css_cache () który agreguje i optymalizuje pliki CSS.
• Plik wynikowy jest zapisywany w folderze sites / default / files / css (będzie inny sposób instalacji na wielu serwerach, ale - myślę - że sam wiesz, gdzie zostaną zapisane).

Co obejmuje optymalizacja?

• Wszystkie instrukcje @import są przetwarzane drupal_load_stylesheet () i są zastępowane treścią pliku, który miał zostać zaimportowany.
• Wszystkie komentarze znajdują się w cudzysłowach pojedynczych i podwójnych i są wysyłane do funkcji w celu przetworzenia. _process_comment () , który próbuje ustalić, czy ten komentarz może zostać usunięty, czy jest to hack dla IE-Mac.
• Spacje są usuwane wokół separatorów, ale pozostają w nawiasach.

Tak więc optymalizacja, którą oferuje nam rdzeń Drupala minimalizacja z agregacją w jeden plik.

Wady metody optymalizacji rdzenia Drupala

Metoda optymalizacji używana w rdzeniu Drupala jest bezpieczna, to znaczy nie prowadzi do błędów w kodzie. Ale metoda nie jest tak skuteczna, jak się wydaje.

Faktem jest, że na stronie może znajdować się tuzin 2 różnych skryptów, które są gromadzone w unikalnym pliku buforowanym dla tej strony. Skrypty na stronie mogą być ładowane w zależności od praw dostępu użytkownika lub innych warunków, co zwiększa liczbę opcji dla jednej strony.

Dlatego tworzymy duży plik, który agreguje skrypty, a przeglądarka buforuje je dla tej strony. Na następnej stronie można dodać lub usunąć kilka skryptów i utworzyć nowy unikalny plik, który agreguje skrypty dla tej strony. Przeglądarka również ją buforuje, ale w tych dwóch dużych plikach jest wiele wspólnego kodu, który jest przesyłany i buforowany przez przeglądarkę oddzielnie w plikach o różnych nazwach. Dzięki temu przy efektywnym buforowaniu przeglądarki (jeśli jest włączona) ta metoda może nawet zwiększyć ruch.

Optymalizacja JavaScript w rdzeniu Drupala

Optymalizacja JavaScript odbywa się jak optymalizacja plików CSS.

Ten sposób łączenia może generować błędy w zagregowanym pliku, gdy na końcu skryptu ostatni wiersz był komentarzem.

Podczas optymalizacji plików JavaScript są one łączone w jeden duży plik nieco inaczej - po każdym pliku dodaje się „; n”.
Sam kod JS nie zmienia się wcale - można to zobaczyć w kodzie funkcji. drupal_build_js_cache () , ale po prostu scalony w jeden duży plik.

Oznacza to, że rdzeń Drupala nawet nie minimalizuje JavaScript !

Korzystanie z kompresji HTTP

Na stronie dostrajania wydajności („Wydajność”) możesz włączyć i wyłączyć kompresję HTTP:

Fukntia page_set_cache () zapisuje skompresowaną zawartość strony w pamięci podręcznej, jeśli:

• Jeśli zdecydujesz się użyć kompresji ruchu na stronie dostrajania wydajności,
• Rozszerzenie Php zlib ) jest obecny w systemie

Drupal buforuje zawartość strony i jeśli warunki określone powyżej są spełnione, kompresuje, a następnie buforuje zawartość strony. .

Jeśli przeglądarka obsługuje kompresję HTTP, to w żądaniu strony wskazuje, z jakim rodzajem kompresji może pracować:

Accept-Encoding: gzip, deflate

Proste narzędzie do kompresji / deflate / gzip strony internetowej - usługa, która sprawdza, czy serwer wysyła plik przy użyciu kompresji HTTP i współczynnika kompresji.

Jeśli serwer korzysta z kompresji HTTP, skompresuje i udostępni przeglądarce skompresowaną wersję treści.
Ale sam Drupal może, za pomocą biblioteki zlib, kompresować i buforować już skompresowaną wersję strony HTML, ale nie pliki JS, a nie CSS.
Oznacza to, że jeśli serwer WWW jest skonfigurowany do kompresji zawartości, a przeglądarka obsługuje tę kompresję, serwer będzie kompresować pliki JS i CSS w locie. Dużo bardziej efektywne byłoby jednak przechowywanie skompresowanych kopii tych plików z najwyższym możliwym współczynnikiem kompresji, niż kompresowanie ich w locie (w tym przypadku domyślnie nie jest to maksymalny współczynnik kompresji).

Dodatkowe moduły

Moduł Agregator JavaScript

Moduł minimalizuje wykorzystanie plików JS Jsmin
Moduł może kompresować zagregowane i zminimalizowane pliki JS przy użyciu kompresji gzip. Skompresowana kopia jest przechowywana w pliku na serwerze i przekazywana do przeglądarki zamiast kompresowania samego serwera WWW.

Przykład kompresji:

FILA SECURITY

Moduł CSS Gzip

• Moduł kompresuje zagregowane pliki CSS, tak jak moduł Aggregator Javascript z plikami JS.
• Kompresuje zawartość raz i oszczędza wynik - zmniejsza obciążenie procesora serwera.
• Używa dziewiątego poziomu kompresji, ponieważ musi być wykonany tylko 1 raz dla każdego pliku, co daje mniejszy rozmiar pliku.
• Wymaga włączonych czystych linków (mod_rewrite).
• Wymaga, aby metoda pobierania była „Publiczna” (patrz admin / settings / file-system ).
• Wprowadzono rdzeń Drupala 7.

Moduł Równolegle

• Pozwala przeglądarce na równoległe ładowanie plików stron zewnętrznych.
• Aby to zrobić, utwórz 3 nowe subdomeny, które wskazują ten sam folder główny witryny.
• Włącz moduł równoległy.
• Na stronie „Wydajność” musisz określić te poddomeny.
• Nie wymaga hakowania rdzenia Drupala.
• Moduł równoległy działa tylko z JavaScriptem, obrazami i CSS.

Moduł IE CSS Optimizer

• Moduł umożliwia programistom wykluczenie z agregacji poszczególnych plików modułów, a także plików CSS motywów.
• Wymaga, aby metoda pobierania była „Publiczna” (patrz admin / settings / file-system ).
• W Drupal 7 moduł nie jest potrzebny: http://drupal.org/node/228818 .
• Inne moduły mogą nadpisywać $ vars ['styles'], a to neutralizuje moduł. Zmienia wagę modułu.

Moduł IE Unlimited CSS Loader

„nie używaj @import” - Artykuł o tym, dlaczego korzystanie z @import nie jest pożądane pod względem wydajności.

Moduł działa mniej więcej tak samo IE CSS Optimizer , ale w nieco inny sposób - użyj @import, aby ominąć ograniczenia przeglądarki IE w pliku 31 CSS.

Moduł CSSTidy

• Moduł uruchomi się automatycznie CSSTidy na maksymalnym poziomie kompresji.
• Możesz go skonfigurować tak, aby kod był czytelny.
• Moduł nie jest kompatybilny z Pressflow.
• Nowy CSS3 może powodować problemy (patrz http://drupal.org/node/763730 ). Niektóre z nich zostały już rozwiązane: http://drupal.org/cvs?commit=432558

Co jest zoptymalizowane:

• Kolory czarne lub rgb (0,0,0) są konwertowane na kody szesnastkowe typu # 000, gdy tylko jest to możliwe. Niektóre kody szesnastkowe są zastępowane nazwami kolorów, jeśli są krótsze (# f00 -> czerwony).
• a {właściwość: x; właściwość: y;} staje się {właściwością: y;} (wszystkie atrybuty cykliczne są łączone).
• margin: 1px 1px 1px 1px; staje się marginesem: 1px;
• margin: 0px; staje się marginesem: 0;.
• a {margin-top: 10px; margin-bottom: 10px; lewy margines: 10px; margin-right: 10px;} staje się {margin: 10px;}.
• margines: 010,0px; staje się marginesem: 10px;
• Wszystkie niepożądane miejsca zostaną usunięte.
• Wszystkie tło właściwości: połączone.
• Wszystkie komentarze zostaną usunięte.
• Ostatni średnik w każdym bloku jest usuwany.
• Dodaje się brakujące średniki, poprawiane są niepoprawne podziały wierszy w wierszach, poprawiane są nieprawidłowe kolory (i nazwy kolorów).
• właściwość: wartość! ważne; staje się właściwością: wartość! ważne;

Hacki CSS, które działają:

Testowanie szybkości ładowania strony

Czas ładowania strony został zmierzony, aby dowiedzieć się, jak bardzo zmieni się średni czas ładowania przy różnych metodach optymalizacji plików JS. Strona testowa zawiera ponad 1300 plików JS i prawie 450 plików CSS. Zainstalowano 227 modułów (w tym moduły jądra). Zbadano różne metody optymalizacji:

• Optymalizuj pliki JavaScript: Wyłączone - optymalizacja plików JS przez rdzeń Drupala jest wyłączona
• Optymalizuj pliki JavaScript: Włączone - włączona jest optymalizacja plików JS przez rdzeń Drupala
• Optymalizacja i minimalizacja plików JavaScript: włączona - optymalizacja plików Js przez rdzeń Drupala jest włączona i zainstalowany jest agregator Javascript, który minimalizuje kod JS więcej.

Warunki testowe

Ustawienia przeglądarki

• Sprawdzona strona: główna strona testowanej witryny
• Przeglądarka: Firefox 3.6.13
• Pamięć podręczna przeglądarki: 500M
• Narzędzie pomiarowe: Yslow 2.1.0
• Serwer proxy: nie używany

Ustawienia serwera

• Używany na serwerze: akcelerator
• System operacyjny: Linux
• Wersja jądra: 2.6.29-5
• Architektura: x86_64

Ustawienia w Drupalu

• Użytkownik Drupala: superadmin
• Tryb buforowania: Normalny
• Minimalny czas życia pamięci podręcznej: brak
• Kompresja strony: włączona
• Blokuj pamięć podręczną: włączona
• Optymalizuj pliki CSS: włączone

Wyniki testu

Średni czas ładowania strony

Wykres ładowania strony w różnych trybach

Analiza wyników badań

• Agregacja zmniejsza liczbę żądań do serwera (z pustą pamięcią podręczną) o 23 części .
  Oznacza to, że gdy użytkownik ładuje stronę po raz pierwszy (pamięć podręczna jest pusta), pobieranie będzie szybsze.
• Korzystanie z pamięci podręcznej przeglądarki zmniejsza liczbę żądań do 13.
  Powtarzające się żądania tej samej strony są jeszcze szybsze ze względu na fakt, że przeglądarka buforuje niektóre pliki.
  Pamięć podręczna jest zwykle włączona domyślnie, ale nie możemy kontrolować buforowania przeglądarki i można ją po prostu wyłączyć.
• Kompresja Gzip nie odbywa się przy maksymalnym poziomie kompresji.
  Zagregowany plik JS ma dokładnie taki sam rozmiar jak całkowity rozmiar wszystkich niezagregowanych plików JS strony. Zagregowany plik na serwerze ma rozmiar 326,9 KB, a skompresowany plik gzip otrzymany przez przeglądarkę to 108,9 KB. Jednocześnie kompresja gzip tego samego pliku ręcznie daje rozmiar około 90 Kb. Powodem jest to, że biblioteka zlib, która jest używana do kompresji serwera, ma domyślny współczynnik kompresji (zlib.output_compression_level) równy „-1”, chociaż maksymalny współczynnik kompresji to „9”, a „-1” to najlepsza wydajność. Mamy więc najgorszą kompresję, ale dzięki temu prędkość serwera jest wyższa.
• Używanie modułu Aggregator JavaScript wraz z agregacją i kompresją Gzip daje plik znacznie mniejszy niż pliki niezagregowane.

Zatem eksperymentalnie stwierdzono, że optymalizacja plików JS przez rdzeń Drupala nie zawsze pokazuje dobry wynik. W naszym przypadku (bez użycia modułu JavaScript Aggregator) otrzymaliśmy niewielki wzrost prędkości pobierania (poprzez zmniejszenie liczby żądań) i zwiększenie (w porównaniu do plików źródłowych) rozmiaru zagregowanego (i skompresowanego) pliku.

Biorąc pod uwagę fakt, że na wielu stronach ładowane są te same pliki JS i CSS, a tylko kilka konkretnych jest dodanych / usuniętych, buforowanie jednego dużego pliku nie zwiększy wydajności. Jednocześnie buforowanie przeglądarki poszczególnych plików stylów i skryptów na jednej stronie pozwoli zaoszczędzić na pobieraniu tych plików na kolejnych stronach.
Użytkownik z reguły nie ładuje tej samej strony kilka razy, ale kontynuuje działanie („surfit”), a zatem buforowanie małych plików skryptów i stylów przeglądarki może być bardziej wydajne niż agregacja w jeden duży plik. Ale jest to tylko dla użytkownika i bardziej opłacalne jest, aby serwer miał jak najmniej żądań i wysyłał zagregowane pliki zamiast sterty małych plików.

Co można zrobić, aby poprawić sytuację?

• Przechowuj skompresowane pliki JS z maksymalnym poziomem kompresji, aby nie zmuszać serwera do kompresji ich dla każdego żądania.
• Użyj bardziej wydajnych metod pakowania dla plików JS i CSS.
• Możesz użyć selektywnej agregacji skryptów i stylów, które są wspólne dla różnych stron witryny, i możesz ładować określone pliki osobno, ale ta metoda jest czasochłonna.
• Przenieś Javascript do stopki, aby przyspieszyć wyświetlanie strony użytkownikowi.
• Użyj modułu CDN lub równoległego, aby zwiększyć liczbę jednoczesnych połączeń, na które może pozwolić przeglądarka.

Migruj javascript do stopki

Na samym początku artykułu dowiedzieliśmy się, że przeglądarka ładuje wszystkie pliki CSS i wszystkie JS z HEAD i dopiero wtedy pokazuje stronę użytkownikowi i rozpoczyna wykonywanie JS. Dlatego sensowne jest przeniesienie plików JS do stopki, aby przynieść moment, w którym zawartość strony pojawi się w przeglądarce. Skróci to czas, w którym użytkownik zobaczy „białą stronę” i wizualnie przyspieszy ładowanie strony (w rzeczywistości strona załaduje się tyle samo czasu).

Pliki JS w Drupalu są połączone w następujący sposób:

drupal_add_js ($ data = NULL, $ type = 'module', $ scope = 'header' , $ defer = FALSE, $ cache = TRUE, $ preprocess = TRUE)

tutaj
$ scope (opcjonalnie) Możliwe wartości to domyślnie „nagłówek” i „stopka”. Możesz ich jednak użyć.

Domyślnie $ scope jest „nagłówkiem” i jeśli nie określono inaczej, wszystkie skrypty są ładowane do HEAD ...
Dlatego we wszystkich modułach musisz zmienić $ scope = 'header' na $ scope = 'footer'.

Po prostu przesunięcie wyniku do stopki nie będzie działać, ponieważ strony HEAD będą miały wbudowane skrypty, które oczekują jquery.js i innych skryptów w HEAD i będą dawały błędy podczas wykonywania.

W siódmej wersji Drupala dyskutowano o możliwości ustawienia domyślnej wartości $ scope - „footer” ( Ustaw „stopkę” jako domyślny zakres dla drupal_add_js (), aby strony szybko się renderowały ), ale najprawdopodobniej będzie już w 8. wersji Drupala.

Przydatne linki

Kompresory skryptowe

Kompresja HTTP

Kolejność ładowania strony przeglądarki

Przenoszenie Javascript do stopki

Inaczej