ខាងក្នុង Browser៖ ពី HTML ទៅជា Pixel

មាតិកា

  1. Browser មានទំព័រអត្ថបទមួយ
  2. Parsing៖ អត្ថបទក្លាយជា DOM
  3. ទំព័រមួយ Request ច្រើន
  4. CSS និង Script អាចធ្វើឲ្យរង់ចាំ
  5. Layout, Paint និងអេក្រង់
  6. JavaScript ផ្លាស់ប្តូរទំព័រនៅពេលក្រោយ
  7. ការអាន Waterfall
  8. View Source ធៀបនឹង Elements
  9. សាកល្បងដោយខ្លួនឯង

1. Browser មានទំព័រអត្ថបទមួយ

នៅចុងបញ្ចប់នៃជំពូកទី 6 browser មាន response 200 OK ដែលមាន Content-Type: text/html និង body ដូចនេះ — គឺ index.html ពីស៊េរី Git ដោយបន្ថែមរូបថតមួយ និង script មួយ៖

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>Dara Sok</title>
    <link rel="stylesheet" href="style.css">
  </head>
  <body>
    <h1>Hi, I'm Dara</h1>
    <img src="photo.jpg" alt="Dara smiling">
    <p><a href="about.html">About me</a></p>
    <script src="app.js"></script>
  </body>
</html>

នោះគ្រាន់តែជាអត្ថបទប៉ុណ្ណោះ។ សម្រាប់អ្នក វាច្បាស់ណាស់ថាជាទំព័រដែលមានចំណងជើង រូបថត និង link មួយ។ ប៉ុន្តែសម្រាប់ browser វាគ្រាន់តែជា byte ពីរបីរយ ដែលត្រូវតែក្លាយជា pixel មានពណ៌។ ជំពូកនេះនឹងតាមដាន byte ទាំងនោះ។ អ្នកនឹងរៀន សរសេរ HTML និង CSS នៅក្នុងស៊េរីបន្ទាប់លើផែនទីការសិក្សា ចំណែកនៅទីនេះ អ្នកគ្រាន់តែត្រូវដឹងថា browser ធ្វើអ្វីជាមួយពួកវា។

2. Parsing៖ អត្ថបទក្លាយជា DOM

Browser អាន HTML ពីលើចុះក្រោម ហើយបង្កើត tree (មែកធាង) នៃអ្វីៗទាំងអស់ដែលនៅក្នុងនោះ។ Tree នេះត្រូវបានហៅថា DOM — Document Object Model៖

document
└── html
    ├── head
    │   ├── meta
    │   ├── title ── "Dara Sok"
    │   └── link (style.css)
    └── body
        ├── h1 ── "Hi, I'm Dara"
        ├── img (photo.jpg)
        ├── p
        │   └── a (about.html) ── "About me"
        └── script (app.js)

ប្រអប់នីមួយៗគឺជា node មួយ។ Element ដែលនៅក្នុង element ផ្សេងទៀត ក្លាយជាកូន (children) របស់វា ដូចជា folder នៅក្នុង folder នៅក្នុងប្រព័ន្ធ file ដែរ។ DOM គឺជាគំរូពិតប្រាកដរបស់ browser អំពីទំព័រ — អ្វីដែលវាគូរ និងអ្វីដែល JavaScript អាន និងផ្លាស់ប្តូរ។

Browser ចាប់ផ្តើម parse ភ្លាមៗនៅពេល byte ដំបូងមកដល់។ វាមិនរង់ចាំ file ទាំងមូលទេ ដែលនេះជាមូលហេតុមួយដែលទំព័រអាចចាប់ផ្តើមលេចឡើង មុនពេលវាទាញយករួចទាំងស្រុង។

HTML parser ក៏អត់ឱនខ្លាំងណាស់ដែរ។ ភ្លេចបិទ </p> ហើយ browser នឹងស្មានដោយស្ងាត់ៗនូវអ្វីដែលអ្នកចង់បាន។ នោះជារឿងល្អ ប៉ុន្តែវាមានន័យថា HTML ដែលខូច ច្រើនតែ «ដំណើរការ» តាមរបៀបដែលអ្នកមិនបានចង់។

3. ទំព័រមួយ Request ច្រើន

ខណៈពេល parse browser រកឃើញអ្វីៗដែលទំព័រ ត្រូវការ ប៉ុន្តែមិនមាននៅក្នុងខ្លួន៖ style.css នៅក្នុង <link> photo.jpg នៅក្នុង <img> និង app.js នៅក្នុង <script>។ សម្រាប់នីមួយៗ វាផ្ញើ request ថ្មី មួយ — ប្រភេទដូចគ្នាដែលអ្នកបានឃើញក្នុងជំពូកទី 5 ហើយជាធម្មតាតាមរយៈការតភ្ជាប់ដដែល៖

