วิธีโฮสต์ฟอนต์ไว้ในเครื่องแทนการใช้ Google Fonts

ทำไมจึงควร self-host Google Fonts?

Google Fonts ทำให้การใช้ตัวอักษรที่ดีเป็นเรื่องง่าย เพิ่ม stylesheet เลือกน้ำหนักไม่กี่แบบ แล้วปล่อยหน้าเว็บขึ้นใช้งานได้เลย หลายปีที่ผ่านมา นี่เป็นค่าเริ่มต้นที่สมเหตุสมผลสำหรับทีมขนาดเล็ก

ข้อแลกเปลี่ยนคือ browser ของผู้เข้าชมทุกคนต้องติดต่อบริการของบุคคลที่สามเพื่อดึง font CSS และไฟล์ฟอนต์ ซึ่งมีผลตามมาสองอย่าง

อย่างแรก มันเพิ่ม dependency ภายนอกเข้าไปในกระบวนการ rendering หาก font CSS ช้า ถูกบล็อก หรือไม่พร้อมใช้งานในภูมิภาคหรือเครือข่ายของผู้ใช้ หน้าเว็บของคุณก็ต้องรอหรือถอยกลับไปใช้ฟอนต์สำรอง

อย่างที่สอง มันทำให้เกิดคำถามด้านความเป็นส่วนตัว คำขอฟอนต์สามารถเปิดเผย IP address, user agent, บริบทของ referrer policy และข้อมูลเวลาให้กับบุคคลที่สามได้ Google Fonts ระบุว่าไม่ได้ตั้ง cookies ผ่าน Fonts API แต่ “no cookies” ไม่ได้เท่ากับ “no personal data” ภายใต้ GDPR, IP address ยังอาจเป็น personal data ได้ตามบริบท

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

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

อะไรเปลี่ยนไปเมื่อคุณ self-host

เมื่อคุณใช้ Google Fonts ตามวิธีปกติ หน้าเว็บของคุณจะทำสิ่งนี้:

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?family=Inter:wght@400;600&display=swap" rel="stylesheet">

browser จะขอ CSS จาก fonts.googleapis.com ก่อน จากนั้นจึงดาวน์โหลดไฟล์ฟอนต์จาก fonts.gstatic.com

เมื่อคุณ self-host หน้าเว็บของคุณควรขอทั้ง CSS และไฟล์ฟอนต์จากโดเมนของคุณเอง:

@font-face {
  font-family: "Inter";
  src: url("/fonts/inter-latin-400.woff2") format("woff2");
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}

สิ่งนี้จะตัดคำขอฟอนต์ไปยังบุคคลที่สามออกไป และยังทำให้คุณต้องรับผิดชอบการเลือก file formats, cache headers, fallback fonts และการอัปเดตเอง

ความรับผิดชอบนี้ควรให้ความสำคัญอย่างจริงจัง ฟอนต์อยู่บน critical rendering path การตั้งค่าฟอนต์ที่ไม่ดีอาจทำให้ข้อความมองไม่เห็น เกิด layout shifts และ first render ช้า

ขั้นตอนที่ 1: ตรวจสอบว่าคุณใช้อะไรจริง ๆ

ก่อนดาวน์โหลดอะไร ให้ระบุ font families, weights, styles และ character sets ที่เว็บไซต์ของคุณต้องการจริง ๆ

เว็บไซต์การตลาดทั่วไปอาจต้องใช้:

• Regular 400 สำหรับ body text
• Semibold 600 หรือ bold 700 สำหรับหัวข้อและปุ่ม
• Italic 400 เฉพาะเมื่อดีไซน์ใช้ตัวเอียงจริง ๆ
• Latin character set เท่านั้น เว้นแต่เว็บไซต์จะรองรับหลายภาษา

ควรระวังค่าเริ่มต้นเก่า ๆ ของ design system หลายเว็บไซต์โหลด 300, 400, 500, 600, 700, italics และหลาย scripts เพียงเพราะมีใครบางคนเคยเลือกไว้ใน font picker ครั้งหนึ่ง

ใน browser DevTools ให้เปิด Network panel กรองด้วย “font” โหลดหน้าใหม่ แล้วตรวจสอบว่าไฟล์ใดถูกขอ จากนั้นตรวจ CSS ของคุณว่ามีการใช้ font-weight อย่างไร หาก CSS ของคุณไม่เคยใช้ 300 ก็อย่าโฮสต์ 300

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

ขั้นตอนที่ 2: ดาวน์โหลดไฟล์ฟอนต์ที่ถูกต้อง

