ไฮไลท์ของ Django: การโต้เถียงเรื่องทรัพย์สินทางปัญญาและไฟล์สื่อ (ตอนที่ 4)

เว็บไซต์ Django เกี่ยวข้องกับไฟล์จำนวนมาก ไม่ใช่แค่ซอร์สโค้ดสำหรับการกำหนดค่า โมเดล มุมมอง และเทมเพลต แต่ยังรวมถึงเนื้อหาแบบคงที่: CSS และ JavaScript, รูปภาพ, ไอคอน ราวกับว่ายังไม่เพียงพอ บางครั้งผู้ใช้ก็เข้ามาและต้องการอัปโหลดไฟล์ของตนเองไปยังเว็บไซต์ของคุณ ก็เพียงพอแล้วที่จะทำให้นักพัฒนาซอฟต์แวร์ทุกคนไม่เชื่อ ไฟล์ได้ทุกที่!

นี่คือสิ่งที่ฉันหวังว่าฉันจะพูดได้ (โดยไม่มีคำเตือน): “ไม่ต้องกังวล Django ช่วยคุณได้!” แต่น่าเสียดาย เมื่อต้องจัดการกับทรัพย์สินแบบคงที่และไฟล์มีเดีย มีข้อแม้ มากมาย ที่ต้องจัดการ

วันนี้ เราจะพูดถึงการจัดเก็บและให้บริการไฟล์สำหรับทั้งเซิร์ฟเวอร์เดียวและการปรับใช้ที่ปรับขนาดได้ ในขณะที่พิจารณาปัจจัยต่างๆ เช่น การบีบอัด การแคช และความพร้อมใช้งาน เราจะหารือเกี่ยวกับค่าใช้จ่ายและประโยชน์ของ CDN และโซลูชันการจัดเก็บไฟล์โดยเฉพาะ

หมายเหตุ : นี่ไม่ใช่บทช่วยสอนเกี่ยวกับวิธีการปรับใช้ไซต์ Django กับแพลตฟอร์มเฉพาะใดๆ เช่นเดียวกับบทความอื่น ๆ ในซีรี่ส์ Django Highlights (ดูด้านล่าง) มีจุดมุ่งหมายเพื่อเป็นแนวทางสำหรับนักพัฒนาและนักออกแบบส่วนหน้าเพื่อทำความเข้าใจส่วนอื่น ๆ ของกระบวนการสร้างเว็บแอปพลิเคชัน วันนี้ เรากำลังมุ่งเน้นไปที่สิ่งที่เกิดขึ้นหลังจากที่แก้ไขด่วนลักษณะหรือกราฟิกที่สวยงามที่คุณเพิ่งทำเสร็จถูกผลักดันให้เป็นผู้เชี่ยวชาญ เราจะร่วมกันพัฒนาสัญชาตญาณสำหรับกลยุทธ์ที่มีให้สำหรับนักพัฒนา Django เพื่อให้บริการไฟล์เหล่านี้แก่ผู้ใช้ทั่วโลกในลักษณะที่ปลอดภัย ประสิทธิภาพ และคุ้มค่า

ส่วนก่อนหน้า ในซีรีส์:

• ส่วนที่ 1: โมเดลผู้ใช้และการตรวจสอบสิทธิ์
• ส่วนที่ 2: เทมเพลตบันทึกเส้น
• ส่วนที่ 3: โมเดล ผู้ดูแลระบบ และการควบคุมฐานข้อมูลเชิงสัมพันธ์
  

คำจำกัดความ

คำศัพท์เหล่านี้ส่วนใหญ่ค่อนข้างตรงไปตรงมา แต่ควรสละเวลาสักครู่เพื่อสร้างคำศัพท์ที่ใช้ร่วมกันสำหรับการสนทนานี้

ไฟล์สามประเภทในแอปพลิเคชั่น Django สดคือ:

1. รหัสแหล่งที่มา
   ไฟล์ Python และ HTML ที่สร้างด้วยเฟรมเวิร์ก Django ไฟล์เหล่านี้เป็นแกนหลักของแอปพลิเคชัน ไฟล์ซอร์สโค้ดโดยทั่วไปมีขนาดเล็กมาก วัดเป็นกิโลไบต์
