ការបង្ហោះធនធានភាគីទីបីដោយខ្លួនឯង៖ ល្អ អាក្រក់ អាក្រក់

ក្នុងរយៈពេលប៉ុន្មានឆ្នាំចុងក្រោយនេះ វេទិកាកាន់តែច្រើនឡើងសម្រាប់ការបង្កើនប្រសិទ្ធភាពគម្រោងផ្នែកខាងមុខផ្តល់នូវឱកាសសម្រាប់ការបង្ហោះដោយខ្លួនឯង ឬប្រូកស៊ីធនធានភាគីទីបី។ Akamai អនុញ្ញាតឱ្យអ្នកកំណត់ ប៉ារ៉ាម៉ែត្រជាក់លាក់ សម្រាប់ URL ដែលបង្កើតដោយខ្លួនឯង។ Cloudflare មានបច្ចេកវិទ្យា Edge Workers ។ Fasterzine អាច សរសេរឡើងវិញ URLs នៅលើទំព័រដើម្បីឱ្យពួកគេចង្អុលទៅធនធានភាគីទីបីដែលមានទីតាំងនៅលើដែនចម្បងនៃគេហទំព័រ។

ប្រសិនបើអ្នកដឹងថាសេវាកម្មភាគីទីបីដែលប្រើក្នុងគម្រោងរបស់អ្នកមិនផ្លាស់ប្តូរញឹកញាប់ទេ ហើយដំណើរការនៃការផ្តល់សេវាទាំងនោះទៅអតិថិជនអាចត្រូវបានកែលម្អ នោះអ្នកប្រហែលជាកំពុងគិតអំពីការផ្តល់សេវាប្រូកស៊ី។ ជាមួយនឹងវិធីសាស្រ្តនេះ អ្នកអាចនាំធនធានទាំងនេះកាន់តែខិតទៅជិតអ្នកប្រើប្រាស់របស់អ្នកបានយ៉ាងល្អ ហើយទទួលបានការគ្រប់គ្រងពេញលេញបន្ថែមទៀតលើឃ្លាំងសម្ងាត់របស់ពួកគេនៅលើផ្នែកអតិថិជន។ លើសពីនេះទៀត នេះអនុញ្ញាតឱ្យអ្នកការពារអ្នកប្រើប្រាស់ពីបញ្ហាដែលបណ្តាលមកពី "គាំង" នៃសេវាកម្មភាគីទីបី ឬការថយចុះនៃដំណើរការរបស់វា។

ល្អ៖ ដំណើរការប្រសើរឡើង

ការបង្ហោះដោយខ្លួនឯងនូវធនធានរបស់អ្នកដទៃធ្វើអោយប្រសើរឡើងនូវការអនុវត្តតាមរបៀបជាក់ស្តែង។ កម្មវិធីរុករកមិនចាំបាច់ចូលប្រើ DNS ម្តងទៀតទេ វាមិនចាំបាច់បង្កើតការតភ្ជាប់ TCP និងអនុវត្តការចាប់ដៃ TLS នៅលើដែនភាគីទីបី។ អ្នកអាចមើលឃើញពីរបៀបដែលការបង្ហោះដោយខ្លួនឯងនូវធនធានរបស់អ្នកដទៃប៉ះពាល់ដល់ដំណើរការដោយប្រៀបធៀបតួលេខពីរខាងក្រោម។

ធនធានភាគីទីបីត្រូវបានទាញយកពីប្រភពខាងក្រៅ (យកពី ពីទីនេះ)

ធនធានភាគីទីបីត្រូវបានរក្សាទុកនៅកន្លែងដដែលជាមួយសម្ភារៈគេហទំព័រដែលនៅសល់ (យកពី ពីទីនេះ)

ស្ថានភាពក៏ប្រសើរឡើងផងដែរដោយការពិតដែលថាកម្មវិធីរុករកនឹងប្រើសមត្ថភាពក្នុងការ multiplex និងកំណត់អាទិភាពទិន្នន័យពីការតភ្ជាប់ HTTP/2 ដែលត្រូវបានបង្កើតឡើងរួចហើយជាមួយដែនមេ។