Google Fonts ให้บริการฟอนต์แบบ open-source คุณสามารถดาวน์โหลดได้จากเว็บไซต์ Google Fonts หรือจาก repository ของโปรเจกต์ฟอนต์ที่เกี่ยวข้อง ตรวจสอบ license เสมอ แต่ Google Fonts ส่วนใหญ่เผยแพร่ภายใต้ open licenses เช่น SIL Open Font License หรือ Apache License

สำหรับเว็บ ให้เลือก WOFF2 เป็นหลัก ฟอร์แมตนี้รองรับอย่างกว้างขวางใน browser สมัยใหม่และมักมีขนาดเล็กกว่า TTF หรือ OTF มาก ในปี 2026 การให้ browser โหลด TTF โดยตรงแทบไม่มีเหตุผลสำหรับเว็บไซต์สาธารณะ

โครงสร้าง directory ที่สมเหตุสมผลมีหน้าตาแบบนี้:

/public
  /fonts
    inter-latin-400.woff2
    inter-latin-600.woff2
    inter-latin-700.woff2

ใช้ชื่อไฟล์ที่อธิบายตัวเองได้ อีกหกเดือนต่อมา font.woff2 จะน่ารำคาญ ส่วน inter-latin-600.woff2 นั้นเรียบและมีประโยชน์

หากเว็บไซต์ของคุณใช้ build system ให้เก็บ source fonts ไว้ในที่ที่ชัดเจน และให้ build pipeline คัดลอกไฟล์ที่ optimize แล้วไปยัง public assets directory

ขั้นตอนที่ 3: ทำ subset ฟอนต์เมื่อเหมาะสม

Subsetting หมายถึงการลบอักขระที่คุณไม่ต้องการออก ฟอนต์แบบเต็มอาจมี Latin, Cyrillic, Greek, Vietnamese, symbols และ OpenType features จำนวนมาก หาก landing page ภาษาอังกฤษอย่างเดียวของคุณต้องการเพียงอักขระ Latin subset จะทำให้ไฟล์เล็กลงได้มาก

มีสองแนวทางที่พบบ่อย:

1. ใช้ subset ที่ผู้ให้บริการฟอนต์หรือ repository เตรียมไว้ให้
2. สร้าง subset เองด้วยเครื่องมือฟอนต์ เช่น pyftsubset จาก fonttools

สำหรับหลายทีม prebuilt Latin subsets ก็เพียงพอแล้ว Custom subsetting มีประโยชน์เมื่อคุณมีหน้าที่มีข้อจำกัดมาก เช่น campaign page หน้าเดียวที่มีข้อความจำกัด หรือ product UI ที่คาดการณ์ character coverage ได้

ระวังเว็บไซต์หลายภาษา glyphs ที่ขาดหายจะทำให้เกิดการผสม fallback font ซึ่งอาจดูเสียและทำให้อ่านยาก หากคุณรองรับหลายภาษา ให้จับคู่ font subsets กับ language routes แทนการบังคับใช้ subset เล็ก ๆ ชุดเดียวทุกที่

ขั้นตอนที่ 4: เขียนกฎ @font-face

การตั้งค่า local แบบน้อยที่สุดมีหน้าตาแบบนี้:

@font-face {
  font-family: "Inter";
  src: url("/fonts/inter-latin-400.woff2") format("woff2");
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}

@font-face {
  font-family: "Inter";
  src: url("/fonts/inter-latin-600.woff2") format("woff2");
  font-weight: 600;
  font-style: normal;
  font-display: swap;
}

body {
  font-family: "Inter", system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif;
}

มีรายละเอียดบางอย่างที่สำคัญตรงนี้

ใช้ font-display: swap สำหรับเว็บไซต์เนื้อหาส่วนใหญ่ มันบอก browser ให้แสดงข้อความ fallback อย่างรวดเร็ว แล้วค่อยสลับเป็น web font เมื่อมาถึง วิธีนี้หลีกเลี่ยง FOIT เวอร์ชันที่แย่ที่สุด: flash of invisible text

กำหนด fallback stack ให้ชัดเจน หาก custom font ล้มเหลว ผู้ใช้ยังควรได้อ่านข้อความที่อ่านได้ Fallbacks ไม่ใช่สิ่งที่คิดทีหลัง แต่เป็นส่วนหนึ่งของดีไซน์ หากคุณต้องทบทวน sizing, line length และตัวเลือก body text ให้เริ่มจาก คู่มือเชิงปฏิบัติสำหรับตัวอักษรที่อ่านง่ายบนเว็บสมัยใหม่

