"Kompresja" skórek w runtime

mam taki pomysł: można w łatwy sposób zmniejszyć o kilkanaście procent ilość wysyłanych przez 4p do klienta danych, poprzez usunięcie zbędnych spacji i enterów z kodu. na wygląd strony nie ma to najmniejszego wpływu, natomiast ma wpływ na jej szybkość ściągania, zwłaszcza kiedy się siedzi na łączu GPRS :] ponadto ostatnio dmk jest cokolwiek zapchane, a przez to powolne.

mam u siebie gotową wersję, kto chce miech sobie zerknie (o ile kompa mam włączonego): http://fronczyk.no-ip.com/4p/coyote/ . Można się logować tak jak na 4p i zmieniać skórki. na submain ,,kompresja" jest największa - średnio 15%, na black i simple najniższa, około 7%, motion ~ 10%. myślę, że jest o co powalczyć.
informacja o stopniu kompresji znajduje się w stopce strony.

ktoś jest przeciw?

Ja jestem za - jednak zalecam autorom skórek wycinanie zawsze końcowych spacji z plików .tpl

Niektórzy zostawiają ich tam po kilkanaście/dziesiąt :| po grzyba...

Pomysł godny realizacji - z tym, że kompresja taka - kiedy miała by miejsce? .. rozumiem, że przed każdym wysłaniem skórki na FTP 4programmers - nie zaś w wersji na CVS .. wtedy utrudniło by to nieco poprawki w przyszłości.

Deti napisał(a)

kompresja taka - kiedy miała by miejsce? .. rozumiem, że przed każdym wysłaniem skórki na FTP 4programmers - nie zaś w wersji na CVS

runtime - przy wysyłaniu kodu html do klienta.

Co do kompresji designtime to proponowałem to swego czasu.

Zastanawia mnie jedna rzecz: jak zmienia się czas generowania strony (a więc i obciążenie serwera) przy zastosowaniu tej kompresji?

Taka myśl - nie wiem jak zgodność tego ze standardami - wszystkie obrazki, linki używają pełnych, a nie relatywnych URLi, patrząc w wynikowy kod html to jest jednak troche

czas generowania strony - bez zmian - to jest jedno preg_replace
a co do zrobienia linków bezwzglednych - OMG - to jest dopiero coś - ponad 10%, czyli w sumie można pakować strony nawet do 40% :-) tylko pojawia się problem z inteligentnym usuwaniem linków, bo albo działają linki na stronie głównej, albo na forum. ale nie na obu naraz.

Nie ma jakiegoś ładnego tagu meta do tego?

Qyon napisał(a)

Nie ma jakiegoś ładnego tagu meta do tego?
jest <base> ale chyba tylko do HTML 4.0 ?

myśle, że to idzie zrobić przez $root_dir, ale nie będę na razie tego wprowadzać w życie. skoro nie ma większych sprzeciwów, to wrzucam zmienione template.php na cvs.

http://validator.w3.org/check?uri=http%3A%2F%2Fqyon.satanbsd.org%2Fbin%2Ftst.htm&charset=%28detect+automatically%29&doctype=Inline&verbose=1

// ? - Ł

// ? - Ł

chyba to było do M że wstawił sobie znacznik base i zwaliło mu jako poprawną stronę ;P

Julek napisał(a)

chyba to było do M że wstawił sobie znacznik base i zwaliło mu jako poprawną stronę ;P

kumam.

dorzuciłem kompresję linków, i średnio jest 25%, momentami nawet 35%. czas parsowania dalej minimalny; ponadto do coyote_config dodałem dwa rekordy umożliwiające selektywne wyłączenie prasowania strony.
całość do zobaczenia pod podanym wcześniej adresem o ile mój komp jest włączony.

to moze podam jeszcze jakis pomysl:
kod <font color="brown" size="12"> mozna zamienic na <font color="brown"size="12">
troche tych odstepow w kodzie jest:)

To skracanie linków jest delikatnie mówiąc problematyczne - przewidziałeś, że forum może być na subdomenie?

// tak - zresztą popatrz na moją kopię kojota (co prawda forum nie jest w subdomenie, ale subdomenę przewidziałem) - tam już działa skracanie linków, tylko gdzieś jest mały bug, którego jeszcze nie namierzyłem - gdzieś w którymś miejscu jakiś link jest nie tak; ale jeszcze go namierzę, drania - Ł

Chwilowo wyłączyłem kompresję bo... ŁF nie przewidział tego, że przy edycji postów w poście też nie ma ani jednego entera i więcej jak 2 spacji! :)

Bezapelacyjnie do poprawy!

Marooned napisał(a)

przy edycji postów w poście też nie ma ani jednego entera i więcej jak 2 spacji! :)

poprawione, przy okazji wreszcie znaczniki

 się normalnie zachowują</p>

[dopisane]
kurde, a teraz wsiąkają \ przy edycji postu. ja się zaraz zastrzelę. o jedno stripslashes za daleko :/

Po tej całej kompresji moja stopka się .... zepsuła :D a dodać BR nie moge, bo przekroczyłem 255 znaków ;/ chyba już usunęliście to n2br?