ប្រសិនបើអ្នកមិនធ្វើជាម្ចាស់ផ្ទះធនធានភាគីទីបីទេ នោះដោយសារពួកវានឹងត្រូវបានផ្ទុកពីដែនដែលខុសពីប្រភពសំខាន់ ពួកគេមិនអាចកំណត់អាទិភាពបានទេ។ នេះនឹងធ្វើឱ្យពួកគេប្រកួតប្រជែងគ្នាសម្រាប់កម្រិតបញ្ជូនរបស់អតិថិជន។ នេះអាចបណ្តាលឱ្យមានពេលវេលាផ្ទុកសម្រាប់មាតិកាដែលមានសារៈសំខាន់ក្នុងការបង្កើតទំព័រដែលវែងជាងអ្វីដែលអាចសម្រេចបានក្នុងកាលៈទេសៈដ៏ល្អប្រសើរ។ នៅទីនេះ ពិភាក្សាលើការកំណត់អាទិភាព HTTP/2 ដែលពន្យល់ទាំងអស់នេះបានយ៉ាងល្អ។

វាអាចត្រូវបានសន្មត់ថាការប្រើប្រាស់គុណលក្ខណៈនៅក្នុងតំណភ្ជាប់ទៅធនធានខាងក្រៅ preconnect នឹងជួយដោះស្រាយបញ្ហា។ ទោះជាយ៉ាងណាក៏ដោយ ប្រសិនបើមានតំណភ្ជាប់ទាំងនេះច្រើនពេកទៅកាន់ដែនផ្សេងៗគ្នា វាពិតជាអាចផ្ទុកលើសទម្ងន់នៃបណ្តាញទំនាក់ទំនងនៅពេលដ៏សំខាន់បំផុត។

ប្រសិនបើអ្នកធ្វើជាម្ចាស់ផ្ទះធនធានភាគីទីបីដោយខ្លួនឯង អ្នកអាចគ្រប់គ្រងថាតើធនធានទាំងនេះត្រូវបានផ្តល់ទៅឱ្យអតិថិជនយ៉ាងដូចម្តេច។ ពោល​គឺ​យើង​កំពុង​និយាយ​អំពី​រឿង​ខាង​ក្រោម៖

• អ្នក​អាច​ប្រាកដ​ថា​ក្បួន​ដោះស្រាយ​បង្ហាប់​ទិន្នន័យ​ដែល​ស័ក្តិសម​បំផុត​នឹង​កម្មវិធីរុករក​តាម​អ៊ីនធឺណិត​នីមួយៗ​ត្រូវ​បាន​ប្រើ (Brotli/gzip)។
• អ្នកអាចបង្កើនពេលវេលាឃ្លាំងសម្ងាត់សម្រាប់ធនធានដែលជាធម្មតាមិនយូរទេ សូម្បីតែអ្នកផ្តល់សេវាដែលល្បីបំផុត (ឧទាហរណ៍ តម្លៃដែលត្រូវគ្នាសម្រាប់ស្លាក GA ត្រូវបានកំណត់ត្រឹម 30 នាទី)។

អ្នកថែមទាំងអាចពង្រីក TTL សម្រាប់ធនធានដើម្បីនិយាយក្នុងមួយឆ្នាំដោយបញ្ចូលខ្លឹមសារដែលពាក់ព័ន្ធទៅក្នុងយុទ្ធសាស្ត្រគ្រប់គ្រងឃ្លាំងសម្ងាត់របស់អ្នក (សញ្ញា URL កំណែ។ ល។ )។ យើងនឹងនិយាយអំពីរឿងនេះខាងក្រោម។

▍ ការការពារប្រឆាំងនឹងការរំខាននៅក្នុងប្រតិបត្តិការនៃសេវាកម្មភាគីទីបី ឬការបិទរបស់ពួកគេ។

