Nem igaz, hogy egy CMS nem lehet gyors!?
Sokan azzal jönnek, hogy a CMS-eket nem lehet használni, mert lomhák a méretük miatt. Mindenkinek mondanám, hogy ez nem igaz!
Alaphelyzetben persze igaz, a hatalmas css-ek, és számtalan bővítmény miatt, de hát erre találták ki a cache-t és egyéb gyorsításokat. Mint látható az eredményemen: [link]
6 MB-os oldalam van, és több mint 20 bővítményt használok, sajna mind kell. Ennek ellenére az eredményem magáért beszél. Tény, hatalmas munka a beállítás, hogy a cache és egyéb gyorsítás ne tegye tönkre az oldal megjelenését, de minden oldallal meg lehet csinálni. Az enyémen még ajax is fut...
Megjegyzem, az egyedileg fejlesztett index.hu lassabb betöltődésű: [link]
Tény, hogy sokkal több lekéréssel, tehát az ideje nagyon jó. Egy CMS soha nem fog ekkora tartalmat kiszolgálni, viszont üzleti és magánoldalnak is kiváló, gyorsaságban is, hiába állítják sokan, hogy lomha... Ha foglalkozol vele, akkor nem az.
válasza:2-3 mp betöltési idő???????
ez neked gyors?
egy CMS lehet gyors, de ez szerintem elég lassú, persze attól függ milyen tartalmat jelenítesz meg...
23F
válasza:> Megjegyzem, az egyedileg fejlesztett index.hu lassabb betöltődésű:
Persze, mivel 3x annyi request van.
válasza:Egy (Free) CMS sebessége sok mindentől függ.
(Itt most WP, Joomla és társairól van szó.)
2~3 másodperces első betöltési idő nem olyan rossz.
(utána értelem szerűen cachbe kerülnek a CSS/JS/képek)
A fő lassúságágát nem is ez adja, hanem a motor ami mögötte van.
Első fő gondja, hogy rengeteg sokszor több ezer fájlt kell elérnie,
egy egyszerű oldal lekérésnél, mikor össze szedi minden almappából.
Osztott szervereknél, ilyenkor a háttértaroló fájlelérése és olvasásától függ.
És mivel párhuzamosan több száz, de olykor több ezer másik weboldallal kell osztozni,
és egyszerre csak 1 fájlt tud olvasni, és rendszer próbálja sorba rakni őket.
SSD -vel kicsit jobb a helyezett, de csak azért mert nincs fejpozicionálás,
és jelentősen gyorsabban tudja olvasni a fájlt háttértárolóról,
bár ez költségesebb mivel közel 10 -ét kapja SSD -be mint HDD -n.
És az adatbázis mérete, ami hatványozottan növeli a betöltési időt.
Első alkalommal ha tudja memcache -be tölti, így közvetlen második alkalommal már gyorsabban megy.
De ha pörög a szerver, nem tudja sokáig RAM -ban tárolni a korábbi lekérdezéseket,
így ott mindig megkel tennie ezt.
(akár 20~30 másodperccel is több lehet, míg cahce-ből már csak ~5mp.)
Tehát ami a lassúságát adja: sok PHP, sok SQL, szerver Terheltsége.
Ha egy 1~2 lapos egyszerű oldal kell, akkor minek egy nagy 20~30MB -os alap CMS -hozzá, ami szinte statikusan is megoldható.
Ha meg nagy több ezres bejegyzéses oldal, akkor meg nagy az adatbázis, (az index.hu -nál több milliós táblák vannak 11 milliós ID -t láttam most a legutóbbi híreknél), ami egy ilyen CMS szerkezetnél, ahol szinte mindent betöltene későbbi feldolgozásra, pedig iszonyat lenne.
válasza:4-es: nagyon vicces :)
2-es: az indexnél írtam, hogy lényeges több lekérést végez :) tehát az ideje nagyon jó
1-es: értesz angolul? Az oldalam a weboldalak 68%-ánál jobban teljesít!
2-3 mp nem jó idő? Már hogy a fenébe ne lenne az..
Az oldalam természetesen alap HDD osztott tárhelyről működik, így ez az eredmény nagyon jó egy 6 MB-os betöltésnél. Nyilván, ha VPS-ről menne, az idő lekúszna 1,5 mp-re, de ennek ára van, súlyos havidíjak... És nem is akarok magamnak telepíteni mindent, meg frissíteni, és nem is értek hozzá...
Az index nyilván sokkal több lekérést tud gyorsan biztosítani, hiszen nem egy olcsó osztott tárhelyről működik :) Valszeg saját profi szerverről megy az egész. Azért az más!
Én a legtöbb alapfelhasználó szemével mutattam be, hogy egy CMS igenis lehet gyors! Az oldalamon egyébként webshop és fórum is van... Tehát üzleti oldalnak is jó a CMS, mondjuk kisebb webshop esetében.
Osztott szervernél túlterhelt időszakban (esti órák) pedig a cache miatt nem lesz túlzottan magasabb a letöltési idő. De ekkor az index betöltési ideje is felmászik, saját szerver ide vagy oda...
Ezt a betöltést is tudnám javítani még MaxCDN használatával, de erre már nem költök, bár asszem valami havi +800 Ft lenne... De minek?
válasza:Nem a kliens oldali cache a lényeg.
Hanem szerver oldali feldolgozási sebesség.
Kliens oldalon Free CMS vagy csupán statikus HTML -el is pont ugyan az.
(Jó kicsit több mert 1-1 modulhoz külön CSS/JS tartozik, de összességében nem jelentős eltérés)
A Free CMS -el szerver oldali feldolgozás ami igen csak lomha tud lenni, azaz a PHP feldolgozási idő, ami MySQL Cache nélkül (szerver oldalon, mert pörög a szerver, és cache dinamikusan cserélődik), méretes adatbázissal, ítélet.
Azaz ha csak 1-2 szinte statikus laphoz, felesleges akkora háttér CMS -t rakni, mert amit segít, azt kis gyakorlattal akár magad is össze ollózhatod kész szkriptekből. És nem egy ~20MB -os alap szerezett lesz, hanem 0.2~0.5 MB.
Ami nem feltétlen sebesség még a CMS hátrányához, hogy méretes a HTML+CSS+JS része, mint írtad 6 MB az oldalad.
De legtöbb forgalomba lévő mobilnak ez már sok!
Ha MB méretesebb, akkor legtöbb 0.5 GB RAM -al szerelt dorid böngészője bezárja magát, mert a rendszer által meghagyott max ~100MB -ba már nem tudja feldolgozva belepréselni, na'h meg olykor 2G -vel betölteni is rémálom.
(Ez jelenleg használatban lévő mobilok, táblagépek 3/4 -e)
És még van tucatnyi dolog, ami gondot okozhat, pl. 20 bővítményt használsz, azaz 20 potenciális támadási felület ha véletlen elfelejted a legfrissebb biztonsági frissítést felrakni.
Nem célzottan téged fognak támadni, hanem automatikusan bot -okkal próbálnak potenciálisan támadható oldalt találni, amit majd pl. viagra email spammelésre tudnak felhasználni...
Lényeg a PHP féldogozási sebesség csak 1 dolog (amit szerver kapacitással áthidalható) a számos okból ami miatt nem szoktam ajánlani üzleti felhasználásra.
Hobbi oldalt, nulla tudással, gyorsan készíteni, arra való..
válasza:Egy osztott tárhelyen lévő weboldalam aminek 3000 terméke van:
válasza:hopp elfelejtettem beállítani hogy ne a bolygó másik feléről nézze. :-D
válasza:Értem, amit mondasz.
De ilyenkor sokszor az van, hogy a nagyon gyorsnak mért főoldal gyakorlatilag tartalom nélküli, mint a 11 lekéréses oldalnál is.
Egyértelmű, ha egy statikus oldalt benyomok főoldalnak, akkor az 1 mp alatt töltődik majd le. De ha már ott több mindent szeretnél megjeleníteni, akkor az is lassulni fog. CMS is betölt 1 mp alatt, ha nincs a főoldalon semmi, csak hogy "ez az első bejegyzés".
Az oldalam most azért is ilyen nagy, mert nagyméretű képeket használok, ezeket majd még tömörítem. De bizonyos méret kell majd a látványhoz. Nyilván, mérlegelni kell gyorsaság is látvány között. A nagyon gyorsan betöltődő oldalakon általában nulla látvány van, vagy 90-es évek eleji dizájnt idéző látvány :)
Lemértem az egyik oldaladat, nálam nem amcsiból mérve:
Requests
86
Load time
2.29s
Page size
1.9MB
Ennyit hoz az én CMS-em is jóval nagyobb tartalommal, shoppal és fórummal, melyek tartalmát mind letölti a főoldalam. A te oldaladon nagyon kis képek vannak, és filmek, melyeket nem is saját szerverről kérsz be... és nincsen az a dizájn, amit említettem... (Valamit valamiért)
Amúgy minek tiltod a jobb egérgombot? :) Ez csak azokat tartja vissza, aki teljesen amatőrök, akik ért hozzá, azonnal meg tudja lesni bármelyik böngésző vizsgálójával! :) Hiába tiltod a közvetlen forrás megjelenítését is, a vizsgáló akkor is mutatja a kódokat.
Innentől persze igaz, hogy a CMS sebezhető, de melyik oldal nem? Én is megmondom, hogy milyen scripteket használsz:
js/nocklick.js
jquery.min.js
crawler.js
md5.js
jwplayer.js
java.js
Nem vagyok programozó, de ha az lennék, és fel akarnék törni egy weboldalt, a tiédnél is tudnám, hol hatoljak be, ahogy egy CMS-nél is. (Erre van a szerveroldali napi biztonsági mentés)
És tegyük hozzá, hackerek nem törnek fel csak úgy oldalakat, mert egyrészt bűncselekmény, másrészt piti oldalak miatt nem fogják lekövettetni saját magukat. Kockázatot csak nagy pénzért vagy egyébért vállalnak...
Szal értem, amit mondasz, de az egyedi fejlesztés egyre jobban kiszorul majd, tényleg csak nagyobb vállalkozások engedhetik meg maguknak... A CMS-ek pedig egyre profibbak, hiszen ezer és ezer programozó áll mögöttük, napi szintű fejlesztésekkel.
Kapcsolódó kérdések:
Minden jog fenntartva © 2025, www.gyakorikerdesek.hu
GYIK | Szabályzat | Jogi nyilatkozat | Adatvédelem | Cookie beállítások | WebMinute Kft. | Facebook | Kapcsolat: info(kukac)gyakorikerdesek.hu
Ha kifogással szeretne élni valamely tartalommal kapcsolatban, kérjük jelezze e-mailes elérhetőségünkön!