จับคู่น้ำหนักให้ถูกต้อง หาก CSS ของคุณเรียก font-weight: 500 แต่คุณกำหนดไว้แค่ 400 และ 700 browser อาจสังเคราะห์น้ำหนักกึ่งกลางขึ้นมา ซึ่งไม่ได้แย่เสมอไป แต่อาจทำให้หน้าตาไม่สม่ำเสมอ

ขั้นตอนที่ 5: ลบการเรียก Google Fonts ภายนอก

หลังจากเพิ่ม local font CSS แล้ว ให้ลบ remote calls เดิมออกจาก templates ของคุณ

มองหาสิ่งเหล่านี้:

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?..." rel="stylesheet">

ตรวจสอบด้วย:

• Theme settings ใน CMS platforms
• Page-builder typography panels
• Third-party widgets
• Tag managers
• CSS imports เก่า เช่น @import url('https://fonts.googleapis.com/...')

ข้อสุดท้ายพบบ่อย CSS @import สำหรับฟอนต์มักแย่กว่าด้านประสิทธิภาพ เพราะทำให้ browser ค้นพบช้าลง หากคุณ self-host ให้กำหนดฟอนต์โดยตรงใน CSS หลักหรือไฟล์ font CSS ที่โหลดตั้งแต่ช่วงต้น

งานด้านความเป็นส่วนตัวมักล้มเหลวเพราะทีมแก้ template ที่เห็นชัด แต่พลาด scripts, widgets และ legacy embeds รูปแบบเดียวกันนี้พบได้ในงานด้าน consent ด้วย คู่มือของเราเรื่อง สิ่งที่เปลี่ยนไปสำหรับ cookies ในปี 2026 เป็นบทความคู่กันที่มีประโยชน์ หากคุณกำลังลดพื้นที่สัมผัสของบุคคลที่สามในภาพรวม

ขั้นตอนที่ 6: ตั้งค่า cache headers

ไฟล์ฟอนต์เป็น static assets ควร cache อย่างเข้มข้นหากชื่อไฟล์มี version หรือ content hash

header สำหรับ production ที่ดีคือ:

Cache-Control: public, max-age=31536000, immutable

ใช้ long-lived immutable caching เฉพาะเมื่อ URL เปลี่ยนเมื่อไฟล์เปลี่ยน ตัวอย่างเช่น:

inter-latin-400.a8f3c2.woff2

หรือ path ที่มี version:

/fonts/v2/inter-latin-400.woff2

หากคุณเขียนทับ /fonts/inter-latin-400.woff2 โดยไม่เปลี่ยน URL ผู้ใช้บางคนอาจเก็บไฟล์เก่าไว้เป็นเวลานาน ซึ่งก็ไม่มีปัญหา จนกว่าจะมีปัญหา Versioning ช่วยหลีกเลี่ยงเรื่องนี้

ให้บริการฟอนต์ด้วย MIME type ที่ถูกต้องด้วย:

Content-Type: font/woff2

hosting platforms สมัยใหม่ส่วนใหญ่จัดการเรื่องนี้ให้อัตโนมัติ แต่ควรตรวจสอบอยู่ดี

ขั้นตอนที่ 7: พิจารณา preload เฉพาะฟอนต์ที่สำคัญ

Preloading ช่วยให้ browser ค้นพบฟอนต์สำคัญได้เร็วขึ้น:

<link rel="preload" href="/fonts/inter-latin-400.woff2" as="font" type="font/woff2" crossorigin>

ใช้สิ่งนี้อย่างประหยัด Preload ฟอนต์หลักของข้อความส่วน above-the-fold ไม่ใช่ทุกน้ำหนักฟอนต์ การ preload มากเกินไปจะแย่งทรัพยากรกับ CSS, images และ JavaScript

แม้กับฟอนต์ same-origin ให้ใส่ crossorigin ใน font preloads ด้วย การดึงฟอนต์ใช้ CORS mode และหากละเว้นอาจทำให้เกิดการดาวน์โหลดซ้ำในบาง setup

หากไม่แน่ใจ ให้ทดสอบ อย่าทำตาม preloads แบบไม่เข้าใจเพียงเพราะ checklist บอกไว้

ขั้นตอนที่ 8: ทดสอบความเป็นส่วนตัวและประสิทธิภาพ

การทดสอบทำได้ตรงไปตรงมา

เปิด DevTools โหลดหน้าใหม่โดยปิด cache แล้วกรอง Network panel ด้วย:

• fonts.googleapis.com
• fonts.gstatic.com
• .woff2
• font

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