ទិដ្ឋភាពគួរឱ្យចាប់អារម្មណ៍មួយទៀតនៃធនធានភាគីទីបីដែលបង្ហោះដោយខ្លួនឯងគឺថាវាអនុញ្ញាតឱ្យអ្នកកាត់បន្ថយហានិភ័យដែលទាក់ទងនឹងការដាច់នៃសេវាកម្មភាគីទីបី។ ចូរសន្មតថាដំណោះស្រាយសាកល្បង A/B ភាគីទីបីដែលអ្នកកំពុងប្រើត្រូវបានអនុវត្តជាស្គ្រីបទប់ស្កាត់ដែលផ្ទុកនៅក្នុងផ្នែកក្បាលនៃទំព័រ។ ស្គ្រីបនេះផ្ទុកយឺត។ ប្រសិនបើស្គ្រីបដែលត្រូវគ្នាមិនអាចផ្ទុកបានទេ ទំព័រនឹងទទេ។ ប្រសិនបើវាចំណាយពេលយូរក្នុងការផ្ទុក ទំព័រនឹងបង្ហាញដោយមានការពន្យារពេលយូរ។ ឬឧបមាថាគម្រោងប្រើបណ្ណាល័យដែលបានទាញយកពីធនធាន CDN ភាគីទីបី។ ចូរយើងស្រមៃថាធនធាននេះជួបប្រទះនឹងការបរាជ័យ ឬត្រូវបានរារាំងនៅក្នុងប្រទេសជាក់លាក់មួយ។ ស្ថានភាពបែបនេះនឹងនាំឱ្យមានការរំលោភលើតក្កវិជ្ជានៃគេហទំព័រ។

ដើម្បីស្វែងយល់ពីរបៀបដែលគេហទំព័ររបស់អ្នកដំណើរការ នៅពេលដែលសេវាកម្មខាងក្រៅមួយចំនួនមិនអាចប្រើបាន អ្នកអាចប្រើផ្នែក SPOF នៅលើ webpagetest.org.

ផ្នែក SPOF នៅលើ webpagetest.org

▍ចុះយ៉ាងណាចំពោះបញ្ហាជាមួយនឹងការរក្សាទុកសម្ភារៈនៅក្នុងកម្មវិធីរុករក? (ការណែនាំ៖ វាជាទេវកថា)

អ្នកប្រហែលជាគិតថាការប្រើប្រាស់ CDNs សាធារណៈនឹងនាំទៅរកដំណើរការធនធានកាន់តែប្រសើរឡើងដោយស្វ័យប្រវត្តិ ចាប់តាំងពីសេវាកម្មទាំងនេះមានបណ្តាញដែលមានគុណភាពខ្ពស់ត្រឹមត្រូវ ហើយត្រូវបានចែកចាយនៅជុំវិញពិភពលោក។ ប៉ុន្តែការពិតអ្វីគ្រប់យ៉ាងគឺស្មុគស្មាញបន្តិច។

ចូរនិយាយថាយើងមានគេហទំព័រផ្សេងៗគ្នាជាច្រើន៖ website1.com, website2.com, website3.com ។ គេហទំព័រទាំងអស់នេះប្រើបណ្ណាល័យ jQuery ។ យើងភ្ជាប់វាទៅពួកគេដោយប្រើ CDN ឧទាហរណ៍ - googleapis.com ។ អ្នកអាចរំពឹងថាកម្មវិធីរុករកនឹងទាញយក និងរក្សាទុកបណ្ណាល័យម្តង ហើយបន្ទាប់មកប្រើវានៅលើគេហទំព័រទាំងបី។ នេះអាចកាត់បន្ថយការផ្ទុកនៅលើបណ្តាញ។ ប្រហែលជានេះនឹងអនុញ្ញាតឱ្យអ្នកសន្សំប្រាក់នៅកន្លែងណាមួយ និងជួយកែលម្អដំណើរការធនធាន។ តាមទស្សនៈជាក់ស្តែង អ្វីៗមើលទៅខុសគ្នា។ ឧទាហរណ៍ Safari មានមុខងារហៅថា ការការពារការតាមដានឆ្លាតវៃ៖ ឃ្លាំងសម្ងាត់ប្រើសោពីរដោយផ្អែកលើប្រភពនៃឯកសារ និងប្រភពនៃធនធានភាគីទីបី។ នៅទីនេះ អត្ថបទល្អលើប្រធានបទនេះ។

