dzek69 napisał(a)
samo ładowanie 70kb js-a przy portalu, który i tak ładuje 2MB contentu nie dużo zmieni
A jeśli masz całkiem złożoną i sporą stronkę na mniej niż 30 kilobajtów, jak pornel, to zmieni bardzo dużo :P.
Jeśli nawet masz witrynę domową Google z dość skomplikowanymi skryptami (teraz jest to dynamiczne ładowanie) i pewną ilością grafik (sprite'y CSS), to i tak Twoja strona zajmuje 134 KB i jQuery to kwestia 50% tego rozmiaru.
Użycie zewnętrznego CDN zwykle mocno polepsza wydajność i jest fajne, ale też nie zawsze. Jeśli tworzysz jakąś witrynę, gdzie konieczny jest bardzo wysoki poziom bezpieczeństwa, np. witrynę banku z internetowymi kontami, to możesz nie chcieć wprowadzać na swoją stronę hotlinka do kodu z zewnętrznej firmy (!). Poza tym, w tych CDN nie ma chyba SSL, które generalnie jest na bezpiecznych witrynach koniecznością, a z importowaniem zasobów nie-SSL do witryny z SSL wiążą się kolejne komplikacje.
Yahoo kiedyś napisali coś takiego na temat cache'u:
"40-60% of Yahoo!’s users have an empty cache experience and ~20% of all page views are done with an empty cache."
(http://yuiblog.com/blog/2007/01/04/performance-research-part-2/)
Czyli około połowy pierwszych wyświetleń witryny Yahoo następuje z "pustym cachem" (potem większości się to już cache'uje, więc w sumie jedynie 20% odsłon jest bez cache'a). Co to znaczy z "pustym cachem" -- nie wiem do końca. Pusty cache oznacza... pusty cache, czyli stan, w którym w pamięci podręcznej przeglądarki nie znajduje się NIC. Może jednak jest tu nieścisłość i chodzi jedynie o zasoby pochodzące z Yahoo. Z drugiej strony, może pewna liczba użytkowników ma po prostu wyłączony cache lub często go czyści.
massther napisał(a)
zgadam sie z dzek69 ze 26KB skrytp przy dzisiejszych laczach to pikus w porownaniu z niezoptymalizowana grafika, ktora dopiero masakruje stronke
Nie 26, tylko 76 KB przy braku GZIP-a, a dla ilu Twoich użytkowników GZIP jest niedostępny, to byś musiał już sam sobie przetestować.
Faktycznie, jeśli strona ma niezoptymalizowaną grafikę, to jak najbardziej może ona przeważać nad skryptami i pewnie często tak się dzieje. Oznacza to, że trzeba w pierwszej kolejności zoptymalizować grafikę. Wydajność w zasadzie zawsze należy zwiększać, zaczynając od wąskich gardeł.
Robiłem jakiś czas temu stosunkowo niewielką witrynę firmową. Miało tam być trochę skryptów, ale nic aż tak kosmicznego. Skrypty walidacyjne formularza, jakieś "accordiony", pomniejsze bajery i nawet canvas/filtr dla paru obrazków, bo grafik wymyślił, żeby obrazki w takiej jakby galerii były czarno białe i stawały się kolorowe dopiero po najechaniu myszą (transformacja do cz-b w JS jest już lepsza niż zrobienie tego po stronie serwera oraz ściąganie dwóch wersji obrazków...). I niby taka niepozorna stronka, niby obrazków całkiem sporo (ale udało mi się je dobrze zoptymalizować), a skrypt zajęły z tego 30-50% zależnie od podstrony, przy czym cała podstrona miała w granicach 200 KB.
Akurat tutaj użyłem jQuery (z pluginem do obsługi formularzy), bo koszt i czas produkcji witryny były bardziej krytycznymi zasobami niż przewidywana wydajność, która i tak wypadła obiektywnie OK, a na tle konkurencji tym bardziej (wyprzedzenie większości polskich webdeveloperów naprawdę nie jest specjalnie trudne...).
To ponownie ma podkreślić tezę, że wyboru należy dokonywać świadomie i nie zawsze należy rzucać się na jQuery. W tym topicu jQuery nie byłoby chyba AŻ TAK przydatne (z tego co widzę). Wystarczyłaby pewnie drobna ilość podstawowych, dostępnych w necie funkcji (addEventListener, hasClass itp.). Logikę trzeba i tak napisać, Ajaxu czy animacji nie ma tu w ogóle, a manipulacje DOM są tylko podstawowe. Nie bójmy się napisać jednej czy dwóch pętli for.