Kategorie
WordPress

jeszcze raz o optymalizacji

Zgodnie z zapowiedzią jest odpowiedź: 6x TAK! Co zyskasz na odchudzeniu bloga?

Zacznę łagodnie, bo sobek{kropka}pl napisał przynajmniej z sensem, choć szukał oszczędności nie tam gdzie trzeba. Przynajmniej moim zdaniem.

Autor donosi, ze udało mu się odchudzić bloga o 6kB! Super. Wezmę na warsztat logo oraz arkusz stylów, które to pliki są ładowane dla unikatowego użytkownika co najmniej raz. Mam nadzieję, że Autor się nie pogniewa na użycie.

Oryginalny plik: gif, 64 kolory, paleta własna, wielkość: 5,95 kB (6039)

sobekpllogo.gif

Plik zmodyfikowany: png, 16 kolorów, paleta własna, wielkość: 2.36kB (2419)

sobekpllogo.png

Różnią się aż tak bardzo, żeby nie użyć drugiego?

Zmiana wielkości pobieranej: 3.59 kB, czyli modyfikując JEDEN plik, co zajęło mi dokładnie 52 sekundy uzyskałem wynik zbliżony do optymalizacji autora. Ile łącznie można zaoszczędzić? Nie wiem.

Oryginalny plik to 5.68 kB (5824), ten sam plik po wycięciu zbędnych znaków to 4.67 kB (4790) co daje „oszczędność” 1.01 kB. Czas optymalizacji 130s.

Sumarycznie: modyfikując dwa pliki „zyskałem” 4.6 kB. Dobrze?

Oszczędności tak, ale gdzie?

Wrócę jeszcze do tekstu Jak przyspieszyć WordPress 3 razy? ze względu na ciekawe komentarze dotyczące liczby zapytań. Przyznam, że wcale mi się nie chciało, ale sobek.pl skutecznie pomachał mi płachtą optymalizacji przed pyskiem. Chwała Mu! Dobra wracając. Sprawdziłem czy teza postawiona w akapicie

1. Zapytania do bazy

jest prawdziwa. Nie jest.

Dlaczego nie jest?

Za „zwracanie” opcji odpowiedzialna w wordpressie jest funkcja get_option leżąca w w pliku ./wp-includes/functions.php, która prawie na samym początku wywołuje: $alloptions = wp_load_alloptions();, która to funkcja w jednym zapytaniu ładuje WSZYSTKIE opcje które mają ustawione pole autoload na wartość „yes”. Zapytanie: SELECT option_name, option_value FROM $wpdb->options WHERE autoload = 'yes'. Sprawdźmy rekomendowane przez autora jako „zaliczane” do wymiany za pomocą zapytania SELECT option_name, autoload
FROM wp_options
WHERE option_name IN (
'blogname',
'blogdescription',
'stylesheet',
'template',
'siteurl'
);

„Niezgodność” nazw powyższych z przykładem Polskiego Bloggera wynika z tego, że tak własnie te nazwy są przekształcane i w zapytaniu są takie, jakimi widzi je silnik wewnętrznie. Nie ma tu żadnego przekłamania. To prawdziwe nazwy.

Wynik!

+-----------------+----------+
| option_name     | autoload |
+-----------------+----------+
| blogdescription | yes      |
| blogname        | yes      |
| siteurl         | yes      |
| stylesheet      | yes      |
| template        | yes      |
+-----------------+----------+

Oznacza, to że zastępowania tych konkretnych miejsc przez statyczny html daje tyle co … nic! Co słusznie zauważył:eRIZ:

Rozprawmy się z drugą częścią, czyli:

<h3><?php _e(’Archives:’); ?></h3>
<h3><?php _e(’Meta:’); ?></h3>
<h3><?php _e(’nazwa menu:’); ?></h3>

OMG! Napisanie, że można to zastąpić przez statyczny HTML i to co da jest nie tylko bezużyteczne, jest wręcz bzdurą! Dlaczego?

Funkcja „_” oraz „_e” są funkcjami odpowiednio: zwracająca oraz wypisująca wyrażenie słownikowe ze skompilowanego pliku typu POT[1], [2] więc to czy będziemy używać zwyłego podstawienia z tego pliku czy tez nie jest bez najmniejszego znaczenia.

Wychodzi na to, że Blogger opierając się od The 3 Easiest Ways to Speed Up WordPress po prostu powielił bzdurę, którą napisał autor pierwotnego dokumentu. A potem ludzie się dziwią, że tyle już optymalizowali i nic to nie pomogło.

Oczywiście zastępowanie rzeczy dynamicznie generowanych przez statyczny html daje możliwość optymalizacji, ale na pewno nie w tym miejscu.

  1. gettext – GNU Project – Free Software Foundation (FSF)
  2. wiki: gettext

13 odpowiedzi na “jeszcze raz o optymalizacji”

Kurcze, przyjemnie się czyta, aż się zapisałem do RSSa ;)

Nie gniewam się, bo nie ma za co. Dziękuję za plik logo. Co do CSS to o ile narzędzie uważam za genialne, o tyle uważam, że troche zbyt dużo zachodu przy modyfikacji.

Co do 6kb zyskanych: przed dodaniem kilku rzeczy i po odchudzaniu rozmiar bloga wynosił 120kB, więc różnica jest nieco większa :)

PS. no ładnie, mówi „że oszczędność nie tam gdzie trzeba”, a wiedzą się nie dzieli. :) Jak tylko się wyśpię może sam wpadnę na kompresje itp. ale na razie ze względu na przemęczenie umysłu to niemożliwe…