2. ไฟล์คงที่
   ไฟล์เหล่านี้เรียกอีกอย่างว่า "สินทรัพย์คงที่" รวมถึง CSS และ JavaScript ซึ่งทั้งเขียนโดยผู้พัฒนาแอปพลิเคชันและไลบรารีของบุคคลที่สาม เช่นเดียวกับ PDF โปรแกรมติดตั้งซอฟต์แวร์ รูปภาพ เพลง วิดีโอ และไอคอน ไฟล์เหล่านี้ใช้เฉพาะฝั่งไคลเอ็นต์เท่านั้น ไฟล์สแตติกมีตั้งแต่ CSS สองสามกิโลไบต์ไปจนถึงกิกะไบต์ของวิดีโอ
3. ไฟล์สื่อ
   ไฟล์ใดๆ ที่ผู้ใช้อัปโหลด ตั้งแต่รูปโปรไฟล์ไปจนถึงเอกสารส่วนตัว เรียกว่าไฟล์มีเดีย ไฟล์เหล่านี้ต้องได้รับการจัดเก็บและเรียกค้นข้อมูลสำหรับผู้ใช้อย่างปลอดภัยและเชื่อถือได้ ไฟล์สื่อสามารถมีขนาดใดก็ได้ ผู้ใช้อาจอัปโหลดข้อความธรรมดาสองสามกิโลไบต์ไปยังวิดีโอสองสามกิกะไบต์ หากคุณอยู่ในจุดสิ้นสุดของมาตราส่วนนี้ คุณอาจต้องการคำแนะนำเฉพาะทางมากกว่าที่บทความนี้เตรียมไว้ให้

การปรับใช้ Django สองประเภทคือ:

1. เซิร์ฟเวอร์เดียว
   การปรับใช้ Django เซิร์ฟเวอร์เดียวเป็นสิ่งที่ดูเหมือน: ทุกอย่างอยู่บนเซิร์ฟเวอร์เดียว กลยุทธ์นี้เรียบง่ายมากและคล้ายกับสภาพแวดล้อมการพัฒนาอย่างใกล้ชิด แต่ไม่สามารถจัดการปริมาณการใช้งานจำนวนมากหรือไม่สอดคล้องกันได้อย่างมีประสิทธิภาพ แนวทางแบบเซิร์ฟเวอร์เดียวใช้ได้กับโครงการการเรียนรู้หรือการสาธิตเท่านั้น ไม่ใช่แอปพลิเคชันแบบ real-word ที่ต้องการเวลาทำงานที่เชื่อถือได้
2. ปรับขนาดได้
   มีหลายวิธีในการปรับใช้โปรเจ็กต์ Django ที่ช่วยให้สามารถปรับขนาดให้ตรงตามความต้องการของผู้ใช้ กลยุทธ์เหล่านี้มักเกี่ยวข้องกับการหมุนเซิร์ฟเวอร์จำนวนมากขึ้นและลง และการใช้เครื่องมือต่างๆ เช่น ตัวโหลดบาลานซ์และฐานข้อมูลที่มีการจัดการ โชคดีที่เราสามารถรวมทุกอย่างที่ซับซ้อนกว่าการปรับใช้เซิร์ฟเวอร์เดียวในหมวดหมู่นี้เพื่อวัตถุประสงค์ของบทความนี้ได้อย่างมีประสิทธิภาพ

ตัวเลือกที่ 1: ค่าเริ่มต้น Django

โครงการขนาดเล็กได้รับประโยชน์จากสถาปัตยกรรมที่เรียบง่าย การจัดการเริ่มต้นของ Django สำหรับทรัพย์สินแบบคงที่และไฟล์มีเดียนั้นง่ายมาก สำหรับแต่ละรายการ คุณมีโฟลเดอร์รูทที่เก็บไฟล์และอยู่ถัดจากซอร์สโค้ดบนเซิร์ฟเวอร์ เรียบง่าย. โฟลเดอร์รากเหล่านี้ถูกสร้างขึ้นและจัดการผ่านการกำหนดค่า yourproject/settings.py เป็นส่วนใหญ่

สินทรัพย์คงที่

