typicode

延时摄影软件要 200 多块，一行命令就够！tlapse 每隔几秒自动截屏拼成延时视频，做演示、记录界面改版、盯长任务都合适，只存压缩帧。2000 星。 typicode/tlapse

The Complete Guide to SVG Icon Optimization for Web Performance SVG icons have become the backbone of modern web interfaces. They scale crisply to any resolution, are easy to style with CSS, and can even be animated for delightful UI touches. But as handy as SVGs are, unoptimized SVG icons can quietly bloat your web assets, slow down rendering, and eat away at the performance gains you expect. To truly harness the benefits of SVG icons, careful svg optimization is essential. This complete guide will walk you through why SVG icon optimization matters, the key techniques and tools at your disposal, and practical steps you can integrate into your workflow. Whether you’re shipping a design system or simply want to improve your site’s web performance, these strategies will help you deliver pixel-perfect icons without unnecessary baggage. Why SVG Optimization Matters SVG (Scalable Vector Graphics) is a text-based XML format, which means that what you ship to the browser can vary wildly in size and complexity. Designers’ export defaults, unnecessary metadata, and verbose markup can inflate SVG files. Unlike PNG or JPEG files, SVGs are human-readable — and that’s both a blessing for flexibility and a curse for performance if left unchecked. Optimized SVG icons lead to: - Faster load times: Smaller file sizes mean quicker downloads and less bandwidth. - Better rendering performance: Clean markup reduces the browser’s parsing and painting work. - Improved maintainability: Simpler SVGs are easier to debug, style, and manipulate with CSS/JavaScript. - Accessibility: Clean, semantic SVGs are easier to make accessible. Optimizing SVGs isn’t just for performance purists. Every byte counts, especially as you scale your icon library across a modern app. Anatomy of an SVG Icon To optimize effectively, it’s helpful to understand the basic structure of an SVG file. Here’s a typical SVG icon: <svg width="24" height="24" viewBox="0 0 24 24" fill="none" xmlns="http://www.w3.org/2000/svg"> <g id="Layer_1"> <title>Home Icon</title> <desc>House outline</desc> <path d="M12 3L2 12h3v7h6v-4h2v4h6v-7h3z" fill="#333"/> <rect x="0" y="0" width="24" height="24" fill="none"/> <metadata>Created by Figma</metadata> </g> </svg> Notice the title, desc, metadata, groupings, and explicit sizing. While some of these elements can help with accessibility or design clarity, much of it is redundant for a simple icon. Key Techniques for SVG Icon Optimization Let’s break down the practical steps to optimize SVG icons for web performance. 1. Remove Unnecessary Metadata and Elements Exported SVGs often include: - <metadata>, <defs>, or proprietary editor tags - <title> and <desc> (useful for accessibility, but optional) - Unused <g> (group) elements - Editor-generated comments or whitespace Manual cleanup: <!-- Before: --> <svg xmlns="http://www.w3.org/2000/svg"> <g> <title>Icon</title> <path d="..." /> <metadata>...</metadata> </g> </svg> <!-- After: --> <svg xmlns="http://www.w3.org/2000/svg"> <path d="..." /> </svg> You can do this in a text editor for a few icons, but automation is much faster. 2. Minimize Path Data SVG paths (<path d="..." />) are the most common way to define icon shapes. However, exported paths often contain unnecessary decimals or redundant commands. Example: <!-- Before: --> <path d="M10.0000001 20.0000003 L20.0000002 10.0000005 Z" /> <!-- After: --> <path d="M10 20L20 10Z" /> Reducing decimal precision (e.g., to 2-3 decimal places) and removing unnecessary whitespace can save bytes and improve rendering speed. 3. Simplify SVG Structure Eliminate unnecessary grouping (<g>) and flatten layers where possible. For simple icons, you may only need a single <path> or a handful of simple shapes. 4. Optimize Color and Attribute Usage - Remove explicit width and height attributes if you want icons to scale responsively; rely on viewBox. - Use currentColor for fill or stroke to inherit text color, enabling easy theming. - Strip out unused attributes like id, class, or editor-specific data. Example: <svg viewBox="0 0 24 24" fill="currentColor"> <path d="..." /> </svg> 5. Compress and Minify SVG Files Just like JavaScript and CSS, SVGs benefit from minification. This removes whitespace, comments, and shortens attribute names where possible. 6. Use Symbols and SVG Sprites (for Many Icons) If you use many icons on the same page, consider SVG sprites or <symbol> elements. This lets you reference icons without duplicating markup or downloads. Example: <svg style="display: none;"> <symbol id="icon-home" viewBox="0 0 24 24"> <path d="M12 3L2 12h3v7h6v-4h2v4h6v-7h3z"/> </symbol> </svg> <!-- Usage: --> <svg width="24" height="24"> <use href="#icon-home" /> </svg> Automation Tools for SVG Optimization Manually optimizing SVG icons is tedious and error-prone. Fortunately, there are robust tools designed for svg optimization. SVGO (SVG Optimizer) SVGO is the industry-standard open source tool for SVG optimization. It parses, cleans, and compresses SVGs using a wide array of plugins. Installation: npm install -g svgo Basic usage: svgo input.svg -o output.svg With custom plugin configuration (svgo.config.js): module.exports = { multipass: true, plugins: [ 'removeTitle', 'removeDesc', 'removeMetadata', 'removeComments', { name: 'removeAttrs', params: { attrs: '(stroke|fill)' } }, { name: 'convertColors', params: { currentColor: true } }, // More plugins as needed ], }; SVGOMG (SVGO’s Online GUI) SVGOMG (jakearchibald.github.io) offers a friendly web UI for SVGO. Drag-and-drop your icons, adjust optimization parameters, and download the results. Great for designers or quick manual optimization. Other Tools and Workflows - svgr: Converts SVG files into React components, with built-in optimization. - ImageMagick: For batch conversion and some cleaning (less flexible than SVGO). - Design tool plugins: Figma, Sketch, and Illustrator offer SVG export options and plugins for cleaner output. - AI-powered generators: Tools like SVGator, Vecta.io, and IcoGenie can generate optimized SVG icons directly, reducing the need for further manual cleanup. Optimizing SVGs in a Build Pipeline For real-world projects, integrate svg optimization into your development workflow: 1. Node.js Scripts You can batch-optimize your /icons directory using SVGO: // optimize-icons.js const { optimize } = require('svgo'); const fs = require('fs'); const path = require('path'); const iconsDir = './icons'; fs.readdirSync(iconsDir).forEach(file => { if (file.endsWith('.svg')) { const filePath = path.join(iconsDir, file); const svg = fs.readFileSync(filePath, 'utf8'); const result = optimize(svg, { path: filePath }); fs.writeFileSync(filePath, result.data); console.log(`Optimized: ${file}`); } }); 2. Webpack or Vite Plugins Many bundlers support SVG optimization plugins: - vite-plugin-svgo: For Vite projects - svg-sprite-loader: For SVG sprites in Webpack - @svgr/webpack: For React component output 3. Git Hooks Run SVG optimization on each commit using tools like lint-staged and husky: // package.json "lint-staged": { "*.svg": "svgo --config=svgo.config.js" } This ensures that all committed icons are optimized. Accessibility Considerations Optimizing for web performance shouldn’t come at the expense of accessibility. When shipping SVG icons: - Use <title> (and optionally <desc>) for meaningful icon descriptions. - Use aria-hidden="true" for purely decorative icons. - Prefer inline SVGs (over background images) for better accessibility and styling. Example: <svg viewBox="0 0 24 24" aria-label="Home"> <title>Home</title> <path d="..." /> </svg> Practical Example: Before and After Original: <svg width="48" height="48" viewBox="0 0 48 48" fill="#0078D4" xmlns="http://www.w3.org/2000/svg"> <!-- Created in Illustrator --> <g id="Layer_2"> <title>Bell Icon</title> <desc>Notification Bell</desc> <path d="M24 4C14.1 4 6 12.1 6 22V32L4 34V36H44V34L42 32V22C42 12.1 33.9 4 24 4Z"/> <rect x="0" y="0" width="48" height="48" fill="none"/> <metadata>Generated by Adobe Illustrator</metadata> </g> </svg> Optimized: <svg viewBox="0 0 48 48" fill="currentColor" aria-label="Notification"> <title>Bell</title> <path d="M24 4C14.1 4 6 12.1 6 22V32L4 34V36H44V34L42 32V22C42 12.1 33.9 4 24 4Z"/> </svg> - Removed pixel-based sizing for scalability - Cleaned up groups, metadata, and unused elements - Used currentColor for theming - Retained minimal accessibility features Key Takeaways - SVG icon optimization is a critical part of web performance, especially for modern UI libraries and design systems. - Always remove unnecessary metadata, minimize path data, and flatten SVG structure for minimal markup. - Use automation tools like SVGO or SVGR in your build pipeline for consistent optimization. - Prioritize accessibility, making sure optimized icons remain usable for all users. - Regularly audit your icon library as your app grows — every byte counts. With these practical svg optimization strategies, you’ll deliver SVG icons that are as efficient as they are beautiful — giving your users a faster, pixel-perfect experience every time.

Git said the commit succeeded. My hooks never ran. I use Husky in several repos so commits hit lint, typecheck, and format checks before they land. I added a git worktree to work on a side branch. The worktree inherited core.hooksPath from the main checkout. It did not inherit the executable shims Husky generates under .husky/_. I committed. Git accepted the commit. None of the pre-commit recipe ran. There was no error, no red banner, no failed hook exit code. The checks I thought were mandatory simply never executed. That was the first time I treated "hooks configured" as "hooks enforced" and was wrong. What "configured" actually means Modern Husky does not drop scripts straight into .git/hooks. Git reads core.hooksPath, usually .husky/_, and Husky installs small forwarding shims there. Those shims call the real hook scripts in .husky/pre-commit and friends. A new worktree inherits the repository's core.hooksPath setting. Husky still has to generate executable shims under .husky/_ in that worktree, and git worktree add does not do that step for you. existing checkout ├─ core.hooksPath → .husky/_ └─ .husky/_ shims present → pre-commit runs new worktree ├─ core.hooksPath → .husky/_ (inherited) └─ .husky/_ shims missing → commit succeeds, hooks silent A fresh worktree could have the expected hook path configured without the executable shims needed to run the checks. Git accepted my commit anyway. From one checkout to a fleet of agents For years, I worked from a relatively stable checkout. I installed dependencies, initialized Husky, and rarely thought about hook setup again. That assumption started breaking with parallel Cursor sessions in Git worktrees. Each new worktree was another checkout that needed its own hook initialization, even when the original checkout was configured correctly. The problem became more interesting as I started designing toward a fleet of Cloud Agents coordinated by GrokBot. GrokBot runs on a cloud computer and delegates coding tasks to Cursor Cloud Agents, each working in its own environment. A Cloud Agent could start correctly, run its installation scripts, and initialize Husky. But if it subsequently created another Git worktree, that checkout would need its own initialization. The startup scripts wouldn't automatically run again. The original checkout was correctly initialized. The new worktree wasn't. And across a fleet of delegated agents, I couldn't rely on noticing and fixing every missing hook myself. Git and Husky hadn't changed. I had started treating agent startup as the initialization boundary, when every new worktree introduced another one. Four layers I needed hook availability to be verifiable in each environment, repairable without my intervention, and backed by checks that didn't depend on local hooks running at all. I split those responsibilities into four layers. | Layer | Responsibility | | --- | --- | | 1. Availability | Verify hooks are runnable in this checkout | | 2. Agent feedback | Improve formatting during edits | | 3. Pre-commit | Run local validation before committing | | 4. CI | Independently validate changes | Blurring these responsibilities is how silent skips hide. Layer 1 is observability, not enforcement by itself. An agent must not assume hooks are active merely because core.hooksPath is set. My verify:git-hooks script checks that each hook under .husky/ has an executable companion shim under .husky/_ in this worktree. A green run means that plumbing is present here; it does not prove Git will invoke those hooks on the next commit or that pre-commit checks would pass. Layers 3 and 4 still own whether the next commit is actually protected. Layer 2 is deliberately weak. Optional formatting while an agent edits files helps diffs stay readable. It is convenience, not a guarantee, and it does not substitute for pre-commit or CI. Layers 3 and 4 stay separate on purpose. Local pre-commit is the recipe you choose per repo. CI is the backstop when a checkout, an agent session, or a skipped hook lets something through anyway. What I changed I moved hook verification and repair into shared scripts that run when a Cursor session starts. They check whether Husky's executable shims exist in the current checkout, attempt repair when they're missing, and warn with HOOKS NOT RUNNABLE if the problem remains. Session startup stays fail-open so a broken hook doesn't prevent me from editing. Cloud Agents need another safeguard. Cursor's hook bridge routes Git hook execution to the current repository at commit time. When the bridge is active, a missing Husky shim can produce an explicit commit failure instead of a silent skip. In repositories where I've configured a blocking Cloud startup gate, the agent also waits for that bridge to become available before starting work. None of this automatically initializes a worktree created later in the session. Each new checkout still needs its own prepare run. I packaged the verification, repair, and Cloud lifecycle scripts into my marketplace plugin and reused them across repositories. Each repository still needs to wire those scripts into its installation and session-start lifecycle; installing the plugin alone doesn't activate those safeguards. The change wasn't that every possible hook failure had been eliminated. It was that broken hook state became easier to detect, repair, or stop before an unchecked commit went unnoticed. Takeaway: A configured hook path told me where Git would look. It did not tell me whether anything would run there. --- Implementation: I've published the hook verification and repair scripts I use across my projects. They're part of my Cursor workflow, but the implementation is public if you're interested in how I approached the problem.