在分析sIFR之前，先来快速的了解一下sIFR是什么，以及它是如何工作的。sIFR表示scalable Inman Flash Replacement，是一种在web上准确发布自定义排版的技术。这种技术的实现方法是，当页面下载时，在一个指定的元素中用Flash渲染的文字来代替一些文本。理解下面这点是很重要的，这个元素并不是被Flash完全替换，文本仍在元素内，这个元素仍可以像通常那样被样式化或者被定位。
关于sIFR的一些事实：并不是为了辩论sIFR不需要更改（X）HTML代码，所有的工作由Javascript、Flash和CSS来完成；如果用户没有安装Flash或者不支持Javascript，那么（X）HTML的文本就会被CSS样式化后显示出来。
sIFR是可缩放的，可以在渲染时更改为用户设置的缺省字体尺寸。
sIFR兼容所有的屏幕阅读机，至今还没有问题被报道出来。
sIFR的文本可以被鼠标选择，尽管当全选文本时，选中的状态看上去不那么确切。
sIFR不影响搜索引擎的定位和评定，不会隐藏真实的文本内容。
结论应该是，sIFR是一种可使用的，慎重的技术，设计者和开发者使用时应该给予认真的考虑。
什么时候使用sIFR就像所有的web技术一样，重要的是要懂得使用sIFR的最好的方式，以及能够知道最适合使用的场合。这指的是要为工作选择恰当的工具，特别是当sIFR作为一个工具从工具箱中跳出让我们使用时。
案例：一个大型的体育新闻站点决定把所有的标题都设计成公司独有的字体。新闻报道（包括它们的标题）通过某些内容管理软件被世界各地不同的人在不同的地方发布。他们不可能雇佣一些人坐在Photoshop面前，当编辑们每次要增加新闻报道时就创建一张标题图片。
在这种情况下，sIFR就是一个绝对简单的，可使用的和可扩充的工具。一些新闻站点解决这个问题的办法是通过PHP来忙碌的创建图片，或者使用另一些服务器端的手段。这个办法可以很好的节省时间，但是当它与sIFR比较时，就会看到有许多缺点：
图片不能缩放为用户缺省的字体尺寸。
尽管图片被缓存在服务器上，但是在产生图片时仍然存在一个性能问题。
每一张图片都必须分别被下载，导致服务器和带宽的消耗。
而采用sIFR，那么就只有一个Flash（。swf）文件和一个Javascript （。js）文件被下载，并可以使站点上所有的标题都被渲染为公司的字体。
这个例子不是空穴来风。这是一个真实的案例，在2001年，为了重新设计ESPN.com，Mike Davidson开发出了最初的Flash替换技术。从那以后，随着Shaun Inman和其他人的加入，这已经发展成为今天我们所拥有的完整而流畅的技术了，而且很有可能在2005年对web排版技术产生重大的冲击。
在链接上使用sIFR最新版本的sIFR允许链接文本被替换。尽管这是一个令人兴奋的发展，但毕竟不适合运用在这样的场合。这是由于以下的可访问性问题：
不支持浏览器的右键点击功能（上下文菜单）
不支持apple的option键没有状态条信息虽然这些问题显得很琐碎，但是很多人发现这些功能的缺失很令人丧气。缺少状态条的信息，你就不能获得你下一个要访问的地址的线索；随着诸如Firefox和Opera浏览器的普及，右键的上下文菜单正在变成一个越来越有用的工具。尽管sIFR在链接上提供一个基本的右键点击，但是浏览器的上下文菜单却是不可访问的。
当然，这是Flash的限制而不是sIFR自身的限制。这些问题看上去可以在将来被克服。举个例子，状态条可以通过Javascript来控制，所以增加显示出链接目标的功能应该不是很困难。但是，在Flash允许在链接上提供完整的浏览器上下文菜单之前，我相信sIFR还不能完全处理这类文本。
反锯齿sIFR大多数的益处都集中在自定义字体的能力上，一个重要的考虑是Flash文本可以被反锯齿。Web开发者经常会忘掉这一点，部分是因为如此多的工作是用Mac OS X完成的，它的Quartz字体可以产生平滑的边缘。然而，Windows的使用者（尽管在显示菜单的某处有平滑字体边缘的选项）看起来并不能反锯齿，能够使这些用户，和预装Windows XP或Mac OS X的用户一样，拥有显示反锯齿标题的能力是一个重要的考虑因素。
精细调节我听到有一个问题多次被提及，那就是sIFR不允许像控制一张图片所可能做的那样来控制文本。确实是这样。用Photoshop或者Fireworks创建的图片，你可以精确的控制字距，拉伸，反锯齿，或者另一些特性，诸如非常准确的下投影。图像编辑器是一个真正的WYSIWYG（所见即所得）的媒介。而渲染为Flash的sIFR却不是。
如果需要达到这个层次的控制，那么一幅图片仍然是发布这类文本的最好的方法，在这些情况下sIFR不是正确的工具。但是，如果纯粹是要发布一个自定义的字体，那么sIFR就比创建图片更适合了。
下载速度当使用sIFR时，替换文本的着色速度是一个重要的考虑因素，虽然从早期的版本以来，速度已经有了一个很大的提高，但是如果在同一时间屏幕上有很多的sIFR实例，那么还是有明显的延迟。（比如，每个页面有一个标题，或者每次传送都有标题）这个例子也许可以最好的说明，为什么适度的使用sIFR是当前使用这项技术的理想方式。
这是使用Flash替换技术的最令人丧气的缺点了。从实现第一个sIFR时起，这诱惑便是在一个页面上替换太多的元素。为了实现它们，下载的速度必须有非常大的提高；虽然一个好的服务器可以帮助你，但是真正消耗时间的是运行那些体积庞大的Javascript.
总结sIFR并不会和图片替换技术相竞争；它是针对不同工作的独特的工具。它能被最好的使用在那些显示为浏览器缺省字体大小的，而又不能替换为自建图片的文本上。
sIFR理想的使用场合是，当你想要仅用一张图片就显示自定义的字体或者反锯齿的标题时。这在web上被非常频繁的使用，在这些案例中sIFR是一个更好的选择。它可以缩放为用户缺省的字体尺寸，可以被选择，可以使用在数以千计的页面上而只需要下载一两个文件。
摘要在页面标题上使用sIFR.有限度的使用sIFR，以获得最佳的下载时间。
不要在链接上使用sIFR.