@mansfeld: Pisać o GZIP i nie wspomnieć o brotli to grzech.
"Technika ta może być wygodna w przypadku dynamicznych elementów, jednak w każdej innej sytuacji warto zastąpić styl in-line dołączając te parę linijek do pliku CSS, który jak pamiętamy może się zapisać w pamięci podręcznej i przyspieszyć wczytywanie się strony w przypadku ponownych wyświetleń."
No nie w każdej innej - np. dla krytycznych elementów taki inline'owy (albo w nagłówku) jest zdecydowanie
@zwierzak40: zdanie dotyczące lepszego ratio w GZIP ściągnąłem z dokumentacji Google, którą podlinkowałem w źródłach.
Co do in-line oczywiście, że tak. Jak klient ma w CMS możliwość dostrojenia np. backogrund-image to od razu in-line leci tak jest szybciej i prościej. Generowanie plików CSS tak jak to jest np. w niektórych wtyczkach WordPressa to typowy overengineering.
@mansfeld: usuwanie tekstu dla samego usunięcia to sztuka dla sztuki przy kompresji gzip. Według mnie najwięcej daje utrzymanie poprawnego drzewa DOM bo ono często muli przeglądarke.
usuwanie tekstu dla samego usunięcia to sztuka dla sztuki przy kompresji gzip. Według mnie najwięcej daje utrzymanie poprawnego drzewa DOM bo ono często muli przeglądarke.
@Wychwalany: Też tak uważam, chyba że możemy to osiągnąć łatwo, szybko i zapomnieć, to nawet jak korzyści są marginalne, to kosztem kilku kliknięć można to zrobić.
A co do DOM - pełna zgoda, szczególnie na wolniejszych urządzeniach rozbuchane drzewo DOM z skryptami latającymi po nim w
@Wychwalany: Ależ oczywiście. Wydajny DOM to podstawa. Im mniej elementów w ogóle i stopni zagnieżdżenia tym lepiej. ta minifikacja coś daje. Kiedyś zrobiłem kalkulację kosztów pominięcia minifikacji - ale faktycznie pominąłem GZIP - dla znanego portalu ;) i wyszła spora suma oszczędności.
@mansfeld: Dzięki. Chociaż moim zdaniem jedyna oszczędność w słowniku GZIP to będzie po prostu krótsza wartość o te dwa znaki. Aż mnie kusi, żeby zrobić testy, bo sposób w jaki to opisali jest niejasny.
@mansfeld: nie mają jakiegokolwiek sensu. Jeżeli formularz znajduje się na jednej podstronie „kontakt” fragment ten można spokojnie dodać ekskluzywnie na tej podstronie w postaci kodu in-line lub jako osobny plik css z dodatkowymi instrukcjami. Choć wydaje się to oczywiste, i łątwe do zastosowania, jest to jedna z najrzadziej przestrzeganych praktyk w tworzeniu front-endu.
Taka kompresja lekko obciąża serwer i przeglądarkę ale złożoność obliczeniowa pakowania i rozpakowywania jest na tyle mała, że opłaca się te operacje wykonać zaoszczędzając dużo cenniejszy transfer.
Wspomniałbym tutaj o poziomach kompresji. Niektóre CDNy stosują niższe poziomy kompresji, bo właśnie okazuje się, że koszt kompresji przewyższa tylko odrobinę większy poziom kompresji.
Jeszcze drobna uwaga do początku tego długiego posta: sam jestem zwolennikiem dzielenia CSSów na mniejsze porcje (Jak wspomniałem później), ale czasem to po prostu nie ma sensu, szczególnie jeśli chodzi o kilka linijek CSS. Bo potem dodamy gdzie indziej formularz i musimy reorganizować CSS, bo z CSS kontaktowego musimy jednak przenieść do globalnego albo załączać w dwóch miejscach. W skrajnych okolicznościach (różnych kombinacjach używanych modułów) tych CSSów wyszłoby kilkadziesiąt. Jak sam napisałeś
@zwierzak40: Dzięki za uwagi. Metodyki pisania CSS faktycznie warto byłoby wspomnieć. Co do wszelkich optymalizacji, oczywiście trzeba robić z głową aby, jak to się mówi, nie oszczędzać centów kosztem dolarów ;) czy jakoś tak to było... Osobiście jestem zwolennikiem CDN, tymbardziej jak plików jest dużo i mamy do czynienia z typowym serwisem z zdjeciami itd... Różnice TTFB i czasów pobierania mogą zaskakiwać: https://mansfeld.pl/webhosting/co-to-jest-cdn-czy-warto-wlaczyc/ Na końcu dałem fajne zrzuty.
@mansfeld: Też jestem zwolennikiem CDN, ale nie dla CSS i JS, a wyłącznie zdjęć i innych, niekrytycznych w pierwszej sekundzie rzeczach. Równie niski TTFB można uzyskać bez CDN bez oczekiwania na połączenie z nim, co szczególnie ważne jest na wolniejszych sieciach mobilnych (szczególnie tych z większym opóźnieniem, gdzie każdy dodatkowy przebieg przeglądarka <-> system DNS, przeglądarka <--(SSL)--> serwer szybko się sumuje). Widzę, że sam nie korzystasz z CDNa dla swoich CSSów
Mirki, jest jakieś picie najlepiej bez cukru albo w miarę mało, które da się pić i nie kosztuje fortuny? Ice tea zero bardzo dobre ale 6-7 zł za 1.5 litra to troche sporo
https://mansfeld.pl/webdesign/optymalizacja-kodu-html/
#html #html5 #seo #webdev #webdesign
"Technika ta może być wygodna w przypadku dynamicznych elementów, jednak w każdej innej sytuacji warto zastąpić styl in-line dołączając te parę linijek do pliku CSS, który jak pamiętamy może się zapisać w pamięci podręcznej i przyspieszyć wczytywanie się strony w przypadku ponownych wyświetleń."
No nie w każdej innej - np. dla krytycznych elementów taki inline'owy (albo w nagłówku) jest zdecydowanie
Co do in-line oczywiście, że tak. Jak klient ma w CMS możliwość dostrojenia np. backogrund-image to od razu in-line leci tak jest szybciej i prościej. Generowanie plików CSS tak jak to jest np. w niektórych wtyczkach WordPressa to typowy overengineering.
@mansfeld: Jestem chyba ślepy. Możesz mi wskazać fragment?
@Wychwalany: Też tak uważam, chyba że możemy to osiągnąć łatwo, szybko i zapomnieć, to nawet jak korzyści są marginalne, to kosztem kilku kliknięć można to zrobić.
A co do DOM - pełna zgoda, szczególnie na wolniejszych urządzeniach rozbuchane drzewo DOM z skryptami latającymi po nim w
Ma taki sens, że jeżeli mamy
Wspomniałbym tutaj o poziomach kompresji. Niektóre CDNy stosują niższe poziomy kompresji, bo właśnie okazuje się, że koszt kompresji przewyższa tylko odrobinę większy poziom kompresji.
Na końcu dałem fajne zrzuty.