ការសិក្សាចាស់ ក្រុមហ៊ុន Yahoo и Facebookក៏ដូចជាថ្មីៗបន្ថែមទៀត ការសិក្សា Paul Calvano បង្ហាញថាធនធានមិនត្រូវបានរក្សាទុកក្នុងឃ្លាំងសម្ងាត់កម្មវិធីរុករកតាមអ៊ីនធឺណិតយូរដូចដែលយើងរំពឹងទុក៖ “វាមានគម្លាតយ៉ាងធ្ងន់ធ្ងររវាងពេលវេលាឃ្លាំងសម្ងាត់នៃធនធានផ្ទាល់ខ្លួន និងភាគីទីបីរបស់គម្រោង។ យើងកំពុងនិយាយអំពី CSS និងពុម្ពអក្សរគេហទំព័រ។ ពោលគឺ 95% នៃពុម្ពអក្សរដើមមានអាយុកាលឃ្លាំងសម្ងាត់ច្រើនជាងមួយសប្តាហ៍ ខណៈដែល 50% នៃពុម្ពអក្សរភាគីទីបីមានអាយុកាលឃ្លាំងសម្ងាត់តិចជាងមួយសប្តាហ៍! នេះផ្តល់ឱ្យអ្នកអភិវឌ្ឍន៍គេហទំព័រនូវហេតុផលដ៏គួរឱ្យទាក់ទាញមួយក្នុងការបង្ហោះឯកសារពុម្ពអក្សរដោយខ្លួនឯង!”

ជាលទ្ធផល ប្រសិនបើអ្នកបង្ហោះខ្លឹមសាររបស់អ្នកដ៏ទៃ នោះអ្នកនឹងមិនកត់សំគាល់បញ្ហាដំណើរការណាមួយដែលបណ្តាលមកពីការរក្សាទុកក្នុងកម្មវិធីរុករកតាមអ៊ីនធឺណិតទេ។

ឥឡូវនេះ យើងបានគ្របដណ្តប់ចំណុចខ្លាំងនៃការបង្ហោះដោយខ្លួនឯងរបស់ភាគីទីបី សូមនិយាយអំពីរបៀបប្រាប់ពីការអនុវត្តដ៏ល្អនៃវិធីសាស្រ្តនេះពីវិធីអាក្រក់មួយ។

អាក្រក់៖ អារក្សស្ថិតនៅក្នុងព័ត៌មានលម្អិត

ការផ្លាស់ទីធនធានភាគីទីបីទៅដែនផ្ទាល់ខ្លួនរបស់អ្នកមិនអាចធ្វើបានដោយស្វ័យប្រវត្តិដោយមិនប្រាកដថាធនធានទាំងនោះត្រូវបានទុកក្នុងឃ្លាំងសម្ងាត់ត្រឹមត្រូវ។

បញ្ហាចម្បងមួយនៅទីនេះគឺពេលវេលាឃ្លាំងសម្ងាត់។ ឧទាហរណ៍ ព័ត៌មានអំពីកំណែត្រូវបានរួមបញ្ចូលនៅក្នុងឈ្មោះស្គ្រីបភាគីទីបីដូចនេះ៖ jquery-3.4.1.js. ឯកសារបែបនេះនឹងមិនផ្លាស់ប្តូរនៅពេលអនាគតទេ ហើយជាលទ្ធផលនេះនឹងមិនបង្កបញ្ហាណាមួយជាមួយឃ្លាំងសម្ងាត់របស់វាឡើយ។

ប៉ុន្តែប្រសិនបើគ្រោងការណ៍កំណែមួយចំនួនមិនត្រូវបានប្រើនៅពេលធ្វើការជាមួយឯកសារ ស្គ្រីបក្នុងឃ្លាំងសម្ងាត់ មាតិកាដែលផ្លាស់ប្តូរខណៈពេលដែលឈ្មោះឯកសារនៅតែមិនផ្លាស់ប្តូរ អាចនឹងហួសសម័យ។ នេះអាចជាបញ្ហាធ្ងន់ធ្ងរ ព្រោះឧទាហរណ៍វាមិនអនុញ្ញាតឱ្យបន្ថែមបំណះសុវត្ថិភាពស្វ័យប្រវត្តិទៅក្នុងស្គ្រីបដែលអតិថិជនត្រូវការទទួលឱ្យបានលឿនតាមដែលអាចធ្វើទៅបាន។ អ្នកអភិវឌ្ឍន៍នឹងត្រូវខិតខំប្រឹងប្រែងដើម្បីធ្វើបច្ចុប្បន្នភាពស្គ្រីបបែបនេះនៅក្នុងឃ្លាំងសម្ងាត់។ លើសពីនេះ វាអាចបណ្តាលឱ្យកម្មវិធីបរាជ័យ ដោយសារកូដដែលប្រើលើម៉ាស៊ីនភ្ញៀវពីឃ្លាំងសម្ងាត់ខុសពីកំណែចុងក្រោយនៃកូដដែលផ្នែកម៉ាស៊ីនមេនៃគម្រោងត្រូវបានរចនាឡើង។

