DEV Community: 王康

Build an Image Compress Budget Gate Before Heavy Assets Reach Production

王康 — Tue, 20 Oct 2026 08:46:56 +0000

The page looked fine in review. The deployment passed. Then someone opened it on a slower mobile connection and found that the new hero image was nearly 5 MB.

Nothing was technically broken. The file existed, the browser could decode it, and the layout rendered correctly. The problem was that our definition of “ready” did not include an image size limit.

That is where an image budget helps. Instead of treating image compress work as a final manual cleanup, we can make file size part of the build contract. If an asset exceeds the agreed limit, CI should explain the problem before the change reaches production.

This tutorial builds a small, dependency-free image size gate with Node.js and runs it in GitHub Actions.

TL;DR

Define limits by asset role, not one universal number.

Check individual files and the total image payload.

Fail CI with an actionable message.

Keep compression separate from validation.

Adjust budgets using real production measurements.

Why a valid image can still be a broken artifact

Most build pipelines answer questions such as:

Does the file exist?
Does the application compile?
Do tests pass?
Can the browser render the asset?

Those checks are necessary, but they do not tell us whether a file is appropriate for delivery. A 4,000-pixel photograph may be valid while still being wasteful inside a 900-pixel content column.

An image compress workflow reduces the file after someone notices the problem. An image budget moves the decision earlier. It turns “this feels too large” into a rule that can be reviewed, versioned, and enforced.

The goal is not to make every image as small as possible. The goal is to catch accidental weight before it becomes a user-facing regression.

Start with budgets you can explain

A single limit for every image is tempting, but it ignores how assets are used. A full-width hero, a product thumbnail, and a small icon have different requirements.

Here is a reasonable starting point for a content site:

Asset group	Example limit
Hero image	350 KB
Article image	220 KB
Thumbnail	100 KB
Icon or badge	30 KB
Total images on one page	1 MB

These are not universal standards. A photography portfolio may accept larger files, while a documentation site can be stricter. What matters is that each limit reflects the rendered size, visual importance, and network conditions of the audience.

Treat the image compress budget as a project constraint rather than a universal score. It should describe what your pages can afford, not force unrelated assets into the same preset.

Start with current production data. Identify the heaviest pages, inspect their image requests, and choose a first budget that catches obvious mistakes without blocking normal work.

Create a dependency-free size checker

The following script scans an image directory, checks every supported file, and fails when either an individual file or the combined folder size exceeds the budget.

Create scripts/check-image-budget.mjs:

import { readdir, stat } from "node:fs/promises";
import { extname, join, relative } from "node:path";

const root = process.argv[2] ?? "public/images";
const maxFileBytes = Number(process.env.MAX_IMAGE_KB ?? 250) * 1024;
const maxTotalBytes = Number(process.env.MAX_IMAGE_TOTAL_KB ?? 1500) * 1024;
const imageExtensions = new Set([
  ".jpg", ".jpeg", ".png", ".webp", ".avif", ".gif"
]);

async function walk(directory) {
  const entries = await readdir(directory, { withFileTypes: true });
  const files = [];

  for (const entry of entries) {
    const fullPath = join(directory, entry.name);

    if (entry.isDirectory()) {
      files.push(...await walk(fullPath));
    } else if (imageExtensions.has(extname(entry.name).toLowerCase())) {
      files.push(fullPath);
    }
  }

  return files;
}

function toKB(bytes) {
  return `${(bytes / 1024).toFixed(1)} KB`;
}

const files = await walk(root);
const failures = [];
let totalBytes = 0;

for (const file of files) {
  const { size } = await stat(file);
  totalBytes += size;

  if (size > maxFileBytes) {
    failures.push(
      `${relative(root, file)} is ${toKB(size)}; limit is ${toKB(maxFileBytes)}`
    );
  }
}

if (totalBytes > maxTotalBytes) {
  failures.push(
    `Total image size is ${toKB(totalBytes)}; limit is ${toKB(maxTotalBytes)}`
  );
}

if (failures.length > 0) {
  console.error("Image budget exceeded:\n");
  for (const failure of failures) console.error(`- ${failure}`);
  console.error("\nResize, convert, or compress the affected assets, then run the check again.");
  process.exit(1);
}

console.log(
  `Image budget passed: ${files.length} files, ${toKB(totalBytes)} total.`
);

