Cache, CDN និងល្បឿន

មាតិកា

1. Request ដែលលឿនបំផុត គឺ Request ដែលអ្នកមិនបានផ្ញើ
2. Cache-Control៖ រក្សាទុករយៈពេលប៉ុន្មាន
3. ការសួរត្រឡប់ទៅវិញ៖ ETag និង 304
4. ហេតុអ្វីការផ្លាស់ប្តូររបស់អ្នកមិនទាន់លេចឡើង
5. File ដែលមាន Fingerprint
6. CDN៖ ច្បាប់ចម្លងនៅជិតអ្នក
7. Compression
8. វិធីផ្សេងទៀតដើម្បីឲ្យលឿន
9. សាកល្បងដោយខ្លួនឯង

1. Request ដែលលឿនបំផុត គឺ Request ដែលអ្នកមិនបានផ្ញើ

សូមនឹកឃើញឡើងវិញពីជំពូកមុនៗ។ Request នីមួយៗចំណាយ DNS lookup មួយ (ប្រហែល) ការតភ្ជាប់មួយ (ប្រហែល) round trip យ៉ាងហោចណាស់មួយ និងពេលវេលាដើម្បីទាញយក response។ គុណវានឹង request រាប់សិបនៅលើទំព័រមួយ និងនឹងគ្រប់ទំព័រដែលមនុស្សម្នាក់ចូលមើល។

ប៉ុន្តែ request ភាគច្រើនទាំងនោះ សុំរបស់ដែល មិនបានផ្លាស់ប្តូរ។ style.css នៃ site របស់អ្នក គឺដូចគ្នានៅលើទំព័រដើម ទំព័រ about និងទំព័រ contact — ហើយដូចគ្នាថ្ងៃនេះនឹងម្សិលមិញ។ ការទាញយកវាម្តងទៀតរាល់ពេល គឺជាការខ្ជះខ្ជាយសុទ្ធសាធ។

Cache គឺជាច្បាប់ចម្លងដែលបានរក្សាទុកនៃអ្វីមួយ ដើម្បីកុំឲ្យអ្នកត្រូវទៅយកវាម្តងទៀត។ អ្នកបានជួប cache ក្នុងស៊េរី របៀបដែលកុំព្យូទ័រដំណើរការ រួចហើយ — cache របស់ CPU នៅពីមុខ RAM — និងក្នុងជំពូកទី 3 ដែលគ្រប់ជំហាននៃ DNS ចងចាំចម្លើយ។ Web ប្រើល្បិចដូចគ្នានេះ នៅកន្លែងជាច្រើន៖

 Browser cache ──▶ CDN cache ──▶ Server
 (on your device)  (near you)    (the original)

បើ browser មានច្បាប់ចម្លងថ្មី (fresh) request នោះមិនដែលចាកចេញពីកុំព្យូទ័ររបស់អ្នកទេ។ បើមិនមានទេ ប្រហែលជា CDN នៅក្បែរនោះមានមួយ។ មានតែពេលដែលគ្មានទាំងពីរទេ ទើប request ធ្វើដំណើររហូតដល់ server ដើម។

2. Cache-Control៖ រក្សាទុករយៈពេលប៉ុន្មាន

Server ជាអ្នកសម្រេចថា response មួយអាចត្រូវបាន cache រយៈពេលប៉ុន្មាន ដោយប្រើ response header Cache-Control។ អ្នកបានឃើញវាក្នុងជំពូកទី 6៖

cache-control: max-age=600

នោះមានន័យថា៖ «response នេះនៅ fresh រយៈពេល 600 វិនាទី (10 នាទី)។ រហូតដល់ពេលនោះ កុំសួរខ្ញុំម្តងទៀត — គ្រាន់តែប្រើច្បាប់ចម្លងរបស់អ្នក»។ ក្នុងរយៈពេលដប់នាទីនោះ browser load ទំព័ររបស់អ្នកភ្លាមៗពី cache ផ្ទាល់ខ្លួនរបស់វា ដោយគ្មាន network request ណាមួយទាល់តែសោះ។

តម្លៃដែលអ្នកនឹងឃើញញឹកញាប់បំផុត៖

ឈ្មោះទាំងនេះពិបាកយល់៖ no-cache មិនមែនមានន័យថា «កុំ cache» ទេ។ វាមានន័យថា «ត្រូវពិនិត្យជាមុនជានិច្ច»។ មួយដែលពិតជាមានន័យថា «កុំ cache» គឺ no-store។

3. ការសួរត្រឡប់ទៅវិញ៖ ETag និង 304

តើមានអ្វីកើតឡើងនៅពេលច្បាប់ចម្លងមួយលែង fresh? Browser មិនចាំបាច់ទាញយកវាទាំងមូលម្តងទៀតទេ។ វាអាច សួរ ថាតើវាបានផ្លាស់ប្តូរឬអត់។

