相关疑难解决方法(0)

我正在查看一个greasemonkey用户脚本的来源,并在他们的css中注意到以下内容:

.even { background: #fff url(data:image/gif;base64,R0lGODlhBgASALMAAOfn5+rq6uvr6+zs7O7u7vHx8fPz8/b29vj4+P39/f///wAAAAAAAAAAAAAAAAAAACwAAAAABgASAAAIMAAVCBxIsKDBgwgTDkzAsKGAhxARSJx4oKJFAxgzFtjIkYDHjwNCigxAsiSAkygDAgA7) repeat-x bottom}

我可以理解,一个greasemonkey脚本想要在源代码中捆绑任何东西而不是在服务器上托管它,这是显而易见的.但由于我以前没有看过这种技术,我考虑过它的使用,看起来很有吸引力有很多原因:

1. 它将减少页面加载时的HTTP请求量,从而提高性能
2. 如果没有CDN,那么它将减少通过cookie与图像一起发送产生的流量
3. CSS文件可以缓存
4. CSS文件可以是GZIPPED

考虑到IE6(例如)有背景图像缓存问题,这似乎不是最糟糕的想法......

那么,这是一个好的或坏的做法,为什么你不使用它,你会使用什么工具base64编码图像？

更新 - 测试结果

• 用图像测试:http://fragged.org/dev/map-shot.jpg - 133.6Kb

• 测试网址:http://fragged.org/dev/base64.html

• 专用的CSS文件: http://fragged.org/dev/base64.css - 178.1Kb

• GZIP编码服务器端

• 结果发送给客户端的大小(YSLOW组件测试):59.3Kb

• 保存发送到客户端浏览器的数据:74.3Kb

不错,但我认为它对于较小的图像会稍微有用.

更新:谷歌的软件工程师Bryan McQuade正在研究PageSpeed,他在ChromeDevSummit 2013上表达了数据:CSS中的uris被认为是一种渲染阻止反模式,用于在他的演讲中提供关键/最小的CSS #perfmatters: Instant mobile web apps.请参阅http://developer.chrome.com/devsum​​mit/sessions并记住这一点 - 实际幻灯片

与简单地链接到服务器上的硬文件相比,使用base64/line显示图像要快多少？

url(data:image/png;base64,.......)

我无法在此找到任何类型的性能指标.

我有一些顾虑:

• 您不再获得缓存的好处
• 不是base64比PNG/JPEG文件大小大吗？

让我们定义"更快",如下所示:用户查看完整呈现的HTML网页所需的时间

Image我的ManagedBean中有对象.如何在我的JSF页面中获取它？

这似乎不起作用: <h:graphicImage value="#{userProfile.image}" />其中image是类userProfile中的字段变量.

Image来自MySql,如下所示.

int len = rs.getInt("ImageLen");
if(len != 0){
    byte[] b = new byte[len];
    InputStream in = rs.getBinaryStream("Image");
    in.read(b);
    in.close();
    this.image = Toolkit.getDefaultToolkit().createImage(b);
}

我得到的错误是:java.lang.ClassCastException - sun.awt.image.ToolkitImage cannot be cast to java.lang.String.