ពិតហើយ ប្រសិនបើយើងនិយាយអំពីសម្ភារៈដែលត្រូវបានអាប់ដេតញឹកញាប់ (អ្នកគ្រប់គ្រងស្លាក ដំណោះស្រាយសម្រាប់ការធ្វើតេស្ត A/B) នោះការរក្សាទុកពួកវាដោយប្រើឧបករណ៍ CDN គឺជាកិច្ចការដែលអាចដោះស្រាយបាន ប៉ុន្តែស្មុគស្មាញជាង។ សេវាកម្មដូចជា Commanders Act ដែលជាដំណោះស្រាយគ្រប់គ្រងស្លាក ប្រើ webhooks នៅពេលបោះពុម្ពកំណែថ្មី។ នេះផ្តល់ឱ្យអ្នកនូវសមត្ថភាពក្នុងការបង្ខំការសម្អាតឃ្លាំងសម្ងាត់នៅលើ CDN ឬប្រសើរជាងនេះទៅទៀត សមត្ថភាពក្នុងការបង្ខំ hash ឬការធ្វើបច្ចុប្បន្នភាព URL ។

▍ ការផ្តល់សម្ភារៈសមស្របដល់អតិថិជន

លើសពីនេះទៀត នៅពេលយើងនិយាយអំពីឃ្លាំងសម្ងាត់ យើងត្រូវគិតគូរពីការពិតដែលថាការកំណត់ឃ្លាំងសម្ងាត់ដែលបានប្រើនៅលើ CDN ប្រហែលជាមិនសមរម្យសម្រាប់ធនធានភាគីទីបីមួយចំនួន។ ជាឧទាហរណ៍ ធនធានបែបនេះអាចប្រើប្រាស់បច្ចេកវិទ្យា sniffing (adaptive serving) ភ្នាក់ងារអ្នកប្រើប្រាស់ ដើម្បីបម្រើកម្មវិធីរុករកតាមអ៊ីនធឺណិតជាក់លាក់ជាមួយនឹងកំណែនៃមាតិកាដែលបានធ្វើឱ្យប្រសើរឡើងជាពិសេសសម្រាប់កម្មវិធីរុករកទាំងនោះ។ បច្ចេកវិទ្យាទាំងនេះពឹងផ្អែកលើកន្សោមធម្មតា ឬមូលដ្ឋានទិន្នន័យនៃព័ត៌មានបឋមកថា HTTP ដើម្បីស្វែងយល់ពីសមត្ថភាពរបស់កម្មវិធីរុករកតាមអ៊ីនធឺណិត។ User-Agent. នៅពេលដែលពួកគេដឹងថាកម្មវិធីរុករកណាមួយដែលពួកគេកំពុងដោះស្រាយ ពួកគេបានផ្តល់ឱ្យវានូវសម្ភារៈដែលត្រូវបានរចនាឡើងសម្រាប់វា។

នៅទីនេះអ្នកអាចចងចាំសេវាកម្មពីរ។ ទីមួយគឺ googlefonts.com ។ ទីពីរគឺ polyfill.io ។ សេវាកម្ម Google Fonts ផ្តល់សម្រាប់ធនធានជាក់លាក់ កូដ CSS ផ្សេងៗ អាស្រ័យលើសមត្ថភាពរបស់កម្មវិធីរុករកតាមអ៊ីនធឺណិត (ផ្តល់តំណភ្ជាប់ទៅធនធាន woff2 ដោយប្រើ unicode-range).