สิ่งที่สำคัญที่สุดที่ต้องทำความเข้าใจเมื่อทำงานกับไฟล์สแตติกใน Django คือคำสั่ง python manage.py collectstatic คำสั่งนี้จะขยายไปถึงโฟลเดอร์ส แตติก ของแต่ละแอพในโปรเจ็กต์ Django และคัดลอกทรัพย์สินสแตติกทั้งหมดไปยังโฟลเดอร์รูท การรันคำสั่งนี้เป็นส่วนสำคัญในการปรับใช้โปรเจ็กต์ Django พิจารณาโครงสร้างไดเร็กทอรีต่อไปนี้:

 - project - project - settings.py - urls.py - ... - app1 - static/ - app1 - style.css - script.js - img.jpg - templates/ - views.py - ... - app2 - static/ - app2 - style.css - image.png - templates/ - views.py - ...

สมมติการตั้งค่าต่อไปนี้ใน โปรเจ็กต์/settings.py :

 STATIC_URL = "/static/" STATIC_ROOT = "/path/on/server/to/djangoproject/static"

การรันคำสั่ง python manage.py collectstatic จะสร้างโฟลเดอร์ต่อไปนี้บนเซิร์ฟเวอร์:

 - /path/on/server/to/djangoproject/static - app1 - style.css - script.js - img.jpg - app2 - style.css - image.png

โปรดสังเกตว่าภายในโฟลเดอร์สแตติกแต่ละโฟลเดอร์ จะมีอีกโฟลเดอร์หนึ่งที่มีชื่อแอป นี่เป็นการป้องกันความขัดแย้งของเนมสเปซหลังจากรวบรวมไฟล์สแตติก ดังที่คุณเห็นในโครงสร้างไฟล์ด้านบนนี้ ทำให้ app1/style.css และ app2/style.css แตกต่างออกไป จากที่นี่ แอปพลิเคชันจะค้นหาไฟล์สแตติกในโครงสร้างนี้ที่ STATIC_ROOT ระหว่างการใช้งานจริง ดังนั้น อ้างอิงไฟล์สแตติกดังต่อไปนี้ในเทมเพลตใน app1/templates/ :

 {% load static %} <link rel="stylesheet" type="text/css" href="{% static "app1/style.css" %}">

Django คำนวณโดยอัตโนมัติว่าจะรับไฟล์สแตติกจากที่ใดในการพัฒนาเพื่อสร้างแบบจำลองพฤติกรรมนี้ คุณไม่จำเป็นต้องเรียกใช้ collectstatic ระหว่างการพัฒนา

สำหรับรายละเอียดเพิ่มเติม โปรดดูเอกสารประกอบของ Django

ไฟล์สื่อ

ลองนึกภาพเว็บไซต์เครือข่ายมืออาชีพที่มีฐานข้อมูลของผู้ใช้ ผู้ใช้แต่ละรายจะมีโปรไฟล์ที่เชื่อมโยงกัน ซึ่งอาจมีรูปอวาตาร์และเอกสารประวัติย่อ นี่เป็นตัวอย่างสั้นๆ ของข้อมูลดังกล่าว:

 from django.db import models from django.contrib.auth.models import User def avatar_path(instance, filename): return "avatar_{}_{}".format(instance.user.id, filename) class Profile(models.Model): user = models.OneToOneField(User, on_delete=models.CASCADE) resume = models.FileField(upload_to="path/string") avatar = models.ImageField(upload_to=avatar_path)

เพื่อให้ใช้งานได้ คุณต้องมีตัวเลือกต่อไปนี้ใน โปรเจ็กต์/settings.py เช่นเดียวกับสินทรัพย์แบบคงที่:

 MEDIA_URL = "/media/" MEDIA_ROOT = "/path/on/server/to/media"

ImageField สืบทอดมาจาก FileField ดังนั้นจึงใช้พารามิเตอร์และความสามารถเดียวกันร่วมกัน ทั้งสองฟิลด์มีตัวเลือก upload_to อาร์กิวเมนต์ ซึ่งใช้สตริงที่เป็นพาธและผนวกเข้ากับ MEDIA_ROOT เพื่อจัดเก็บไฟล์ ซึ่งสามารถเข้าถึงได้โดยพาธเดียวกันที่ด้านบนของ MEDIA_URL อาร์กิวเมนต์ upload_to สามารถใช้ฟังก์ชันที่ส่งคืนสตริง ดังที่แสดงด้วยฟังก์ชัน avatar_path

