Trình Tạo Hình Ảnh Giữ Chỗ

Cách hoạt động

1. Đặt kích thước: nhập chiều rộng và chiều cao tính bằng pixel của hình ảnh điền chỗ của bạn.
2. Tùy chỉnh giao diện: chọn màu nền, màu văn bản và nhãn để hiển thị (hoặc để trống để hiển thị kích thước).
3. Sử dụng hoặc tải xuống: sao chép URL hình ảnh để dùng trong HTML/CSS, hoặc tải xuống PNG trực tiếp cho mockup và thiết kế của bạn.

Tại sao sử dụng trình tạo hình ảnh điền chỗ?

Trong quá trình phát triển web và tạo mockup, thường cần hình ảnh trước khi nội dung thật sẵn sàng. Hình ảnh điền chỗ chiếm chỗ trong các bố cục để hiển thị tỷ lệ, kiểm thử hành vi responsive và truyền đạt ý định thiết kế đến khách hàng. Thay vì tìm ảnh stock hoặc tạo hình ảnh trống bằng tay, công cụ này tạo tức thì những hình ảnh có kích thước đúng với kích thước và màu sắc mong muốn.

Tính năng

• Kích thước tùy chỉnh: bất kỳ chiều rộng và chiều cao nào theo pixel, định dạng vuông, dọc, ngang hoặc banner.
• Tùy chỉnh màu sắc: đặt màu nền và màu văn bản qua mã hex hoặc bộ chọn màu.
• Văn bản nhãn tùy chỉnh: hiển thị bất kỳ văn bản nào trên hình ảnh, hoặc để mặc định là nhãn kích thước (ví dụ 400×300).
• URL tức thì: nhận URI dữ liệu để dán trực tiếp vào thuộc tính src để kiểm thử.
• Tải xuống PNG: tải hình ảnh điền chỗ dưới dạng tệp PNG để dùng trong các công cụ thiết kế.

Câu hỏi thường gặp

Tôi có thể dùng nó trong thuộc tính src HTML không?

Có. Hình ảnh được tạo có sẵn dưới dạng URI dữ liệu mà bạn có thể dán trực tiếp vào thuộc tính <img src=""> trong HTML của bạn. Không cần lưu trữ hoặc URL bên ngoài.

Những kích thước nào phổ biến cho hình ảnh điền chỗ?

Kích thước phổ biến: hình ảnh chính (1200×630), thumbnail bài viết (400×300), avatar (100×100), hình ảnh Open Graph (1200×628) và banner quảng cáo (728×90). Nhập bất kỳ kích thước tùy chỉnh nào theo nhu cầu của bạn.

Làm thế nào để dùng hình ảnh điền chỗ trong CSS?

Sao chép URI dữ liệu và sử dụng làm nền CSS: background-image: url("data:image/png;base64,…"). Điều này hoạt động trong tất cả các trình duyệt hiện đại và không cần tệp bên ngoài.

Lịch sử ngắn của các dịch vụ ảnh placeholder

Các dịch vụ ảnh placeholder xuất hiện vào năm 2010 khi các nhà thiết kế web cần một cách nhanh chóng để lấp đầy các mockup trước khi các tài sản cuối cùng đến. placehold.it, ra mắt bởi Dave Reilly vào năm 2010, là dịch vụ đầu tiên được sử dụng rộng rãi: dán URL như placehold.it/300x200 vào bất kỳ thẻ <img> nào và bạn sẽ có một hình chữ nhật màu xám. placekitten.com theo sau cùng năm, thay thế hình chữ nhật bằng mèo con ngẫu nhiên, và dummyimage.com (Russell Heimlich, 2010) đã thêm tùy chỉnh màu sắc. Các biến thể kỳ quặc nhân lên: fillmurray.com (ảnh Bill Murray, 2013), placebeard.it (râu, 2014), placecage.com (Nicolas Cage). Những kế thừa nghiêm túc đến muộn hơn: Lorem Pixel (ngừng hoạt động khoảng 2017) và Lorem Picsum của David Marby (2018), phục vụ ảnh ngẫu nhiên từ Unsplash ở bất kỳ kích thước nào. Khoảng năm 2014, Facebook đã phổ biến mẫu hình «skeleton screen»: hiển thị các hình dạng màu xám nơi nội dung sẽ tải. Đến 2019, Wolt đã phát hành BlurHash, một chuỗi 20 byte giải mã thành một placeholder mờ độ phân giải thấp của ảnh thực tế. Ngày nay, ThumbHash (Evan Wallace, 2023) và thuộc tính CSS gốc aspect-ratio (Chrome 88, tháng 1/2021) cho phép bạn đặt chỗ ảnh mà không cần bất kỳ dịch vụ bên ngoài nào.

