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)

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

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