oj… można usunąć:

1. zbędne class’y i id’i
2. nadmiarowych i niewykorzystywane tagi html
3. nadmiarowe deklaracje css (polecam plugin Dust-Me Selectors)
4. zbędne znaki białe z szablonów (na stronie głównej sobek.pl dało to 600 bajtów).

Lub właczyć mod_gzip, a powyższe punkty wywalić do śmieci.

HA, wiedziałem że to lipa ;) Również analizowałem zapytania i wyszło mi, że są takie same w ilości.

Co do .css to można łatwo skompresować kosztem czytelności o 25-30%.

1. zbędne class’y i id’i

Spróbuj zrobić dobry design, który będzie dobrze wyglądać pod wszystkimi przeglądarkami bez nadmiaru klas i bez hacków (mam tu na myśli IE6, który nawet zwykłego nazwa > nazwa nie rozkmini).

nadmiarowych i niewykorzystywane tagi html

jw. element:before, element:after… :/

3. nadmiarowe deklaracje css (polecam plugin Dust-Me Selectors)

Wciąż się powtarza kwestia IE6… :/

Owszem, jest IE7lib, ale po co do muchy strzelać z armaty…?

4. zbędne znaki białe z szablonów (na stronie głównej sobek.pl dało to 600 bajtów).

Owszem, ale popatrzmy, czy to jest naprawdę warte zachodu? 0.6KiB, to jest obecnie niezauważalna różnica – a sobie tylko utrudnimy życie (np. poprawki przy wdrażaniu/w późniejszym czasie).

mod_gzip chyba jest jednak najrozsądniejszym wyjściem…

…i ustawienie kompresji dla .css, .js, etc + nagłówki expires na jakiś długi czas.

Spróbuj zrobić dobry design, który będzie dobrze wyglądać pod wszystkimi przeglądarkami[…]

Zawsze tak robię, pseudoklas „after/before” – nie używam poza @media print, żeby wyświetlić zawartość href’a. Podeślę linka do ładnego designu, który jest aktualnie w fazie produkcji i wygląda wszędzie dobrze.

Co do znaków białych w szablonach, to raczej jakiś plugin, bo założenie paru regexpów to trywiał.

…mod_gzip chyba jest jednak najrozsądniejszym wyjściem…

…i ustawienie kompresji dla .css,…

CSSa wrzucić do pliku html i już kompresja mod_gzip jest :)

Spróbuj zrobić dobry design, który będzie dobrze wyglądać pod wszystkimi przeglądarkami bez nadmiaru klas i bez hacków

Jeśli CSS jest większy niż 8kB, to i tak znaczy, że da się sporo wyciąć i połączyć.

PS. Kurcze, nie mogę się pozbyć jquery ze strony głównej.

CSSa wrzucić do pliku html i już kompresja mod_gzip jest :)

I po co parę razy ściągać to samo? :P

Jeśli CSS jest większy niż 8kB, to i tak znaczy, że da się sporo wyciąć i połączyć.

Owszem, jeśli jest to sama strona główna albo jeden lay na csszengarden. :P

Z obserwacji, to CSS obejmujący cały serwis raczej trudno zmieścić w objętości 8KiB:

blog Riddle’a: ~26KiB
wykop.pl: 46KiB

Więc dlaczego wg Ciebie, Łukaszu, CSS większy niż 8KiB jest zbyt wielkim?

I po co parę razy ściągać to samo? :P

O masz, o tym nie pomyślałem w swoim pędzie do odchudzenia bloga.

Z drugiej patrząc na skompresowany plik HTML+CSS w porównaniu do komp.HTML+niekomp.CSS różnica jest ok 4kB (przy pliku CSS objętości 6kB) podczas, gdy sam plik komp.HTML jest tylko 2kb mniejszy (od komp.HTML+komp.CSS). Myśle, że temat musi jeszcze trochę dojrzeć w łepetynie, choć obecnie ta zmiana plasuje się w moim mysleniu w kategoriach ‚kwestia gustu’.

Owszem, jeśli jest to sama strona główna albo jeden lay na csszengarden. :P

Fakt :)

Więc dlaczego wg Ciebie, Łukaszu, CSS większy niż 8KiB jest zbyt wielkim?

Ze względu na to, że nie widzę zastosowania takiego pliku, co jest zapewne spowodowane tym, że nigdy nie projektowałem dużego serwisu :P

36kB wydaje się ogromnym plikiem.

Content-Length: 6702

Własnie do tego nawiązywałem, strona jest BARDZO mała (50276 bajty) ale ze wzgledu na ilość elementów (18) ładuje się wolniej niż moja (85721 bajtów – 14 elementów), co uważam za bardzo ciekawe zjawisko pod względem wpływu ilości elementów na czas ładowania strony.

Z drugiej patrząc na skompresowany plik HTML+CSS w porównaniu do komp.HTML+niekomp.CSS różnica jest ok 4kB (przy pliku CSS objętości 6kB) podczas, gdy sam plik komp.HTML jest tylko 2kb mniejszy (od komp.HTML+komp.CSS). Myśle, że temat musi jeszcze trochę dojrzeć w łepetynie, choć obecnie ta zmiana plasuje się w moim mysleniu w kategoriach ‘kwestia gustu’.

Ale potem odejmujesz, bo CSS pobierany jest tylko raz. ;]
/no chyba, że pokopałbyś nagłówki expire ;P/

36kB wydaje się ogromnym plikiem.

Uwierz, że nie… IMHO, to teraz standard.

Możliwość komentowania jest wyłączona.