ሆስቲንግ እና አፈጻጸም
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 cache-control እና በtag ራስጌዎች ያትመዋል፣ እንዲሁም LiteSpeed በቀጣዩ ጥያቄ ላይ ሙሉውን ገጽ በቀጥታ ያቀርባል — ምንም የPHP ሂደት አይፈጠርም፣ ምንም የMySQL መጠይቅ አይሰጥም። ይህ አጠቃላይ የመተግበሪያ ማስነሳትን ከተደጋጋሚ የሂደት መስመር ስለሚያስወግድ፣ በWordPress TTFB ላይ ትልቁ ተጽዕኖ ፈጣሪ እርምጃ ነው።
LSCache በ PHP ተሰኪ ውስጥ ሳይሆን በድር አገልጋዩ ውስጥ ስለሚገኝ፣ በጥያቄው የሕይወት ዑደት ውስጥ ቀደም ብሎ መሥራት ይጀምራል እና አገልጋዩ ገጾችን ወዲያውኑ ማጽዳት በሚችልበት መልኩ ይይዛል። የሸጎጥ መፈለጊያ (cache crawler) ታዋቂ ገጾችን ዝግጁ አድርጎ ስለሚጠብቅ፣ ከመጣሉ በኋላ የሚመጣ የመጀመሪያው ጎብኚ ገጹን እንደገና ለማመንጨት የሚከፍል አይሆንም። ውጤቱም መሸጎጫው አሁንም ከ PHP ጀርባ በሚቀመጥበት፣ በባህላዊ መደራረብ ላይ ከተጣበቀ በተሰኪ-ብቻ መሸጎጫ ጋር ሲነጻጸር በእጅጉ ዝቅተኛ እና ይበልጥ ወጥ የሆነ TTFB ነው።
የራሳችን የመረጃ ቋት ደረጃ ያለው የካሽ ፕለጊን በእያንዳንዱ ድረ-ገጽ ላይ ቀድሞ ተጭኖ እና በራስ-ሰር እየተዘመነ የሚቀርብ ሲሆን ይህም WordPressን ከLSCache ጋር ከመጀመሪያው ጀምሮ በትክክል ያገናኛል። LiteSpeed ባልሆነ መነሻ ላይ ሙሉ ገጽ ራስጌዎችን አያወጣም እና መንገድ ይለቃል፣ ነገር ግን የነገር ካሽ እና የማግለያ ደንቦች ስራቸውን መስራታቸውን ይቀጥላሉ — ስለዚህ የተዛወረ ድረ-ገጽ ፈጽሞ በተበላሸ በከፊል የተዋቀረ ሁኔታ ውስጥ አይቀርም።
ያረጀ ይዘት ሳያቀርቡ ፈጣን ሆኖ መቆየት፦ ESI እና ብልህ ራስ-ሰር ማጽዳት
አስገዳጅ የሙሉ ገጽ መሸጎጫ ሁለት የተለመዱ የስህተት ሁነታዎች አሉት፡ ለገባ ተጠቃሚ የሌላ ሰውን ገጽ ማሳየት፣ እና ለማንኛውም ሰው መለወጥ የነበረበትን ገጽ ማሳየት። ሁለቱም መሸጎጥን በመቀነስ ሳይሆን በመሸጎጫው ንብርብር ላይ መፍትሔ ያገኛሉ።
ESI (Edge Side Includes) ገጹን መሸጎጥ ሲያስችለን፣ ቀጥታ መቆየት ላለባቸው ክፍሎች ግን ክፍተቶችን እንድንፈጥር ይረዳናል። በWooCommerce መደብር ላይ ለፈጣን TTFB ካታሎጉ፣ የምርት እና የምድብ ገጾች እንደ ሙሉ-ገጽ መሸጎጫ ሆነው ይቀርባሉ፤ በዚያው ወቅት ESI ለእያንዳንዱ ጥያቄ የጋሪውን ቁራጭ፣ አነስተኛ የጋሪ ድምርን እና የመለያውን ሁኔታ ያቀርባል። ጋሪ፣ ቼክአውት፣ የእኔ መለያ እና ማንኛውም የnonce ወይም የsession ገጾች በነባሪነት አይካተቱም። ገዢዎች ሁልጊዜ የራሳቸውን ቅርጫት እና የሚሰራ ቼክአውት ይመለከታሉ፤ ሁሉም ሰው የመደብሩን ገጽ ከመሸጎጫ ማግኘቱን ይቀጥላል።
አዲስነት የሚተዳደረው በብልህ ራስ-ሰር ማጽዳት (auto-purge) ነው። ይዘት፣ ምርቶች፣ ዋጋዎች ወይም ትዕዛዞች ሲለወጡ የማጽጃ መንጠቆዎች (purge hooks) በራስ-ሰር ይሰራሉ፣ ስለዚህ አግባብነት ያላቸው የተሸጎጡ ገጾች በሰዓት ቆጣሪ ሳይሆን ወዲያውኑ ይታደሳሉ፤ እንዲሁም ከዳሽቦርዱ ወይም ከWordPress ውስጥ ሆነው እንደፍላጎትዎ ማጽዳት ይችላሉ። በመለያዎች ላይ የተመሠረተ ማጽዳት ማለት አንድን ጽሁፍ ማርትዕ ያንን ጽሁፍ እና ማህደሮቹን ብቻ ያጸዳል—ሙሉ መሸጎጫውን አይደለም—ስለዚህ አንድ ነጠላ አርትዖት መላውን ድረ-ገጽ እንደ አዲስ እንዲጀምር (cold-start) አያደርገውም።
ለእያንዳንዱ ድረ-ገጽ የRedis የነገር መሸጎጫ፦ ሙሉ ገጽ መሆን ለማይችለው
እያንዳንዱ ጥያቄ የማይንቀሳቀስ ሙሉ ገጽ ሊሆን አይችልም። የገቡ ክፍለ-ጊዜዎች፣ የ WordPress አስተዳዳሪ፣ የ WooCommerce ጋሪዎች፣ ፍለጋ እና ESI በቀጥታ የሚተዋቸው ተለዋዋጭ ክፍሎች በሙሉ PHP ማሄድ አለባቸው። ለእነዚያ፣ ግቡ 'መተግበሪያውን መዝለል' ከሚለው ወደ 'የውሂብ ጎታውን መዝለል' ይቀየራል።
እያንዳንዱ ጣቢያ የራሱ የሆነ ራሱን የቻለ የ Redis ነገር መሸጎጫ (object cache) ያገኛል። WordPress በተደጋጋሚ የሚነበቡ የውሂብ ጎታ ውጤቶችን — ምርጫዎችን፣ ጊዜያዊ መረጃዎችን (transients)፣ የጽሁፍ እና የቃላት ፍለጋዎችን፣ የ WooCommerce ምርት እና የክፍለ-ጊዜ (session) ውሂብን — በማህደረ ትውስታ (memory) ውስጥ ይሸጉጣል፣ ስለዚህ ተመሳሳይ ጥያቄ በእያንዳንዱ ጉብኝት ወቅት በ MySQL ላይ አይተገበርም። ውጤቱ ሙሉ-ገጽ መሸጎጫ ሊረዳ በማይችልበት ቦታ ላይ በግልጽ ይታያል፦ ፈጣን ዳሽቦርዶች፣ ፈጣን የግዢ ጋሪዎች፣ እና በትራፊክ ወቅት እጅግ በጣም ዝቅተኛ የሆነ የውሂብ ጎታ ጭነት።
የነገር መሸጎጫው ለእያንዳንዱ ድረ-ገጽ የተለየ እንጂ የሚጋራ አይደለም፣ ይህም ለአፈጻጸምም ሆነ ለብቻ መለየት አስፈላጊ ነው። ለእያንዳንዱ ድረ-ገጽ ከሚደረግ የውሂብ ጎታ ገደብ ጋር ተዳምሮ የአንድ ድረ-ገጽ ከባድ ወይም በትክክል ያልተጻፉ መጠይቆች ለጎረቤቶቹ የሚሆን የውሂብ ጎታ ሀብት እንዳያጥሩ ያደርጋል። አጠቃላይ ባለብዙ ንብርብር ቅንብር እንዴት አብሮ እንደሚሰራ በመሸጎጫ ባህሪ ገጻችን ላይ እና በተከራዮች መካከል ስላለው ወሰን ደግሞ በመገለል ክፍል ስር የበለጠ ማንበብ ይችላሉ።
ዳርቻው እና ከስሩ ያለው ማጓጓዣ
በመነሻው አገልጋይ ላይ የሚቀመጥ መሸጎጫ አሁንም አውታረ መረቡን ማቋረጥ አለበት። ከአገልጋዩ ፊት ለፊት የሲዲኤን (CDN) ጠርዝ ይገኛል፣ ስለዚህ የማይለዋወጡ ሀብቶች እና ሊሸጎጡ የሚችሉ ገጾች ለጎብኚው ቅርብ ከሆነ የይዘት ማሰራጫ ነጥብ ይቀርባሉ፣ እና መነሻው በከፍተኛ ጫና ውስጥም እንኳ ዝም ብሎ ይቆያል። ለእኛ ከዱካ-ነጻ (footprint-free) የማስተናገጃ መስመር፣ ይኸው ጠርዝ በበርካታ አቅራቢዎች የተዘረጋ የባለብዙ-ሲዲኤን (multi-CDN) ስብስብ ሲሆን፣ ይህም የአፈጻጸምን ያህል የፍለጋ ሞተር ዱካ ግብንም ያገለግላል፤ በመደበኛ WordPress ላይ ደግሞ መነሻዎችን ስራ ፈት አድርጎ የሚያቆይ ፈጣን እና በሚገባ የሚሰራ ንብርብር ብቻ ነው።
በመሰረቱ፣ ዋና ዋናዎቹ ነገሮች አልተጓደሉም። ጣቢያዎች በNVMe ማከማቻ እና በHTTP/3 የሚሰሩ በመሆናቸው መሸጎጫው (cache) የሚልካቸው ባይቶች በማናቸውም የመሸጎጫ እጦት (cache miss) ጀርባ ፈጣን ማከማቻ ባለው ዘመናዊ እና የተባዛ የማጓጓዣ ስርዓት ይደርሳሉ። ከእነዚህ ንብርብሮች መካከል አንዳቸውም ተጨማሪ ክፍያ የሚጠይቁ አይደሉም፦ LiteSpeed፣ LSCache፣ ለእያንዳንዱ ጣቢያ የሚሆን Redis፣ NVMe እና HTTP/3 በእያንዳንዱ እቅድ ውስጥ መሰረታዊ ነገሮች ናቸው እንጂ ተጨማሪ መሸጫ አይደሉም።
በእርግጥ Core Web Vitals የሚያሻሽለው ምንድን ነው
ትክክለኛ መሆን ተገቢ ነው፣ ምክንያቱም ሆስቲንግ ብዙ ጊዜ በ Core Web Vitals ላይ ከመጠን በላይ ይጋነናል። TTFB አገልጋዩ ኃላፊነት የሚወስድበት የቀመር ክፍል ነው፣ እና ከላይ ያለው የካሺንግ ቁልል ነው እንዲቀንስ የሚያደርገው — ከዳርቻው በ HTTP/3 የሚቀርብ የተሸጎጠ ሙሉ ገጽ TTFB ሊደርስበት የሚችለው ዝቅተኛው ደረጃ ነው። TTFB የ Largest Contentful Paint መሪ ጫፍ ስለሆነ፣ ፈጣን መነሻ ለእያንዳንዱ ተከታይ መለኪያ በሌላ መንገድ ሊኖረው የማይችለውን ቅድመ ሁኔታ ይሰጠዋል።
ነገር ግን LCP፣ CLS እና INP በአብዛኛው የሚወሰኑት በአሳሹ ውስጥ፣ በገጹ ራሱ ነው፦ ያልተመቻቸ የhero ምስል፣ አተረጓጎምን የሚያግድ CSS እና JavaScript፣ ቅርጸ-ቁምፊዎች እና ማስታወቂያዎች ሲጫኑ የሚቀያየር አቀማመጥ፣ እና ከተሰኪዎች የሚመጣ ከባድ የዋናው ክር (main-thread) ስራ። ምንም ያህል የአገልጋይ መሸጎጫ (server caching) የ2 ሜጋባይት hero ምስልን ወይም ሜጋባይት የሚቆጠር JavaScript የሚያቀርብን ጭብጥ ሊያስተካክል አይችልም። እውነተኛ አስተናጋጅነት የአገልጋዩን አስተዋፅኦ በተጨባጭ ነጻ እና ወጥ ያደርገዋል፤ ከዚያ በኋላ የፊት ለፊቱን ክፍል (front end) ቀላል አድርጎ ማቆየት የጣቢያው ኃላፊነት ነው።
ያ የሥራ ክፍፍል ጠቃሚ የአስተሳሰብ ሞዴል ነው። ጥያቄው አሳሹን በፍጥነት እንዲደርስ እና በትራፊክ መጨናነቅ ወቅትም ፈጣን ሆኖ እንዲቆይ ዋስትና እንሰጣለን፤ እርስዎ ደግሞ የይዘቱን መጠን አነስተኛ እና የተረጋጋ እንዲሆን ያደርጋሉ። ሁለቱ የሚገናኙበት ቦታ — የሸጎጥ ማሞቅ፣ የዳርቻ ማድረስ እና ተለዋዋጭ ገጾች እንዳይዘገዩ የውሂብ ጎታውን ምላሽ ሰጪ አድርጎ ማቆየት — የእኛ ቴክኖሎጂ በትክክል የተስተካከለበት ቦታ ሲሆን፣ በዚህ መድረክ ላይ የሚተዳደር WordPress በተለመደው አስተናጋጅ ላይ ካለ ተመሳሳይ ጣቢያ የበለጠ ፈጣን እንዲሆን የሚያደርገውም ይኸው ነው።
ተደጋግመው የሚጠየቁ ጥያቄዎች
አሁንም እንደ WP Rocket ያለ የማከማቻ ተሰኪ ያስፈልገኛል?
አይ። የሙሉ ገጽ መሸጎጫ (Full-page caching) በድር አገልጋዩ ላይ በLiteSpeed LSCache የሚስተናገድ ሲሆን፣ አስቀድሞ የተጫነው እና በራስ-ሰር የሚዘምነው የራሳችን የመሸጎጫ ፕለጊን WordPressን ከእሱ ጋር በትክክል ያገናኘዋል፤ ከበስተጀርባው ደግሞ ለእያንዳንዱ ድረ-ገጽ የሚሆን የRedis ነገር መሸጎጫ (object cache) አለው። ሁለተኛ የሙሉ ገጽ መሸጎጫ ፕለጊን በላዩ ላይ መደራረብ ከመርዳት ይልቅ ከአገልጋይ-ደረጃ መሸጎጫ ጋር ስለሚጋጭ አያስፈልግም እንዲሁም አይመከርም።
መሸጎጥ (caching) የWooCommerce ጋሪዬን ወይም የገቡባቸውን ገጾች ያበላሻል?
አይ። የጋሪ፣ የክፍያ መፈጸሚያ፣ my-account እንዲሁም ማንኛውም የ-nonce ወይም የ-session ገጾች በነባሪነት ከመሸጎጫ (cache) ውጪ ይደረጋሉ፣ እና ESI በሌላ መልኩ በተሸጎጡ ገጾች ላይ የጋሪ ክፍሎችን እና ድምሮችን የቀጥታ ያደርጋቸዋል። መደብሩ አሁንም ከመሸጎጫ በሚጫንበት ጊዜ፣ ገዢዎች ሁልጊዜ የራሳቸውን ቅርጫት እና የሚሰራ የክፍያ መፈጸሚያ ያያሉ።
ሳሳትም ወይም ሳርትዕ መሸጎጫው እንዴት አዲስ ሆኖ ይቆያል?
ስማርት ራስ-ሰር ማጽዳት አግባብ በሆኑ የWordPress መንጠቆዎች ላይ ይሠራል፣ ስለዚህ ይዘትን ማተም፣ ማርትዕ ወይም ምርትን፣ ዋጋን ወይም ትዕዛዝን መለወጥ የተጎዱትን ገጾች እና ማህደሮቻቸውን ብቻ ያጸዳል—ሙሉውን መሸጎጫ አይደለም—እንዲሁም ክራውለር እንደገና ያዘጋጃቸዋል። እንዲሁም ከዳሽቦርዱ ወይም ከWordPress ውስጥ ሆነው እንደፍላጎትዎ ማጽዳት ይችላሉ።
ሆስቲንግ ብቻ ፍጹም Core Web Vitals ሊሰጠኝ ይችላል?
ይህ ለLargest Contentful Paint የአገልጋዩ ድርሻ እና ቅድመ ጅማሮ የሆነውን ምርጥ ሊሆን የሚችል TTFB ይሰጥዎታል። ነገር ግን LCP፣ CLS እና INP በብዛት በገጹ ራሱ ይወሰናሉ — የምስል መጠኖች፣ አተረጓጎምን የሚያግዱ ንብረቶች፣ የአቀማመጥ መረጋጋት እና የዋናው ክር JavaScript። የእኛ ስቴክ የአገልጋዩን አስተዋፅኦ ፈጣን እና ወጥ ያደርገዋል፤ የፊት-ለፊት ጭነትን መጠነኛ አድርጎ ማቆየት ቀሪውን ልዩነት የሚያጠብ ነው።
ተዛማጅ
ለ14 ቀናት በነጻ ይሞክሩት
የመጀመሪያ ድረ-ገጾችዎን ለ14 ቀናት በነጻ ያስጀምሩ — ካርድ አያስፈልግም። ያለዎትን ኔትወርክ ማዛወር ይፈልጋሉ? ፍልሰቶች ያለ ምንም ገደብ ነጻ ናቸው።
በነጻ ይጀምሩ