હોસ્ટિંગ અને પ્રદર્શન
અમે WordPress ને કેવી રીતે ઝડપી બનાવીએ છીએ: LiteSpeed Enterprise, LSCache અને સાઇટ દીઠ Redis
સૌથી ઝડપી WordPress વિનંતી તે છે જે ક્યારેય રન થતી નથી — PHP અથવા MySQL ને કૉલ કરવામાં આવે તે પહેલાં જ અમારો સ્ટેક કેશમાંથી મોટાભાગની મુલાકાતોનો જવાબ કેવી રીતે આપે છે, અને Core Web Vitals માટે તેનો શું અર્થ થાય છે તે અહીં છે.
સૌથી ઝડપી વિનંતી તે છે જે ક્યારેય ચાલતી નથી
એક સામાન્ય WordPress વિનંતી ઘણી ખર્ચાળ છે. વેબ સર્વર PHP ને કામ સોંપે છે, PHP એ WordPress ને બૂટ કરે છે, પ્લગઇન્સ ચલાવે છે, MySQL માં થોડા ડઝન વાર ક્વેરી કરે છે, HTML તૈયાર કરે છે, અને ત્યાર પછી જ બાઇટ્સ પાછા મોકલે છે. વ્યસ્ત સાઇટ પર આ આખી પ્રક્રિયા દરેક મુલાકાતી માટે થાય છે, અને તમારો લગભગ તમામ ટાઇમ-ટુ-ફર્સ્ટ-બાઇટ (time-to-first-byte) સમય અહીં જ વપરાય છે.
અમારો જવાબ એ સુનિશ્ચિત કરવાનો છે કે, મોટાભાગની મુલાકાતો માટે, આમાંથી કશું જ ન થાય. અમે હોસ્ટ કરીએ છીએ તે સાઇટ્સમાં — 1,00,000 થી વધુ PBN સાઇટ્સ ઉપરાંત મુખ્ય પ્રવાહના સંચાલિત WordPress — મોટાભાગના ફ્રન્ટ-એન્ડ પૃષ્ઠ દૃશ્યો PHP નો ઉપયોગ કર્યા વિના અથવા ડેટાબેઝને સ્પર્શ કર્યા વિના સીધા જ કેશમાંથી પૂર્વ-રેન્ડર કરેલા સંપૂર્ણ પૃષ્ઠ તરીકે પ્રદાન કરવામાં આવે છે. આ પોસ્ટનો બાકીનો ભાગ એ વિશે છે કે આને શક્ય બનાવતા સ્તરો કેવી રીતે એકસાથે જોડાય છે, અને દરેક સ્તર કેવી રીતે પોતાનું સ્થાન મેળવે છે.
મહત્વપૂર્ણ બાબત એ છે કે આ કોઈ સ્પર્ધાત્મક કૅશ નથી જેમાંથી તમારે પસંદગી કરવાની હોય. ફુલ-પેજ કૅશ, ઑબ્જેક્ટ કૅશ અને CDN એજ દરેક અલગ-અલગ પ્રકારની વિનંતીઓને સંભાળે છે, અને તેનું વાસ્તવિક મૂલ્ય તેઓ એકબીજાને કેવી રીતે ડેટા સોંપે છે તેમાં રહેલું છે.
LiteSpeed Enterprise + LSCache: સંપૂર્ણ પૃષ્ઠ સ્તર
દરેક સાઇટ સર્વર-લેવલ LSCache સાથે LiteSpeed Enterprise પર ચાલે છે. જ્યારે ફ્રન્ટ-એન્ડ પ્રતિસાદ કેશ કરી શકાય તેવો હોય, ત્યારે વેબ સર્વર તેને LiteSpeed cache-control અને ટેગ હેડર્સ સાથે સ્ટેમ્પ કરે છે, અને LiteSpeed આગલી વિનંતી પર સંપૂર્ણ પૃષ્ઠ સીધું જ પ્રદર્શિત કરે છે — કોઈ PHP પ્રક્રિયા શરૂ થતી નથી, કોઈ MySQL ક્વેરી જારી થતી નથી. આ WordPress TTFB પર સૌથી મોટો પ્રભાવક પરિબળ છે, કારણ કે તે હોટ પાથમાંથી સંપૂર્ણ એપ્લિકેશન બૂટને દૂર કરે છે.
કારણ કે LSCache PHP પ્લગઇનમાં હોવાને બદલે વેબ સર્વરની અંદર રહેલું છે, તેથી તે વિનંતી જીવનચક્રમાં ખૂબ વહેલું કામ કરવાનું શરૂ કરે છે અને પૃષ્ઠોને એવા સ્વરૂપમાં રાખે છે જેને સર્વર તાત્કાલિક સાફ કરી શકે છે. કૅશ ક્રોલર લોકપ્રિય પૃષ્ઠોને તૈયાર રાખે છે, જેથી શુદ્ધિકરણ (purge) પછીનો પ્રથમ મુલાકાતી એવો ન હોય જેને પૃષ્ઠ ફરીથી જનરેટ કરવાની રાહ જોવી પડે. તેનું પરિણામ એ છે કે સામાન્ય સ્ટેક પર ફક્ત પ્લગઇન આધારિત કૅશની તુલનામાં નોંધપાત્ર રીતે ઓછો અને વધુ સુસંગત TTFB મળે છે, જ્યાં કૅશ હજી પણ PHP પાછળ રહેલું હોય છે.
અમારું પોતાનું રેપો-ગ્રેડ કેશ પ્લગઇન દરેક સાઇટ પર પ્રી-ઇન્સ્ટોલ કરેલું અને ઑટો-અપડેટ થયેલું આવે છે, જે શરૂઆતથી જ WordPress ને LSCache સાથે યોગ્ય રીતે જોડે છે. બિન-LiteSpeed મૂળ સર્વર પર તે ફક્ત કોઈ પૂર્ણ-પૃષ્ઠ હેડર્સ બહાર પાડતું નથી અને વચ્ચે આવતું નથી, જ્યારે ઑબ્જેક્ટ કેશ અને બાકાત રાખવાના નિયમો તેમનું કામ કરવાનું ચાલુ રાખે છે — તેથી સ્થળાંતર કરેલી સાઇટ ક્યારેય તૂટેલી અડધી-રૂપરેખાંકિત સ્થિતિમાં રહેતી નથી.
જૂની સામગ્રી પીરસ્યા વિના ઝડપી રહેવું: ESI અને સ્માર્ટ ઑટો-પર્જ
આક્રમક પૂર્ણ-પૃષ્ઠ કેશીંગમાં બે ક્લાસિક નિષ્ફળતા મોડ્સ છે: લૉગ-ઇન થયેલ વપરાશકર્તાને અન્ય કોઈનું પૃષ્ઠ પીરસવું, અને કોઈપણને એવું પૃષ્ઠ પીરસવું જે બદલાઈ જવું જોઈતું હતું. બંને કેશીંગ સ્તરે ઉકેલાય છે, નહીં કે ઓછું કેશ કરીને.
ESI (Edge Side Includes) આપણને પૃષ્ઠને કૅશ કરવાની મંજૂરી આપે છે અને સાથે જ જે ભાગો લાઇવ રહેવા જરૂરી છે તેના માટે જગ્યા બનાવે છે. WooCommerce સ્ટોર પર ઝડપી સંભવિત TTFB માટે કૅટેલૉગ, ઉત્પાદન અને શ્રેણીના પૃષ્ઠો સંપૂર્ણ-પૃષ્ઠ કૅશ તરીકે સેવા આપે છે, જ્યારે ESI પ્રત્યેક વિનંતી દીઠ કાર્ટનો ભાગ, મિની-કાર્ટનો સરવાળો અને એકાઉન્ટની સ્થિતિ પ્રદર્શિત કરે છે. કાર્ટ, ચેકઆઉટ, મારું એકાઉન્ટ અને કોઈપણ nonce અથવા સત્ર પૃષ્ઠો ડિફૉલ્ટ રૂપે બાકાત રાખવામાં આવ્યા છે. ખરીદદારો હંમેશાં પોતાની બાસ્કેટ અને કાર્યરત ચેકઆઉટ જુએ છે; દરેકને હજી પણ સ્ટોરફ્રન્ટ કૅશમાંથી જ મળે છે.
તાજગીનું સંચાલન સ્માર્ટ ઑટો-પર્જ દ્વારા કરવામાં આવે છે. જ્યારે સામગ્રી, ઉત્પાદનો, કિંમતો અથવા ઓર્ડરમાં ફેરફાર થાય છે ત્યારે પર્જ હુક્સ આપમેળે સક્રિય થાય છે, જેથી સંબંધિત કૅશ્ડ પૃષ્ઠો ટાઈમરને બદલે તરત જ રિફ્રેશ થાય છે, અને તમે ડૅશબોર્ડ પરથી અથવા WordPress ની અંદરથી પણ માંગ મુજબ પર્જ કરી શકો છો. ટૅગ-આધારિત પર્જિંગનો અર્થ એ છે કે એક પોસ્ટને સંપાદિત કરવાથી તે પોસ્ટ અને તેના આર્કાઇવ્સ સાફ થાય છે — સમગ્ર કૅશ નહીં — જેથી એક જ સંપાદન આખી સાઇટને કોલ્ડ-સ્ટાર્ટ કરતું નથી.
પ્રતિ-સાઇટ Redis ઑબ્જેક્ટ કેશ: જે સંપૂર્ણ પૃષ્ઠ ન હોઈ શકે તેના માટે
દરેક વિનંતી સ્થિર સંપૂર્ણ પૃષ્ઠ હોઈ શકતી નથી. લૉગ-ઇન સત્રો, WordPress એડમિન, WooCommerce કાર્ટ્સ, શોધ અને ESI જીવંત છોડે છે તે ગતિશીલ ટુકડાઓ આ બધાએ PHP ચલાવવી પડે છે. તેમના માટે, ધ્યેય 'એપ્લિકેશન છોડો' થી 'ડેટાબેઝ છોડો' પર બદલાય છે.
દરેક સાઇટને પોતાનું સમર્પિત Redis ઑબ્જેક્ટ કૅશ મળે છે. WordPress વારંવાર ડેટાબેઝ વાંચવાના પરિણામો — વિકલ્પો, ક્ષણિક ડેટા (transients), પોસ્ટ અને શબ્દ શોધ, WooCommerce ઉત્પાદન અને સત્ર ડેટા — ને મેમરીમાં કૅશ કરે છે, જેથી દરેક મુલાકાત વખતે MySQL પર એક જ ક્વેરી ફરીથી ચલાવવામાં ન આવે. આ અસર ખાસ કરીને ત્યાં વધુ સ્પષ્ટ દેખાય છે જ્યાં પૂર્ણ-પૃષ્ઠ કૅશ મદદ કરી શકતું નથી: ઝડપી ડેશબોર્ડ્સ, ઝડપી કાર્ટ્સ અને ટ્રાફિક દરમિયાન ડેટાબેઝ પર નોંધપાત્ર રીતે ઓછો લોડ.
ઑબ્જેક્ટ કૅશ દરેક સાઇટ દીઠ હોય છે, શેર કરેલી નથી હોતી, જે પ્રદર્શન અને આઇસોલેશન બંને માટે મહત્વપૂર્ણ છે. સાઇટ દીઠ ડેટાબેઝ થ્રોટલિંગ સાથે મળીને, એક સાઇટની ભારે અથવા ખરાબ રીતે લખાયેલી ક્વેરીઝ તેના પડોશીઓ માટે ડેટાબેઝના સંસાધનોને અવરોધિત કરી શકતી નથી. સમગ્ર મલ્ટિ-લેયર સેટઅપ કેવી રીતે કાર્ય કરે છે તે વિશે તમે અમારા કૅશિંગ ફીચર પેજ પર અને આઇસોલેશન હેઠળ વપરાશકર્તાઓ વચ્ચેની સીમાઓ વિશે વધુ વાંચી શકો છો.
એજ અને તેની નીચેનું પરિવહન
ઓરિજિન સર્વર પર રહેલા કૅશને પણ નેટવર્ક પાર કરવું પડે છે. સર્વરની આગળ CDN એજ હોય છે, જેથી સ્ટેટિક એસેટ્સ અને કૅશ કરી શકાય તેવા પેજીસ મુલાકાતીની નજીકના પોઇન્ટ ઓફ પ્રેઝન્સ પરથી પૂરા પાડવામાં આવે છે, અને વધુ લોડ હેઠળ પણ ઓરિજિન શાંત રહે છે. અમારી ફૂટપ્રિન્ટ-ફ્રી હોસ્ટિંગ લાઇન માટે આ જ એજ એ ઘણા પ્રદાતાઓ વચ્ચે વહેંચાયેલું મલ્ટી-CDN પૂલ છે, જે પરફોર્મન્સની સાથે સાથે સર્ચ એન્જિન ફૂટપ્રિન્ટના લક્ષ્યને પણ પૂર્ણ કરે છે; સામાન્ય WordPress પર તે માત્ર એક ઝડપી, સુવ્યવસ્થિત લેયર છે જે ઓરિજિન સર્વર્સને નિષ્ક્રિય રાખે છે.
આંતરિક રીતે, મૂળભૂત બાબતોમાં કોઈ કસર છોડવામાં આવી નથી. સાઇટ્સ HTTP/3 સાથે NVMe સ્ટોરેજ પર ચાલે છે, જેથી કૅશ દ્વારા મોકલવામાં આવતા બાઇટ્સ આધુનિક, મલ્ટિપ્લેક્સ્ડ ટ્રાન્સપોર્ટ દ્વારા પહોંચે છે અને કોઈપણ કૅશ મિસ પાછળ ઝડપી સ્ટોરેજ રહે છે. આમાંનું કોઈપણ સ્તર ઍડ-ઑન નથી: LiteSpeed, LSCache, સાઇટ-દીઠ Redis, NVMe અને HTTP/3 એ દરેક પ્લાનનો પાયો છે, કોઈ અપસેલ ટિયર નથી.
ખરેખર Core Web Vitals ને શું અસર કરે છે
ચોક્કસ હોવું જરૂરી છે, કારણ કે હોસ્ટિંગને ઘણીવાર Core Web Vitals પર વધુ પડતું પ્રમોટ કરવામાં આવે છે. TTFB એ સમીકરણનો એવો ભાગ છે જે સર્વરને આધીન છે, અને ઉપરોક્ત કેશિંગ સ્ટેક તેને ઘટાડે છે — એજ પરથી HTTP/3 દ્વારા પીરસવામાં આવેલું કેશ કરેલું સંપૂર્ણ પૃષ્ઠ TTFB ને શક્ય તેટલું નીચું લાવે છે. TTFB એ Largest Contentful Paint ની શરૂઆત હોવાથી, ઝડપી મૂળ દરેક ડાઉનસ્ટ્રીમ મેટ્રિકને એવી શરૂઆત આપે છે જે તે અન્યથા મેળવી શકતું નથી.
પરંતુ LCP, CLS અને INP મોટાભાગે બ્રાઉઝરમાં, પેજ દ્વારા જ નક્કી થાય છે: ઑપ્ટિમાઇઝ ન કરેલી હીરો ઇમેજ, રેન્ડર-બ્લોકિંગ CSS અને JavaScript, ફોન્ટ્સ અને જાહેરાતો લોડ થતાં બદલાતું લેઆઉટ, અને પ્લગઇન્સ તરફથી ભારે મુખ્ય-થ્રેડ વર્ક. સર્વર કેશિંગની કોઈ પણ માત્રા 2 MB ની હીરો ઇમેજ અથવા મેગાબાઇટ્સ JavaScript લોડ કરતી થીમને ઠીક કરી શકતી નથી. પ્રામાણિક હોસ્ટિંગ સર્વરના યોગદાનને અસરકારક રીતે નહિવત અને સુસંગત બનાવે છે, પછી ફ્રન્ટ એન્ડને હળવું રાખવું એ સાઇટ પર નિર્ભર છે.
શ્રમનું આ વિભાજન એ ઉપયોગી માનસિક મોડેલ છે. અમે ખાતરી આપીએ છીએ કે વિનંતી બ્રાઉઝર સુધી ઝડપથી પહોંચે અને ટ્રાફિક હેઠળ પણ ઝડપી રહે; તમે પેલોડને નાનો અને સ્થિર રાખો છો. જ્યાં આ બંને મળે છે — કેશ વોર્મ-અપ, એજ ડિલિવરી, અને ડેટાબેઝને પ્રતિભાવશીલ રાખવો જેથી ડાયનેમિક પેજીસ અટકી ન જાય — ત્યાં જ અમારો સ્ટેક ચોક્કસપણે ટ્યુન થયેલ છે, અને તે જ આ પ્લેટફોર્મ પર મેનેજ્ડ WordPress ને સામાન્ય હોસ્ટ પરની એ જ સાઇટ કરતાં વધુ ઝડપી બનાવે છે.
વારંવાર પૂછાતા પ્રશ્નો
શું મારે હજુ પણ WP Rocket જેવા કેશીંગ પ્લગઇનની જરૂર છે?
ના. પૂર્ણ-પૃષ્ઠ કેશીંગ વેબ સર્વર પર LiteSpeed ના LSCache દ્વારા સંચાલિત થાય છે, અને અમારું પોતાનું કેશ પ્લગઇન — પૂર્વ-સ્થાપિત અને આપમેળે અપડેટ થયેલું — WordPress ને તેની સાથે યોગ્ય રીતે જોડે છે, જેની પાછળ દરેક-સાઇટ માટે Redis ઑબ્જેક્ટ કેશ હોય છે. તેની ઉપર બીજું પૂર્ણ-પૃષ્ઠ કેશીંગ પ્લગઇન ઉમેરવું સામાન્ય રીતે મદદ કરવાને બદલે સર્વર-સ્તરના કેશ સાથે સંઘર્ષ કરે છે, તેથી તેની જરૂર નથી અને તેની ભલામણ કરવામાં આવતી નથી.
શું કેશિંગ મારી WooCommerce કાર્ટ અથવા લૉગ-ઇન કરેલા પૃષ્ઠોને બગાડશે?
ના. કાર્ટ, ચેકઆઉટ, my-account અને કોઈપણ nonce અથવા સત્ર પૃષ્ઠો ડિફૉલ્ટ રૂપે કૅશમાંથી બાકાત રાખવામાં આવ્યા છે, અને ESI અન્યથા-કૅશ થયેલા પૃષ્ઠો પર કાર્ટ ફ્રેગમેન્ટ અને કુલ રકમ લાઇવ રાખે છે. સ્ટોરફ્રન્ટ હજી પણ કૅશમાંથી લોડ થાય છે ત્યારે ખરીદદારો હંમેશા તેમની પોતાની બાસ્કેટ અને કાર્યરત ચેકઆઉટ જુએ છે.
જ્યારે હું પ્રકાશિત અથવા સંપાદિત કરું ત્યારે કૅશ કેવી રીતે તાજી રહે છે?
સ્માર્ટ ઑટો-પર્જ સુસંગત WordPress હુક્સ પર કાર્ય કરે છે, તેથી સામગ્રી પ્રકાશિત કરવી, સંપાદિત કરવી, અથવા કોઈ ઉત્પાદન, કિંમત કે ઑર્ડરમાં ફેરફાર કરવાથી માત્ર અસરગ્રસ્ત પૃષ્ઠો અને તેમના આર્કાઇવ્સ સાફ થાય છે — સમગ્ર કેશ નહીં — અને ક્રાઉલર તેમને ફરીથી વોર્મ કરે છે. તમે ડેશબોર્ડ પરથી અથવા WordPress ની અંદરથી પણ જરૂરિયાત મુજબ પર્જ કરી શકો છો.
શું માત્ર હોસ્ટિંગ જ મને સંપૂર્ણ Core Web Vitals આપી શકે છે?
તે તમને શ્રેષ્ઠ સંભવિત TTFB આપે છે, જે સર્વરનો હિસ્સો છે અને Largest Contentful Paint માટે શરૂઆતનો ફાયદો છે. પરંતુ LCP, CLS અને INP મોટાભાગે પેજ દ્વારા જ નક્કી થાય છે — ઈમેજના કદ, રેન્ડર-બ્લોકિંગ એસેટ્સ, લેઆઉટ સ્થિરતા અને મુખ્ય-થ્રેડ JavaScript. અમારો સ્ટેક સર્વરના યોગદાનને ઝડપી અને સુસંગત બનાવે છે; ફ્રન્ટ-એન્ડ પેલોડને હલકો રાખવો એ બાકીના તફાવતને પૂર્ણ કરે છે.
સંબંધિત
તેને ૧૪ દિવસ માટે મફતમાં અજમાવો
તમારી પ્રથમ સાઇટ્સ ૧૪ દિવસ માટે મફતમાં શરૂ કરો — કોઈ કાર્ડની જરૂર નથી. અગાઉથી અસ્તિત્વમાં રહેલા નેટવર્કને ખસેડી રહ્યા છો? સ્થળાંતરણ કોઈપણ મર્યાદા વિના તદ્દન મફત છે.
મફતમાં શરૂ કરો