piątek, 30 września 2016

Mein Kampf... z Google PageSpeed Tools Insights

Tytuł wpisu oczywiście żartobliwy ale nieco gorzko. Moja walka z tym narzędziem również, muszę przyznać, zakończyła się może nie klęską ale nie takim sukcesem jakiego oczekiwałem. Oczywiście oczekiwałem wyniku 100/100/100. - Tak, wiem, to przerost ambicji i próżny trud jak wielu mi mówiło i pisało. I faktycznie. O ile osiągnięcie takiego wyniku dla prostej strony, korzystającej wyłącznie z własnych skryptów wewnętrznych jest mniej lub bardziej trudne ale na pewno osiągalne o tyle dla złożonego serwisu www, korzystającego z API takich serwisów jak Twitter, Google, Facebook, jest walką z wiatrakami.

Porzuć ambicję chłopcze i zaakceptuj otaczającą cię rzeczywistość. - Niestety taka smutna prawda. Trudno obejść przykładowo ustawić daty wygaśnięcia lub maksymalnego wieku w statycznych zasobach HTTP dla plików API z zewnętrznych serwisów. Jest to często wykonalne i tak przykładowo dla Google Analytics można to zrobić kawałkiem kodu PHP (dla zainteresowanych Ładowanie GA z własnego serwera). Gorzej gdy taki zasób wewnątrz odwołuje się do serwera zewnętrznego. Można pomyśleć, że na zdrowy rozum można i taki zasób dołączyć podobnym sposobem. Nic bardziej mylnego. Często przesyłane są zmienne, które mogą być tylko analizowane na zewnętrznym serwerze. Nie twierdzę, że nie jest to wykonalne ale na pewno czasochłonne i obarczone dużym prawdopodobieństwem, że coś może pójść nie tak. Taką walkę przeprowadziłem z API Google+. Nie mniej nawalczyłem się z API Facebooka i Twittera.

Kolejny problem to tak złożone własne skrypty js i css, że nawet maksymalnie zoptymalizowane i skompresowane budzą niechęć GPSI i zostaniemy uradowani komunikatem, że powinniśmy zoptymalizować i skompresować swój zasób. Niestety, skompresowaliśmy już wszystko maksymalnie a nie mamy możliwości większej kompresji powiedzmy do gęstości gwiazdy neutronowej. I znów sugestia której nie jesteśmy w stanie podołać.

Inną radosną sugestią jest abyśmy wyeliminowali blokujący renderowanie kod JavaScript i CSS z części strony widocznej na ekranie. Mamy dwa wyjścia – wywalić kod, co oczywiście raczej nikomu rozsądnemu nie przyjdzie do głowy (chyba, że to faktycznie zbędny kod) albo idąc za radą Google przenieść kod za znacznik HTML. Tyle, że jeśli mamy bardziej złożoną stronę, zwłaszcza gdy skrypt js analizuje i reaguje na formatowanie zawarte w pliku css, to użytkownik na ekranie może zobaczyć naszą stronę w dość niekorzystnym stanie mówiąc delikatnie.

Reasumując mogę napisać i uderzyć się w pierś. Osiągnięcie 100/100/100 nie zawsze jest opłacalne. Oczywiście wyniosłem z tego jakąś korzyść. Przewaliłem kawał internetu i przy okazji przyswoiłem sporo innym przydatnych wiadomości. No i mogłem zrobić dla Was ten wpis na bloga:) Ku przestrodze, ku pokrzepieniu serc:)

Na koniec chciałbym tylko jeszcze napisać, że jeden wynik warto mieć 100. Chodzi mi o wygodę użytkownika na urządzeniach mobilnych. W tym miejscu nie jesteśmy ograniczeni niczym w zasadzie a wszystko zależy od odpowiedniego rozplanowania elementów strony. O ten wynik sądzę warto zadbać. Oczywiście pozostałe wyniki należy starać się za wszelką cenę utrzymać w zielonym polu.



Sławomir Własik
Netteria.NET - programowanie, tworzenie stron, usługi programistyczne

Brak komentarzy:

Prześlij komentarz