ตรวจสอบให้แน่ใจว่าได้ละเว้นไดเร็กทอรีไฟล์สื่อและเนื้อหาจากการควบคุมเวอร์ชัน เนื้อหาอาจขัดแย้งกันเมื่อนักพัฒนาสองคนทดสอบแอปพลิเคชันเดียวกันบนเครื่องที่ต่างกัน และไม่เหมือนกับทรัพย์สินแบบคงที่ ไม่ใช่ส่วนหนึ่งของแอปพลิเคชัน Django ที่ปรับใช้ได้

ตัวเลือกที่ 2: Django พร้อมบริการ

ปรัชญาชี้นำของฉันคือการใช้เครื่องมือสำหรับสิ่งที่พวกเขาทำได้ดีที่สุด Django เป็นเฟรมเวิร์กที่น่าทึ่ง และให้เครื่องมือที่ยอดเยี่ยมสำหรับการรับรองความถูกต้องของผู้ใช้ การเรนเดอร์ฝั่งเซิร์ฟเวอร์ การทำงานกับโมเดลและแบบฟอร์ม ฟังก์ชันการดูแลระบบ และส่วนสำคัญอื่นๆ อีกนับสิบของการสร้างเว็บแอปพลิเคชัน อย่างไรก็ตาม เครื่องมือสำหรับจัดการทรัพย์สินแบบคงที่และไฟล์มีเดีย ในความคิดของฉัน ไม่เหมาะสำหรับการผลิตบนไซต์ที่ปรับขนาดได้ นักพัฒนาหลักของ Django ตระหนักดีว่าหลายคนเลือกวิธีอื่นในการจัดการไฟล์เหล่านี้ในการผลิต เฟรมเวิร์กนั้นดีมากในการหลีกเลี่ยงเมื่อคุณทำ ไซต์ Django ส่วนใหญ่ที่มีไว้สำหรับการใช้งานทั่วไปจะต้องการรวมสินทรัพย์แบบคงที่และจัดการไฟล์มีเดียโดยใช้วิธีการที่ไม่เฉพาะเจาะจงของ Django เหล่านี้

สินทรัพย์คงที่บน CDN

แม้ว่าโปรเจ็กต์ขนาดเล็กถึงขนาดกลางจะหายไปโดยไม่มีโครงการ แต่ CDN (เครือข่ายการจัดส่งเนื้อหา) นั้นใช้งานง่ายและปรับปรุงประสิทธิภาพของแอปพลิเคชันทุกขนาด CDN คือเครือข่ายของเซิร์ฟเวอร์ โดยทั่วไปทั่วโลก ที่แจกจ่ายและให้บริการเนื้อหาเว็บ ซึ่งส่วนใหญ่เป็นทรัพย์สินแบบคงที่ CDN ยอดนิยม ได้แก่ Cloudflare CDN, Amazon CloudFront และ Fastly ในการใช้ CDN คุณต้องอัปโหลดไฟล์สแตติก จากนั้นในแอปพลิเคชันของคุณให้อ้างอิงดังนี้:

 <link rel="stylesheet" type="text/css" href="https://cdn.example.com/path/to/your/files/app1/style.css">

กระบวนการนี้ง่ายต่อการรวมเข้ากับสคริปต์การปรับใช้ Django ของคุณ หลังจากรันคำสั่ง python manage.py collectstatic แล้ว ให้คัดลอกไดเร็กทอรีที่สร้างขึ้นไปยัง CDN ของคุณ (กระบวนการที่แตกต่างกันอย่างมากตามบริการที่คุณใช้) จากนั้นลบเนื้อหาสแตติกออกจากแพ็คเกจการปรับใช้ Django

ในการพัฒนา คุณจะต้องการเข้าถึงสำเนาของทรัพย์สินแบบคงที่ที่แตกต่างจากที่ใช้งานจริง ด้วยวิธีนี้ คุณสามารถทำการเปลี่ยนแปลงภายในเครื่องได้โดยไม่กระทบกับไซต์การผลิต คุณสามารถใช้สินทรัพย์ในเครื่องหรือเรียกใช้ CDN อินสแตนซ์ที่สองเพื่อส่งไฟล์ กำหนดค่า yourproject/settings.py ด้วยตัวแปรที่กำหนดเอง เช่น CDN_URL และใช้ค่านั้นในเทมเพลตของคุณเพื่อให้แน่ใจว่าคุณใช้เนื้อหาเวอร์ชันที่ถูกต้องในการพัฒนาและใช้งานจริง