នេះ​ជា​លទ្ធផល​នៃ​សំណួរ Google Fonts ពីរ​ដែល​បាន​ធ្វើ​ឡើង​ពី​កម្មវិធី​រុករក​ផ្សេង​គ្នា។

លទ្ធផលសំណួរ Google Fonts ពី Chrome

លទ្ធផលនៃសំណួរ Google Fonts ត្រូវបានប្រតិបត្តិពី IE10

Polyfill.io ផ្តល់ឱ្យកម្មវិធីរុករកតែ polyfill ដែលវាត្រូវការប៉ុណ្ណោះ។ នេះត្រូវបានធ្វើសម្រាប់ហេតុផលនៃការអនុវត្ត។

ជាឧទាហរណ៍ សូមក្រឡេកមើលថាតើមានអ្វីកើតឡើង ប្រសិនបើអ្នកដំណើរការសំណើខាងក្រោមពីកម្មវិធីរុករកផ្សេងៗ៖ https://polyfill.io/v3/polyfill.js?features=default

ដើម្បីឆ្លើយតបទៅនឹងសំណើដែលបានប្រតិបត្តិពី IE10 ទិន្នន័យ 34 KB នឹងត្រូវបានទទួល។ ហើយចម្លើយចំពោះវា ប្រតិបត្តិពី Chrome នឹងទទេ។

ខឹង៖ ការពិចារណាអំពីឯកជនភាពមួយចំនួន

ចំណុច​នេះ​ស្ថិត​ក្នុង​លំដាប់​ចុង​ក្រោយ ប៉ុន្តែ​មិន​សំខាន់​តិច​ទេ។ ចំនុចនោះគឺថាការបង្ហោះដោយខ្លួនឯងនៃធនធានភាគីទីបីនៅលើដែនចម្បងនៃគម្រោង ឬនៅលើដែនរងរបស់វាអាចធ្វើឱ្យប៉ះពាល់ដល់ភាពឯកជនរបស់អ្នកប្រើប្រាស់ និងជះឥទ្ធិពលអវិជ្ជមានដល់គម្រោងបណ្ដាញចម្បង។

ប្រសិនបើប្រព័ន្ធ CDN របស់អ្នកមិនត្រូវបានកំណត់ត្រឹមត្រូវទេ អ្នកអាចនឹងបញ្ចប់ការផ្ញើខូគីរបស់ដែនរបស់អ្នកទៅកាន់សេវាកម្មភាគីទីបី។ ប្រសិនបើការត្រងត្រឹមត្រូវមិនត្រូវបានរៀបចំនៅកម្រិត CDN នោះខូគីសម័យរបស់អ្នក ដែលជាធម្មតាមិនអាចប្រើក្នុង JavaScript (ជាមួយ httponly) អាចត្រូវបានបញ្ជូនទៅម្ចាស់ផ្ទះបរទេស។

នេះគឺជាអ្វីដែលអាចកើតឡើងជាមួយអ្នកតាមដានដូចជា Eulerian ឬ Criteo។ កម្មវិធីតាមដានភាគីទីបីអាចកំណត់អត្តសញ្ញាណតែមួយគត់នៅក្នុងខូគី។ ប្រសិនបើពួកគេជាផ្នែកមួយនៃសម្ភារៈគេហទំព័រ ពួកគេអាចអានឧបករណ៍កំណត់អត្តសញ្ញាណតាមការសំរេចចិត្តរបស់ពួកគេ ខណៈពេលដែលអ្នកប្រើប្រាស់កំពុងធ្វើការជាមួយធនធានគេហទំព័រផ្សេងៗគ្នា។

សព្វថ្ងៃនេះ កម្មវិធីរុករកតាមអ៊ីនធឺណិតភាគច្រើនរួមបញ្ចូលការការពារប្រឆាំងនឹងប្រភេទនៃឥរិយាបថកម្មវិធីតាមដាននេះ។ ជាលទ្ធផល អ្នកតាមដានឥឡូវនេះប្រើប្រាស់បច្ចេកវិទ្យា ការបិទបាំង CNAMEដោយក្លែងបន្លំជាស្គ្រីបផ្ទាល់ខ្លួនរបស់ពួកគេសម្រាប់គម្រោងផ្សេងៗ។ ពោលគឺកម្មវិធីតាមដានផ្តល់ជូនម្ចាស់គេហទំព័រដើម្បីបន្ថែម CNAME ទៅក្នុងការកំណត់របស់ពួកគេសម្រាប់ដែនជាក់លាក់មួយ អាសយដ្ឋានដែលជាធម្មតាមើលទៅដូចជាសំណុំតួអក្សរចៃដន្យ។

