کوربه توب او کارکردګي
څنګه موږ WordPress چټک کوو: LiteSpeed Enterprise، LSCache او د هر سایټ لپاره Redis
د WordPress تر ټولو چټکه غوښتنه هغه ده چې هېڅکله نه چلیږي — دلته تشریح شوي چې زموږ سټیک څنګه مخکې له دې چې کله هم PHP یا MySQL وغوښتل شي، له کیش څخه ډېرو لیدنو ته ځواب ورکوي، او دا د Core Web Vitals لپاره څه معنی لري.
تر ټولو چټکه غوښتنه هغه ده چې هېڅکله نه پلي کېږي
د WordPress یوه معیاري غوښتنه ډېر لګښت لري. وېب سرور غوښتنه PHP ته سپاري، PHP خپله WordPress روښانه کوي، پلګېنونه چلوي، MySQL ته څو لسګونه ځله غوښتنې لېږي، HTML راټولوي، او یوازې له هغې وروسته بایټونه بېرته لېږي. په یوه بوخت سایټ کې دا ټوله پروسه د هر لیدونکي لپاره ترسره کېږي، او دا هغه ځای دی چې ستاسو نږدې ټول time-to-first-byte مصرفېږي.
زموږ ځواب دا دی چې ډاډ ترلاسه کړو چې د ډېری لیدنو لپاره، د دې هېڅ برخه په بشپړ ډول نه ترسره کېږي. په هغو سایټونو کې چې موږ یې کوربه توب کوو — له 100,000 څخه ډېر PBN سایټونه او همدارنګه اصلي اداره کېدونکی WordPress — د مخکینۍ برخې ډېری لیدنې د بشپړې مخکې چمتو شوې پاڼې په توګه په مستقیم ډول له کیش څخه وړاندې کېږي، پرته له دې چې PHP فعال شي یا د ډیټابیس سره اړیکه ونیول شي. د دې لیکنې پاتې برخه په دې اړه ده چې هغه پوړونه چې دا چاره ممکنه کوي څنګه سره نښلي، او هر یو یې څنګه خپل ارزښت ثابتوي.
مهمه چوکاټ دا دی چې دا داسې سیال کیشونه نه دي چې تاسو یې ترمنځ یو غوره کړئ. د بشپړې پاڼې کیش، د ابجیکټ کیش، او د CDN وروستۍ څنډه هر یو د غوښتنې یوه جلا طبقه نیسي، او اصلي ارزښت په دې کې دی چې دوی څنګه یو بل ته کار سپاري.
LiteSpeed Enterprise + LSCache: د بشپړې پاڼې کچه
هر سایټ د سرور په کچه د LSCache سره پر LiteSpeed Enterprise چلیږي. کله چې د فرنټ-اینډ غبرګون د کیش وړ وي، نو ویب سرور یې د LiteSpeed د کیش کنټرول او ټګ سرلیکونو سره نښه کوي، او LiteSpeed په راتلونکي لیدنه کې بشپړه پاڼه مستقیم وړاندې کوي — نه د PHP پروسه رامینځته کیږي، نه د MySQL پوښتنه کیږي. دا پر WordPress TTFB ترټولو لوی اغېزمن عامل دی، ځکه چې دا د اپلیکیشن بشپړ پیل له فعالې لارې څخه لیرې کوي.
ځکه چې LSCache د PHP پلګ ان پر ځای د ویب سرور دننه شتون لري، دا د غوښتنې د دورې په لومړیو کې کار پیل کوي او پاڼې په داسې بڼه ساتي چې سرور کولی شي سمدستي یې فلش کړي. د کیش کرالر مشهورې پاڼې تودې ساتي، ترڅو له پاکولو وروسته لومړنی لیدونکی هغه څوک نه وي چې د پاڼې د بیا جوړولو بیه پرې کوي. پایله یې د یوازې-پلګ ان کیش په پرتله چې په یو عام سټیک باندې اضافه شوی وي، د پام وړ ټیټ او ډیر ثابت TTFB دی، چیرې چې کیش لاهم د PHP تر شا پروت وي.
زموږ خپل د ریپو کچې کیش پلګ ان په هر سایټ کې مخکې له مخکې نصب او په اتوماتيک ډول تازه کیږي، چې WordPress سمدلاسه له LSCache سره په سمه توګه نښلوي. په غیر LiteSpeed سرچینه کې دا یوازې د بشپړې پاڼې سرلیکونه نه خپروي او له لارې لرې کیږي، پداسې حال کې چې د اعتراض کیش او د استثنا قواعد خپل کار ته دوام ورکوي — نو یو لیږدول شوی سایټ هیڅکله په مات شوي او نیمګړي تنظیم شوي حالت کې نه پاتې کیږي.
د زړې منځپانګې وړاندې کولو پرته چټک پاتې کېدل: ESI او ځیرک اتومات پاکول
د بشپړې پاڼې تېز او تېری کوونکی کیش کول دوه کلاسیک د ناکامۍ حالتونه لري: یو ننوتلي کاروونکي ته د بل چا د پاڼې ښودل، او هر چا ته د داسې پاڼې وړاندې کول چې باید بدله شوې وای. دا دواړه ستونزې د لږ کیش کولو پر ځای، په خپله د کیش کولو په طبقې کې هوارېږي.
ESI (Edge Side Includes) موږ ته اجازه راکوي چې پاڼه کیش کړو پداسې حال کې چې د هغو برخو لپاره سوري رامینځته کوو چې باید ژوندي پاتې شي. په یو WooCommerce پلورنځي کې د کټلاګ، محصول او کټګورۍ پاڼې د ترټولو ممکنه ګړندي TTFB لپاره د بشپړې پاڼې کیش په توګه وړاندې کیږي، پداسې حال کې چې ESI د کارټ ټوټه، د مینی کارټ ټولټال او د حساب حالت په هر غوښتنه کې رینډر کوي. کارټ، چیک آوټ، زما حساب او هر ډول nonce یا د ناستې پاڼې د ډیفالټ له مخې خارج شوي دي. پیرودونکي تل خپله ټوکرۍ او یو کاري چیک آوټ ګوري؛ هرڅوک بیا هم د کیش څخه پلورنځی ترلاسه کوي.
تازه والی د سمارټ اوتوماتیک پاکولو له لارې اداره کیږي. د پاکولو هکونه په اوتومات ډول هغه وخت فعالېږي کله چې منځپانګه، محصولات، نرخونه یا فرمایشونه بدل شي، نو اړوندې خوندي شوې پاڼې پر وخت د ټاکل شوي وخت پر ځای سمدستي تازه کیږي، او تاسو کولی شئ د ډشبورډ یا د WordPress له دننه څخه هم د اړتیا په وخت کې پاکول ترسره کړئ. پر ټګونو ولاړ پاکول پدې مانا دي چې د یوې لیکنې سمول یوازې هغه لیکنه او د هغې آرشیفونه پاکوي — نه ټوله خوندي شوې حافظه — نو یو واحد سمون د ټول سایټ د بیا سست پیل لامل نه ګرځي.
د هر سایټ لپاره د Redis اعتراض کیش: د هغه څه لپاره چې بشپړه پاڼه نشي کیدی
هر غوښتنه یو بشپړ جامد مخ نشي کیدی. ننوتلې ناستې، د WordPress اډمین، د WooCommerce کارټونه، لټون، او هغه متحرک ټوټې چې ESI یې ژ ژوندۍ پریږدي ټول باید PHP پرمخ بوځي. د دې لپاره، هدف له 'اپلیکیشن پریښودل' څخه 'ډیټابیس پریښودل' ته بدلیږي.
هره وېبپاڼه خپله ځانګړې د Redis آبجیکټ کیش ترلاسه کوي. WordPress په ډیټابیس کې د مکررو لوستلو پایلې — لکه غوراوي، ترانزینټونه، د پوسټونو او اصطلاحاتو لټونونه، او د WooCommerce د محصولاتو او ناستو ډاټا — په حافظه کې ساتي، ترڅو هر ځل لیدلو سره په MySQL باندې همغه پوښتنه تکرار نه شي. د دې اغېز په ځانګړې توګه په هغو ځایونو کې ډېر څرګند دی چېرته چې د بشپړې پاڼې کیش مرسته نشي کولی: ګړندي ډشبورډونه، ګړندۍ کڅوړې (کارټونه)، او د ټرافیک پر مهال پر ډیټابیس خورا کم بوج.
د څیزونو کاشې (object cache) د هر سایټ لپاره جلا ده او شریکه نه ده، چې دا کار هم د فعالیت او هم د جلاوالي لپاره خورا مهم دی. د هر سایټ لپاره د ډیټابیس د سرعت د کنټرول سره په یوځای کېدو، د یو سایټ درنې یا ناسمې لیکل شوې پوښتنې نشي کولی د خپلو ګاونډیو سایټونو لپاره ډیټابیس له کمښت سره مخ کړي. تاسې کولی شئ زموږ د کاشینګ ځانګړتیاوو په پاڼه کې د بشپړ څو پوړیز جوړښت د یوځای کار کولو په اړه، او د جلاوالي لاندې د کاروونکو (tenants) ترمنځ د حدودو په اړه نور معلومات ولولئ.
څنډه او د هغې لاندې ترانسپورت
هغه کیش چې په اصلي سرور (origin) کې وي، لاهم باید له شبکې څخه تېر شي. د سرور مخې ته د CDN څنډه (edge) شتون لري، نو ځکه جامد توکي او د کیش وړ پاڼې لیدونکي ته نږدې د شتون له نقطې څخه وړاندې کیږي، او اصلي سرور حتی د بار لاندې هم ارام پاتې کیږي. زموږ د footprint-free کوربه توب لاین لپاره همدا څنډه د ملټي-CDN یوه مجموعه ده چې په څو برابرونکو ویشل شوې، کوم چې د فعالیت ترڅنګ د footprint یو هدف هم پوره کوي؛ په اصلي جریان WordPress کې دا په ساده ډول یو چټک، ښه تنظیم شوی پرت دی چې اصلي سرورونه بې کاره ساتي.
په باطن کې، بنسټیزو اړخونو ته په کمه سترګه نه دي کتل شوي. سایټونه د HTTP/3 سره په NVMe ذخیره کې چلیږي، نو هغه بایټونه چې کیش یې استوي د هر کیش مس تر شا د چټکې ذخیرې سره د یو عصري، ملټي پلیکس شوي ټرانسپورټ له لارې رسیږي. له دې طبقو څخه هیڅ یو هم اضافي (add-on) نه دی: LiteSpeed، LSCache، د هر سایټ لپاره جلا Redis، NVMe او HTTP/3 په هر پلان کې بنسټیز معیار دی، نه د لوړې بیې پلورلو کچه.
څه شی په حقیقت کې په Core Web Vitals اغیزه کوي
دقت لرل ارزښت لري، ځکه چې هوسټینګ ډېری وخت د Core Web Vitals په اړه له اندازې زیات ستايل کېږي. TTFB د معادلې هغه برخه ده چې د سرور په واک کې ده، او پورته یاد شوی caching stack هغه څه دي چې دا کموي — یوه بشپړه کیش شوې پاڼه چې له edge څخه د HTTP/3 له لارې وړاندې کېږي تر ټولو ټیټ حد دی چې TTFB یې ترلاسه کولی شي. له دې امله چې TTFB د Largest Contentful Paint پیل ټکی دی، نو یو ګړندی origin د بهیر هر راتلونکي میټریک ته داسې لومړنی پرمختګ ورکوي چې له بلې لارې یې ترلاسه کول ناممکن دي.
خو LCP، CLS او INP تر ډېره په براوزر کې، پخپله د پاڼې له لوري ټاکل کېږي: یو نا اصلاح شوی د مخکښې برخې انځور (hero image)، د رینډر مخنیوی کوونکی CSS او JavaScript، هغه بڼه چې د فونټونو او اعلاناتو په پورته کېدو سره بدلیږي، او د پلګ انونو له امله د اصلي تار دروند کار. د سرور هېڅ ډول زیرمه کول (caching) یو ۲ اېم بي هیرو انځور یا داسې بڼه نه شي سمولی چې میګابایټونه JavaScript لېږدوي. رښتینی کوربه توب د سرور ونډه په اغېزمنه توګه وړیا او ثابته کوي، بیا نو د سایټ کار دی چې مخکینۍ برخه (front end) سپکه وساتي.
د کار دا وېش ګټور فکري موډل دی. موږ تضمین کوو چې غوښتنه ژر براوزر ته ورسېږي او د ترافیک لاندې هم چټکه پاتې شي؛ تاسې بار کوچنی او باثباته وساتئ. چيرته چې دا دواړه سره یو ځای کېږي — د کېش تودول، په څنډه کې رسول، او د ډېټابېس چټک ساتل ترڅو متحرکې پاڼې ونه ځنډېږي — کټ مټ هغه ځای دی چې زموږ سټېک عیار شوی، او همدا چاره په دې پلاتفارم کې اداره شوی WordPress په یو عادي کوربه کې د ورته سایټ په پرتله خورا ګړندی کوي.
پرله پسې پوښتنې
ایا زه لاهم د WP Rocket په څیر د کیشینګ پلگ ان ته اړتیا لرم؟
نه. د بشپړې پاڼې کیش کول په ویب سرور کې د LiteSpeed د LSCache لخوا ترسره کیږي، او زموږ خپل کیش پلگ ان — چې مخکې له مخکې نصب شوی او په اوتومات ډول تازه کیږي — WordPress په سمه توګه ورسره نښلوي، چې تر شا یې د هرې سایټ لپاره د Redis اعتراض کیش شتون لري. په دې سربېره د بشپړې پاڼې کیش کولو د دویم پلگ ان اضافه کول معمولاً د مرستې پرځای د سرور د کچې له کیش سره ټکر رامنځته کوي، نو دا اړین نه دی او سپارښتنه یې نه کیږي.
ایا کیش کول به زما د WooCommerce کارټ یا هغه پاڼې خرابې کړي چې ننوتل شوي وي؟
نه. د Cart، checkout، my-account او د nonce یا session هره پاڼه په ډیفالټ ډول له کیش څخه ایستل کیږي، او ESI د کارټ ټوټه او ټول مقدار په نورو کیش شویو پاڼو کې ژوندی ساتي. پېرودونکي تل خپله ټوکرۍ او یو فعال چیک آوټ ګوري پداسې حال کې چې د پلورنځي مخکینۍ برخه لاهم له کیش څخه بیارغول کیږي.
کله چې زه خپروم یا سمون کوم، نو کیش څنګه تازه پاتې کیږي؟
هوښیار اتوماتیک پاکول په اړوندو WordPress هکونو کار کوي، نو د منځپانګې خپرول، سمول، یا د محصول، بیې یا فرمایش بدلول یوازې اغیزمن شوي پاڼې او د هغوی ارشیفونه پاکوي — نه ټوله زیرمه — او یو کرالر دا پاڼې بیرته تازه کوي. تاسو کولی شئ د ډشبورډ یا د WordPress له دننه څخه هم د اړتیا سره سم پاکول ترسره کړئ.
ایا یوازې کوربه توب کولی شي ما ته مناسب Core Web Vitals راکړي؟
دا تاسو ته غوره ممکنه TTFB درکوي، چې د سرور برخه ده او د Largest Contentful Paint لپاره یو ښه پیل دی. مګر LCP، CLS او INP تر ډېره حده پخپله د پاڼې له خوا ټاکل کیږي — د انځورونو کچه، د رینډر خنډ کوونکې سرچینې، د جوړښت ثبات او د اصلي تار JavaScript. زموږ سټیک د سرور برخه چټکه او ثابته کوي؛ د فرنټ-اینډ د ډېټا کچه کمه ساتل هغه څه دي چې پاتې واټن له منځه وړي.
اړوند
دا د ۱۴ ورځو لپاره وړیا و ازموئ
خپلې لومړۍ وېبپاڼې د ۱۴ ورځو لپاره وړیا پیل کړئ — هیڅ کارټ ته اړتیا نشته. ایا شته شبکه لېږدوئ؟ کډه کول وړیا او بې له کوم محدودیت څخه دي.
وړیا پیل کړئ