หมายเหตุสุดท้ายประการหนึ่งคือไลบรารีจำนวนมากสำหรับ CSS และ JavaScript มี CDN ฟรีที่เว็บไซต์ส่วนใหญ่สามารถใช้ได้ หากคุณกำลังโหลด เช่น Bootstrap 4 หรือ underscore.js คุณสามารถข้ามความยุ่งยากในการใช้สำเนาของคุณเองในการพัฒนาและค่าใช้จ่ายในการให้บริการสำเนาของคุณเองในการผลิตโดยใช้ CDN สาธารณะเหล่านี้

ไฟล์มีเดียพร้อมที่เก็บไฟล์เฉพาะ

ไซต์ Django ที่ใช้งานจริงไม่ควรเก็บไฟล์ผู้ใช้ไว้ในโฟลเดอร์ /media/ แบบธรรมดาที่ใดที่หนึ่งบนเซิร์ฟเวอร์ที่รันไซต์ มีเหตุผลสามประการที่ทำไมไม่:

1. หากคุณต้องการขยายขนาดไซต์โดยเพิ่มเซิร์ฟเวอร์หลายเครื่อง คุณต้องมีวิธีคัดลอกและซิงค์ไฟล์ที่อัปโหลดในเซิร์ฟเวอร์เหล่านั้น
2. หากเซิร์ฟเวอร์ขัดข้อง ซอร์สโค้ดจะได้รับการสำรองข้อมูลไว้ในระบบควบคุมเวอร์ชันของคุณ แต่ไฟล์สื่อจะไม่ได้รับการสำรองข้อมูลตามค่าเริ่มต้น เว้นแต่คุณจะกำหนดค่าเซิร์ฟเวอร์ของคุณให้ทำเช่นนั้น แต่สำหรับความพยายามนั้น คุณควรจะใช้เซิร์ฟเวอร์เฉพาะ ที่เก็บไฟล์
3. ในกรณีที่มีกิจกรรมที่เป็นอันตราย ควรเก็บไฟล์ที่ผู้ใช้อัปโหลดไว้บนเซิร์ฟเวอร์ที่แยกจากเซิร์ฟเวอร์ที่เรียกใช้แอปพลิเคชัน แม้ว่าจะไม่ได้ทำให้ข้อกำหนดในการตรวจสอบไฟล์ที่ผู้ใช้อัปโหลดออกไปก็ตาม

การรวมบุคคลที่สามเพื่อจัดเก็บไฟล์ที่ผู้ใช้อัปโหลดนั้นง่ายมาก คุณไม่จำเป็นต้องเปลี่ยนแปลงอะไรในโค้ดของคุณ ยกเว้นการลบหรือแก้ไขค่า FileField upload_to โมเดลของคุณ และกำหนดการตั้งค่าบางอย่าง ตัวอย่างเช่น หากคุณวางแผนที่จะจัดเก็บไฟล์ของคุณใน AWS S3 คุณต้องทำสิ่งต่อไปนี้ ซึ่งคล้ายกับกระบวนการจัดเก็บไฟล์ด้วย Google Cloud, Azure, Backblaze หรือบริการคู่แข่งที่คล้ายกันมาก

ก่อนอื่น คุณจะต้องติดตั้งไลบรารี boto3 และ django-storages จากนั้น คุณต้องตั้งค่าบัคเก็ตและบทบาท IAM บน AWS ซึ่งอยู่นอกขอบเขตของบทความนี้ แต่คุณสามารถดูคำแนะนำได้ที่นี่ เมื่อกำหนดค่าทั้งหมดแล้ว คุณต้องเพิ่มตัวแปรสามตัวใน โปรเจ็ กต์/settings.py ของคุณ:

 DEFAULT_FILE_STORAGE = "storages.backends.s3boto3.S3Boto3Storage" AWS_STORAGE_BUCKET_NAME = "BUCKET_NAME" AWS_S3_REGION_NAME = "us-east-2"

