【问题标题】:Inline svg vs svg Sprite vs multiple external files内联 svg vs svg Sprite vs 多个外部文件
【发布时间】:2020-08-28 23:25:21
【问题描述】:

好的,所以我主要使用 Laravel 和 Vue js 构建一个 Web 应用程序。我尝试使用https://github.com/JetBrains/svg-sprite-loader#installation,但导出的 svg 显示为空白。

在继续之前,我开始怀疑这是否真的值得,而且我不确定。

所以我的问题是,真正的区别是什么?

假设我们不能使用图标字体,因为我们想要多色的 svg。

  • 是否值得尝试使用一个包将 svg 合并到一个 sprite 中然后使用它,或者它与 http/2 并没有真正的区别?

  • 考虑到文件大小和数据使用情况,是否值得尝试使用 sprite 而不是多个外部 svg 文件来最小化这方面?

  • 内联 svg 也是一种选择,但这会显着增加 dom 大小。

所以我想知道...有没有人尝试过所有这些技术并找出最好和最高效的技术以及它们的真正区别是什么。

最后,如果有人能给我一些关于为什么我的 svg sprite 显示为空白的意见,那将是一个巨大的奖励:P

我已经在我的 webpack.mix 中配置了上面的包,如下所示:

const mix = require('laravel-mix');
const SpriteLoaderPlugin = require('svg-sprite-loader/plugin');

mix.js('resources/js/app.js', 'public/js')
    .sass('resources/sass/app.scss', 'public/css')
    .webpackConfig({
        module: {
            rules: [
                {
                    test: /resources\/images\/.*\.svg$/,
                    loader: 'svg-sprite-loader',
                    exclude: /node_modules/,
                    options: {
                        extract: true,
                        spriteFilename: 'icons-sprite.svg',
                        publicPath: 'images/sprites/',
                    }
                }
            ]
        },
        plugins: [
            new SpriteLoaderPlugin({ plainSprite: true}) // Sprites Plugin.
        ],
    })
    .version()

【问题讨论】:

    标签: svg webpack inline-svg svg-sprite svg-sprite-loader


    【解决方案1】:

    是否值得尝试使用一个包将 svg 合并到一个 sprite 中然后使用它,或者它与 http/2 并没有真正的区别?

    这确实很重要,但取决于您的用例。您必须自己在 生产 环境中进行测试。当然 HTTP/2 总是更好

    考虑到文件大小和数据使用情况,是否值得尝试使用 sprite 而不是多个外部 svg 文件来最小化这方面?

    答案与 1.. 用例相同。归结为估计(因为您无法计算)浏览器 A 必须等待新内容的时间。

    GZip 是影响数据使用的最重要因素。

    在慢速 3G 连接上,为(大)文件添加您自己的 LZMA 压缩可能很有趣。

    内联 svg 也是一种选择,但这会大大增加 dom 的大小。

    您仍然在发送相同的字节,只是在不同的文件中,因为 GZip 在一个文件中处理所有内容可能会更好。

    总的来说,我的建议是不要担心性能;这不是 OR-OR 决定。

    从单独的文件开始,仅在遇到性能问题时重新考虑。
    如果您预计性能问题,也许可以考虑重构。

    替代方案:创建 SVG 客户端

    我更进一步。成为一个实验,我可以走多小/多快:

    • 将所有 SVG 重新设计为字符串表示法 <circle cx='20' cy='20' r='5'/> 变为 c:20,20,5
    • 在一个JS文件中使用
    • 解析字符串客户端
    • 创建 SVG
    • 在 DataURI IMG src 中使用

    这将 52 个 SVG 文件中的 550 KB 降至 一个 自定义元素文件中的 16 KB

    而 GZip 是一个重要因素!

    GZip 在将服务器端文件发送到客户端之前对其进行压缩。

    是的,缩小很重要,但缩小可能对 GZip 压缩产生负面影响。

    很久以前的好书:

    https://encode.su/threads/1889-gzthermal-pseudo-thermal-view-of-Gzip-Deflate-compression-efficiency

    它解释了为什么 <!DOCTYPE HTML> 不好,而 <!doctype html> 好。

    同样适用于 SVG 文件:<circle ... 优于 <CIRCLE ...

    <circle fill='...' cx='20' .../> 优于 <circle cx='20' ... fill='...'/>

    因为 GZip 发现了更长的重复模式<circle fill='

    【讨论】:

    • 好吧,如果我理解正确的话: - 内联 svg 绝不是最好的解决方案,如果我们谈论的是一个动态生成多个 svg 的过程,因为它几乎与我们使用单独的, 文件,但会增加 dom 大小。 - Sprites 在性能方面总是更好,但应该评估实施时间是否值得。 - 应该通过反复试验来实现它,因为实际上不可能评估它是否值得。如果我想在未来实现服务器端渲染,您建议的技术是否可行? TY
    • 只有当您为许多用户提供服务并且流量具有(显着)价格时,这种选择才值得努力。在 HTML 文件或带有符号的 SVG 文件中内联没有区别,它们只是在不同的文件中是相同的字节。添加SSR时没有区别。对于一切:人们认为它是关于缩小文件的;不是,这都是关于 GZip 的:encode.su/threads/…
    • 我想关于缓存可以提出一个论点。我猜当文档的缓存因任何原因而失效时,内联 svgs 通常是加载器,而如果您引用的是单独的缓存 svg 文件。 (免责声明:我“还没有:P”对完整的缓存周期如此了解)。如果我们认为我们可能会有一些 svg 重复自己很多次(例如,带有某些实体的预告片的页面,使用相同的 svg 来表示某些指示),您还会回答更改吗?
    • 是的,然后是客户端缓存(甚至可能使用 localStorage 来存储内容)和服务器端缓存。你说重复很多,然后坚持一个文件......因为缓存是最重要的部分。这一切都是关于思考每个字节的传输位置/方式/时间。但最后:耐克的方法:只做 IT .. 开始开发。
    猜你喜欢
    • 2014-02-13
    • 2017-03-01
    • 1970-01-01
    • 2011-08-18
    • 2011-11-04
    • 2013-07-19
    • 2014-06-06
    • 1970-01-01
    • 2012-07-29
    相关资源
    最近更新 更多