pomozcie zoptymalizowac kod strony...

[bufik]

Od jakiegos czasu zajmuję się stroną serwisu https://horror.com.pl - Horror Online - w tej chwili największego polskiego serwisu o sztuce grozy (film, książka itp) Serwis jest dość potężny mamy bazę ponad 700 recenzji książek i filmów całość działa na naszych skryptach i na bazie MYSQL. Na stronie znajduje się też dość potężne Forum dyskusyjne i kilka innych działów. Ale nie o tym miałem pisać.

Ponieważ wraz z rozwojem strony uczymy się wielu rzeczy nie wszystko wychodzi nam idealnie, ale chcemy aby witryna była jak najlepsza - dlatego min piszę z prośbą do Was. Nie mamy jednak problemu z pozycjonowaniem (PR=4) bez większych zabiegów i w wyszukiwarkach wśród polskich jesteśmy pierwsi.

Naszym problemem jest gigantyczny transfer generowany przez stronę. Przy dziennych odwiedzinach rzędu 1300 - 1500 osób transfer wynosi od 1,5 - 1,8 GB dziennie (35-55 GB miesięcznie!!!). Nasze konto w superhoście ma ograniczenie 20 GB i za każdy dodatkowy GB płacimy osobno. Ostatnio wyczytałem o stosowaniu komresji gzip do stron w php i wprowadziliśmy komresję na stronach z recenzjami (najchętniej oglądane) ale to nic nie dało...

Czy ktoś widzi może jeszcze możliwość zrobienia czegoś aby zminimalizować ten transfer?

Jak jeszcze zotymalizować kod (głównie stron z recenzjami) strony? Jakieś sugestie? Zastanawiam się nad przeniesieniem Forum na jakiś serwer sponsorowany w zamian za mozliwość umieszczenia na nim reklam Adsense, ale mam mieszane uczucia co do "darmowych" usług.

To jak - pomożecie?

[Dżyszla]

Jak na mój gust, to sporawo grafiki jest, która generuje ruch.

Kompresje gzip nic nie dadzą, bo przecież komuś nie wysyłasz skompresowanej strony, tylko normalną postać. To jest dobre do oszczędzania miejsca na dysku.

Co do kodu - trochę enterów by się zdało powywalać z kodu - z 5% się zaoszczędzi myślę.

Recenzje powiadasz... No to zaglądamy w źródła, i co widzimy - dziesiątki powtórzeń [span style=color:red]B[/span] Nie lepiej zdafiniować klasę dla [a] lub nawet zredefiniować styl samego odnośnika?

Dalej - od groma komentarzy - dobre do pisania strony, ale beznadziejne w publikacji w necie.

To samo z masą enterów - przypominam, że Enter to 2 (3?) bajty! (w zapisie 1-bajtowym znaków)

Końcówka strony - zaś masa powtórzeń [span style=font-family: @Arial Unicode MS; font-size: 8pt] - uwaga jak wcześniej.

No ale jakby nie patrzeć - to najwięcej żre grafika i to z nią przede wszysktim trzeba walczyć!

[pabel]

Tak jak powiedział Dżyszla - może nie tyle walczyć ;-) a pobawić się.

Zobacz - w recenzjach macie ok 10 screenów na film które mają średnio po 10 kb + kod + jeszcze grafa z boku to daje tak 100 - 200 kilo/recenzję.

1,5 GB bez problemu można nabić.

Ale jeśli - skompresujecie trochę bardziej grafikę (np. w photoshopie - quality 50) i zmniejszycie np. szerokość z średnio 250 pixeli do 200 - będzie trochę gorzej - ale średnio screen będzie miał 5 kB - czyli połowę tego co jest.

Wielkość strony spadnie gdzieś 30-50% i dzienny transfer też.

Acha - żeby nie przerabiać całej grafy - jeśli macie kogoś od zabawy z php i na serwerze bibliotekę gd do php - to można bardzo ładne zmniejszanie "w locie" zrobić.

[_ash_]

Kompresje gzip nic nie dadzą, bo przecież komuś nie wysyłasz skompresowanej strony, tylko normalną postać. To jest dobre do oszczędzania miejsca na dysku.

Wlasnie o to chodzi, ze strona jest wysylana w postaci skompresowanej (chodzi tutaj oczywiscie o sam kod html, a nie grafike itp.). Na tekscie mozna zaoszczedzic srednio nawet ponad 50% (mozesz sprawdzic tutaj). Ja bym polecal wlaczenie kompresji dla calego serwisu, najprosciej w pliku .htaccess:

php_flag zlib.output_compression On 

php_value zlib.output_compression_level 5 

[nrm]

Kompresje gzip nic nie dadzą, bo przecież komuś nie wysyłasz skompresowanej strony, tylko normalną postać. To jest dobre do oszczędzania miejsca na dysku.

a co to za bzdura???

bufik jesteś pewien, że gzip działa? Nie ma mozliwości, żeby to nic nie dało bo gzip daje w zalezności od strony bardzo dobre rezultaty. W przypadku for można przyciąć transfer nawet o 60-70%!!!!!