A nie lepiej zamiast tego kombinowania uzyc gzip? Praktycznie wszystkie przegladarki to obsluguja. Albo stworzyc jakas minimalistyczna skorke - zero grafiki, zadnych wyjechanych stylow, tylko div, jakies td w cssie i to wszystko . Zwlaszcza, ze czasami bralem przyklad z htmla generowanego przez kojota a teraz ...

No nieco z tym problemów... :/

Marooned napisał(a)

No nieco z tym problemów... :/

no, chyba jednak będzie trzeba usunąć kompresję spacji i enterów, bo powoduje to sporo problemów; za to można zaeksperymentować z linkami względnymi, bo to też nieźle prasuje stronę, a jak na razie nie sprawia żadnych problemów (ale cóż, spacje też nie sprawiały ;]). w razie czego też będzie można usunąć...

Czy istnieje jakaś racjonalna przesłanka aby nie potraktowac .tpli jakimś html packerem przed wrzuceniem ich na ftp?

Cokolwiek to jest html paker - tplki powinny mieć wcięcia i być ładnie sformatowane - nie utrudniajmy sobie zarządzania i poprawiania skórek!

Natomiast nie róbmy czegoś takiego, jak Ty Qyon ostatnio zrobiłeś przy PM - zostawiałeś nawet po kilkadziesiąt spacji na końcach linijek - każdy plik przed wysłaniem na cvs/ftp należy potraktować funkcją obcinającą spacje z końców linijek.

Hmm mea culpa - musze zmienić edytor.
Nie rozumiem natomiast arg. o wcięciach - czy aż tak często trzeba dokonywać zmian w plikach na ftp? Czy też nie zrozumiałeś o co mnie chodzi?

Myślałem, że chcesz 'pakować' .tpl i takie masakry wrzucać na cvs.

Ale jesli chodzi Ci o zmianę przed wrzuceniem na ftp, ale na cvs będą z wcięciami to tymbardziej NIE -> potem żadna synchronizacja katalogu na dysku ze zmianami z ftp nie działa.

Nie wrzucasz plików na ftp więc będzie Ci to wisieć. Ja mówię kategoryczne NIE!

// Mówi się trudno - będzie 10-20% większy transfer - Q

//nie! ale nie będzie o 10-20% mniejszego transferu :> - M
//i nie odpowiadaj dopiskami, bo nie widać, że coś zostało dopisane...

Pozwoliłem sobie wyłączyć tę funkcję poprzez zmienną w bazie - zjadało wszystkie entery w stopce przy edycji.. ogólnie więcej problemów z tym było niż mogło się wydawać.

Moja propozycja, to usunięcie zmian z CVS [poprzez skasowanie ostatnich rewizji plików a nie wprowadzeniu nowych - wiadomo o co cho] do czasu przemyślenia i napisania metody nie stwarzającej problemów.

Od takich testów niechaj będzie kojot na orange.

Cóż - zamysł był dobry :)
We are only human

Nie wiem czy to przejdzie (ze względu na obciążenie serwera), ale może dałoby się tą kompresję skórek (tpli) wprowadzić "dynamicznie", podczas wywoływania skryptu php? Myślę, że wtedy pozbylibyśmy się problemu związanego z niezgodną wersją na CVS i na FTP, a jednocześnie zaoszczędzili trochę na transferze.

// a przeczytałeś z tego wątku coś więcej niż ostatnie dwa posty? przecież była mowa o kompresji RUNTIME! - Ł

// [glowa] - M

ha! mam nowy, lepszy pomysł :-) po co się męczyć z danymi z bazy danych - są z nimi ciągłe problemy. wytnę spacje przed kompilacją kodu - co prawda wtedy nie będzie można poprawnie obliczyć ratio kompresji, ale nie będzie najmniejszych problemów z enterami, spacjami i ukośnikami :-)
a na koniec dodam jeszcze ucinanie linków i będzie git!

// Gratulacje, właśnie podpisałeś się pod pomysłem Adama - Q

Adam.Pilorz napisał(a)

// a przeczytałeś z tego wątku coś więcej niż ostatnie dwa posty? przecież była mowa o kompresji RUNTIME! - Ł

// [glowa] - M

A nie chodzilo czasem o cacheowaniu tego? Tj po wycieciu tych spacji czy czegos mozna zapisac w jakims pliku pod inna nazwa/rozszerzeniem skompresowanego tpla.

// teraz skompresowane skórki będą buforowane przez istniejący już system cache :-) - Ł

ŁF napisał(a)

ha! mam nowy, lepszy pomysł :-)

• ojciec, wyluzuj - popatrz na http:*fronczyk.no-ip.com/4p/coyote/ - spróbuj znaleźć najmniejszy błąd (chociaż zabezpieczenia do textarea wywaliłem ]:->) - Ł

// a przeczytałeś z tego wątku coś więcej niż ostatnie dwa posty? przecież była mowa o kompresji RUNTIME! - Ł

// [glowa] - M

Oczywiście. Przeczytałem cały temat. I wyczytałem, że były problemy z kompresją runtime PO przepuszczeniu przez system template'ów, czyli całości. Ja natomiast mówię o skompresowaniu SAMEJ SKÓRKI przed przepuszczeniem przez nią systemu template'ów. Coś na wzór tego, co proponował ktoś wcześniej, ale nie przy wgrywaniu na FTP, tylko przy wywołaniu strony.