ចាំ header etag ពីជំពូកទី 6 ទេ៖

etag: "6aa7ac7d-60b"

ETag គឺជាស្លាកសម្រាប់កំណែពិតប្រាកដមួយនៃ file — ដូចជាស្នាមម្រាមដៃ (fingerprint)។ នៅពេលច្បាប់ចម្លងរបស់ browser ចាស់ (stale) វាផ្ញើស្លាកនោះត្រឡប់ទៅវិញនៅក្នុង header If-None-Match៖

GET /my-site/style.css HTTP/1.1
Host: dara-sok.github.io
If-None-Match: "6aa7ac7d-60b"

បើ file មិនបានផ្លាស់ប្តូរ server ឆ្លើយតបដោយ response តូចមួយ ហើយ គ្មាន body៖

HTTP/1.1 304 Not Modified

«ច្បាប់ចម្លងរបស់អ្នកនៅតែល្អ — ប្រើវាចុះ»។ នោះគឺជា 304 ពីជំពូកទី 6។ វានៅតែចំណាយ round trip មួយ ប៉ុន្តែវារំលងការទាញយក file។ បើ file បាន ផ្លាស់ប្តូរ ETag នឹងមិនត្រូវគ្នាទេ ហើយ server ផ្ញើ 200 ធម្មតាជាមួយកំណែថ្មី។

មានកំណែចាស់ជាងនៃគំនិតដូចគ្នានេះ ដែលប្រើកាលបរិច្ឆេទ៖ server ផ្ញើ Last-Modified ហើយ browser សួរដោយប្រើ If-Modified-Since។

4. ហេតុអ្វីការផ្លាស់ប្តូររបស់អ្នកមិនទាន់លេចឡើង

នេះគឺជា cache ដែលបង្កបញ្ហាមួយដែលអ្នកប្រហែលជាបានជួបរួចហើយ។ នៅក្នុងស៊េរី Git អ្នកបាន merge pull request មួយ GitHub Pages បាន build site របស់អ្នកឡើងវិញ… ហើយនៅពេលអ្នកបើកវា អ្នកនៅតែឃើញកំណែ ចាស់។

មើល header ម្តងទៀត៖ cache-control: max-age=600។ GitHub Pages ប្រាប់គ្រប់ browser ឲ្យរក្សាទំព័រទុករហូតដល់ 10 នាទី ដោយមិនចាំបាច់ពិនិត្យ។ Browser របស់អ្នកកំពុងធ្វើតាមអ្វីដែលគេប្រាប់វាយ៉ាងត្រឹមត្រូវ។

នៅពេលអ្នកត្រូវការមើលកំណែចុងក្រោយភ្លាមៗ៖

• Hard reload៖ Ctrl+Shift+R (Windows/Linux) ឬ Cmd+Shift+R (macOS)។ វាប្រាប់ browser ឲ្យមិនអើពើ cache របស់វាសម្រាប់ទំព័រនេះ។
• នៅក្នុង DevTools → Network ធីក Disable cache។ ខណៈពេល DevTools បើក គ្មានអ្វីត្រូវបាន cache ទេ។ Web developer ភាគច្រើនបើកវាទុកពេលកំពុងធ្វើការ។
• បើកទំព័រនៅក្នុង private/incognito window ដែលចាប់ផ្តើមជាមួយ cache ទទេ។

«តើអ្នកបានសាក hard refresh ហើយឬនៅ?» គឺជាសំណួរមួយក្នុងចំណោមសំណួរដែលគេសួរញឹកញាប់បំផុតក្នុងការអភិវឌ្ឍ web។ ឥឡូវអ្នកដឹងហើយថាហេតុអ្វី។

5. File ដែលមាន Fingerprint

Cache បង្កើតបញ្ហាពិបាកសម្រេចមួយ។ រយៈពេល cache វែង ធ្វើឲ្យ site លឿន។ ប៉ុន្តែបើ file មួយត្រូវបាន cache រយៈពេលមួយឆ្នាំ តើអ្នក update វាដោយរបៀបណា?

ចម្លើយគឺ ប្តូរឈ្មោះវា រាល់ពេលដែលខ្លឹមសាររបស់វាផ្លាស់ប្តូរ។ Build tool បន្ថែម fingerprint ខ្លីមួយ — hash នៃខ្លឹមសាររបស់ file — ទៅក្នុងឈ្មោះ file៖

style.css          →  style.3f9a1c2b.css
app.js             →  app.81d0e47f.js

