WordPress wielki na 12 GB. Ponad 600 wpisów i 2100 obrazków dodanych do mediów. 14 miniatur zdefiniowanych w kodzie. Czas przenoszenia strony z serwera na serwer to ponad godzina przy wykorzystaniu SSH. To było nie lada wyzwanie, aby zoptymalizować tę stronę.

Choć w zasadzie „optymalizacja” to w tym przypadku określenie nieco nad na wyrost. Trochę czasu i odpowiednie narzędzie dało jednak znakomity rezultat.

Rozpoznanie

Jak pewnie się domyślasz znakomity udział w tej stronie mają media. Katalog uploads ważył ponad 11 GB, więc stał się oczywistym miejscem do poszukiwania oszczędności.

Po sprawdzeniu mediów okazało się, że dodawane były na stronę zdjęcia prosto ze stocków. Mam na myśli to, że trafiały się perełki o wadze 30 MB i rozdzielczości większej niż 20 000 px.

Wybór narzędzia

Pierwsze co przychodzi mi do głowy w temacie kompresji grafik to imagemin. Niestety nie miałem możliwości zainstalowania Node na serwerze, więc do samego procesu optymalizacji musiałby dojść transfer wszystkich danych na mojego desktopa i z powrotem na serwer. Zrezygnowałem więc z tego pomysłu ze względu na potencjalną utratę danych oraz duży nakład pracy.

Drugim sposobem na poradzenie sobie z mediami to użycie którejś z wtyczek kompresujących obrazki. Jako że od dawna korzystałem z WP Smush, wykorzystałem tę wtyczkę też w tym przypadku. Konkretnie użyłem wersji PRO, ponieważ darmowa wersja nie obsługuje plików większych niż 1 MB. Niestety WPMU DEV od jakiegoś czasu nie sprzedaje wtyczek osobno, a udostępnia abonament, dzięki któremu dostaje się dostęp do wszystkich ich produktów w rozliczeniu miesięcznym. Koszt abonamentu to $49 miesięcznie, czyli prawie 200 zł.

Optymalizacja i wyniki

Wersja PRO wtyczki WP Smush oferuje bardzo przydatną funkcję, a mianowicie zmniejszenie obrazów do maksymalnej zdefiniowanej rozdzielczości. Wybrałem w tym przypadku rozdzielczość 4k, aby mieć pewność, że zdjęcia wyświetlające się w wielkich sliderach nie stracą na jakości.

Wtyczka posiada również opcję kompresji stratnej, która wyciska z grafik ostatnie poty. Nie użyłem jej jednak ponieważ proces trwałby dłużej i nie mogłem sobie pozwolić na widoczne straty na jakości.

Sam proces przetwarzania tych ponad 2100 mediów (mnożąc przez 14 miniatur dostajemy 29 400 obrazów) trwał około 16 godzin. Jednak warto było czekać.

Grafiki zostały zmniejszone o dokładnie 71%! Ilość miejsca, które zaoszczędziliśmy na serwerze to 8 GB. Nie mogę ukryć, że jestem bardzo zadowolony z wyników.

A Ty optymalizujesz media w swoim WordPressie? Jakich narzędzi do tego używasz?

Opublikowany przez Kuba Mikita

Miłośnik minimalizmu i prostoty, bo nie potrafi stworzyć niczego ładnego. Ma kołdrę, na której wypisane są funkcje WordPressa.

