آخرین بهروزرسانی: 20 Aug, 2026

۸ فرمت مدرن تصویر که هر توسعهدهنده باید بداند
تصاویر همچنان سنگینترین کلاس دارایی در وب مدرن باقی میمانند و بهطور منظم ۴۵٪ تا ۶۰٪ از وزن کل انتقال یک صفحه وب متوسط را تشکیل میدهند. وقتی تیمهای مهندسی نمرات کند Largest Contentful Paint (LCP)، هزینههای بالارونده خروجی شبکه توزیع محتوا (CDN) یا نرخ پرش بالای موبایل را مشاهده میکنند، عامل معمولاً یک پرسوجوی پایگاه دادهٔ کند یا بستهٔ جاوااسکریپت حجیم نیست—بلکه تحویل تصویر بهینهنشده و پیکربندی نادرست است.
اتکا صرف به JPEGهای استاندارد و PNGهای بدون فشردهسازی در تمام نمایشگرهای مشتری یک الگوی قدیمی است. دستگاههای امروزی از نمایشگرهای ۴K با DPI بالا تا گوشیهای موبایل با پهنای باند کم متغیرند و از توسعهدهندگان میخواهند تا کانتینر فایل مناسب، کدک فشردهسازی و عملکرد رمزگشایی را با نوع دارایی خاص مطابقت دهند.
این راهنما تحلیلی عمیق و آماده برای تولید از ۱۰ فرمت تصویر مدرن برتر را ارائه میدهد که هر مهندس نرمافزار، توسعهدهنده وب و معمار پلتفرم باید با آن آشنا باشد.
ماتریس مقایسه فنی
| قالب | معماری | مدل فشردهسازی | کانال آلفا | انیمیشن بومی | عمق رنگ / HDR | پشتیبانی جهانی مرورگرها | مورد استفاده ایدهآل در تولید |
|---|---|---|---|---|---|---|---|
| WebP | راستر (VP8/VP8L) | فشردهسازی با اتلاف و بدون اتلاف | بله (۸‑بیتی) | بله | ۸‑بیتی (SDR) | ~۹۷٪ | پیشفرض ایمن و جهانی برای رسانههای وب |
| AVIF | راستر (AV1) | فشردهسازی با اتلاف و بدون اتلاف | بله (8/10/12 بیت) | بله | تا 12 بیت HDR/WCG | ~93% | تصاویر قهرمان، بهینهسازی LCP با ترافیک بالا |
| SVG | بردار (XML) | متن ساده / Brotli | بله (بینهایت) | بله (CSS/SMIL) | بدون وابستگی به نمایش | >99% | لوگوها، نمادهای ناوبری، طرحهای رابط کاربری |
| JPEG XL | راستر | فشردهسازی با اتلاف و بدون اتلاف | بله | بله | HDR ۳۲‑بیتی شناور کامل | انتخابی / در حال پیشرفت | آرشیوهای عکس با دقت بالا، تبدیل JPEG بدون اتلاف |
| HEIC / HEIF | راستر (H.265) | فشردهسازی با اتلاف و بدون اتلاف | بله | بله (دنبالهها) | تا ۱۶‑بیتی HDR | فقط سیستمعامل بومی (سافاری جزئی) | ضبط توسط کلاینت موبایل، دریافت سمت سرور |
| PNG (کوانتیده) | راستر (Deflate) | بدونضایعات سخت | بله (8/24/32-bit) | خیر | ۸‑بیت / ۱۶‑بیت | ۱۰۰٪ | اسکرینشاتها، قطعهکدها، جایگزینهای پیکسلآرت |
| MozJPEG | راستر (DCT) | پروگرسیو با افت کیفیت | خیر | خیر | ۸‑بیتی (SDR) | ۱۰۰٪ | پشتیبانگیری قدیمی، قالبهای ایمیل HTML |
| WebP انیمیشنی | راستر (VP8) | فشردهسازی با اتلاف و بدون اتلاف | بله (8-bit) | بله | 8-bit (SDR) | ~97% | جایگزین سبک برای GIFهای قدیمی و پرحجم |
1. WebP (.webp) — کارگر اصلی مدرن وب
وبپی که توسط گوگل معرفی شد، از یک پروژه آزمایشی وب به استاندارد پایه رسانهای در سراسر اینترنت تبدیل شده است. این فرمت ترکیبی از چگالی فشردهسازی کدگذاریهای عکاسی با اتلاف و پشتیبانی از شفافیت PNG است.
پروفایل فنی
- کدک پایه: بر پایه طرح فشردهسازی فریم کلیدی ویدئویی VP8 (با VP8L برای حالتهای بدون اتلاف).
- کارایی فشردهسازی: معمولاً فایلها ۲۵٪ تا ۳۵٪ کوچکتر نسبت به تصاویر JPEG سنتی با رتبهبندی مشابهت ساختاری (SSIM) معادل تولید میکند.
- سازگاری مرورگر: پشتیبانی در مرورگرهای Chrome، Firefox، Safari، Edge و تمام مرورگرهای اصلی موبایل (~97% پوشش بازار جهانی).
ارزیابی تولید
WebP بهعنوان هدف پیشفرض برای خطوط لوله تصویر استاندارد استفاده میشود. این فرمت معضل تاریخی انتخاب بین JPEG (برای عکسهای بدون شفافیت) و PNG (برای شفافیت بهقیمت حجم بسیار بزرگ فایلها) را برطرف میکند.
<!-- Safe WebP delivery with JPEG fallback -->
<picture>
<source srcset="/assets/hero-banner.webp" type="image/webp">
<img
src="/assets/hero-banner.jpg"
alt="Developer workstation setup"
width="1200"
height="630"
loading="eager"
fetchpriority="high">
</picture>
۲. AVIF (.avif) — استاندارد حداکثر فشردهسازی
فرمت فایل تصویر AV1 (AVIF) یک فرمت منبع باز و بدون حق امتیاز است که توسط اتحاد رسانههای باز (AOMedia) تعریف شده است — پشتیبانی شده توسط Google، Mozilla، Cisco، Apple و Netflix. AVIF فریمهای تصویری رمزگذاریشده با کدک ویدئویی AV1 را در یک کانتینر فرمت فایل رسانهای پایه ISO (ISOBMFF) بستهبندی میکند.
پروفایل فنی
- کدک زیرین: رمزگذاری داخلفریم AV1.
- کارایی فشردهسازی: نسبت به WebP با 20% تا 35% بیشتر عملکرد دارد و اندازه فایلهای JPEG استاندارد را تا حداکثر 50% کاهش میدهد.
- مدیریت رنگ: پشتیبانی بومی از عمق رنگ 10‑بیتی و 12‑بیتی، دامنه دینامیک بالا (HDR) و گام رنگ وسیع (WCG، شامل BT.2020 و DCI‑P3).
- معایب: بارگذاری پردازشی CPU بهمراتب بالاتر نسبت به WebP. تولید فایلهای AVIF در مراحل ساخت خودکار نیاز به منابع محاسباتی قوی یا موتورهای تبدیل لبه CDN بر‑تقاضا دارد.
ارزیابی تولید
AVIF بهترین انتخاب برای بنرهای قهرمان بزرگترین محتوای قابلنمایش (LCP) و صفحات بازاریابی با ترافیک بالا است. مقاومت آن در برابر آثار فشردهسازی بلوکی در گرادیانهای رنگی صاف (مانند غروبها، پسزمینههای مهآلود یا سایههای حالت تاریک) بینظیر است.
۳. SVG (.svg) — گرافیکهای برداری مستقل از وضوح
گرافیکهای برداری مقیاسپذیر (SVG) داراییهای بصری را بهعنوان توصیفات ریاضیاتی—مسیرها، نقاط مختصاتی، چندضلعیها و منحنیهای بزیه—در قالب متنی ساده مبتنی بر XML ذخیره میکنند.
پروفایل فنی
- معماری: هندسه برداری مبتنی بر متن.
- تحویل شبکه: بهصورت بسیار فشردهپذیر بر روی HTTP با استفاده از الگوریتمهای فشردهسازی استاندارد حملونقل (gzip یا Brotli).
- تعامل: بهصورت مستقیم با جاوااسکریپت قابل اسکریپتنویسی و با متغیرهای CSS قابل استایلگذاری است هنگامی که بهصورت درونخطی در مدل شیء سند (DOM) جاسازی میشود.
<!-- Example of an optimized, accessible inline SVG -->
<svg xmlns="[http://www.w3.org/2000/svg](http://www.w3.org/2000/svg)" viewBox="0 0 24 24" width="24" height="24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" aria-labelledby="iconTitle">
<title id="iconTitle">Server Uptime Status</title>
<rect x="2" y="2" width="20" height="8" rx="2" ry="2"></rect>
<rect x="2" y="14" width="20" height="8" rx="2" ry="2"></rect>
<line x1="6" y1="6" x2="6.01" y2="6"></line>
<line x1="6" y1="18" x2="6.01" y2="18"></line>
</svg>
ارزیابی تولید
از SVG برای لوگوها، آیکونهای رابط کاربری، عناصر ناوبری، نمودارهای تجسم دادهها و الگوهای هندسی ساختاری استفاده کنید.
هشدار امنیتی: چون SVGها درختهای کامل XML را تجزیه میکنند، میتوانند تگهای
<script>جاسازیشده را اجرا کنند. هرگز SVGهای بارگذاریشده توسط کاربر که پاکسازی نشدهاند را بهصورت مستقیم در مرورگر رندر نکنید؛ از یک پاککننده XML مانند DOMPurify استفاده کنید یا هنگام بارگذاری آنها را به فرمتهای رستر تبدیل کنید.
۴. JPEG XL (.jxl) — استاندارد عکاسی نسل بعدی
توسط گروه مشترک متخصصان عکاسی (Joint Photographic Experts Group) توسعه یافت، JPEG XL به گونهای طراحی شد که جایگزین JPEG قدیمی شود و در عین حال مشکلات عملکردی و معماری فرمتهای قبلی را برطرف کند.
پروفایل فنی
- تبدیلپذیری معکوس: امکان فشردهسازی بدونضایعات جریانهای بیتی JPEG قدیمی را به فایلهای JXL که تقریباً ۲۰٪ کوچکتر هستند، فراهم میکند و بهطور کامل از از دست رفتن نسل یا کاهش کیفیت بصری جلوگیری میکند. این عملیات میتواند معکوس شود تا JPEG اصلی را بیت به بیت بازسازی کند.
- حالتهای بدونضایعات و باضایعات: در طیف وسیعی از بیتریتها بهطور بسیار واکنشگرا عمل میکند و وفاداری برتری نسبت به AVIF در عکاسی با وضوح فوقالعاده بالا ارائه میدهد.
- مجموعه ویژگیها: پشتیبانی کامل از کانالهای آلفا، دامنه دینامیک گسترده، انیمیشنها، ترکیبهای چندلایه، و رمزگشایی پیشرونده سریع چندنخی.
ارزیابی تولید
JPEG XL فرمت مورد ترجیح برای آرشیوهای دارایی دیجیتال، پلتفرمهای انتشار چاپ‑به‑وب و جوامع عکاسی است. پیادهسازیهای مرورگر در سافاری و موتورهای رندر متنباز پیشرونده فعال هستند و این فرمت را به عنوان یک فرمت اساسی برای نظارت تبدیل میکند، زیرا ابزارهای اکوسیستم به بلوغ میرسند.
۵. HEIC / HEIF (.heic) — ضبط و واردسازی موبایلی
قالب فایل تصویر با کارایی بالا (HEIF)، که معمولاً با پسوند .heic ذخیره میشود، فریمهای تصویری فشردهشده با استفاده از استاندارد کدگذاری ویدئوی با کارایی بالا (HEVC / H.265) را در خود میگیرد.
پروفایل فنی
- کدک پایه: H.265 / HEVC.
- قابلیتها: تصاویر تک، توالیهای پیوسته، پروفایلهای رنگ HDR، مسیرهای صوتی و متادیتای نقشه عمق را در یک کانتینر واحد ذخیره میکند.
- حجم بار: تقریباً ۵۰٪ فشردهسازی بهتر نسبت به JPEG قدیمی با کیفیت ادراکی یکسان ارائه میدهد.
ارزیابی تولید
HEIC برای تحویل مستقیم در وب طراحی نشده است به دلیل محدودیتهای مجوز پتنت و پشتیبانی محدود مرورگرها خارج از اکوسیستم Apple. با این حال، هر توسعهدهندهٔ مدرن فولاستک باید HEIC را درک کند زیرا دستگاههای iOS و اندروید مدرن عکسها را در این قالب ضبط و بارگذاری میکنند. خط لولهٔ دریافت بکاند شما باید بارگذاریهای .heic را به AVIF/WebP تبدیل کند قبل از ارائه به مرورگرهای کاربر:
// Example Node.js transcode pipeline using Sharp
import sharp from 'sharp';
export async function processUserUpload(inputBuffer) {
return await sharp(inputBuffer)
.rotate() // Automatically orient based on EXIF
.resize({ width: 1920, withoutEnlargement: true })
.avif({ quality: 65, effort: 4 })
.toBuffer();
}
۶. PNG (بهینهسازی ۸‑بیتی و ۲۴‑بیتی) — لنگر بدونافت
قالب گرافیکهای پورتابل نتورک (PNG) همچنان معیار برای گرافیکهای رستر دو‑بعدی بدون افت کیفیت است که در آن حفظ لبهها و صحت پیکسلها غیرقابل مذاکره است.
پروفایل فنی
- الگوریتم فشردهسازی: Deflate (LZ77 ترکیبشده با کدگذاری هوفمان)، که با فیلترگذاری پیشبینی بایت بر روی خطوط اسکن افقی تقویت شده است.
- پشتیبانی از رنگ: پالت ایندکسشده 8‑بیتی (PNG-8) یا رنگ واقعی 24‑بیتی با کانال آلفا 8‑بیتی (PNG-24/PNG-32).
- ویژگیها: بدون آثار فشردهسازی. متن، چارچوبهای ریز و حاشیههای با کنتراست تیز واضح باقی میمانند.
ارزیابی تولید
خروجیهای پیشفرض PNG از ابزارهایی مانند Photoshop یا Figma شامل متادیتای تکراری، جداول رنگ بهینهنشده و انتخابهای فیلتر ناکارآمد هستند. توسعهدهندگان باید PNGها را از طریق ابزارهای مدرن کمیتسازی مانند pngquant یا oxipng عبور دهند تا داراییهای 24‑بیتی را در صورت امکان به PNGهای پالتدار 8‑بیتی تبدیل کنند، که معمولاً 60٪ تا 75٪ حجم فایل را کاهش میدهد در حالی که شفافیت کامل حفظ میشود.
7. MozJPEG / Progressive JPEG (.jpg) — پشتیبان عمومی
در حالی که استاندارد پایه JPEG در سال 1992 به وجود آمد، رمزگذارهای مدرن این فرمت را مرتبط نگه داشتهاند. رمزگذار متنباز MozJPEG شرکت Mozilla با بهینهسازی جداول هوفمان، کمیتسازی تریلس و ساختارهای پیشرفت اسکن، این فرمت را احیا کرد.
پروفایل فنی
- اسکن پیشرونده: پیشنمایش اولیه با وضوح پایین را در اولین بستههای داده ورودی ارائه میدهد و بهصورت تدریجی با تکمیل جریان بایت، وضوح را افزایش میدهد.
- سازگاری: ۱۰۰٪ جهانی در تمام مرورگرها، سیستمعاملها، اسکرابرهای بدون سر (headless)، WebViewهای توکار، تجزیهکنندههای بومی PDF و کلاینتهای ایمیل دسکتاپ (مثلاً Microsoft Outlook).
Progressive Loading Sequence:
[ Pass 1: Blurry Outline ] -> [ Pass 2: Defined Geometry ] -> [ Pass 3: Full Contrast ]
ارزیابی تولید
MozJPEG به عنوان آخرین گزینهٔ اضطراری مورد نیاز در داخل تگ <picture> است. علاوه بر این، ایمیلهای بازاریابی HTML باید به JPEGهای پیشرونده تکیه کنند، زیرا نرمافزارهای ایمیل مشتری بهطور مکرر علامتگذاری مدرن <picture> را حذف میکنند و منابع AVIF/WebP را رد مینمایند.
8. WebP انیمیشنی (.webp) — جایگزین سبک حرکت
قالب قدیمی Graphics Interchange Format (GIF) به شدت منسوخ شده است. با محدودیت ۲۵۶ رنگی و کدگذاری فریمهای LZW بدون فشردهسازی، GIFهای انیمیشنی استاندارد به طور معمول برای کلیپهای کوتاه با نرخ فریم پایین، حجمی بین ۵ مگابایت تا ۲۰ مگابایت دارند.
پروفایل فنی
- معماری پایه: محفظهٔ فشردهسازی VP8 بینفریم با ذخیرهسازی تفاضل فریمها.
- عمق رنگ و آلفا: رنگ واقعی ۲۴‑بیتی RGB با شفافیت آلفای کامل ۸‑بیتی برای هر فریم (که لبههای پُردندانه و هالهدار خاص شفافیت ۱‑بیتی GIF را حذف میکند).
- حجم بار: معمولاً ۶۵٪ تا ۸۵٪ کوچکتر نسبت به یک GIF انیمیشنی یکسان.
ارزیابی تولید
از WebP انیمیشنی برای نمایشهای رابط بازاریابی، نشانکهای وضعیت انیمیشنی، میکرو‑تعاملات کوتاه قهرمان، و بستههای برچسب واکنش چت استفاده کنید. برای ضبطهای ویدئویی پیوسته بیش از ۵ ثانیه، عنصر HTML5 <video> که H.264/AV1 را سرو میکند، همچنان کارآمدتر از نظر پهنای باند است.
پیادهسازی معماری: خط لوله مدرن واکنشگرا <picture>
برای حداکثر کردن Core Web Vitals در حالی که سازگاری جهانی حفظ میشود، از رویکرد بازگشت لایهای با استفاده از تگ بومی HTML5 <picture> استفاده کنید. مرورگرها اعلانهای <source> را بهصورت متوالی ارزیابی میکنند و فقط اولین فرمت سازگار را که پشتیبانی میکند، دانلود مینمایند:
<picture>
<!-- 1. Primary High-Efficiency Layer (AVIF) for modern engines -->
<source
type="image/avif"
srcset="/img/showcase-480.avif 480w, /img/showcase-960.avif 960w, /img/showcase-1440.avif 1440w"
sizes="(max-width: 600px) 100vw, (max-width: 1200px) 50vw, 33vw">
<!-- 2. Secondary Universal Modern Layer (WebP) -->
<source
type="image/webp"
srcset="/img/showcase-480.webp 480w, /img/showcase-960.webp 960w, /img/showcase-1440.webp 1440w"
sizes="(max-width: 600px) 100vw, (max-width: 1200px) 50vw, 33vw">
<!-- 3. Universal Fallback Layer (Progressive MozJPEG) -->
<img
src="/img/showcase-960.jpg"
srcset="/img/showcase-480.jpg 480w, /img/showcase-960.jpg 960w, /img/showcase-1440.jpg 1440w"
sizes="(max-width: 600px) 100vw, (max-width: 1200px) 50vw, 33vw"
alt="Detailed architectural schematic of cloud deployment"
width="960"
height="540"
loading="lazy"
decoding="async">
</picture>
سوالات متداول (FAQ)
**Q1: چرا باید AVIF را بهجای WebP سرو کنم اگر WebP قبلاً پشتیبانی گستردهای از مرورگرها دارد؟ AVIF تا 30٪ فشردهسازی بایتی بیشتری نسبت به WebP با همان کیفیت بصری ارائه میدهد و بهصورت بومی از فضاهای رنگی HDR 10‑بیتی و 12‑بیتی پشتیبانی میکند.
**Q2: آیا فایلهای SVG میتوانند آسیبپذیریهای امنیتی سمتکلاینت را به یک برنامه وب وارد کنند؟
بله، زیرا SVGها اسناد XML مبتنی بر متن هستند که میتوانند تگهای <script> جاسازیشده را اجرا کنند، بنابراین بارگذاریهای کاربران غیرمطمئن بدون پاکسازی دقیق، تهدید مستقیم Cross-Site Scripting (XSS) ایجاد میکنند.
**Q3: چرا خبرنامههای ایمیل HTML هنوز بهطور گستردهای به فرمتهای قدیمی JPEG و PNG وابسته هستند؟ کلاینتهای ایمیل دسکتاپ و سازمانی اصلی (مانند نسخههای قدیمی Microsoft Outlook) از موتورهای رندرینگ قدیمی استفاده میکنند که قادر به رمزگشایی فرمتهای مدرن مانند WebP یا AVIF نیستند.
**Q4: تفاوت معماری اصلی بین WebP فشردهسازی با اتلاف و WebP بدون اتلاف چیست؟ WebP فشرده با استفاده از رمزگذاری پیشبینی‑مانند DCT برای حذف دادههای پیکسلی که بهصورت بصری قابل تشخیص نیستند، استفاده میکند، در حالی که WebP بدونفشرده بهصورت ریاضیاتی هر مقدار پیکسل اصلی را با استفاده از الگوریتمهای تبدیل فضایی حفظ میکند.
**Q5: انتقال به فرمتهای تصویر نسل بعدی چگونه رتبهبندی موتورهای جستجو را بهبود میبخشد؟ فرمتهای تصویر مدرن وزن بار و زمان دانلود را بهطور چشمگیری کاهش میدهند و بهصورت مستقیم معیارهای Core Web Vitals—بهویژه Largest Contentful Paint (LCP)—را بهبود میبخشند، که موتورهای جستجو در الگوریتمهای رتبهبندی ارگانیک خود در نظر میگیرند.