GET /my-site/            → index.html   (the page itself)
GET /my-site/style.css   → the styles
GET /my-site/photo.jpg   → the image
GET /my-site/app.js      → the script
GET /favicon.ico         → the little icon in the tab

Relative path ពីជំពូកទី 2 ត្រូវបានបកស្រាយនៅទីនេះ៖ style.css នៅលើទំព័រ /my-site/ ក្លាយជា /my-site/style.css។

Website ផ្ទាល់ខ្លួនតូចមួយ ប្រហែលជាត្រូវការ request ប្រាំ។ គេហទំព័រព័ត៌មាន ឬហាងអនឡាញ អាចត្រូវការ ពីររយ៖ font រូបភាព script style ពាណិជ្ជកម្ម analytics វីដេអូ។ នីមួយៗគឺជា request និង response ពេញលេញមួយ។ នោះហើយជាមូលហេតុដែលជំពូកទី 4 យកចិត្តទុកដាក់ខ្លាំងលើការប្រើការតភ្ជាប់ឡើងវិញ ហើយហេតុអ្វីជំពូកទី 9 យកចិត្តទុកដាក់ខ្លាំងលើ cache។

Link ទៅ about.html មិនទាន់ ត្រូវបាន request នៅឡើយទេ។ Link នឹង load តែនៅពេលអ្នកចុចវាប៉ុណ្ណោះ។

4. CSS និង Script អាចធ្វើឲ្យរង់ចាំ

Resource ខ្លះធ្វើឲ្យ browser រង់ចាំ មុនពេលវាបង្ហាញអ្វីមួយ៖

  • CSS block ការ render។ Browser នឹងមិនគូរទំព័រទេ រហូតដល់ stylesheet នៅក្នុង <head> មកដល់ — បើមិនដូច្នោះទេ អ្នកនឹងឃើញទំព័រគ្មាន style មួយភ្លែត បន្ទាប់មកលោតផ្លាស់ប្តូរនៅពេល style load រួច។
  • Script block ការ parse។ នៅពេល parser ជួប <script> ធម្មតាមួយ វាឈប់ ទាញយក script ដំណើរការវា ហើយទើបបន្តទៅមុខ ព្រោះ script នោះអាចផ្លាស់ប្តូរទំព័របាន។

នោះហើយជាមូលហេតុដែលពីមុនគេដាក់ script នៅ ចុងបញ្ចប់ នៃ <body> ដូច app.js ខាងលើ៖ នៅពេល parser ទៅដល់វា ទំព័រដែលមើលឃើញត្រូវបានបង្កើតរួចហើយ។ ទំព័រសម័យថ្មីច្រើនតែប្រើ <script defer> ជំនួសវិញ ដែលមានន័យថា «ទាញយកវានៅខាងក្រោយ ហើយដំណើរការវាបន្ទាប់ពី parse រួច»៖

<script src="app.js" defer></script>

រូបភាពមិន block អ្វីទេ។ ទំព័របង្ហាញឡើងដោយគ្មានពួកវា ហើយពួកវាលេចឡើងនៅពេលមកដល់ — គឺជាឥរិយាបថ async ដែលអ្នកបានសម្គាល់នៅចុងបញ្ចប់នៃជំពូក Input/Output ក្នុងស៊េរី របៀបដែលកុំព្យូទ័រដំណើរការ។

5. Layout, Paint និងអេក្រង់

នៅពេល browser មាន DOM និង CSS ហើយ វាបំប្លែងពួកវាទៅជា pixel តាមរយៈជំហានសំខាន់ៗ៖

 DOM + CSS ──▶ Style ──▶ Layout ──▶ Paint ──▶ Composite ──▶ Screen
  1. Style៖ គណនាថា CSS rule ណាខ្លះអនុវត្តចំពោះ node នីមួយៗ។ «h1 នេះមានទំហំ 32px ដិត ពណ៌ខៀវចាស់»។
  2. Layout៖ គណនាថាអ្វីៗនៅទីណា និងធំប៉ុណ្ណា។ «h1 ចាប់ផ្តើម 16px ពីខាងឆ្វេង ទទឹង 600px និងកម្ពស់ 40px»។ រឿងនេះអាស្រ័យលើទំហំ window — ដែលនេះជាមូលហេតុដែលទំព័ររៀបចំខ្លួនឡើងវិញនៅពេលអ្នកប្តូរទំហំវា ឬបង្វិលទូរស័ព្ទរបស់អ្នកផ្តេក។
  3. Paint៖ បំពេញ pixel ពិតប្រាកដ — អក្សរ ពណ៌ ស៊ុម រូបភាព។
  4. Composite៖ ដាក់ស្រទាប់ដែលបាន paint រួចត្រួតលើគ្នា ដោយប្រើ GPU ហើយប្រគល់រូបភាពចុងក្រោយទៅប្រព័ន្ធប្រតិបត្តិការ ដើម្បីបង្ហាញលើអេក្រង់។

