Utworzono dnia: 4 grudnia, 2007 (wtorek). Śledź komentarze subskrybując kanał RSS 2.0. Dodaj komentarz lub skorzysaj z odnośnika trackback, który możesz wykorzystać w swoim serwisie.

jeszcze raz o optymalizacji

4 grudnia, 2007
Tagi: bzdury, lorelle.wordpress.com, optymalizacja, polskiblogger.pl, sobek.pl, wordpress

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 http://sobek.pl/wp-content/themes/bluegreen3/style.css 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.

Liczba komentarzy: 14

5 grudnia 2007 o godzinie 0:16 Łukasz Sobek skomentował:

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…

5 grudnia 2007 o godzinie 0:20 Gurthg Shae skomentował:

Wiedza to kasa. Dzielę się oszczędnie.

5 grudnia 2007 o godzinie 0:28 Łukasz Sobek skomentował:

Co do tego nie ma wątpliwości. Pozostaje metoda prób i błędów – jak w większości przypadków – ale i tak dziękuję :)

5 grudnia 2007 o godzinie 0:43 Gurthg Shae skomentował:

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.

5 grudnia 2007 o godzinie 11:16 tfiedoruk skomentował:

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%.

5 grudnia 2007 o godzinie 13:14 eRIZ skomentował:

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.

5 grudnia 2007 o godzinie 14:00 Gurthg Shae skomentował:

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ł.

5 grudnia 2007 o godzinie 15:34 Łukasz Sobek skomentował:

…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.

5 grudnia 2007 o godzinie 22:51 eRIZ skomentował:

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?

5 grudnia 2007 o godzinie 23:18 Gurthg Shae skomentował:

css na tej stronie ma:
Content-Length: 6702

5 grudnia 2007 o godzinie 23:26 Łukasz Sobek skomentował:

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.

5 grudnia 2007 o godzinie 23:33 Łukasz Sobek skomentował:

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.

6 grudnia 2007 o godzinie 0:40 eRIZ skomentował:

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.

7 grudnia 2007 o godzinie 3:12 sobek.pl – jÄ™zyk angielski i blogowanie » Projekt – odchudzenie bloga http://blog.fiedoruk.pl/ skomentował:

[...] odnoĹ›nie optymalizacji bloga i zmniejszania jego rozmiarów. Dodatkowa pomoc ze strony Gurthg Shae i eRIZ pozwoliĹ‚y, mam nadziejÄ™, ukierunkowaÄ‡ i wyklarowaÄ‡ punkt widzenia, którego [...]

Dodaj komentarz

należy wpełnić pola oznaczone znakiem gwiazdki "*".