ឥឡូវ file នីមួយៗអាចត្រូវបាន cache រយៈពេលមួយឆ្នាំ (max-age=31536000, immutable) ព្រោះ file ដែលមានឈ្មោះពិតប្រាកដនោះនឹង មិនដែល ផ្លាស់ប្តូរទេ។ នៅពេលអ្នកកែ CSS, build នឹងបង្កើត style.5c2e09aa.css ជំនួសវិញ HTML ចង្អុលទៅឈ្មោះថ្មី ហើយ browser ទៅយកវាជា file ថ្មីទាំងស្រុង។ ទំព័រ HTML ខ្លួនឯងទទួលបានរយៈពេល cache ខ្លី ដូច្នេះវាតែងតែចង្អុលទៅឈ្មោះចុងក្រោយបំផុត។

Website នេះដំណើរការតាមរបៀបនេះ។ បើក DevTools នៅលើទំព័រណាមួយនៅទីនេះ ហើយមើល file ក្រោម /_next/static/ — អ្នកនឹងឃើញឈ្មោះដែលពោរពេញដោយតួអក្សរដែលមើលទៅដូចចៃដន្យ។ នោះគឺ Next.js កំពុង fingerprint ពួកវានៅពេល build។

6. CDN៖ ច្បាប់ចម្លងនៅជិតអ្នក

ជំពូកទី 4 បានបង្ហាញថា ចម្ងាយចំណាយពេលវេលា៖ ប្រហែល 40 ms ក្នុងមួយ round trip ទៅសិង្ហបុរី និង 250 ms ទៅសហរដ្ឋអាមេរិក។ Server នៅក្នុងប្រទេសមួយ គឺយឺតសម្រាប់អ្នកគ្រប់គ្នាដែលនៅឆ្ងាយពីវា។

CDN — Content Delivery Network — ដោះស្រាយបញ្ហានេះ ដោយរក្សា ច្បាប់ចម្លង នៃ site មួយនៅលើ server រាប់រយនៅជុំវិញពិភពលោក ដែលហៅថា edge server។ DNS (ជំពូកទី 3) បញ្ជូនអ្នកចូលមើលម្នាក់ៗទៅកាន់ edge server មួយដែលនៅជិត។ អ្នកនៅភ្នំពេញទទួលបានច្បាប់ចម្លងនៅសិង្ហបុរី ចំណែកអ្នកនៅប៉ារីសទទួលបានច្បាប់ចម្លងនៅប៉ារីស។

              Original server (USA)
                     │
        ┌────────────┼────────────┐
   Edge: Singapore  Edge: Paris  Edge: São Paulo
        │                │             │
  Visitors in Asia   in Europe   in South America

អ្នកចូលមើលដំបូងគេដែលនៅជិត edge server មួយ បង្កឲ្យមាន cache miss៖ edge ទៅយក file ពី server ដើម ហើយរក្សាច្បាប់ចម្លងមួយទុក។ អ្នកគ្រប់គ្នាបន្ទាប់ពីនោះទទួលបាន cache hit ដែលបម្រើពីកន្លែងជិតៗ។

អ្នកបានប្រើ CDN តាំងពីដំបូងមកម្ល៉េះ។ GitHub Pages ដំណើរការលើ CDN មួយឈ្មោះ Fastly។ នោះហើយជាអ្វីដែល header ទាំងនេះពីជំពូកទី 6 និយាយអំពី៖

x-cache: HIT
age: 245
x-served-by: cache-sin-…

x-cache: HIT មានន័យថា edge server មានច្បាប់ចម្លងមួយ។ age: 245 មានន័យថាច្បាប់ចម្លងនោះមានអាយុ 245 វិនាទី។ ហើយ sin គឺជាកូដអាកាសយានដ្ឋានរបស់ សិង្ហបុរី — edge server ដែលបានឆ្លើយតប។ CDN ដូចជា Cloudflare, Fastly និង Amazon CloudFront គឺជាផ្នែកធំមួយនៃមូលហេតុដែល website នេះ (និង web ភាគច្រើន) មានអារម្មណ៍ថាលឿន មិនថាអ្នកនៅទីណាក៏ដោយ។

7. Compression

អត្ថបទអាចបង្រួម (compress) បានល្អខ្លាំងណាស់។ HTML, CSS, JavaScript និង JSON ជាធម្មតារួមតូច 70–80% នៅពេល compress — script ទំហំ 100 KB ក្លាយជា 25 KB នៅលើខ្សែ។

ចាំ request header Accept-Encoding ពីជំពូកទី 5 ទេ៖

Accept-Encoding: gzip, br

Browser កំពុងនិយាយថា៖ «ខ្ញុំអាចពន្លា (unzip) gzip និង Brotli បាន»។ Server compress response ហើយប្រាប់ថាវាបានប្រើមួយណា៖

Content-Encoding: br