นอกจากนี้ คุณจะต้องตั้งค่าการเข้าถึงข้อมูลประจำตัวไปยังบัคเก็ต AWS ของคุณ บทช่วยสอนบางอย่างจะสาธิตการเพิ่ม ID และรหัสลับในไฟล์การตั้งค่าของคุณหรือเป็นตัวแปรสภาพแวดล้อม แต่สิ่งเหล่านี้เป็นแนวทางปฏิบัติที่ไม่ปลอดภัย ให้ใช้ django-storages กับ AWS CLI เพื่อกำหนดค่าคีย์แทน ตามที่อธิบายไว้ที่นี่ คุณอาจสนใจเอกสาร django-storages

คุณไม่ต้องการให้การพัฒนาหรือทดสอบไฟล์มีเดียปะปนกับการอัปโหลดจากผู้ใช้จริง การหลีกเลี่ยงสิ่งนี้ค่อนข้างง่าย: ตั้งค่าหลายบัคเก็ต อันหนึ่งสำหรับการพัฒนา (หรือหนึ่งอันสำหรับนักพัฒนาแต่ละราย) อันหนึ่งสำหรับการทดสอบ และอีกอันสำหรับการผลิต จากนั้น สิ่งที่คุณต้องทำคือเปลี่ยนการตั้งค่า AWS_STORAGE_BUCKET_NAME ต่อสภาพแวดล้อม เท่านี้คุณก็พร้อมแล้ว

ประสิทธิภาพและความพร้อมใช้งาน

มีหลายปัจจัยที่ส่งผลต่อประสิทธิภาพและความน่าเชื่อถือของเว็บไซต์ของคุณ ต่อไปนี้คือสิ่งสำคัญบางประการในการพิจารณาไฟล์สแตติกและไฟล์สื่อที่มีความสำคัญ ไม่ว่าคุณจะใช้วิธีใดในการจัดการไฟล์เหล่านี้

ค่าใช้จ่าย

การให้บริการไฟล์แก่ผู้ใช้ต้องเสียค่าใช้จ่ายด้วยเหตุผลสองประการ: พื้นที่เก็บข้อมูลและแบนด์วิดท์ คุณต้องจ่ายผู้ให้บริการโฮสต์เพื่อจัดเก็บไฟล์ให้คุณ แต่คุณต้องจ่ายเงินเพื่อให้บริการไฟล์ด้วย แบนด์วิดท์มีราคาแพงกว่าพื้นที่จัดเก็บอย่างมาก (เช่น AWS S3 คิดค่าบริการ 2.3 เซนต์ต่อกิกะไบต์สำหรับพื้นที่จัดเก็บ เทียบกับ 9 เซนต์ต่อกิกะไบต์ของการถ่ายโอนข้อมูลออกทางอินเทอร์เน็ตในขณะที่เขียน) เศรษฐศาสตร์ของที่เก็บไฟล์เช่น S3 หรือ CDN นั้นแตกต่างจากเศรษฐศาสตร์ของโฮสต์ทั่วไปเช่น Digital Ocean droplet ใช้ประโยชน์จากความเชี่ยวชาญพิเศษและการประหยัดจากขนาดโดยการย้ายไฟล์ราคาแพงไปยังบริการที่ออกแบบมาสำหรับพวกเขา นอกจากนี้ ที่เก็บไฟล์และ CDN จำนวนมากเสนอแผนบริการฟรี ดังนั้นไซต์ที่อาจมีขนาดเล็กพอที่จะหลีกหนีโดยไม่ได้ใช้งาน จึงสามารถทำเช่นนั้นได้และเก็บเกี่ยวผลประโยชน์โดยไม่มีค่าใช้จ่ายด้านโครงสร้างพื้นฐานเพิ่มเติม

การบีบอัดและการแปลงรหัส

