હોસ્ટિંગ અને પર્ફોર્મન્સ
અમે WordPress ને કેવી રીતે ઝડપી બનાવીએ છીએ: LiteSpeed Enterprise, LSCache અને પ્રતિ-સાઇટ Redis
સૌથી ઝડપી WordPress વિનંતી તે છે જે ક્યારેય રન થતી નથી — PHP કે MySQL શરૂ થાય તે પહેલાં અમારું સ્ટેક કેવી રીતે કેશમાંથી મોટાભાગની મુલાકાતોનો જવાબ આપે છે અને Core Web Vitals માટે તેનો શું અર્થ થાય છે તે અહીં છે.
સૌથી ઝડપી વિનંતી તે છે જે ક્યારેય ચાલતી નથી
એક સ્ટાન્ડર્ડ WordPress વિનંતી મોંઘી હોય છે. વેબ સર્વર PHP ને સોંપે છે, PHP WordPress ને બૂટ કરે છે, પ્લગઇન્સ ચલાવે છે, MySQL ને થોડી વાર ક્વેરી કરે છે, HTML એસેમ્બલ કરે છે, અને તે પછી જ બાઇટ્સ પાછા મોકલે છે. વ્યસ્ત સાઇટ પર તે પૂરી નૃત્ય દરેક મુલાકાતી માટે થાય છે, અને તે જ જગ્યાએ તમારા ટાઇમ-ટુ-ફર્સ્ટ-બાઇટનો લગભગ બધો જ સમય જાય છે.
આ અમારો જવાબ છે કે મોટાભાગની મુલાકાતો માટે, તેમાંથી કંઈપણ બિલકુલ થતું નથી. અમે હોસ્ટ કરીએ છીએ તે સાઇટ્સ પર — 100,000 થી વધુ PBN સાઇટ્સ ઉપરાંત મુખ્ય પ્રવાહના મેનેજ્ડ WordPress — ફ્રન્ટ-એન્ડ પેજ દૃશ્યોનો મોટો ભાગ PHP ને આમંત્રિત કર્યા વિના અથવા ડેટાબેઝને સ્પર્શ કર્યા વિના, કેશમાંથી સીધા જ પૂર્વ-રેન્ડર કરેલા સંપૂર્ણ પૃષ્ઠ તરીકે સેવા આપે છે. આ પોસ્ટનો બાકીનો ભાગ એ સ્તરો વિશે છે જે તેને સાચા બનાવે છે તે કેવી રીતે એકસાથે જોડાય છે, અને દરેક તેનું સ્થાન ક્યાં મેળવે છે.
મહત્વની સમજૂતી એ છે કે આ કોઈ સ્પર્ધાત્મક કેશ (caches) નથી જેની વચ્ચે તમારે પસંદગી કરવાની હોય. ફુલ-પેજ કેશ, ઑબ્જેક્ટ કેશ અને CDN એજ દરેક અલગ પ્રકારની રિક્વેસ્ટને હેન્ડલ કરે છે, અને આમાં મુખ્ય ફાયદો એ વાતનો છે કે તે કેવી રીતે એકબીજાને કામ સોંપે છે.
LiteSpeed Enterprise + LSCache: ફુલ-પેજ લેયર
દરેક સાઇટ સર્વર-સ્તરના LSCache સાથે LiteSpeed Enterprise પર ચાલે છે. જ્યારે ફ્રન્ટ-એન્ડ રિસ્પોન્સ કેશ કરવા યોગ્ય હોય છે, ત્યારે વેબ સર્વર તેને LiteSpeed કેશ-કંટ્રોલ અને ટેગ હેડર્સ સાથે સ્ટેમ્પ કરે છે, અને LiteSpeed આગામી હિટ પર સીધું જ આખું પૃષ્ઠ સર્વ કરે છે — કોઈ PHP પ્રક્રિયા સ્પૉન થતી નથી, કોઈ MySQL ક્વેરી જારી થતી નથી. WordPress TTFB પર તે સૌથી મોટું પરિબળ છે, કારણ કે તે હોટ પાથમાંથી સમગ્ર એપ્લિકેશન બૂટને દૂર કરે છે.
કેમ કે LSCache પીએચપી પ્લગઇનની અંદરને બદલે વેબ સર્વરની અંદર કામ કરે છે, તે રિક્વેસ્ટ લાઈફસાઇકલની શરૂઆતમાં જ કામ કરવાનું શરૂ કરી દે છે અને પૃષ્ઠોને એવા સ્વરૂપમાં રાખે છે જેને સર્વર તાત્કાલિક ફ્લશ કરી શકે. એક કેશ ક્રોલર લોકપ્રિય પૃષ્ઠોને ગરમ રાખે છે, જેથી પર્જ પછીનો પહેલો મુલાકાતી એવો નથી હોતો જેને પૃષ્ઠ ફરીથી જનરેટ કરવા માટે રાહ જોવી પડે. પરિણામ એ આવે છે કે સામાન્ય સ્ટેક પર લગાવેલા માત્ર પ્લગઇન કેશ (જ્યાં કેશ હજુ પણ પીએચપી પાછળ રહે છે) કરતાં TTFB નોંધપાત્ર રીતે નીચો અને વધુ સુસંગત રહે છે.
અમારી પોતાની રેપો-ગ્રેડ કેશ પ્લગઇન દરેક સાઇટ પર પ્રી-ઇન્સ્ટોલ અને ઓટો-અપડેટ થઈને આવે છે, જે WordPress ને LSCache સાથે બોક્સની બહાર યોગ્ય રીતે જોડે છે. બિન-LiteSpeed ઓરિજિન પર તે ફક્ત કોઈ ફુલ-પેજ હેડર્સ બહાર પાડતું નથી અને રસ્તામાંથી હટી જાય છે, જ્યારે ઓબ્જેક્ટ કેશ અને એક્સક્લુઝન નિયમો પોતાનું કામ ચાલુ રાખે છે — જેથી માઈગ્રેટ કરેલી સાઇટ ક્યારેય અધૂરી કન્ફિગર થયેલી તૂટેલી સ્થિતિમાં રહેતી નથી.
ઝડપી રહેવું પણ જૂનું ન પીરસવું: ESI અને સ્માર્ટ ઓટો-પર્જ
એગ્રેસિવ ફુલ-પેજ કેશિંગમાં બે પરંપરાગત નિષ્ફળતાના મોડ હોય છે: લૉગ ઇન થયેલા યુઝરને કોઈ બીજાનું પેજ બતાવવું, અને કોઈને પણ એવું પેજ બતાવવું જે બદલાઈ જવું જોઈએ. આ બંને સમસ્યાઓ ઓછું કેશ કરવાને બદલે કેશિંગ લેયર પર જ ઉકેલાય છે.
ESI (Edge Side Includes) આપણને લાઈવ રહેવાના ભાગો માટે છિદ્રો બનાવતી વખતે પેજને કેશ કરવાની મંજૂરી આપે છે. WooCommerce સ્ટોર પર કેટલોગ, પ્રોડક્ટ અને કેટેગરી પેજ સૌથી ઝડપી સંભવિત TTFB માટે ફૂલ-પેજ કેશ તરીકે સર્વ કરવામાં આવે છે, જ્યારે ESI દરેક વિનંતી દીઠ કાર્ટ ફ્રેગમેન્ટ, મિની-કાર્ટ ટોટલ્સ અને એકાઉન્ટ સ્ટેટ રેન્ડર કરે છે. કાર્ટ, ચેકઆઉટ, માય-એકાઉન્ટ અને કોઈપણ નોન્સ અથવા સેસન પેજ મૂળભૂત રીતે બાકાત રાખવામાં આવ્યા છે. ખરીદદારો હંમેશાં તેમની પોતાની બાસ્કેટ અને કામ કરતું ચેકઆઉટ જુએ છે; દરેક વ્યક્તિને હજુ પણ કેશમાંથી સ્ટોરફ્રન્ટ મળે છે.
ફ્રેશનેસ સ્માર્ટ ઓટો-પર્જ દ્વારા હેન્ડલ કરવામાં આવે છે. કન્ટેન્ટ, પ્રોડક્ટ્સ, કિંમતો અથવા ઓર્ડર બદલાય ત્યારે પર્જ હુક્સ આપમેળે થાય છે, જેથી સંબંધિત કેશ્ડ પેજ ટાઈમર પર નહીં પરંતુ તરત જ રિફ્રેશ થઈ જાય, અને તમે ડેશબોર્ડમાંથી અથવા WordPress ની અંદરથી પણ ઓન-ડિમાન્ડ પર્જ કરી શકો છો. ટૅગ-આધારિત પર્જિંગનો અર્થ એ છે કે એક પૉસ્ટ સંપાદિત કરવાથી તે પૉસ્ટ અને તેના આર્કાઇવ્સ સાફ થાય છે — આખો કેશ નહીં — જેથી એક જ સંપાદન આખી સાઇટને કોલ્ડ-સ્ટાર્ટ કરતું નથી.
પ્રતિ-સાઇટ Redis ઑબ્જેક્ટ કૅશ: જે સંપૂર્ણ પૃષ્ઠ ન હોઈ શકે તેના માટે
દરેક વિનંતી સ્થિર પૂર્ણ પૃષ્ઠ હોઈ શકતી નથી. લૉગ ઇન થયેલા સત્રો, WordPress એડમિન, WooCommerce કાર્ટ, શોધ અને ESI છોડેલા ડાયનેમિક ફ્રેગમેન્ટ્સ લાઈવ આ બધાએ PHP ચલાવવું જ પડશે. તેના માટે, 'એપ્લિકેશન છોડો' થી લક્ષ્ય બદલાઈને 'ડેટાબેઝ છોડો' પર જાય છે.
દરેક સાઈટને પોતાનું સમર્પિત Redis ઓબ્જેક્ટ કેશ મળે છે. WordPress પુનરાવર્તિત ડેટાબેઝ રીડ્સના પરિણામો — ઓપ્શન્સ, ટ્રાન્ઝિયન્ટ્સ, પોસ્ટ અને ટર્મ લુકઅપ્સ, WooCommerce પ્રોડક્ટ અને સેશન ડેટા — મેમરીમાં કેશ કરે છે, જેથી દરેક હિટ પર MySQL સામે એ જ ક્વેરી ચલાવવામાં ન આવે. પૂર્ણ-પૃષ્ઠ કેશ જ્યાં મદદ કરી શકતી નથી ત્યાં જ આ અસર સૌથી વધુ દેખાય છે: ઝડપી ડેશબોર્ડ્સ, ઝડપી કાર્ટ્સ અને ટ્રાફિક હેઠળ ઘણો ઓછો ડેટાબેઝ લોડ.
ઓબ્જેક્ટ કેશ પ્રતિ-સાઇટ છે, શેર કરેલ નથી, જે પરફોર્મન્સ અને આઇસોલેશન બંને માટે મહત્વપૂર્ણ છે. પ્રતિ-સાઇટ ડેટાબેઝ થ્રોટલિંગ સાથે મળીને, એક સાઇટની ભારે અથવા ખરાબ રીતે લખાયેલી ક્વેરીઝ તેના પાડોશીઓ માટે ડેટાબેઝને વંચિત રાખી શકતી નથી. આ સમગ્ર મલ્ટી-લેયર સેટઅપ કેવી રીતે કામ કરે છે તેના વિશે તમે અમારા કેશિંગ ફીચર પેજ પર વધુ વાંચી શકો છો, અને આઇસોલેશન હેઠળ ટેનન્ટ્સ વચ્ચેની સીમાઓ વિશે પણ જાણી શકો છો.
ધ એજ એન્ડ ધ ટ્રાન્સપોર્ટ અન્ડરનીથ
ઓરિજિન પર રહેલા કેશને પણ નેવરવર્ક ક્રોસ કરવો પડે છે. સર્વરની સામે CDN એજ આવેલું છે, જેથી સ્ટેટિક એસેટ્સ અને કેશ કરી શકાય તેવા પેજ મુલાકાતીની નજીકના પોઇન્ટ ઓફ પ્રેઝન્સથી સર્વ થાય છે, અને લોડ હેઠળ પણ ઓરિજિન શાંત રહે છે. અમારી ફૂટપ્રિન્ટ-ફ્રી હોસ્ટિંગ લાઇન માટે આ જ એજ અનેક પ્રોવાઇડર્સમાં ફેલાયેલું મલ્ટી-CDN પૂલ છે, જે પર્ફોર્મન્સની સાથે એસઇઓ ફૂટપ્રિન્ટના હેતુને પણ પૂરો કરે છે; મુખ્ય પ્રવાહના WordPress પર તે ફક્ત એક ઝડપી, સારી રીતે કામ કરતું લેયર છે જે ઓરિજિનને નિષ્ક્રિય રાખે છે.
નીચે, પાયાની બાબતોમાં કોઈ સમજૂતી નથી કરાઈ. સાઇટ્સ NVMe સ્ટોરેજ અને HTTP/3 પર ચાલે છે, જેથી કેશ જે બાઇટ્સ મોકલે છે તે કેશ મિસ થવા પર પણ ઝડપી સ્ટોરેજની સાથે આધુનિક, મલ્ટિપ્લેક્સ્ડ ટ્રાન્સપોર્ટ દ્વારા પહોંચે છે. આમાંથી કોઈ પણ લેયર એડ-ઓન નથી: 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 જેવા કેશિંગ પ્લગઇનની જરૂર છે?
નં. સંપૂર્ણ પૃષ્ઠ કેશિંગ (full-page caching) વેબ સર્વર પર LiteSpeed ના LSCache દ્વારા સંભાળવામાં આવે છે, અને અમારું પોતાનું કેશ પ્લગઇન - પ્રી-ઇન્સ્ટોલ કરેલું અને ઓટો-અપડેટ થયેલું - WordPress ને તેની સાથે યોગ્ય રીતે જોડે છે, જેની પાછળ પ્રતિ-સાઇટ Redis ઓબ્જેક્ટ કેશ હોય છે. તેની ઉપર બીજું સંપૂર્ણ પૃષ્ઠ કેશિંગ પ્લગઇન ઉમેરવાથી મદદ કરવાને બદલે સામાન્ય રીતે સર્વર-સ્તરના કેશ સાથે વિરોધ થાય છે, તેથી તેની જરૂર નથી અને તેની ભલામણ પણ કરવામાં આવતી નથી.
શું કેશિંગ (caching) મારા WooCommerce કાર્ટ અથવા લૉગ-ઇન કરેલા પૃષ્ઠોને બગાડશે?
ના. કાર્ત, ચેકઆઉટ, માય-એકાઉન્ટ અને કોઈપણ નોન્સ અથવા સેશન પેજ ડિફોલ્ટ રૂપે કેશમાંથી બાકાત રાખવામાં આવે છે, અને ESI અન્યથા કેશ કરેલા પેજ પર કાર્ત ફ્રેગમેન્ટ અને કુલ રકમ લાઇવ રાખે છે. ખરીદદારો જ્યારે સ્ટોરફ્રન્ટ હજુ પણ કેશમાંથી લોડ થઈ રહ્યું હોય ત્યારે હંમેશા તેમની પોતાની બાસ્કેટ અને કાર્યરત ચેકઆઉટ જુએ છે.
જ્યારે હું પ્રકાશિત કે સંપાદન કરું છું ત્યારે કેશ (cache) કેવી રીતે તાજું રહે છે?
સ્માર્ટ ઓટો-પર્જ સંબંધિત WordPress હુક્સ પર કામ કરે છે, જેથી કન્ટેન્ટ પબ્લિશ કરતી વખતે, સંપાદિત કરતી વખતે, અથવા કોઈ પ્રોડક્ટ, કિંમત કે ઓર્ડર બદલતી વખતે માત્ર અસરગ્રસ્ત પેજ અને તેના આર્કાઇવ્સ ક્લિયર થાય છે — આખો કેશ નહીં — અને એક ક્ર્રોલર તેને ફરીથી વોર્મ કરે છે. તમે ડેશબોર્ડમાંથી અથવા WordPress ની અંદરથી પણ માંગ પર પર્જ કરી શકો છો.
શું એકલું હોસ્ટિંગ મને પરફેક્ટ Core Web Vitals આપી શકે છે?
તે તમને શ્રેષ્ઠ સંભવિત TTFB આપે છે, જે સર્વરનો હિસ્સો છે અને Largest Contentful Paint માટે એક હેડ સ્ટાર્ટ છે. પરંતુ LCP, CLS અને INP મોટાભાગે પેજ પોતે જ નક્કી કરે છે — ઇમેજનું કદ, રેન્ડર-બ્લોકિંગ એસેટ્સ, લેઆઉટ સ્ટેબિલિટી અને મુખ્ય-થ્રેડ JavaScript. અમારું સ્ટેક સર્વર યોગદાનને ઝડપી અને સુસંગત બનાવે છે; ફ્રન્ટ-એન્ડ પેલોડને હલકો રાખવાથી બાકીની ખાધ પૂરી થાય છે.
સંબંધિત
૧૪ દિવસ માટે મફતમાં અજમાવો
તમારી પ્રથમ વેબસાઇટ્સ 14 દિવસ માટે મફતમાં શરૂ કરો — કોઈ કાર્ડ નહીં. કોઈ હાલનું નેટવર્ક ખસેડી રહ્યા છો? તમારું પ્રથમ માઈગ્રેશન અમારા તરફથી છે.
મફત શરૂ કરો