Oszczędność za wszelką cenę - optymalizacja CSS
Internet wymaga od nas - programistów - coraz więcej. Aplikacje internetowe rosą w potęgę, łącza internetowe zwiększają swoje przepustowości, a komputery użytkowników mają ciągle większą moc. Owszem. Jednak statystycznie rzecz biorąc, to wszystko nie ma znaczenia. Biorąc pod uwagę że istnieje ogromna część społeczeństwa, która dopiero co posiadła komputer i internet jest dla niej nowy lub komputer posiada od dawna, lecz ani się jej śni zmieniać na nowy ( bo przecież działa (sic!) ), lub ze względu na zamieszkanie w obszarze słabo zurbanizowanym, przepustowość łącza bije rekordy wolności - należy się zastanowić czy wszyscy ci użytkownicy mają być pominięci?. Właśnie z myślą nich, architekci i programiści wielkich nowoczesnych aplikacji internetowych nie powinni zapominać o podstawowych zasadach optymalizacji i stron, jako HTML, i silników tych aplikacji. -by wszystkim żyło się lepiej 
Zapraszam do lektury nowego artykułu: Mastering Zend Framework - HeadLink, który w imię optymalizacji wszystkiego co się da, przedstawia propozycję zarządzania stylami CSS w aplikacji napisanej w oparciu o silnik Zend Framework.
Stety, niestety, takie dzisiaj są trendy - łatwiej jest dokupić nowy serwer lub kazać dokupić coś użytkownikowi, bo dzięki temu programista mógł swoją robotę zrobić w 3 zamiast 4 miesięcy i pieniądze zaoszczędziliśmy na nim. Oczywiście są też plusy - bardziej zaawansowane systemy już na etapie tworzenia wychwycą większość błędów. W przypadku stron internetowych strasznie nie lubię przypakowanych serwisów, które podczas każdego żądania potrafią pobrać nawet 0,5 MB danych! W domu na łączu 10 Mbit to hula znośnie, ale wystarczy, że na uczelni jestem w miejscu z gorszym zasięgiem i mnie mało szlag nie trafia, gdy widzę: “Pobrano 347 KB, transfer 7 KB/s”… dobrze, że są jeszcze ludzie, którzy o takich sytuacjach pamiętają.
Komentarz od Zyx — 06/11/2008 @ 20:36
Zyx. Lekka “rozrzutność” po stronie serwerowej w celu zaoszczędzenia roboczogodzin, a zwiększanie wymagań systemowych wobec klienta to dwie różne sprawy!
Komentarz od X — 16/11/2008 @ 15:57
Jeśli mamy duży serwis to nie lepiej po porostu skonfigurować go tak żeby sam kompresował pliki css i js? Szybkiej, łatwiej i bez zmian w kodzie.
Komentarz od luinnar — 17/11/2008 @ 00:14
@luinnar - a powiedz proszę co masz na mysli, mówiąc o tej konfiguracji. Jaki sposób na to znasz?
Komentarz od Kubek Bartosz — 17/11/2008 @ 09:24
Artykuł do którego się odnosisz nie wnosi nic nowego do “świata www” (IMO). Używam “czegoś podobnego” od wielu miesięcy - tylko na “dev” używam plików źródłowych (+nagłówki no-cache), a na docelowym wszystko łączę, kompresuję i nazywam odpowiednią wersją (zwiększaną również w configu) [akcja jednorazowa] - to samo dla JSów. Jeśli zaś chodzi o kompresję “w locie”, to bez problemu można to zrobić w apachu odpowiednią dyrektywą.
Komentarz od Marcin Kłeczek — 19/11/2008 @ 19:51
@Kubek Bartosz: google mym pasterzem nie brak mi niczego
http://nadeausoftware.com/articles/2007/03/speed_web_site_enabling_apache_file_compression
http://askapache.info/2.0/mod/mod_deflate.html
http://sourceforge.net/projects/mod-gzip/
Komentarz od luinnar — 21/12/2008 @ 01:11