Run it locally with:

MAX_IMAGE_KB=250 \
MAX_IMAGE_TOTAL_KB=1500 \
node scripts/check-image-budget.mjs public/images

This first version intentionally checks bytes, not perceived quality. CI can tell us that a file is too large; a person still needs to decide whether resizing, format conversion, or a gentler image compress setting is the correct fix.

Add the gate to GitHub Actions

Run the same command on pull requests so the feedback appears before merge:

name: Image budget

on:
  pull_request:
    paths:
      - "public/images/**"
      - "scripts/check-image-budget.mjs"
      - ".github/workflows/image-budget.yml"

jobs:
  check-images:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - name: Check image budget
        env:
          MAX_IMAGE_KB: 250
          MAX_IMAGE_TOTAL_KB: 1500
        run: node scripts/check-image-budget.mjs public/images

The paths filter avoids running the job when a pull request changes unrelated code. The limits remain visible in the workflow, which makes a budget change an explicit code review decision.

Make failures actionable

A gate is useful only when developers know how to recover. “Build failed” is not enough. The check should name the file, show its current size, state the allowed size, and suggest the next step.

A useful image compress gate therefore reports a repair path, not only a red status icon.

When a file fails, use this order:

Check dimensions. If the source is much wider than its largest rendered size, resize it first.
Check the format. A photograph exported as PNG may be better suited to JPEG, WebP, or AVIF.
Apply image compression. Compare at least two quality levels at the actual display size.
Retest the page. Confirm that text, gradients, transparency, and important details still look correct.
Run the budget check again. Validation should use the final file that will be deployed.

For occasional assets, a browser tool such as ImageCompress can help compare a smaller output without opening a full image editor. For private or unreleased material, review the service’s file-handling policy or keep processing inside an approved local workflow.

Do not let CI silently rewrite assets

It may seem convenient to have CI automatically run an image compress command and commit the result. In practice, that hides an important visual decision.

Different assets fail in different ways. Photographs can develop blocking around edges, screenshots can lose text clarity, and transparent graphics can gain halos. A fully automatic rewrite may pass the byte limit while damaging the image’s purpose.

A safer separation is:

local tooling or a controlled build step creates optimized candidates;
a developer reviews the visual result;
CI validates the committed output against the budget.

Automation should prevent regressions, not remove the quality review.

Improve the rule as the project grows

The basic script is intentionally small. A production system can extend it in several ways:

use different limits for hero/, content/, and thumbnails/;
inspect pixel dimensions with an image metadata library;
compare only files changed in the pull request;
publish a size report as a pull request comment;
track page-level transfer size with Lighthouse or a browser test;
allow documented exceptions for assets that genuinely need more detail.

Be careful with permanent exceptions. If every failure becomes a larger limit, the budget stops protecting anything. An exception should explain why the heavier asset is necessary and which page owns the cost.

What this check does not solve

A small file can still load late. The browser may discover it only after JavaScript runs, the server may omit effective caching, or the page may lazy-load its main visual by mistake.

The budget covers transfer weight. It does not replace responsive srcset candidates, correct width and height, caching, request prioritization, or performance measurement in real browsers.

Think of it as one reliable boundary in a larger delivery system.

Pre-merge checklist

[ ] The source dimensions match the asset’s intended display size.
[ ] The format fits the visual content.
[ ] The image compress result was reviewed at normal zoom.
[ ] The file passes its individual size budget.
[ ] The page stays within its total image budget.
[ ] Responsive variants exist where they provide a real benefit.
[ ] The pull request explains any approved exception.
[ ] The deployed request size is verified in browser tools.

Final thoughts

The most expensive image regressions are often ordinary mistakes: an original camera export, a screenshot saved in the wrong format, or a replacement asset with much larger dimensions than the file before it.

A small CI gate catches those mistakes while they are still easy to fix. It also turns image compress decisions into shared engineering rules instead of relying on someone to remember a checklist before every release.

Start with one directory and one understandable limit. Run the check in warning mode if necessary, observe what it catches, and tighten the budget using real page data. Once the rule reflects the project’s needs, make it a required check.

The build should not only prove that an image can ship. It should also prove that the image belongs in the delivery budget.

Image Compress Workflow: Reduce File Size Without Ruining Quality