ปัญหาส่วนใหญ่ที่เกิดจากทรัพย์สินแบบคงที่ เช่น รูปภาพและวิดีโอ เป็นเพราะเป็นไฟล์ขนาดใหญ่ โดยปกติ นักพัฒนาจะจัดการเรื่องนี้โดยพยายามทำให้ไฟล์เหล่านี้มีขนาดเล็กลง มีหลายวิธีในการทำเช่นนี้โดยใช้การบีบอัดและการแปลงรหัสร่วมกันในสองหมวดหมู่ทั่วไป: แบบไม่สูญเสียข้อมูลและการสูญเสีย การบีบอัดแบบไม่สูญเสียข้อมูลจะคงคุณภาพดั้งเดิมของเนื้อหาไว้ แต่ให้ขนาดไฟล์ลดลงเล็กน้อย การบีบอัดแบบ Lossy หรือการแปลงรหัสให้อยู่ในรูปแบบที่สูญเสียข้อมูล ทำให้ไฟล์มีขนาดเล็กลงมากโดยสูญเสียคุณภาพของสิ่งประดิษฐ์ดั้งเดิมบางส่วนไป ตัวอย่างนี้คือการแปลงรหัสวิดีโอเป็นบิตเรตที่ต่ำกว่า สำหรับรายละเอียด โปรดดูบทความเกี่ยวกับการเพิ่มประสิทธิภาพการส่งวิดีโอ เมื่อให้บริการไฟล์ขนาดใหญ่บนเว็บ ความเร็วแบนด์วิดท์มักจะต้องการให้คุณให้บริการไฟล์ที่มีการบีบอัดสูง ซึ่งต้องการการบีบอัดแบบสูญเสียข้อมูล

เว้นแต่คุณจะเป็น YouTube การบีบอัดและการแปลงรหัสจะไม่เกิดขึ้นทันที เนื้อหาแบบคงที่ควรมีรูปแบบที่เหมาะสมก่อนการปรับใช้งาน และคุณสามารถบังคับใช้ข้อจำกัดประเภทไฟล์พื้นฐานและขนาดไฟล์ในการอัปโหลดของผู้ใช้เพื่อให้แน่ใจว่ามีการบีบอัดที่เพียงพอและการจัดรูปแบบที่เหมาะสมในไฟล์สื่อของผู้ใช้ของคุณ

การย่อขนาด

แม้ว่าไฟล์ของ JavaScript และ CSS มักจะมีขนาดไม่ใหญ่เท่ากับรูปภาพ แต่บ่อยครั้งสามารถบีบอัดให้มีขนาดเล็กลงได้ กระบวนการนี้เรียกว่าการลดขนาด การลดขนาดไม่เปลี่ยนการเข้ารหัสของไฟล์ ไฟล์ยังคงเป็นข้อความ และไฟล์ที่ย่อเล็กสุดยังคงต้องเป็นรหัสที่ถูกต้องสำหรับภาษาต้นฉบับ ไฟล์ที่ย่อเล็กสุดจะคงนามสกุลเดิมไว้

สิ่งสำคัญที่ถูกลบในไฟล์ย่อเล็กสุดคือช่องว่างที่ไม่จำเป็น และจากมุมมองของคอมพิวเตอร์ ช่องว่างเกือบทั้งหมดใน CSS และ JavaScript นั้นไม่จำเป็น แผนการย่อขนาดยังทำให้ชื่อตัวแปรสั้นลงและลบความคิดเห็นออก

การลดขนาดโดยค่าเริ่มต้นจะทำให้โค้ดสับสน ในฐานะนักพัฒนา คุณควรทำงานกับไฟล์ที่ไม่ย่อขนาดเท่านั้น ขั้นตอนอัตโนมัติบางอย่างในระหว่างกระบวนการปรับใช้ควรลดขนาดไฟล์ก่อนที่จะจัดเก็บและให้บริการ หากคุณกำลังใช้ไลบรารีที่จัดเตรียมโดย CDN บุคคลที่สาม ตรวจสอบให้แน่ใจว่าคุณใช้ไลบรารีเวอร์ชันย่อเล็กสุดของไลบรารีนั้น หากมี ไฟล์ HTML สามารถลดขนาดลงได้ แต่เนื่องจาก Django ใช้การเรนเดอร์ฝั่งเซิร์ฟเวอร์ ค่าใช้จ่ายในการดำเนินการในทันทีมักจะมีค่ามากกว่าขนาดเพจที่ลดลงเล็กน้อย

ความพร้อมใช้งานทั่วโลก