จากนั้นทดสอบทั้ง cold cache และ warm cache ในการเข้าชมครั้งแรก ฟอนต์ควรถูกดาวน์โหลดครั้งเดียว ในการเข้าชมภายหลัง ฟอนต์ควรมาจาก memory หรือ disk cache ขึ้นอยู่กับ browser

ตรวจสอบ layout shift เมื่อฟอนต์สลับเข้ามา หากหัวข้อกระโดด แสดงว่า fallback font metrics แตกต่างจาก web font มากเกินไป คุณสามารถลดการเปลี่ยนแปลงที่มองเห็นได้ด้วยการเลือก fallback ที่ใกล้เคียงกว่า หรือใช้ CSS font metric overrides รุ่นใหม่ เช่น size-adjust, ascent-override, descent-override และ line-gap-override สิ่งเหล่านี้ขั้นสูงกว่า แต่มีประโยชน์สำหรับ interfaces ที่ต้องการความประณีต

สุดท้าย ทดสอบหน้าใน private browsing หรือเมื่อเปิด content blockers ข้อดีอย่างหนึ่งของการ self-host คือ privacy tools มีโอกาสน้อยลงที่จะบล็อก typography ของคุณโดยไม่ตั้งใจ

ข้อผิดพลาดที่พบบ่อยและควรหลีกเลี่ยง

โฮสต์น้ำหนักฟอนต์มากเกินไป

นี่คือความล้มเหลวที่พบบ่อยที่สุด สองน้ำหนักมักเพียงพอ สามน้ำหนักมักเหลือเฟือ ห้าน้ำหนักเป็นสัญญาณของ design system ที่มีกลิ่นไม่ดี เว้นแต่คุณมีเหตุผลหนักแน่น

ลืม italics

หากเนื้อหาของคุณใช้การเน้นจริง ให้โหลดไฟล์ italic จริง Synthetic italics อาจดูไม่ดี โดยเฉพาะในเนื้อหา editorial แบบยาว

เก็บลิงก์ Google CSS เดิมไว้

สิ่งนี้ทำให้เสียจุดประสงค์ หลัง migration ไม่ควรมีคำขอฟอนต์ไปยัง Google เว้นแต่องค์ประกอบอื่นกำลัง inject เข้ามา

ให้บริการฟอนต์โดยไม่มี long-term caching

การ self-host ให้การควบคุมแก่คุณ ใช้มันให้คุ้ม ฟอนต์เป็นผู้สมัครที่เหมาะมากสำหรับ cache lifetimes ยาว

มองข้ามงานด้านกฎหมายและเอกสาร

หาก privacy policy ของคุณเคยกล่าวถึง Google Fonts หรือการโหลดฟอนต์จากบุคคลที่สาม ให้ปรับปรุงหลัง migration หากคุณดูแล data-processing inventory ก็ให้ปรับปรุงด้วย การเปลี่ยนแปลงทางเทคนิคและบันทึกด้าน compliance ควรสอดคล้องกัน

<!-- tool-cta:start -->

💡 ลองทำสิ่งนี้: แปลงไฟล์ TTF ที่คุณดาวน์โหลดจาก Google Fonts เป็น WOFF2 ที่โฮสต์เองได้พร้อม CSS ด้วย Webfont Generator

<!-- tool-cta:end -->

Checklist การ migration แบบง่าย

1. ระบุ font families, weights, styles และ scripts ที่คุณใช้จริง
2. ดาวน์โหลดไฟล์ WOFF2 และยืนยัน license
3. ทำ subset ฟอนต์หากเว็บไซต์มีความต้องการด้านภาษาจำกัด
4. เพิ่มกฎ local @font-face พร้อม font-display: swap
5. ลบการอ้างอิง Google Fonts link, preconnect และ @import ทั้งหมด
6. ให้บริการฟอนต์จากโดเมนของคุณเองพร้อม cache headers ที่มีอายุยาว
7. Preload เฉพาะฟอนต์ above-the-fold ที่สำคัญที่สุด หากการทดสอบสนับสนุน
8. ตรวจสอบใน DevTools ว่าไม่มีคำขอ Google Fonts เหลืออยู่
9. ปรับปรุงเอกสารความเป็นส่วนตัวหากจำเป็น

การ self-host ฟอนต์ไม่ใช่งานที่หวือหวา แต่มันเป็นงานเก็บกวาดโครงสร้างพื้นฐานเล็ก ๆ ที่ช่วยลดความเสี่ยงด้าน dependency ปรับปรุงท่าทีด้านความเป็นส่วนตัว และทำให้ rendering คาดการณ์ได้มากขึ้น ซึ่งโดยทั่วไปคุ้มค่ากับเวลาหนึ่งหรือสองชั่วโมงที่ใช้ไป