我公司聘请了一家开发公司来制作一些复杂的软件。看起来他们正在使用.NET框架来编写代码。我不知道这是否与.NET严格相关，但在查看HTML的结构时，我注意到了很多内联CSS。格式中只有很多div
<div style="position: absolute; top:177px; left:229px; width: 710px; height: 306px;" class="EventLabel Event_bg_red"></div>
还有长ID的元素。 id="ctl00_ctl00_ctl00_MainContent_MainContent_BodyContent_grid_DXDataRow0"
这些长文本字符串和长内联样式声明会影响网站的性能吗？ （我注意到一些滞后的问题，并且不知道是由于某些脚本还是复杂的HTML）或者.NET可能动态地写入这个HTML，因此计算所有position:absolute值的时间很长。或者，当涉及到浏览器呈现网页时，这样的文本字符串可以忽略不计吗？
答案 0 :(得分：4)
我怀疑这是事情的组合。
首先，funky-ID是.NET的东西 - 它表示网站中元素的层次结构。它可以被优化和/或禁用，但它通常是无害的。查看页面的源代码并查找名为VIEWSTATE的表单变量 - 我怀疑它很大（他们使用的所有ID都意味着许多服务器端控件对ViewState有贡献）这可能是一个问题
长/动态生成的ID也会使编写与页面元素交互的客户端代码变得更加困难。
所有内联样式可能来自他们用于进行布局的WSYIWYG编辑器。这些工具通常会产生讨厌的HTML，但“完成工作。”
您可能担心的唯一性能问题是传送到浏览器的内容大小，使用长ID和内嵌样式会更大。我怀疑是否存在任何曾经存在的性能问题。
然而，稍后修改网站布局可能会更加困难。
希望这有帮助
答案 1 :(得分：2)
是的，内联CSS比单独的CSS文件中的CSS慢。 不，我怀疑长ID会在性能方面产生任何影响。
但是，即使这些问题存在问题，也不一定会出现 问题。修正您正在查看的点将是微观优化。所有主浏览器都不会给内联CSS带来任何明显的性能问题。它是网页代码的标准元素，即使通常有更好的方法。至于长字符串......好吧，浏览器的渲染引擎经过高度优化，可以解析长字符串，所以我不认为一些长ID会导致任何问题。
如果你遇到了一般性能问题，我会说这听起来比那更深。
我建议使用像Firebug或Chrome开发人员工具这样的工具在网站上运行一些分析，并详细了解它的确切位置。可用于此类调试的工具现在非常先进，通过一些工作，您应该能够准确地确定问题所在。也许这是服务器端代码很慢：你会看到HTML和Ajax的长页面加载。或者也许一些Javascript例程很慢：分析工具会准确显示哪些调用花费的时间最多。
我的预感是，你所拾取的这些东西都是一个更基本的根本问题的症状：说实话，听起来你雇用来编写代码的人听起来不像是他们的真的很擅长。尝试查看他们编写的源代码，并了解代码质量。
答案 2 :(得分：0)
内联CSS永远不会被缓存，就像HTML永远不会被缓存一样。外部CSS文件确实被用户的浏览器缓存和重用 - 因此在那里有性能影响。 （同样适用于Javascript内联文件与外部文件。）
内联CSS也难以维护，并使HTML文件本身更大。我不认为长ID本身就是一个问题。
答案 3 :(得分：0)
这些ID是使用ASP.NET WebForm框架自动生成的。要查看它们是否存在性能问题，您可以使用页面速度插件，可用于chrome或firefox。我在这一点上的猜测是它们不是，因为浏览器通常将它们存储在一个hashmap中，因此查找它们的速度非常快。
https://developers.google.com/speed/pagespeed/
关于渲染时间，请使用页面检查器（内置chrome / Safari）或firebug（Firefox插件）。网络窗格通常会告诉您每个资源花费了多少时间。
我的猜测是滞后是在任何数据发送到客户端之前。当WebForm在页面上有很多控件时，或者当他们需要从数据库中获取大量数据时，WebForm可能会非常沉重地使用资源。检查 ViewState 用法。 （如果您不知道它是什么，请在谷歌上查看）如果您不小心，WebForm可以在您的页面中移动数百KB的数据，并且每次单击按钮时都会将这些数据发送回服务器。 / p>
好狩猎！