31 odpowiedzi na “Jak zmniejszyć użycie transferu i powierzchni na serwerze o 71% – case study”

  1. szczerze mówiąc nad tym siedze. nie mam tak rozudowanych mediów ale myśle , że problemy z prędkością strony nie doskwierają tylko dużym. Po testach na spedzie mam 100/100 dostosowanie na telefonach. 57/100 szybkość telefonach 75/100 szybkość komp. I o ile obrazy nie stanowią tutaj problemu to przewija mi sie serwer- krótki czas na odpowiedz(można podono to jakoś ustawić) i zbędny css i js

    1. Na hostingu współdzielonym nie da rady za bardzo zoptymalizować czasu odpowiedzi serwera. Jedyne co może pomóc w tym przypadku to zastosowanie cache, tak aby serwer nie przerabiał za każdym razem PHP tylko zwracał statyczny HTML.

      1. Miałem jedną wtyczkę, która miała mi to zoptymalizować ale strona mi poleciała (dokładnie sklep na woocommerce) i zrezygnowałem. Mam jeszcze inny pomysł co do serwera ale musze popróbować

      2. Mam z php trochę problem. Minifikując i cachując skrypty php skracam czas odpowiedzi, ale hosting wyrzucił mi przekroczenie dzienne zajętości procesora. Jest jakieś dobre wyjście z tego?

        1. To może być coś poważniejszego niż nieoptymalna strona czy słaby serwer. WordPress może być zarażony i dlatego produkuje takie obciążenie. Lub masz DDOS :)

          Zacząłbym od sprawdzenia logów serwera, które pliki za to odpowiadają. Jeśli nie masz do nich dostępów to możesz poprosić hostingodawcę, powinni coś takiego udostępnić.

  2. Od siebie dodam, że dużo miejsca zajmują niepotrzebne różne rozmiary wgranych zdjęć.
    Można zainstalować plugin
    https://wordpress.org/plugins/fly-dynamic-image-resizer/

    który to działa tak:
    Przy wgrywaniu zdjęcia jest tylko wgrany oryginalny rozmiar oraz miniatura i tyle.
    Dopiero przy pierwszym wywołaniu strony tworzy dodatkowy tylko aktualnie potrzebny rozmiar tylko dla wywołanego pliku.

    Trochę kalkulacji dla przykładu:
    Piszesz, że masz zdefiniowanych 14 dodatkowy rozmiarów + do tego miniatura + rozmiar średni + rozmiar duży no i oczywiście rozmiar oryginalny.
    Daje nam to 18 różnych plików dla 10 zdjęć mamy już ich 180
    Natomiast przy zastosowaniu styczki po wgraniu 10 mamy na serwerze 20 plików (oryginalne rozmiary + miniaturki) i dopiero potem są tworzone potrzebne rozmiary. Dajmy na to, że ustawimy ikonę wisu i jest ona wyświetla w 5 różnych rozmiarach. Da to nam 20 plików + 5

    dodatkowych rozmiarów tylko dla tego kliku + 25 plików zamiast 180.

    1. To bardzo ciekawa wtyczka! Dzięki za podzielenie się.

      Jako, że ta strona była pisana od podstaw i zoptymalizowana to potrzebowałem wszystkich 14 rozmiarów (taki motyw), kwestia czasu kiedy by się one wygenerowały przy użyciu tej wtyczki. Pytanie też ile czasu zajmuje wygenerowanie takiej miniatury w locie.

      A przez 14 rozmiarów miałem na myśli wszystkie rozmiary miniatur – i te wbudowane i te niestandardowe.

      1. Potrzebowałeś wszystkich 14 rozmiarów ale dla wszystkich wgranych plików czy

        tylko dla aktualnie ustawionej ikony wpisu?

        Bo to jak nie patrzeć jest spora różnica i zazwyczaj dodatkowe rozmiary są potrzebne tylko dla pliku ustawionego jako ikona wpisu.

        No chyba, że mamy jakąś galerię, ale w tedy i tak wygeneruje nam się tylko dodatkowe rozmiary potrzebne do galerii a nie np 5 dodatkowych rozmiarów miniaturek (dla każdego pliku) które i tak z dużym prawdopodobieństwem nigdy nie zostaną użyte.

        Z testów nie zaobserwowałem jakiś specjalnych opóźnień. Jest to nieodczuwalne dla użytkownika.

    2. Ale miniatury są generowane od nowa przy każdym wywołaniu, czy pierwsze wywołanie generuje miniaturę i ją zapisuje na serwerze. Wydaje mi się, iż realne jest tylko rozwiązanie nr 2, gdyż nr 1 raczej byłby nieakceptowalny jeśli chodzi o obciążenie komputera.

    3. Choć muszę przyznać, iż takie rozwiązanie ma pewną możliwość „oszczędności” miejsca. Jeśli zrobimy do tego jeszcze jakiś mechanizm, który by starsze niż 90 dni miniatury po prostu usuwał. Waga „archiwum” serwisu znacząco spadnie, a jak ktoś wejdzie na stary wpis, to dostanie świeżo generowane miniatury.

      1. Przy większym ruch takie rozwiązanie jest bez sensu. Bo tylko by te same miniatury co jakiś czas generowało od nowa a przy dużej ilości wisów to już kompletnie bez sensu.

    4. Do minusów można jeszcze dodać jeden punkt, brak panowania nad kadrowaniem. Bo końcu po co nam miniatury, które nie pokażą nam tego, o co nam chodzi. Choć pewnie dało by się to jakoś obejść wykorzystując jakieś tagi, które by określały sposób kadrowania. Tylko przydało by się, by WP jakoś „kodował” te tagi, w momencie kadrowania przez nasz miniatur.

  3. @kubamikita:disqus ja używam dwóch na raz: Tiny PNG oraz wspomnianej przez Ciebie WP Smush (obie w wersji darmowej). W duecie świetnie optymalizują obrazki. Ciekaw też jestem czy Fly Dynamic Image Resizer zaoszczędzi przyznany limit (500 zdjęć) w Tiny PNG :)

  4. Z innej gruchy – ostatnio miałem okazję tetsować wtyczkę Gonzales. Produkt Polski, komercyjny. Zadaniem jest wyłączanie niepotrzebnych plików CSS JS. O tym jakie pliki wyłączyć decydujemy sami. Po optymalizacji zdołałem wyciągnąć z 1.1MB => 0.9MB więc jest to spoko wynik jak na tak pół godziny klikania. Sprawdziłem również jak wygląda kontakt z developerem – odpowiedź po dniu czasu, także szału nie ma lecz rozwiązał problem którego nie potrafiłem sam przeskoczyć. Szkoda że tak plugin słabo wypromowany ponieważ stanowi alternatywę do oklepanej ścieżki przyspieszenia ładowania strony.

Możliwość komentowania została wyłączona.