Azt szeretném, hogy a megírt weboldal minél gyorsabb legyen minél kevesebb erőforrás használatával, miközben szempont a biztonság, a kódok átláthatósága, a jó felhasználói élmények és a stabilitás.
PHP, Mysql, css témában érdekelnek ezek. Érdekel, hogy miként lehet a js-ben megoldott dolgokat js nélkül jól megoldani akár php és css szinten, mikor célszerübb js-ben megoldani. És ha js-ben kell megoldani, hogy lehet jól optimalizáltan megírni. A js használatát szeretném minél jobban kerülni, sajnos ez nem mindig a célszerűbb megoldás. Mármint a kerülése.
Szóval ha már meg akarok rendesen tanulni jól programozni, a felhasználóknak gyors, jól használható weboldalt készíteni, amik akár lassúbb gépeken nézik akár a világ másik oldaláról is, akkor szükségem van ezzel kapcsolatos elméleti és gyakorlati ismeretekre, ami jelen pillanatban is jól alkalmazhatóak. Mindezt úgy, hogy lehetőleg már a kezdő is értse valamennyire, de későbbre is lehet, amikor már komolyabb szinten megy. Függvényt már írtam, osztályokkal meg csak abban az esetben akarok foglalkozni, ha optimalizálás terén ez a legjobban járható út.
Bár leginkább a magyar nyelvű ingyenes digitális tartalmak lenne a legjobb, de ettől is szívesen eltérek, ha tényleg jó szakmai ismereteket kapok.
Illetve nagyon jó lenne tudni mérni és ellenőrizni, hogy mi mennyire válik be. Gondolok például a kód lefutási sebbességre, erőforrások terhelésére szerveren és kliensen.
Hozzászólások
http://www.google.com/analytics/
Mér, tanácsot ad, ellenőriz
Régen láttam Analytics-et admin oldalról, segít az optimalizálásban is?
Szerintem nem, arra a page speed való. Persze lehet hogy össze vannak drótozva.
https://developers.google.com/speed/pagespeed/
Az ilyen eszközök max sejtethetik, hogy egy aloldal ha lassabban fut, mint a többi, akkor merre lehet érdemes tapogatózni php szinten. A html, css, js szinten tudnak inkább segíteni. Mondjuk ez sem rossz. Pl javasolta, hogy a css fájl betöltését későbbre rakjam, de biztosan az a legjobb megoldás, hogy egy ideig az oldalt formázás nélkül lássák? Mondjuk több felé szedhetem a css fájlt és a php fájl több részébe szórhatom el. De hogy ez jó megoldás lenne e, az jó kérdés. Az egy dolog, hogy header és footer részbe rakom őket. De ha valahol a fájl közepében húzom be egy css fájlt, akkor mindig meg kell ezt csinálnom. Mondjuk ha egy függvény része, akkor nem is kell a későbbiekben foglalkoznom vele.
> de biztosan az a legjobb megoldás, hogy egy ideig az oldalt formázás nélkül lássák?
Normális internetkapcsolattal, átlagos gépen a felhasználónak ez nem fog feltűnni. De ha éppen a lekorlátozott mobilnettel szenvedsz, akkor megtanulod értékelni a formázás nélküli tartalmat.
> Mondjuk több felé szedhetem a css fájlt és a php fájl több részébe szórhatom el.
Ha arra gondolsz, hogy PHP szkriptből tolod ki az inline CSS-t a vakvilágba, akkor szerintem ne tedd. :) Fájni fog egy idő utáni módosítgatni a spagettikódot.
Azért lehet az ésszel is csinálni :D
Hát, végül is az elvi lehetőség nincs kizárva. :)
Bár valami template-es okos megoldás általában jobban szokott elsülni. Itt szerintem inkább az volt a kérdés, hogy az echo-val stringként kitolt inline CSS jó-e, és a tapasztalataim szerint az többször nem jó hosszú távon, mint igen. Persze az is igaz, hogy nem vagyok webfejlesztő, és olyan *igazán* nagy projektből nem olyan brutálisan sokat láttam összesen.
Előnye: eggyel kevesebb get, hátránya: nagyobb oldal. Ha amúgy kicsi a css akkor valószínűleg jobb az inline, ha nagy, akkor valószínűleg jobb külön tenni és mindenképp hasznos _jól_ beállítani az expires meg cache headereket (és reménykedni hogy a kliensoldal ezeket figyelembe veszi :D), esetleg etag-et használni, bár azzal nem lesz kevesebb get.
Atmeneti megoldas: fizikailag kulon van a CSS, de a PHP beolvassa, es inline kiirja.
--
Valóban a "weboldal sebessége" igen sok mindentől függ. Ezek egy részére ott találsz mérésre alkalmas eszközt. Más problémákra máshol.
Nézz körül például a weblabor.hu oldalon! Úgy emlékszem, van ott néhány hasznos írás erről is.
A google csak egy, ha tenyleg romma akarod optimalizalni a dolog akkor nezd meg ezt.
http://gtmetrix.com/
Jah es ha megcsinalod szepen a reget, akkor folyamataban is kovetheted hogy egy sw verziougrasnal patchnel, server config valtoztatasnal hogyan valtozott a teljesitmeny.
Jah es ez termeszetesen nem segit abban ha a kodban vagy a logikaban van a hulyeseg, pl a webserver adatbazisbol olvassa be reqestenkent a rewriterule-t, utana meg adatbazisba logolja a reqestet mielott barmit csinal, meg js-ekel van teletomve stb, szoval csak tippeket ad, de a kodot meg mindig neked kell jol megirni!
Ha a mnuanszok is kellenek akkor
http://www.phpbench.com/
http://mysqltuner.pl/
meg stb stb
Ez a phpbench nagyon jó. Mondjuk olyasmi se lenne rossz, hogy a szerveren lefut egy php file és vele minden használt cucc, majd logolná, hogy melyik utasítás, ciklus, függvény mennyi idő alatt fut le. Úgyis jó, ha konkrét értékekkel, azaz élesben tesztelést követően mutatná. Mert akkor látnám, hogy pl ez a kód gyanúsan sokáig fut, amitől a weboldal is lassan megy, valamit érdemes lehet még itt tenni.
Adatbázis lekérdezés nem gond, ott tudom az sql kódokat tesztelni. De elvileg itt sem mindegy, hogy hogyan fogalmazzuk meg a lekérdezést, mert több módon is megtehetjük. Pl a like lassabb, mint a számokkal való játszadozás logikai alapon.
Azért is foglalkozok az optimalizással elég erősen, mert nem akarom, hogy érezhető legyen az oldal betöltödése még a gyengébb eszközön sem, illetve alacsony sávszéleségnél sem. Ezt elérni nehéz egy komolyabb weboldal esetén, de ez nem ok arra, hogy ne tegyem meg a tőlem telhetőt.
"logolná, hogy melyik utasítás, ciklus, függvény mennyi idő alatt fut"
Ezt hívják profilernek. Ilyet keress, vagy ilyet javasoljon hozzáértő php fejlesztő.
Aztán ha tényleg gyorsra akarod csinálni, akkor jöhet a caching, amikor a dinamikus oldalakat (vagy azok egy részét) legenerált fájlokban tartja az alkalmazás és kb. a statikus kiszolgálás sebességével tudja kitolni az oldalt. De ezt is agyon lehet csapni a rosszul összerakott .js, .css vagy font fájlokkal, erre jók a pagespeed cuccok.
Vagy ami még segíthet, hogy az oldal egészét nem töltöd újra, csak a megváltozott részeket, de ez se old meg minden problémát, cserébe viszont hoz újakat :D
phpbench lefordított verziójára akadtam:
http://dynamicart.hu/code_speedtest/index.php
ez a weblap nagyon jó, sokat segített nekem, én is használom! ajánlom mindenkinek!
"Azt szeretném...Függvényt már írtam, osztályokkal meg csak abban az esetben akarok foglalkozni..."
Felmerül a kérdés, hogy az optimalizációs szempontok gyermeteg lelkesültségű kiválasztása, hogyan határozódik meg a kezdő naív akarnoksága által? Vagyis miként lehet segíteni az önképzés rögös útjára tévedőt a fontos dolgok és a látszólag fontos dolgok elválasztásában?
+1 :)
--
http://pyftpadmin.earthquake.hu
This is a motherfucking website
----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám
Awesome :) \o/
------------------------
Program terminated
{0} ok boto
boto ?
"A js használatát szeretném minél jobban kerülni, sajnos ez nem mindig a célszerűbb megoldás. Mármint a kerülése."
Jajj. Legyszi, ne legyel a +1 -edik "akkor jo, ha allandoan refreshel az oldal" fejleszto. Igen, kell olyan megoldas is, ami nem tartalmaz js-t, hogy a JS-t nem tamogato, vagy azt tilto bongeszokben is _valamennyire_ mukodjon az oldal, de ha mar van mukodo JS, akkor igenis tessek kihasznalni azt.
Altalaban egyebkent a JS nelkuli megoldast egyszerubb megcsinalni, foleg egyszerubb esetekben, mint pl. ahol az akcio gyakorlatilag egy form postolasa.
De itt alapveto hianyossagokat erzek a programozasi eszkozok ismerete teren, szoval elobb azzal kellene ismerkedni elobb, es utana optimalizalni.
--
"De itt alapveto hianyossagokat erzek a programozasi eszkozok ismerete teren, szoval elobb azzal kellene ismerkedni elobb, es utana optimalizalni."
+1
Optimalizálni egy rendszert csak az tud, aki érti, hogy mi hogyan működik. Weboldal esetén ebbe bele kell érteni a szerver oldali PHP-t, a hálózatot, az adatbázist, a kliens oldalon a böngészőt. Ha ott tartasz, hogy OOP-t nem akarsz tanulni, mert te "csak" optimalizálni akarsz, akkor még nagyon sokat kell tanulnod (mármint az eredeti poszt-tolónak), mielőtt elkezdhetnél dolgozni.
Azért hogy ontopik is legyek:
A szerver oldali optimalizálástól a szerveren futó dolgok lesznek gyorsabbak. A kliens oldalitól meg a kliensen. Tehát a PHP optimalizálásától nem lesz gyorsabb a weboldal(JS és renderelés része) egy lassú kliensen, mert nem ott fut a PHP.
Azért a kliens-szerver optimalizáció sokszor egymással szembe megy. Mert a feladatot pakolja innen-oda.
Példa: Dinamikus grafikon.
Ennek rengetek lehetséges megoldása van, attól függően, hogy milyen böngészőt feltételezünk a másik oldalon.
HTML5+JS esetén akár az egészet kitolhatjuk a kliensre. És a szerver csak némi JS-kódot, és az adatokat küldi. Másodlagos effektje, hogy nem cachelődik, tehát minden oldaltöltésnél megdolgoztatja a klienst. Hacsak az ember nem tárolja le a képet. Ez ugye böngészőtől függően nem tehető meg mindíg. De ez is egy opció.
Egy ilyen JS megoldás esetén érdemes minimalizálni az oldaltöltések számát. Tehát akkor már kihasználni a JS-t más módon is.
Szerver oldalon többféle megoldás is kivitelezhető. SVG-t generálni periodikusan amikor új adat van. Előnye, hogy kihasználja a cache-eket. Egy sokat frissülő grafikonnál ez az előny elvész.
Ha nem bízunk a böngészőben akkor lehet JPG-t PNG-t is generálni.. ez adott esetben plusz terhelés a szerveren.
Ha csak egy nézete van a grafikonnak akkor sok esetben a szerver-en való megvalósítás tényleg komoly terhelést jelenthet. Ilyen esetben egyértelműen a JS megoldás a nyerő.
stb... stb... stb... Lehet ezt még folytatni. Az optimalizálás gyönyörei.
Amik nekem eddig általánosságban beváltak.
- Sok külső vacak hanyagolása. két funkcióért ne hívj JQuery-t meg Mootoolst meg tudomisénmit.
- Ha nem feltétlen kell GAnalyitics akkor ne töltsd be
- Random social-network shit dettó
- JS-ben az onLoad() dolgokat vékonyan tartani.
- Design közben figyelembe venni, hogy az mennyire megvalósítható kevés elemmel.
- Ha van JS, akkor akár nem egyszerre betölteni mindent, hanem hagyni megjelenni az oldalt, és utána betölteni pl. a képek nagyfelbontású változatát. Akár valamilyen prediktív jelleggel, nem is mindet.
- A browser cache a barátod. Lehet, hogy a külön CSS plussz egy request de csak 1, és nem tolod le a kódot minden oldalbetöltésnél.
- Mindennel csinnyán bánni aminek a nevében a library, és főleg a plugin szerepel.
- Profile and Test... sokat.. többet...mégtöbbet.
- minify, meg tömörítés mindenre.
- A feladatokat csak annyiszor elvégezni ahányszor szükséges.
### ()__))____________)~~~ #################
# "Ha én veletek, ki ellenetek?" # E130/Arch
vannak olyan tárhely szolgáltatók, akik kifejezetten erre mennek rá, hogy valami iszonyat kevés usert pakolnak egy szerverre, és nagyon feltuningolt szerverre tesznek. Ez is tud lódítani a sebességen!
Talán ennyire konkrétan nem említették, de azért azt mondanám, hogy egy gyors oldalnál alapvető, hogy mindent, amit lehet, gyorsítótárazz. Hogy hányféle szinten/módszerrel lehet ezt csinálni, arról például jó képet kaphatsz, ha ránézel mondjuk a W3TC nevű wordpress plugin-ra.
És fontos a CDN is, főleg ha a „világ minden táján” szerepel a céljaid között.