នេះគឺជាចុងបញ្ចប់នៃដំណើរដែលជំពូកចុងក្រោយនៃស៊េរី របៀបដែលកុំព្យូទ័រដំណើរការ បានតាមដាន៖ browser គឺជា process មួយ ជំហានទាំងនេះដំណើរការលើ thread របស់វា ហើយ GPU ដាក់លទ្ធផលលើអេក្រង់របស់អ្នក។

6. JavaScript ផ្លាស់ប្តូរទំព័រនៅពេលក្រោយ

ការ render មិនមែនកើតឡើងតែម្តងទេ។ JavaScript អាចផ្លាស់ប្តូរ DOM បានគ្រប់ពេល — បន្ថែម node មួយ ផ្លាស់ប្តូរអត្ថបទខ្លះ លាក់ menu មួយ — ហើយ browser ធ្វើជំហាន style, layout និង paint ឡើងវិញសម្រាប់ផ្នែកដែលបានផ្លាស់ប្តូរ។

JavaScript ក៏អាច ផ្ញើ request ផ្ទាល់ខ្លួន បានដែរ ដោយប្រើ function មួយឈ្មោះ fetch()៖

const response = await fetch("/api/messages");
const messages = await response.json();

នោះគឺជា HTTP request ធម្មតាមួយ ដូចគ្នាបេះបិទនឹង request ក្នុងជំពូកទី 5 ដែរ — គ្រាន់តែវាកើតឡើងបន្ទាប់ពីទំព័រ load រួច ដោយ address bar មិនផ្លាស់ប្តូរ។ នេះជារបៀបដែលកម្មវិធី chat បង្ហាញសារថ្មីៗ ឬហាងអនឡាញ update កន្ត្រករបស់អ្នក ដោយមិនចាំបាច់ reload ទំព័រទាំងមូល។ អ្នកនឹងឃើញ request ទាំងនេះនៅក្នុង Network tab របស់ DevTools ក្រោម filter Fetch/XHR ហើយអ្នកនឹងរៀនសរសេរពួកវានៅក្នុង មូលដ្ឋានគ្រឹះ JavaScript និង TypeScript។ ជំពូកទី 10 ពន្យល់ថា server ប្រភេទណាដែលឆ្លើយតបពួកវា។

7. ការអាន Waterfall

Network tab មាន column Waterfall៖ របារមួយសម្រាប់ request នីមួយៗ ដែលបង្ហាញថាវាចាប់ផ្តើមនៅពេលណា និងចំណាយពេលប៉ុន្មាន។ នៅលើទំព័រសាមញ្ញមួយ វាមើលទៅប្រហែលដូចនេះ៖

 index.html  ████
 style.css       ███
 photo.jpg       ██████████
 app.js          ██
 favicon.ico               █
            └────────────────────▶ time

អានវាពីលើចុះក្រោម៖

  • ទំព័រខ្លួនឯងមកមុនគេ។ គ្មានអ្វីផ្សេងទៀតអាចចាប់ផ្តើមបានទេ រហូតដល់ browser បាន parse HTML គ្រប់គ្រាន់ ដើម្បីរកឃើញវា។
  • បន្ទាប់មក resource ដែលវារកឃើញចាប់ផ្តើមព្រមគ្នា ស្របគ្នា (parallel)។
  • File ធំៗដូចជារូបភាព មានរបារវែងជាងគេ។

ដាក់ mouse លើរបារមួយ ដើម្បីមើលការបំបែករបស់វា — ជំហាន DNS ការតភ្ជាប់ និង TLS ដូចគ្នាដែលអ្នកបានឃើញក្នុង tab Timing នៃជំពូកទី 4 បូកនឹង Waiting (server កំពុងគិត) និង Content Download។

