ការបង្ហោះ និងដំណើរការ
របៀបដែលយើងធ្វើឱ្យ WordPress មានល្បឿនលឿន៖ LiteSpeed Enterprise, LSCache និង Redis ក្នុងមួយគេហទំព័រ
សំណើ WordPress លឿនបំផុតគឺសំណើដែលមិនធ្លាប់ដំណើរការ — នេះជារបៀបដែលប្រព័ន្ធរបស់យើងឆ្លើយតបការចូលមើលភាគច្រើនពីឃ្លាំងសម្ងាត់ (cache) មុនពេល PHP ឬ MySQL ត្រូវបានហៅ ហើយវាមានន័យយ៉ាងណាសម្រាប់ Core Web Vitals ។
សំណើដែលលឿនបំផុត គឺជាសំណើដែលមិនធ្លាប់ដំណើរការ
សំណើ WordPress ស្តង់ដារគឺមានតម្លៃថ្លៃ។ សុវែរបើកគេហទំព័របញ្ជូនបន្តទៅ PHP, PHP បើកដំណើរការ WordPress, ដំណើរការកម្មវិធីជំនួយ, សួរទិន្នន័យ MySQL រាប់សិបដង, ប្រមូលផ្ដុំ HTML, ហើយទើបបញ្ជូនបដិភាគត្រឡប់មកវិញ។ នៅលើគេហទំព័រដែលមានការមមាញឹក ការដំណើរការទាំងអស់នោះកើតឡើងសម្រាប់អ្នកទស្សនាម្នាក់ៗ ហើយវាជាពេលដែលពេលវេលាទៅកាន់បដិភាគដំបូងរបស់អ្នកត្រូវចំណាយលើវា។
ចម្លើយរបស់យើងគឺធ្វើឱ្យប្រាកដថា សម្រាប់ការចូលមើលភាគច្រើន គឺមិនមានអ្វីកើតឡើងទាល់តែសោះ។ នៅតាមគេហទំព័រទាំងអស់ដែលយើងផ្តល់សេវាកម្ម host — គេហទំព័រ PBN ជាង 100,000 ព្រមទាំងគេហទំព័រគ្រប់គ្រងទូទៅ WordPress — ការចូលមើលទំព័រមុខភាគច្រើនបំផុតត្រូវបានបង្ហាញជាទំព័រពេញលេញដែលបានបង្កើតទុកជាមុនចេញពី cache ដោយផ្ទាល់ ដោយមិនបាច់ហៅ PHP ឬប៉ះពាល់ដល់ database ឡើយ។ ផ្នែកដែលនៅសល់នៃអត្ថបទនេះគឺនិយាយអំពីរបៀបដែលស្រទាប់នីមួយៗដែលធ្វើឱ្យចំណុចនេះក្លាយជាការពិតផ្គុំចូលគ្នា និងកន្លែងដែលស្រទាប់នីមួយៗទទួលបានតួនាទីរបស់វា។
ខេមរៈឃ្លាំងទំព័រពេញ ខេមរៈឃ្លាំងវត្ថុ និងប្រព័ន្ធ CDN edge មិនមែនជាឃ្លាំងទិន្នន័យដែលត្រូវប្រកួតប្រជែងគ្នានោះទេ ប៉ុន្តែពួកវាចាប់យកប្រភេទសំណើផ្សេងៗគ្នា ហើយតម្លៃរបស់វាគឺស្ថិតនៅលើរបៀបដែលពួកវាបញ្ជូនតគ្នាទៅវិញទៅមក។
LiteSpeed Enterprise + LSCache: កម្រិតទំព័រពេញ
គ្រប់គេហទំព័រទាំងអស់ដំណើរការលើ LiteSpeed Enterprise ជាមួយនឹង LSCache នៅកម្រិតម៉ាស៊ីនបម្រើ។ នៅពេលដែលការឆ្លើយតបផ្នែកខាងមុខអាចផ្ទុកក្នុងកែច្នៃបាន ម៉ាស៊ីនបម្រើវេបនឹងបិទត្រាវាជាមួយនឹងការគ្រប់គ្រងកែច្នៃ LiteSpeed និងក្បាលស្លាក ហើយ LiteSpeed នឹងផ្តល់ទំព័រពេញលេញដោយផ្ទាល់នៅពេលមានការចូលមើលលើកក្រោយ — ដោយមិនចាំបាច់ដំណើរការដំណើរការ PHP ឬសួរកម្រងទិន្នន័យ MySQL ឡើយ។ នោះគឺជាឧបករណ៍ដ៏ធំបំផុតតែមួយគត់នៅលើ WordPress TTFB ព្រោះវាដកចេញនូវការចាប់ផ្តើមកម្មវិធីទាំងមូលចេញពីផ្លូវសកម្ម។
ដោយសារតែ LSCache ស្ថិតនៅខាងក្នុងប្រព័ន្ធម៉ាស៊ីនបម្រើគេហទំព័រ ជាជាងនៅក្នុងកម្មវិធីជំនួយ PHP វាចាប់ផ្តើមដំណើរការមុនក្នុងវដ្តជីវិតសំណើ និងរក្សាទុកទំព័រក្នុងទម្រង់ដែលម៉ាស៊ីនបម្រើអាចបញ្ចេញភ្លាមៗ។ កម្មវិធីស្វែងរកឃ្លាំងសម្ងាត់ (cache crawler) រក្សាទំព័រពេញនិយមឱ្យនៅក្ដៅជានិច្ច ដូច្នេះអ្នកទស្សនាដំបូងបន្ទាប់ពីការសម្អាតទិន្នន័យ មិនមែនជាអ្នកដែលត្រូវចំណាយពេលបង្កើតទំព័រឡើងវិញនោះទេ។ លទ្ធផលគឺ TTFB ដែលមានកម្រិតទាបគួរឱ្យកត់សម្គាល់ និងមានភាពស៊ីសង្វាក់គ្នាជាងឃ្លាំងសម្ងាត់ដែលមានតែកម្មវិធីជំនួយ ដែលភ្ជាប់មកជាមួយស្តាកទូទៅ ដែលឃ្លាំងសម្ងាត់នៅតែស្ថិតនៅពីក្រោយ PHP ដដែល។
កម្មវិធីជំនួយ cache កម្រិត repo ផ្ទាល់ខ្លួនរបស់យើងត្រូវបានដំឡើងជាស្រេច និងធ្វើបច្ចុប្បន្នភាពដោយស្វ័យប្រវត្តិនៅលើគេហទំព័រនីមួយៗ ដោយភ្ជាប់ WordPress ទៅ LSCache យ៉ាងត្រឹមត្រូវភ្លាមៗតែម្តង។ នៅលើម៉ាស៊ីនបម្រើដើមដែលមិនមែនជា LiteSpeed វាគ្រាន់តែមិនបញ្ចេញ full-page headers ហើយចៀសផ្លូវ ចខណៈដែល object cache និងវិធាននៃការលើកលែងនៅតែបន្តធ្វើការងាររបស់ពួកគេ — ដូច្នេះគេហទំព័រដែលបានផ្លាស់ទីទីតាំងនឹងមិនត្រូវទុកចោលក្នុងស្ថានភាពខូចខាត ឬកំណត់រចនាសម្ព័ន្ធបានពាក់កណ្តាលនោះទេ។
រក្សាភាពលឿនដោយមិនប្រើទិន្នន័យចាស់៖ ESI និងការសម្អាតស្វ័យប្រវត្តិដ៏ឆ្លាតវៃ
ការឃ្លាំងទំព័រពេញលេញបែបឈ្លានពានមានកំហុសបរាជ័យបុរាណចំនួនពីរគឺ៖ ការផ្ដល់ទំព័ររបស់អ្នកដទៃដល់អ្នកប្រើប្រាស់ដែលបានចូលគណនី និងការផ្ដល់ទំព័រដែលគួរតែត្រូវបានផ្លាស់ប្ដូរដល់អ្នកណាម្នាក់។ បញ្ហាទាំងពីរនេះត្រូវបានដោះស្រាយនៅកម្រិតឃ្លាំងទំព័រ ជាជាងការកាត់បន្ថយការឃ្លាំង។
ESI (Edge Side Includes) អនុញ្ញាតឱ្យយើងរក្សាទុកទិន្នន័យបណ្តោះអាសន្ន (cache) នៃទំព័រ ព្រមទាំងរក្សាផ្នែកដែលត្រូវធ្វើបច្ចុប្បន្នភាពផ្ទាល់បានផងដែរ។ នៅលើហាង WooCommerce ទំព័របញ្ជីផលិតផល ផលិតផល និងប្រភេទ ត្រូវបានផ្តល់ជូនជា full-page cache ដើម្បីទទួលបាន TTFB លឿនបំផុតតាមដែលអាចធ្វើទៅបាន ខណៈពេលដែល ESI បង្ហាញផ្នែករទេះទំនិញ សរុបរទេះទំនិញតូច និងស្ថានភាពគណនីរាល់ពេលមានការស្នើសុំ។ ទំព័ររទេះទំនិញ ទំព័រទូទាត់ប្រាក់ គណនីរបស់ខ្ញុំ និងទំព័រ nonce ឬ session ផ្សេងទៀតត្រូវបានដកចេញតាមការកំណត់ដើម។ អ្នកទិញទំនិញតែងតែមើលឃើញកន្ត្រកទំនិញផ្ទាល់ខ្លួន និងទំព័រទូទាត់ប្រាក់ដែលដំណើរការបានល្អជានិច្ច ហើយអ្នកផ្សេងទៀតនៅតែទទួលបានទំព័រមុខហាងចេញពី cache ដដែល។
ភាពស្រស់ថ្មីនៃទិន្នន័យត្រូវបានគ្រប់គ្រងដោយមុខងារសម្អាតស្វ័យប្រវត្តិនៃប្រព័ន្ធឆ្លាតវៃ។ មុខងារសម្អាតស្វ័យប្រវត្តិនឹងដំណើរការដោយផ្ទាល់នៅពេលដែលមានការផ្លាស់ប្ដូរមាតិកា ផលិតផល តម្លៃ ឬការបញ្ជាទិញ ដូច្នេះទំព័រដែលបានរក្សាទុកក្នុងឃ្លាំងសម្ងាត់ពាក់ព័ន្ធនឹងធ្វើបច្ចុប្បន្នភាពភ្លាមៗ ដោយមិនចាំបាច់រង់ចាំតាមពេលកំណត់នោះទេ ហើយអ្នកក៏អាចសម្អាតតាមតម្រូវការពីផ្ទាំងគ្រប់គ្រង ឬពីខាងក្នុង WordPress បានផងដែរ។ ការសម្អាតផ្អែកលើស្លាក (Tag-based purging) មានន័យថា ការកែសម្រួលអត្ថបទមួយនឹងសម្អាតតែអត្ថបទនោះ និងប័ណ្ណសាររបស់វាប៉ុណ្ណោះ — មិនមែនឃ្លាំងសម្ងាត់ទាំងមូលនោះទេ — ដូច្នេះការកែសម្រួលតែមួយ មិនធ្វើឲ្យប៉ះពាល់ដល់ល្បឿនគេហទំព័រទាំងមូលឡើយ។
ឃ្លាំងសម្ងាត់វត្ថុ Redis តាមគេហទំព័រនីមួយៗ៖ សម្រាប់អ្វីដែលមិនអាចជាទំព័រពេញលេញ
មិនមែនរាល់សំណើទាំងអស់សុទ្ធតែអាចជាទំព័រស្ថិតិពេញលេញនោះទេ។ វគ្គដែលបានចូលប្រព័ន្ធ, ផ្នែកគ្រប់គ្រង WordPress, រទេះទំនិញ WooCommerce, ការស្វែងរក, និងបំណែកថាមវន្តដែល ESI ទុកចោលសុទ្ធតែត្រូវដំណើរការ PHP ទាំងអស់។ សម្រាប់កិច្ចការទាំងនោះ គោលដៅត្រូវប្តូរពី «រំលងកម្មវិធី» ទៅជា «រំលងមូលដ្ឋានទិន្នន័យ» វិញ។
គេហទំព័រនីមួយៗទទួលបាន Redis object cache ដែលមានបម្រុងទុកដាច់ដោយឡែកផ្ទាល់ខ្លួន។ WordPress រក្សាទុកលទ្ធផលនៃការអានទិន្នន័យដដែលៗពីទិន្នន័យផ្ទុក — ជម្រើស, transients, ការស្វែងរកប្រកាស និងពាក្យ, ផលិតផល និងទិន្នន័យសម័យកាលរបស់ WooCommerce — នៅក្នុងអង្គចងចាំ ដូច្នេះការសួរដូចគ្នានឹងមិនត្រូវដំណើរការទល់នឹង MySQL នៅរាល់ពេលមានការចូលមើលនោះទេ។ ប្រសិទ្ធភាពនេះត្រូវបានមើលឃើញច្បាស់បំផុតនៅត្រង់កន្លែងដែល full-page cache មិនអាចជួយបាន៖ ផ្ទាំងគ្រប់គ្រងដើរលឿនជាងមុន, រទេះទំនិញដើរលឿនជាងមុន, និងការថយចុះបន្ទុកយ៉ាងខ្លាំងលើទិន្នន័យផ្ទុកនៅពេលមានចរាចរណ៍ចូលមើលច្រើន។
ឃ្លាំងផ្ទុកទិន្នន័យបណ្តោះអាសន្ន (Object cache) គឺសម្រាប់តែគេហទំព័រនីមួយៗ ដោយមិនចែករំលែកគ្នាទេ ដែលចំណុចនេះមានសារៈសំខាន់ទាំងសម្រាប់ដំណើរការ និងភាពឯកោ។ រួមផ្សំជាមួយនឹងការកំណត់កម្រិតទិន្នន័យសម្រាប់គេហទំព័រនីមួយៗ សំណួរទិន្នន័យ (queries) ដែលធ្ងន់ធ្ងរ ឬសរសេរមិនបានល្អរបស់គេហទំព័រណាមួយ មិនអាចធ្វើឱ្យប្រព័ន្ធទិន្នន័យខ្វះខាតធនធានសម្រាប់គេហទំព័រជិតខាងបានឡើយ។ អ្នកអាចអានបន្ថែមអំពីរបៀបដែលការរៀបចំច្រើនស្រទាប់នេះរួមបញ្ចូលគ្នានៅលើទំព័រមុខងារឃ្លាំងផ្ទុកទិន្នន័យរបស់យើង និងអំពីព្រំដែនរវាងអ្នកជួល (tenants) ក្រោមលក្ខខណ្ឌឯកោ។
គែមនិងប្រព័ន្ធដឹកជញ្ជូននៅពីក្រោមវា
ឃ្លាំងសម្ងាត់ដែលស្ថិតនៅលើប្រភពនៅតែត្រូវឆ្លងកាត់បណ្តាញ។ នៅពីមុខម៉ាស៊ីនបម្រើគឺកម្រិតគែម CDN ដូច្នេះទ្រព្យសម្បត្តិឋិតិវន្ត និងទំព័រដែលអាចដាក់ឃ្លាំងសម្ងាត់ត្រូវបានបម្រើពីចំណុចវត្តមានដែលនៅជិតអ្នកទស្សនា ហើយប្រភពនៅតែស្ងាត់សូម្បីតែក្រោមទម្ងន់ផ្ទុកក៏ដោយ។ សម្រាប់បន្ទាត់បង្ហោះដែលគ្មាន footprint របស់យើង គែមដូចគ្នាគឺជា kumpulan multi-CDN ដែលរីករាលដាលពាសពេញអ្នកផ្តល់សេវាជាច្រើន ដែលបម្រើទាំងគោដៅ footprint និងដំណើរការមួយដែរ; នៅលើ WordPress ទូទៅ វាគ្រាន់តែជាស្រទាប់លឿន និងមានឥរិយាបថល្អ ដែលរក្សាប្រភពឱ្យនៅទំនេរ។
នៅផ្នែកខាងក្រោម គ្រឹះស្ថានទ្រទ្រង់គឺត្រូវបានយកចិត្តទុកដាក់យ៉ាងហ្មត់ចត់។ គេហទំព័រទាំងឡាយដំណើរការលើទំហំផ្ទុក NVMe ជាមួយ HTTP/3 ដូច្នេះ byte ដែល cache បញ្ជូនទៅ គឺមកដល់តាមរយៈប្រព័ន្ធដឹកជញ្ជូន multiplexed ដ៏ទំនើប ជាមួយនឹងទំហំផ្ទុកល្បឿនលឿននៅពីក្រោយការខកខាន cache ណាមួយ។ គ្មានស្រទាប់ណាមួយក្នុងចំណោមស្រទាប់ទាំងនេះជាមុខងារបន្ថែមនោះទេ៖ LiteSpeed, LSCache, Redis តាមគេហទំព័រ, NVMe និង HTTP/3 គឺជាកម្រិតមូលដ្ឋាននៅលើគ្រប់កញ្ចប់សេវាកម្ម មិនមែនជាកម្រិតសម្រាប់ការលក់ដំឡើងថ្លៃនោះទេ។
អ្វីដែលធ្វើឱ្យ Core Web Vitals ប្រែប្រួលពិតប្រាកដ
វាមានតម្លៃក្នុងការផ្ដល់ភាពជាក់លាក់ ពីព្រោះការបង្ហោះវែបសាយជារឿយៗត្រូវបានផ្សាយលើសពីការពិតនៅលើ Core Web Vitals។ TTFB គឺជាផ្នែកមួយដែលម៉ាស៊ីនបម្រើគ្រប់គ្រង ហើយប្រព័ន្ធឃ្លាំងសម្ងាត់នៅពីលើគឺជាកត្តាជំរុញឱ្យវាថយចុះ ដែលទំព័រពេញលេញត្រូវបានឃ្លាំងសម្ងាត់ និងបម្រើតាមរយៈ HTTP/3 ពីបណ្តាញគែម (edge) គឺប្រហែលជាកម្រិតទាបបំផុតដែល TTFB អាចទៅរួច។ ដោយសារ TTFB គឺជាកត្តាចម្បងនៃ Largest Contentful Paint នោះប្រភពដើមដែលមានល្បឿនលឿនផ្ដល់ឱ្យរាល់រង្វាស់ទឹកប្រាក់ខាងក្រោមនូវការចាប់ផ្ដើមលឿនជាងមុន ដែលមិនអាចទទួលបានតាមមធ្យោបាយផ្សេងឡើយ។
ប៉ុន្តែ LCP, CLS និង INP គឺភាគច្រើនត្រូវបានសម្រេចនៅក្នុងកម្មវិធីរុករក តាមរយៈទំព័រផ្ទាល់តែម្តង៖ រូបភាព hero ដែលមិនបានបង្កើនប្រសិទ្ធភាព, CSS និង JavaScript ដែលរាំងស្ទះការបង្ហាញ, ប្លង់ដែលផ្លាស់ប្តូរនៅពេលពុម្ពអក្សរ និងពាណិជ្ជកម្មផ្ទុកឡើង, និងការងារធ្ងន់ៗនៅលើ main-thread ចេញពីផ្លែកអ៉ិន។ គ្មានទំហំ caching របស់ម៉ាស៊ីនបម្រើណាអាចដោះស្រាយរូបភាព hero ទំហំ 2 MB ឬរូបរាងគេហទំព័រដែលបញ្ជូន JavaScript រាប់មេកាបៃបានឡើយ។ សេវាបង្ហោះគេហទំព័រដែលមានស្មោះត្រង់ គឺធ្វើឱ្យការរួមចំណែករបស់ម៉ាស៊ីនបម្រើមានប្រសិទ្ធភាព ដោយឥតគិតថ្លៃ និងមានស្ថិរភាព ហើយបន្ទាប់មកវាជាភារកិច្ចរបស់គេហទំព័រក្នុងការរក្សា front end ឱ្យស្រាល។
ការបែងចែកការងារនោះគឺជាគំរូផ្លូវចិត្តដ៏មានប្រយោជន៍។ យើងធានាថាសំណើទៅដល់កម្មវិធីរុករកយ៉ាងលឿន និងរក្សាភាពលឿនក្រោមចរាចរណ៍។ អ្នកត្រូវរក្សាទំហំទិន្នន័យឱ្យតូច និងមានស្ថេរភាព។ ចំនុចដែលទាំងពីរជួបគ្នា គឺការកម្តៅឃ្លាំងសម្ងាត់ ការបញ្ជូនតាមរយៈ edge delivery និងការរកឱ្យមូលដ្ឋានទិន្នន័យឆ្លើយតបយ៉ាងលឿនដើម្បីកុំឱ្យទំព័រឌីណាមិកគាំង គឺពិតជាកន្លែងដែលប្រព័ន្ធរបស់យើងត្រូវបានលៃតម្រូវ ហើយវាជាអ្វីដែលធ្វើឱ្យ WordPress ដែលបានគ្រប់គ្រងនៅលើវេទិកានេះមានលឿនជាងគេហទំព័រដដែលនៅលើម៉ាស៊ីនបម្រើទូទៅ។
សំណួរដែលសួរញឹកញាប់
តើខ្ញុំនៅតែត្រូវការកម្មវិធីជំនួយឃ្លាំងសម្ងាត់ដូចជា WP Rocket ដែរឬទេ?
ការរក្សាទុកទិន្នន័យក្នុងខាជបែបពេញទំព័រត្រូវបានគ្រប់គ្រងនៅលើម៉ាស៊ីនបម្រើបណ្ដាញដោយ LSCache របស់ LiteSpeed និងកម្មវិធីជំនួយឃ្លាំងសម្ងាត់ផ្ទាល់ខ្លួនរបស់យើង ដែលត្រូវបានដំឡើងទុកជាមុននិងអាប់ដេតដោយស្វ័យប្រវត្តិ ដែលភ្ជាប់ WordPress ទៅនឹងវាបានយ៉ាងត្រឹមត្រូវ ជាមួយឃ្លាំងសម្ងាត់វត្ថុ Redis ក្នុងមួយគេហទំព័រនៅពីក្រោយវា។ ការដាក់បញ្ចូលកម្មវិធីជំនួយឃ្លាំងសម្ងាត់ទំព័រពេញទីពីរនៅលើកំពូល ជាទូទៅគឺប៉ះទង្គិចជាមួយឃ្លាំងសម្ងាត់កម្រិតម៉ាស៊ីនបម្រើជំនួសឱ្យការជួយ ដូច្នេះវាគឺមិនចាំបាច់ និងមិនត្រូវបានណែនាំទេ។
តើឃ្លាំងសម្ងាត់ (caching) នឹងធ្វើឱ្យរទេះទំនិញ WooCommerce ឬទំព័រចូលគណបក្សរបស់ខ្ញុំមានបញ្ហាដែរឬទេ?
តាមលំនាំដើម គ្មានទំព័ររទេះទំនិញ ទូទាត់ប្រាក់ គណនីរបស់ខ្ញុំ និងទំព័រ nonce ឬ session ណាមួយត្រូវបានដាក់ក្នុងឃ្លាំងសម្ងាត់ឡើយ ហើយ ESI រក្សាផ្នែករទេះទំនិញ និងតម្លៃសរុបឱ្យដំណើរការនៅលើទំព័រដែលបានដាក់ក្នុងឃ្លាំងសម្ងាត់។ អ្នកទិញតែងតែឃើញកន្ត្រកទំនិញផ្ទាល់ខ្លួន និងការទូទាត់ប្រាក់ដែលដំណើរការ ខណៈពេលដែលផ្នែកខាងមុខហាងនៅតែផ្ទុកចេញពីឃ្លាំងសម្ងាត់។
តើខែស (cache) រក្សាភាពថ្មីដោយរបៀបណា នៅពេលដែលខ្ញុំផ្សាយ ឬកែសម្រួល?
ការជម្រះឃ្លាំងសម្ងាត់ស្វ័យប្រវត្តិតាមរយៈមុខងារឆ្លាតវៃដំណើរការលើ WordPress hooks ដែលពាក់ព័ន្ធ ដូច្នេះការផ្សាយ ការកែសម្រួលមាតិកា ឬការផ្លាស់ប្តូរផលិតផល តម្លៃ ឬការបញ្ជាទិញ គឺជម្រះតែទំព័រដែលរងផលប៉ះពាល់ និងបណ្ណសាររបស់ពួកវាប៉ុណ្ណោះ មិនមែនជម្រះឃ្លាំងសម្ងាត់ទាំងអស់នោះទេ ហើយកម្មវិធីស្វែងរកនឹងធ្វើឱ្យវាដំណើរការឡើងវិញ។ អ្នកក៏អាចជម្រះតាមតម្រូវការពីផ្ទាំងគ្រប់គ្រង ឬពីក្នុង WordPress ផងដែរ។
តើគ្រាន់តែមានសេវាហូស្ដិង អាចផ្តល់ឱ្យខ្ញុំនូវ Core Web Vitals ដ៏ល្អឥតខ្ចោះបានទេ?
វាផ្ដល់ឱ្យអ្នកនូវ TTFB ល្អបំផុតដែលអាចធ្វើទៅបាន ដែលជាចំណែករបស់ម៉ាស៊ីនបម្រើ និងជាការចាប់ផ្ដើមដំបូងសម្រាប់ Largest Contentful Paint។ ប៉ុន្តែ LCP, CLS និង INP ភាគច្រើនត្រូវបានកំណត់ដោយទំព័រខ្លួនឯង — ទំហំរូបភាព ធនធានរាំងស្កាត់ការបង្ហាញ ស្ថេរភាពប្លង់ និង JavaScript ប្រភេទ main-thread។ កំរងបច្ចេកវិទ្យារបស់យើងធ្វើឱ្យការចូលរួមរបស់ម៉ាស៊ីនបម្រើមានល្បឿនលឿន និងស៊ីសង្វាក់គ្នា ការរក្សាទំហំផ្នែកខាងមុខ (front-end payload) ឱ្យតូចល្មម គឺជាអ្វីដែលបំពេញចន្លោះប្រហោងដែលនៅសល់។
ទាក់ទង
សាកល្បងប្រើវាដោយឥតគិតថ្លៃរយៈពេល ១៤ ថ្ងៃ
ចាប់ផ្តើមគេហទំព័រដំបូងរបស់អ្នកដោយឥតគិតថ្លៃរយៈពេល ១៤ថ្ងៃ ដោយមិនបាច់ប្រើកាត។ កំពុងផ្ទេរបណ្តាញដែលមានស្រាប់មែនទេ? ការផ្ទេរដំបូងរបស់អ្នកគឺឥតគិតថ្លៃសម្រាប់ពួកយើង។
ចាប់ផ្តើមដោយឥតគិតថ្លៃ