Kích thước ảnh tiêu chuẩn đáng ghi nhớ

• Open Graph (1200×630). Kích thước preview liên kết chuẩn được định nghĩa bởi giao thức Open Graph của Facebook. LinkedIn, Slack, Discord, Twitter (khi không có Twitter Card được đặt) đều mặc định về kích thước này. Tỷ lệ 1,91:1.
• Twitter Card summary_large_image (1200×675). Tỷ lệ 16:9 cho preview trong feed. 1200×628 mà bạn thấy được trích dẫn là tiêu chuẩn cũ, thay thế bằng 1200×675 vào năm 2023.
• Instagram (1080×1080 vuông, 1080×1350 dọc, 1080×1920 story). Bất kỳ thứ gì rộng hơn 1080 đều bị giảm mẫu. Tỷ lệ story là 9:16.
• Thumbnail YouTube (1280×720). 16:9. YouTube tự động tạo từ các khung hình video; thumbnail tùy chỉnh tải lên phải dưới 2 MB.
• Kích thước quảng cáo IAB. Interactive Advertising Bureau đã chuẩn hóa kích thước banner: 728×90 (leaderboard), 300×250 (hình chữ nhật trung bình, kích thước được mua nhiều nhất toàn cầu), 300×600 (nửa trang), 160×600 (skyscraper rộng), 320×50 và 320×100 (di động).
• Favicon. 16×16 và 32×32 cho tab trình duyệt, 180×180 cho biểu tượng Apple touch, 192×192 và 512×512 cho manifest.json Android, tối thiểu 512×512 cho prompt cài đặt PWA.
• Header email (600×200). Hầu hết các email client giới hạn chiều rộng được kết xuất là 600 px. Đi rộng hơn sẽ bị bóp lại hoặc thanh cuộn xuất hiện trong Outlook desktop.

Placeholder và Core Web Vitals

Core Web Vitals của Google (ra mắt vào tháng 5/2020) đo lường trải nghiệm người dùng và ảnh hưởng đến xếp hạng tìm kiếm. Hai trong ba chỉ số phụ thuộc trực tiếp vào cách bạn xử lý ảnh. CLS (Cumulative Layout Shift) phạt nội dung nhảy khi trang tải. Nguyên nhân phổ biến nhất: một <img> không có thuộc tính width và height rõ ràng, không cho trình duyệt không gian nào để đặt chỗ cho đến khi ảnh tải xong. Điểm trên 0,1 không đạt chỉ số. Cách sửa rất đơn giản: luôn đặt width và height, ngay cả trên ảnh responsive, để trình duyệt có thể tính tỷ lệ. LCP (Largest Contentful Paint) đo lường khi phần tử có thể nhìn thấy lớn nhất tải xong. Đối với hầu hết các trang, phần tử đó là ảnh hero. Bất cứ thứ gì trên 2,5 giây đều thất bại. Chiến lược: phục vụ các định dạng hiện đại (WebP, AVIF), sử dụng loading="lazy" trên các ảnh dưới fold (Chrome 76, tháng 8/2019), và sử dụng fetchpriority="high" trên hero. Placeholder lấp khoảng trống về mặt hình ảnh: skeleton screen cho bố cục, BlurHash hoặc ThumbHash cho preview tức thì của bảng màu ảnh thực tế.

Hướng dẫn quyết định định dạng ảnh