王康 — Tue, 20 Oct 2026 03:10:20 +0000

Large images are one of the easiest ways to make a fast website feel slow. A single photo exported directly from a camera or design tool can outweigh the HTML, CSS, and JavaScript used to render the entire page.

An effective image compress workflow is not about pushing every file toward the lowest possible number. It is about removing data the visitor will never see while preserving the detail that makes the image useful.

This guide walks through a repeatable process you can apply to blogs, product pages, portfolios, and documentation sites.

TL;DR

Resize before compressing.

Match the file format to the image content.

Judge quality at the actual display size.

Deliver responsive variants and lazy-load only non-critical images.

Why image weight matters

Images often account for a large share of a page's transferred bytes. Reducing that weight can shorten downloads, lower mobile data usage, and make content appear sooner on slower connections.

However, image compress work is only one part of web performance. A small hero can still appear late if its URL is hidden behind client-side rendering, while an image discovered immediately can still delay the page if it is several megabytes. Measure transfer size, discovery time, and rendering separately.

1. Resize before you compress

The most common mistake is placing a 5,000-pixel photo inside a content column that never exceeds 900 pixels. CSS may display it at the correct width, but the browser still downloads the original file.

A practical image compress process begins with the rendered dimensions:

Find the largest rendered size.
Resize the source while preserving its aspect ratio.
Compress the resized version.
Preview it in the real layout.

If an article image displays at 800 pixels wide, a 1,200- or 1,600-pixel source may be enough. Resizing first usually reaches a reasonable file size without an aggressive quality setting.

2. Choose a format based on the content

No format is best for every asset. Choose based on whether the image is a photograph, screenshot, logo, or transparent graphic.

Format	Good for	Watch out for
JPEG	Photos, gradients, product shots	No transparency; artifacts appear at low quality
PNG	Logos, UI screenshots, sharp lines	Photographs can become unnecessarily large
WebP	Photos and graphics for modern web delivery	Keep your build and fallback strategy consistent
AVIF	High compression efficiency for supported workflows	Encoding can be slower; verify tool and browser requirements

Format selection is part of the image compress decision. Converting a photo from PNG to WebP may save more than repeatedly lowering PNG quality, while a text-heavy screenshot may look better as PNG or lossless WebP.

3. Evaluate quality where users will see it

A quality value of 80 does not produce identical results for every image. Hair, foliage, gradients, and small interface text often reveal damage early.

When reviewing an image compress result, inspect:

faces and product edges;
text and icons in screenshots;
smooth gradients and transparent edges;
QR codes that must remain readable.

Finally, view it at the real rendered size. A tiny artifact at 400% may not matter, while blurred text can remain distracting on a phone. File size is a constraint, not the only success metric.

4. Send responsive image candidates

Even a well-compressed desktop image may be wasteful on a small screen. Use srcset and sizes so the browser can choose a suitable candidate.

<img
  src="workspace-960.webp"
  srcset="workspace-480.webp 480w,
          workspace-960.webp 960w,
          workspace-1440.webp 1440w"
  sizes="(max-width: 768px) 100vw, 960px"
  width="960"
  height="640"
  alt="A desk with a laptop and design sketches"
>

Each candidate needs its own image compress pass. The browser selects among the files you provide; it does not automatically optimize an oversized source.

Including width and height gives the browser an aspect ratio before the file arrives, reserving space and reducing layout movement.

5. Use lazy loading selectively

Below-the-fold images are good candidates for loading="lazy". Do not apply it to every image by habit. The main hero or likely Largest Contentful Paint image usually needs to be fetched early, and delaying it can make the page feel slower even after image compress optimization.

Compression changes transfer size. Lazy loading changes request timing. Use each technique for the problem it actually solves.

6. Build a repeatable optimization routine

For occasional blog images, a manual workflow can be enough:

Save the untouched original.
Crop unused space and generate the required dimensions.
Select the output format.
Apply image compress settings and compare the result.
Test on desktop, mobile, and a slower network profile.

For a small batch, a browser-based tool can make comparison convenient. For example, ImageCompress can be used when you want to prepare common web images without opening a full editing application.

Before using any online service, check how files are processed and deleted. Confidential documents, internal designs, and unreleased product images should stay in a trusted environment.