Browser ពន្លាវាមុនពេល parse។ អ្នកមិនដែលឃើញវាកើតឡើងទេ។ រូបភាព និងវីដេអូត្រូវបាន compress រួចហើយក្នុងទម្រង់ផ្ទាល់ខ្លួនរបស់វា (JPEG, WebP, MP4) ដូច្នេះ server មិនរំខាន compress ពួកវាម្តងទៀតទេ។

8. វិធីផ្សេងទៀតដើម្បីឲ្យលឿន

Cache, CDN និង compression គឺជាវិធីធំៗទាំងបី។ មានវិធីពីរបីទៀតដែលអ្នកនឹងឮនិយាយ ក្នុងនាមជា frontend developer៖

• Request តិចជាងមុន៖ request នីមួយៗមានតម្លៃ ដូច្នេះត្រូវបញ្ចូល file តូចៗចូលគ្នា ហើយជៀសវាង load អ្វីៗដែលទំព័រមិនប្រើ។
• រូបភាពតូចជាងមុន៖ រូបភាពជាធម្មតាគឺជាផ្នែកធ្ងន់បំផុតនៃទំព័រមួយ។ ប្តូរទំហំវាឲ្យស្មើនឹងទំហំដែលវាត្រូវបានបង្ហាញ ហើយប្រើទម្រង់សម័យថ្មីដូចជា WebP។ រូបថតនៅលើ website នេះត្រូវបានរក្សាទទឹងក្រោមប្រហែល 1600px ដោយសារមូលហេតុនេះហើយ។
• Lazy loading៖ <img loading="lazy"> ទាញយករូបភាពតែនៅពេលអ្នក scroll មកជិតវាប៉ុណ្ណោះ។
• វាស់វែង៖ tab Lighthouse របស់ Chrome នៅក្នុង DevTools ផ្តល់ពិន្ទុ performance ដល់ទំព័រមួយ ជាមួយបញ្ជីនៃអ្វីដែលត្រូវកែ។

9. សាកល្បងដោយខ្លួនឯង

1. មើល cache កំពុងដំណើរការ។ បើក site GitHub Pages របស់អ្នក ដោយបើក DevTools → Network ហើយត្រូវប្រាកដថា Disable cache ត្រូវបាន បិទ។ Load ទំព័រ បន្ទាប់មកចុច link មួយ ហើយត្រឡប់មកវិញ។ មើល column Size៖ អ្នកនឹងឃើញ (memory cache) ឬ (disk cache) ជំនួសឲ្យលេខ។ ឥឡូវធីក Disable cache ហើយ reload — ទំហំពិតប្រាកដត្រឡប់មកវិញ។

2. បង្កើត 304 ដោយខ្លួនឯង។ យក ETag នៃទំព័ររបស់អ្នក បន្ទាប់មកផ្ញើវាត្រឡប់ទៅវិញ៖

   curl -I https://dara-sok.github.io/my-site/
   curl -I https://dara-sok.github.io/my-site/ \
     -H 'If-None-Match: "6aa7ac7d-60b"'
   

   Copy

   ជំនួស ETag នៅក្នុង command ទីពីរ ដោយ ETag ដែល អ្នក ទទួលបាន — រួមទាំងសញ្ញាសម្រង់ផង។ Response ទីពីរគួរតែជា 304។

3. មើល CDN។ រត់ curl -I លើ site របស់អ្នកពីរដង ឃ្លាតពីគ្នាពីរបីវិនាទី។ ប្រៀបធៀប x-cache, age និង x-served-by។ តើ age កំពុងកើនឡើងទេ?

4. វាស់ compression។ -w "%{size_download}\n" បង្ហាញចំនួន byte ដែលបានទាញយក ហើយ --compressed សុំ response ដែលបាន compress៖

   curl -s -o /dev/null -w "%{size_download}\n" https://github.com
   curl -s -o /dev/null -w "%{size_download}\n" --compressed https://github.com
   

   Copy

   តើលេខទីពីរតូចជាងប៉ុន្មាន?

5. កំណត់ពេលការផ្លាស់ប្តូរបន្ទាប់របស់អ្នក។ លើកក្រោយដែលអ្នក merge ការផ្លាស់ប្តូរមួយទៅ site របស់អ្នក សូមកត់ចំណាំថាចំណាយពេលប៉ុន្មាន ទើប reload ធម្មតាបង្ហាញវា — ហើយថាតើ hard reload បង្ហាញវាលឿនជាងឬអត់។

ឥឡូវអ្នកបានឃើញអ្វីៗទាំងអស់ដែលកើតឡើងសម្រាប់ site សាមញ្ញមួយហើយ។ នៅជំពូកបន្ទាប់ យើងនឹងមើលពីរបៀបដែលរឿងនោះផ្លាស់ប្តូរ សម្រាប់ web app និង API។