• PNG (1996). Không mất dữ liệu, hỗ trợ độ trong suốt, không có vấn đề bằng sáng chế. Tốt nhất cho logo, biểu tượng, ảnh chụp màn hình, đồ họa với cạnh sắc nét. PNG-8 màu được lập chỉ mục (256 màu) nhỏ hơn đáng kể so với PNG-24 RGB và thường không thấy rõ trên biểu tượng UI.
• JPEG (1992). Mất dữ liệu, không trong suốt, được tối ưu cho ảnh chụp. Chất lượng 75-85 là điểm ngọt cho web; không thể phân biệt trực quan với chất lượng 95 ở một nửa kích thước. Tránh JPEG cho bất cứ thứ gì có cạnh sắc nét (văn bản, logo): bạn sẽ có các artifact ringing có thể nhìn thấy.
• WebP (Google, 2010). Nhỏ hơn JPEG 25-35% ở chất lượng hình ảnh tương đương, cũng nhỏ hơn PNG cho không mất dữ liệu. Hỗ trợ độ trong suốt, hoạt hình, cả chế độ có và không mất dữ liệu. Hỗ trợ trình duyệt: 97% tính đến 2024. Lựa chọn mặc định cho các trang mới.
• AVIF (Alliance for Open Media, 2019). Dựa trên codec video AV1. Nhỏ hơn JPEG khoảng 50%, nhỏ hơn WebP 20%. Chi phí CPU cao hơn để mã hóa. Hỗ trợ trình duyệt: ~93% tính đến 2024, thiếu trên Safari cũ. Sử dụng phía sau fallback <picture>.
• SVG. Vector. Mở rộng vô hạn mà không mất chất lượng. Một logo trong SVG thường là 500 byte so với 10 KB như PNG 512×512. SVG nội tuyến trong HTML tránh hoàn toàn một yêu cầu HTTP bổ sung. Không sử dụng cho ảnh chụp.
• Data URI. data:image/png;base64,... nhúng các byte ảnh trực tiếp vào HTML hoặc CSS. Tiết kiệm một yêu cầu HTTP với chi phí làm phồng tệp xung quanh khoảng 33% (overhead base64). Đáng giá cho thumbnail placeholder nhỏ, không bao giờ cho ảnh hero.

Nơi placeholder ảnh thực sự được sử dụng

• Wireframe và mockup. Figma, Sketch, Adobe XD, Penpot đều hỗ trợ kéo và thả ảnh placeholder. Các nhà thiết kế phác thảo bố cục trước khi định hướng nghệ thuật đến, sử dụng hình chữ nhật màu xám hoặc văn bản kích thước làm placeholder hình ảnh.
• Skeleton screen. Twitter, Facebook, YouTube, LinkedIn đều hiển thị placeholder khối màu xám khi nội dung tải. Nghiên cứu của Luke Wroblewski (2013) cho thấy skeleton screen khiến thời gian tải nhận thức cảm thấy nhanh hơn tới 20% so với spinner.
• Câu chuyện design system. Storybook, Histoire và Ladle kết xuất các xem trước thành phần cần ảnh thay thế. Một bộ placeholder nhất quán làm cho ảnh chụp màn hình có thể tái tạo qua các build CI.
• Mockup email. Litmus, Email on Acid, các bộ xây dựng mẫu Mailchimp. Email client thay đổi rất nhiều về hỗ trợ ảnh (Outlook desktop, Gmail web, iOS Mail), vì vậy các nhà thiết kế thử nghiệm với placeholder trước khi chuyển sang tài sản sản xuất.
• Bản in proof. Bố cục sách, trang tạp chí và thiết kế bao bì sử dụng placeholder FPO («for position only») trong quá trình sắp chữ. Kích thước tồn tại trong bố cục từ rất lâu trước khi nhiếp ảnh gia giao hàng.
• Hướng dẫn và tài liệu. Khi viết «cách xây dựng thành phần card», bạn cần ảnh thay thế không bị hỏng nếu nguồn thay đổi. Placeholder tự host tồn tại khi các dịch vụ bên ngoài ngừng hoạt động (như Lorem Pixel đã làm).
• Tests A/B và nguyên mẫu. Kiểm tra bố cục nhanh với ba kích thước ảnh khác nhau nhanh hơn với placeholder được tạo so với việc render lại các tài sản thực.

Những sai lầm gây hại cho hiệu suất trang