នៅខាងក្រោមនៃ panel អ្នកនឹងឃើញការសង្ខេបមួយ៖ ចំនួន request ចំនួន byte និងពេលវេលាពីរ។ DOMContentLoaded គឺជាពេលដែល HTML ត្រូវបាន parse រួចទាំងស្រុង ចំណែក Load គឺជាពេលដែលអ្វីៗទាំងអស់ រួមទាំងរូបភាពគ្រប់សន្លឹក បាន load រួចរាល់។

8. View Source ធៀបនឹង Elements

DevTools ផ្តល់ឲ្យអ្នកនូវទិដ្ឋភាពពីរផ្សេងគ្នានៃទំព័រមួយ ហើយពួកវាមិនតែងតែដូចគ្នាទេ៖

  • View source (right-click → View Page Source ឬដាក់ view-source: នៅខាងមុខ URL) បង្ហាញ HTML ដែល server បានផ្ញើមក — ដូចគ្នាបេះបិទនឹងអ្វីដែល curl បង្ហាញ។
  • Tab Elements (ឬ Inspector ក្នុង Firefox) បង្ហាញ DOM នៅពេលនេះ បន្ទាប់ពី parser បានកែកំហុស ហើយ JavaScript បានធ្វើការផ្លាស់ប្តូររបស់វា។

នៅលើ site សាមញ្ញរបស់អ្នក ពួកវានឹងមើលទៅស្ទើរតែដូចគ្នា។ នៅលើ web app សម័យថ្មី view source អាចបង្ហាញទំព័រស្ទើរតែទទេ ដែលមានត្រឹមតែ <div id="root"></div> និង script ខ្លះ — ចំណែក Elements បង្ហាញ app ពេញលេញ ព្រោះ JavaScript បានបង្កើតវាទាំងអស់នៅក្នុង browser។ ភាពខុសគ្នានោះគឺជាប្រធានបទនៃជំពូកទី 10។

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

  1. រាប់ request។ បើក site GitHub Pages របស់អ្នក និងគេហទំព័រព័ត៌មាន ឬហាងអនឡាញធំមួយ ដោយបើក DevTools → Network ហើយ reload។ ប្រៀបធៀបចំនួន request និងទំហំសរុបនៅខាងក្រោម panel។
  2. ធ្វើឲ្យវាយឺត។ នៅក្នុង Network tab រក menu throttling (វាសរសេរថា No throttling) ហើយជ្រើស Slow 4G ឬ 3G។ ធីក Disable cache ហើយ reload site ធំមួយ។ មើលទំព័របង្កើតខ្លួនឡើងម្តងមួយផ្នែកៗ៖ អក្សរមុន បន្ទាប់មក style បន្ទាប់មករូបភាព។ ប្តូរវាត្រឡប់ទៅ No throttling វិញនៅពេលអ្នកធ្វើរួច។
  3. បំបែក style។ Right-click លើ request style.css របស់អ្នក ហើយជ្រើស Block request URL បន្ទាប់មក reload។ នោះគឺជាទំព័ររបស់អ្នកដែលមានតែ HTML។ ដោះការ block វាវិញបន្ទាប់ពីនោះ (នៅក្នុង panel Network request blocking ឬដោយ right-click ម្តងទៀត)។
  4. កែ DOM។ នៅក្នុង Elements ចុចពីរដងលើអក្សរនៃ h1 របស់អ្នក ហើយផ្លាស់ប្តូរវា។ ទំព័រ update ភ្លាមៗ — ប៉ុន្តែ reload ហើយវាបាត់។ អ្នកបានផ្លាស់ប្តូរ DOM របស់ browser មិនមែន file នៅលើ server ទេ។
  5. ប្រៀបធៀបទិដ្ឋភាពទាំងពីរ។ បើក view-source: សម្រាប់ site របស់អ្នក បន្ទាប់មកសម្រាប់ web app ធំមួយដូចជា YouTube។ តើមួយណាមើលទៅដូច tab Elements ហើយមួយណាមិនដូច?

ទំព័រនៅលើអេក្រង់ហើយ។ បន្ទាប់ យើងនឹងមើលពីរបៀបដែល website មួយចងចាំថាអ្នកជានរណា ពី request មួយទៅ request បន្ទាប់ — ទោះបីជា HTTP ខ្លួនឯងភ្លេចអ្វីៗទាំងអស់ក៏ដោយ។

មុនHTTP Response និង Status Codeបន្ទាប់Cookie, Session និង State

ទិញកាហ្វេជូនខ្ញុំ

ចូលចិត្តមេរៀននេះមែនទេ? សូមពិចារណាទិញកាហ្វេជូនខ្ញុំមួយកែវ ដើម្បីគាំទ្រការបង្កើតមាតិកាឥតគិតថ្លៃបន្ថែមទៀត!