เช่นเดียวกับการใช้เวลาส่งจดหมายถึงเพื่อนบ้านน้อยกว่าการส่งทั่วประเทศ ดังนั้นการส่งข้อมูลในบริเวณใกล้เคียงจึงใช้เวลาน้อยกว่าทั่วโลก วิธีหนึ่งที่ CDN ปรับปรุงประสิทธิภาพของเพจคือการคัดลอกเนื้อหาไปยังเซิร์ฟเวอร์ทั่วโลก จากนั้น เมื่อไคลเอนต์ส่งคำขอ พวกเขาจะได้รับทรัพย์สินแบบคงที่จากเซิร์ฟเวอร์ที่ใกล้ที่สุด (มักเรียกว่าโหนดขอบ) ซึ่งจะช่วยลดเวลาในการโหลด ข้อดีอย่างหนึ่งของการใช้ CDN กับไซต์ Django คือการแยกการแจกจ่ายทรัพย์สินแบบคงที่ทั่วโลกออกจากการแจกจ่ายโค้ดของคุณทั่วโลก

การแคชฝั่งไคลเอ็นต์

อะไรจะดีไปกว่าการมีไฟล์สแตติกบนเซิร์ฟเวอร์ใกล้กับผู้ใช้ของคุณ มีไฟล์สแตติกเก็บไว้ในอุปกรณ์ของผู้ใช้แล้ว! การแคชเป็นกระบวนการในการจัดเก็บผลลัพธ์ของการคำนวณหรือการร้องขอ เพื่อให้สามารถเข้าถึงได้ซ้ำๆ ได้เร็วขึ้น เช่นเดียวกับสไตล์ชีต CSS ที่สามารถแคชได้ทั่วโลกใน CDN สามารถแคชในเบราว์เซอร์ของลูกค้าในครั้งแรกที่พวกเขาโหลดหน้าจากไซต์ของคุณ จากนั้น สไตล์ชีตจะพร้อมใช้งานบนอุปกรณ์ในคำขอครั้งต่อๆ ไป ดังนั้นไคลเอ็นต์จึงส่งคำขอน้อยลง ปรับปรุงเวลาในการโหลดหน้าเว็บ และลดการใช้แบนด์วิดท์

เบราว์เซอร์ดำเนินการแคชของตัวเอง แต่ถ้าไซต์ของคุณมีการรับส่งข้อมูลจำนวนมาก คุณสามารถปรับพฤติกรรมการแคชฝั่งไคลเอ็นต์ของคุณให้เหมาะสมได้โดยใช้เฟรมเวิร์กแคชของ Django

สรุปแล้ว

อีกครั้ง ปรัชญาชี้นำของฉันคือการใช้เครื่องมือสำหรับสิ่งที่พวกเขาทำได้ดีที่สุด โปรเจ็กต์เซิร์ฟเวอร์เดียวและการปรับใช้ที่ปรับขนาดได้ขนาดเล็กที่มีสินทรัพย์สแตติกน้ำหนักเบาเท่านั้นสามารถใช้การจัดการสินทรัพย์สแตติกในตัวของ Django ได้ แต่แอปพลิเคชันส่วนใหญ่ควรแยกสินทรัพย์ออกเพื่อให้บริการผ่าน CDN

หากโปรเจ็กต์ของคุณมีจุดประสงค์เพื่อการใช้งานจริงทุกประเภท อย่าเก็บไฟล์มีเดียด้วยวิธีเริ่มต้นของ Django ให้ใช้บริการแทน ด้วยทราฟฟิกที่เพียงพอ โดยที่ “ทราฟฟิกที่เพียงพอ” เป็นจำนวนที่ค่อนข้างน้อยบนมาตราส่วนของอินเทอร์เน็ต ความยุ่งยากเพิ่มเติมของสถาปัตยกรรม กระบวนการพัฒนา และการปรับใช้นั้นคุ้มค่ามากกว่าสำหรับประสิทธิภาพ ความน่าเชื่อถือ และการประหยัดต้นทุนของการใช้ แยก CDN และโซลูชันการจัดเก็บไฟล์สำหรับไฟล์สแตติกและไฟล์มีเดียตามลำดับ

การอ่านที่แนะนำ

• ส่วนที่ 1: โมเดลผู้ใช้และการตรวจสอบสิทธิ์
• ส่วนที่ 2: เทมเพลตบันทึกเส้น
• ส่วนที่ 3: โมเดล ผู้ดูแลระบบ และการควบคุมฐานข้อมูลเชิงสัมพันธ์