• Quên thuộc tính width và height. Nguyên nhân phổ biến nhất của điểm CLS kém. Ngay cả với ảnh responsive được điều khiển bởi CSS, hãy đặt width và height nội tại để trình duyệt đặt chỗ tỷ lệ chính xác. Các trình duyệt hiện đại tính toán aspect-ratio: width/height tự động từ các thuộc tính này kể từ 2020.
• Phục vụ placeholder 4096×4096 cho hiển thị 200×200. Hai mươi lần byte không có lợi ích hình ảnh. Khớp kích thước placeholder với kích thước thực tế được render, hoặc sử dụng srcset với nhiều biến thể.
• Văn bản alt trống hoặc thiếu. Screen reader thông báo «ảnh» mà không có ngữ cảnh. Đối với placeholder thuần trang trí, sử dụng alt="" một cách rõ ràng để báo hiệu «bỏ qua điều này». Đối với ảnh nội dung, viết mô tả ngay cả trên placeholder để QA bắt được copy bị thiếu.
• Inlining data URI khổng lồ. Một ảnh 100 KB dưới dạng base64 trở thành ~133 KB bên trong HTML của bạn, chặn việc phân tích, và phá hỏng bộ nhớ đệm (HTML thường không được cache mạnh mẽ, ảnh thì có). Sử dụng data URI chỉ dưới ~2-4 KB.
• Phụ thuộc vào placehold.it / lorempixel / dịch vụ bên ngoài trong sản xuất. Họ sập. Lorem Pixel biến mất khoảng 2017 và phá vỡ hàng ngàn site demo. Đối với hướng dẫn, demo và câu chuyện, hãy tự tạo placeholder hoặc tự host chúng.
• PNG cho ảnh chụp, JPEG cho logo. Một ảnh dưới dạng PNG lớn hơn 3-5 lần so với cùng ảnh dưới dạng JPEG. Một logo dưới dạng JPEG sẽ có những vòng nén xấu xí quanh các cạnh. Chọn định dạng theo loại nội dung, không phải thói quen.
• Bỏ qua loading="lazy". Các ảnh dưới fold tải háo hức cạnh tranh băng thông với hero. Thêm loading="lazy" vào mọi thứ dưới viewport. Native, không cần thư viện, được hỗ trợ từ Chrome 76 (tháng 8/2019) và Safari 15.4 (2022).

Thêm các câu hỏi thường gặp

Tại sao nhãn kích thước lại hữu ích trên một placeholder?

Khi bạn có hàng tá placeholder trong một bố cục với các kích thước khác nhau, nhãn ngay lập tức cho bạn biết slot nào là slot nào. «400×300» trên hình chữ nhật xám là thông tin hơn việc đoán liệu card là 4:3 hay 16:9. Các nhà thiết kế và nhà phát triển xem xét mockup có thể phát hiện các phần tử có kích thước sai từ phía bên kia phòng.

Sự khác biệt giữa BlurHash, ThumbHash và LQIP là gì?

Cả ba đều mã hóa một bản xem trước nhỏ của một ảnh giải mã thành placeholder mờ. LQIP («low-quality image placeholder») chỉ là một JPEG nhỏ (~100 byte đến 2 KB). BlurHash (Wolt, 2019) mã hóa bất kỳ ảnh nào thành chuỗi ASCII 20-30 ký tự mà bạn lưu trữ trong cơ sở dữ liệu; thời gian giải mã là vi giây. ThumbHash (Evan Wallace, 2023) tương tự nhưng nhỏ hơn 30-50% với cùng chất lượng, và kết xuất các cạnh sắc nét hơn. Các framework hiện đại (Next.js, Astro, Hugo) đều hỗ trợ BlurHash mặc định.

Tôi nên sử dụng SVG hay PNG cho thumbnail placeholder?

SVG nếu placeholder là một hình dạng đơn giản (hình chữ nhật, biểu tượng, mẫu hình học). Một SVG nội tuyến 50 byte đánh bại PNG 2 KB mọi lúc. PNG nếu bạn cần kết xuất văn bản chính xác pixel hoặc fallback font cụ thể: kết xuất văn bản SVG khác nhau giữa các trình duyệt và nền tảng. Đối với placeholder động được tạo phía client, công cụ này tạo PNG vì kết xuất văn bản canvas có thể dự đoán được giữa các trình duyệt.

PNG được tạo có bao gồm EXIF hoặc metadata ẩn không?

Không. PNG được tạo bởi API canvas HTML toBlob() hoặc toDataURL() chỉ chứa các khối IHDR, IDAT, và IEND cộng với một khối tEXt tối thiểu trong một số trình duyệt. Không có GPS, không có thông tin máy ảnh, không có lịch sử chỉnh sửa, không có định danh người dùng. So sánh với JPEG máy ảnh điện thoại làm rò rỉ tọa độ GPS và số serial thiết bị.

Có gì được gửi đến máy chủ khi tôi tạo ảnh ở đây không?

Không. Ảnh được vẽ cục bộ thông qua API Canvas 2D HTML5 trong trình duyệt của bạn. Mở tab Network trong DevTools khi tạo: không có yêu cầu đi ra cho ảnh. An toàn cho mockup bảo mật, NDA, công việc khách hàng, và thiết kế sản phẩm chưa phát hành.