W twoim przypadku masz sporo grafiki - tego nie przeskoczysz, ale z 30% powinienes uzyskać na samym htmlu.

[Dżyszla]

No możliwe, że się mylę, ale w takim razie - przeglądarka niby mi dekompresuje zawartość? Może mi ktoś opisać mechanizm? I na czym dokładnie polega ta kompresja... Które przeglądarki niby to obsługują. PRzyznaję się, że stykam się pierwszy raz z czymś takim...

Ale na marginesie - statystyki dla moję strony głównej:

skompresowane: 23802 bajtów

nieskompresowane: 23914 bajtów

zysk: 0.47 %

I dla największej s pod stron serwisu (statystyk):

skompresowane: 70215 bajtów

nieskompresowane: 70398 bajtów

zysk: 0.26 %

Więc chyba kompresowanie jest tutaj śmiesznym...

[_ash_]

przeglądarka niby mi dekompresuje zawartość? Może mi ktoś opisać mechanizm? I na czym dokładnie polega ta kompresja...

Jesli Twoja przegladarka obsluguje kompresje, wysyla w naglowku HTTP informacje o tym i jesli serwer tez obsluguje kompresje wysyla zawartosc strony skompresowana w formacie gzip. Przegladarka przed wyswietleniem dekompresuje. Zysk na transferze, ale wymaga dodatkowej mocy serwera.

Które przeglądarki niby to obsługują.

Obecnie niemal wszystkie.

Więc chyba kompresowanie jest tutaj śmiesznym...

A czy Twoj serwer ma wlaczona kompresje? Sama przegladarka, ktora to umie to nie wszystko

[nrm]

Może mi ktoś opisać mechanizm?

google.pl -> mod_gzip

zobacz sobie np. źródło strony wp.pl i jej pierwsze linijki...

Ale na marginesie - statystyki dla moję strony głównej:

skompresowane: 23802 bajtów

nieskompresowane: 23914 bajtów

zysk: 0.47 %

I dla największej s pod stron serwisu (statystyk):

skompresowane: 70215 bajtów

nieskompresowane: 70398 bajtów

zysk: 0.26 %

Więc chyba kompresowanie jest tutaj śmiesznym...

to jakies mało wiarygodne dane... abstrajhując od wszelkich statystyk każdy gimnazjalista powinien wiedzieć, że HTML (czyli w ogóle plain text) jest bardzo dobrze 'pakowalny'. popakuj sobie zipem na localhoscie troche stron to zobaczysz

[Dżyszla]

No dokładnie. PRzecież kompresja ZIP (głównie oparta o LZ78) jest wyśmienita do kompresji tekstu tym bardziej HTML (w końcu sam kompresor pisałem )

Serwer - no chyba obsługje, skoro różnice są.

Aha - czyli wniosek, że jeśli przeglądarka nie obsługuje, to serwer wyśle jej stronę bez kompresji?

No to się w gruncie rzeczy czegoś nowego nauczyłem. Tylko te wyniki... Hmm... :roll:

[_ash_]

Serwer - no chyba obsługje, skoro różnice są.

Takie minimalne roznice moga wynikac np. z wielkosci naglowka, dynamicznej zawartosci strony itp.

[Dżyszla]

No tak, puściłem posta na Forum mojego hostingowca i post zniknął po 60 sekundach z upomnieniem, aby nie stosować tego! ROTFL

[breja]

ja wszedzie uzywam kompresji

Serwer www.wardriving.pl, scieżka: /

skompresowane:	8145 bajtów	

nieskompresowane:	25767 bajtów	

zysk:	68.39 %

[bufik]

Dziękuję wszystkim za pomoc - będę działał - jak pisałem w pierwszym poście dopiero sie uczę tego wszytskiego zatem chętnie korzystam z wiedzy bardziej doświadczonych.

Mam nadzieję, że uda mi się coś z tym zrobić bo inaczej pójdziemy z torbami, a szkoda byłoby takiej ilości materiału.

Na razie pokombinuję z grafiką i z kompresją - nie wiem co się dzieje kody kompresji gzip dopisalem do plików php które otwieraja recenzje - niestety nie zauważyłem żadnego spadku transferu - choc wspomniaja strona sugeruje że oszczędność wyniosłaby nawet 68%...

Muszę wgryźć się w temat .htaccess

Dzięki raz jeszcze i pozdrawiam.

[michal]

Muszę wgryźć się w temat .htaccess

Raczej tak, bo mozesz na tym duzo zyskac.

Dla przykladu

Serwer forum.optymalizacja.com, scieżka: /

skompresowane:	8522 bajtów

nieskompresowane:	75031 bajtów

zysk:	88.64 %

8)

[lutek]

No tak, puściłem posta na Forum mojego hostingowca i post zniknął po 60 sekundach z upomnieniem, aby nie stosować tego!    ROTFL

Co to więc za "hostingowiec" co ma fora dyskusyjne i na dodatek usuwa posty, aby ludzie nie robili źle serwerowi? Pewnie jakiś z The Planet...