ទោះបីជាវាមិនត្រូវបានណែនាំឱ្យធ្វើខូគីគេហទំព័រដែលមានសម្រាប់ដែនរងទាំងអស់ (ឧទាហរណ៍ - *.website.com) គេហទំព័រជាច្រើនធ្វើដូចនេះ។ ក្នុងករណីនេះ ខូគីបែបនេះត្រូវបានផ្ញើដោយស្វ័យប្រវត្តិទៅកាន់កម្មវិធីតាមដានភាគីទីបីដែលក្លែងខ្លួន។ ជាលទ្ធផល យើងមិនអាចនិយាយអំពីឯកជនភាពណាមួយបានទៀតទេ។

ដូចគ្នានេះផងដែរ រឿងដដែលនេះកើតឡើងជាមួយបឋមកថា HTTP អតិថិជន - ព័ត៌មានជំនួយដែលត្រូវបានផ្ញើទៅដែនមេ ព្រោះវាអាចត្រូវបានប្រើដើម្បីបង្កើត ស្នាមម្រាមដៃឌីជីថល អ្នក​ប្រើ។ ត្រូវប្រាកដថាសេវាកម្ម CDN ដែលអ្នកប្រើត្រងបឋមកថាទាំងនេះត្រឹមត្រូវ។

លទ្ធផល

ប្រសិនបើអ្នកមានគម្រោងអនុវត្តការបង្ហោះដោយខ្លួនឯងនៃធនធានភាគីទីបីក្នុងពេលឆាប់ៗនេះ ខ្ញុំសូមផ្តល់ដំបូន្មានមួយចំនួនដល់អ្នក៖

• ធ្វើជាម្ចាស់ផ្ទះបណ្ណាល័យ JS ពុម្ពអក្សរ និងឯកសារ CSS សំខាន់បំផុតរបស់អ្នក។ វានឹងកាត់បន្ថយហានិភ័យនៃការបរាជ័យនៃគេហទំព័រ ឬការថយចុះនៃការអនុវត្ត ដោយសារធនធានដ៏សំខាន់ចំពោះគេហទំព័រនេះមិនអាចប្រើបាន ដោយសារកំហុសនៃសេវាកម្មភាគីទីបី។
• មុនពេលអ្នករក្សាទុកធនធានភាគីទីបីនៅលើ CDN ត្រូវប្រាកដថាប្រព័ន្ធកំណែមួយចំនួនត្រូវបានប្រើនៅពេលដាក់ឈ្មោះឯកសាររបស់ពួកគេ ឬអ្នកអាចគ្រប់គ្រងវដ្តជីវិតនៃធនធានទាំងនេះដោយកំណត់ឡើងវិញនូវឃ្លាំងសម្ងាត់ CDN ដោយដៃ ឬដោយស្វ័យប្រវត្តិនៅពេលបោះពុម្ពកំណែថ្មីនៃ ស្គ្រីប។
• សូមប្រយ័ត្នចំពោះ CDN ម៉ាស៊ីនមេប្រូកស៊ី និងការកំណត់ឃ្លាំងសម្ងាត់របស់អ្នក។ វានឹងអនុញ្ញាតឱ្យអ្នកការពារគម្រោង ឬបឋមកថារបស់អ្នកពីការផ្ញើខូគី Client-Hints សេវាកម្មភាគីទីបី។

អ្នកអានជាទីស្រឡាញ់! តើអ្នកធ្វើជាម្ចាស់ផ្ទះសម្ភារៈរបស់អ្នកដទៃនៅលើម៉ាស៊ីនមេរបស់អ្នកដែលមានសារៈសំខាន់ខ្លាំងណាស់សម្រាប់ប្រតិបត្តិការនៃគម្រោងរបស់អ្នកទេ?

ប្រភព: www.habr.com