Once optimization becomes routine, automate maximum dimensions, formats, quality ranges, and responsive variants in the build system or CDN. Verify transferred files in the browser Network panel and compare performance tests under consistent conditions.

Common mistakes

Compressing the full-resolution original: resize to the required dimensions first.
Optimizing only for a percentage: a large reduction is meaningless if text becomes unreadable.
Applying one preset to every asset: photos, logos, and screenshots need different settings.
Ignoring mobile candidates: a compressed desktop file can still be too large for a phone.
Lazy-loading the hero image: prioritize critical visuals and defer only lower content.

Pre-publish checklist

[ ] The image dimensions match the largest rendered size.
[ ] The format fits the image content.
[ ] The image compress result has been checked at actual display size.
[ ] Responsive candidates are available where they provide value.
[ ] width, height, and meaningful alt text are present.
[ ] Below-the-fold images use lazy loading.
[ ] The critical hero image is not unnecessarily delayed.
[ ] The original asset is stored separately.
[ ] The real network request was verified in browser tools.

Final thoughts

A good image compress workflow delivers only the pixels and bytes a user needs, at the moment they need them.

Start with one high-impact image. Resize it, test two suitable formats, compare quality at the rendered size, and measure the actual transfer. Once the result is repeatable, turn the decisions into build rules.

The result is better performance without sacrificing the visual quality your content depends on.

I Built a Free Online PDF Compressor — No Signup, No Watermark

王康 — Tue, 13 Oct 2026 10:02:33 +0000

Hi everyone!

I recently built a small project called PDFCompress — a free online tool that helps people reduce PDF file sizes without installing software, creating an account, or adding a watermark.

The goal was simple: make PDF compression fast, flexible, and easy enough for anyone to use.

💡 The Problem

Large PDF files are surprisingly inconvenient.

They can exceed email attachment limits, take too long to upload, consume unnecessary storage space, and become difficult to share on mobile devices or slower networks.

There are already plenty of online PDF compressors, but many of them come with frustrating restrictions: mandatory registration, hidden fees, watermarks, small upload limits, or very little control over the final result.

I wanted to create a simpler workflow:

Upload → choose a compression level → compress → download

No unnecessary steps and no confusing interface.

🛠️ What I Built

PDFCompress works directly in the browser and supports PDF files up to 1 GB. Users can upload and process up to five files at once, which is useful when compressing reports, scanned documents, presentations, application materials, or other large PDFs.

The tool provides several compression options:

Low compression: preserves more detail and is suitable for printing, portfolios, and professional documents.

Medium compression: balances quality and file size for everyday sharing.

High compression: produces the smallest possible file for email attachments and online uploads.

Grayscale mode: removes unnecessary color information for additional size reduction.

Depending on the document and selected mode, PDFCompress can typically reduce its size by approximately 20%–80% while keeping the text, images, and layout clear.

⚙️ Balancing File Size and Quality

One of the biggest challenges with PDF compression is that there is no single setting that works perfectly for every document.

A scanned PDF containing hundreds of images needs a different strategy from a mostly text-based report. Compress too little, and the resulting file is still too large. Compress too aggressively, and images or small text may lose clarity.

Instead of hiding this tradeoff, PDFCompress gives users a few straightforward compression levels. This keeps the interface simple while still allowing people to decide what matters most for their document: visual quality, smaller file size, or a balance between the two.

🔒 Privacy Was Part of the Product Design

PDF files often contain personal, academic, financial, or business information, so privacy could not be treated as an afterthought.

Files uploaded to PDFCompress are encrypted during transfer and processing. Both the original and compressed files are automatically deleted within 24 hours and are not stored or shared.

The service also requires no account, which means users can compress a document without providing personal registration details.

🧪 Lessons Learned

A few things became especially clear while building the product:

Users care about the final file size, but they care just as much about whether the document still looks good.

A single compression preset cannot handle every type of PDF effectively.

Supporting large files and batch processing makes the tool much more useful in real workflows.

Privacy information should be visible before users upload a file.

A focused interface is often better than a feature-heavy one—most people simply want to upload a PDF, make it smaller, and download it.

🌍 Try It Out

If you regularly need to email reports, submit documents through online portals, or save storage space, you can try PDFCompress here:

👉 https://pdfcompress.ai/

It is free to use, requires no registration, and adds no watermark to the compressed document.

I would love to hear your feedback—esp