我公司聘请了一家开发公司来制作一些复杂的软件。看来他们正在使用 .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值需要很长时间。或者当浏览器呈现网页时，这样的文本字符串可以忽略不计？
我怀疑这是多种因素的结合。
首先，funky-ID 是 .NET 的东西——它表示站点中元素的层次结构。它可以被优化和/或禁用，但它通常是无害的。查看页面的源代码并查找名为 VIEWSTATE 的表单变量 - 我怀疑它很大（他们使用的所有 ID 都意味着许多服务器端控件有助于 ViewState），这可能是一个问题.
长/动态生成的 ID 也会使编写与页面上的元素交互的客户端代码变得更加困难。
所有的内联样式可能来自他们用来进行布局的 WSYIWYG 编辑器。这些工具通常会生成令人讨厌的 HTML，但会“完成工作”。
您可能担心的唯一性能问题是传递给浏览器的内容的大小，如果使用长 ID 和内联样式，它会变得更大。我怀疑是否会有任何一次性的性能问题。
但是，这可能会使以后修改站点布局变得更加困难。
希望这可以帮助
是的，内联 CSS 比来自单独 CSS 文件的 CSS 慢。不，我怀疑长 ID 会在性能方面产生任何影响。
但是，即使这些事情是一个问题，它们也不太可能成为问题。修复您正在查看的点将是微优化。没有一个主要的浏览器会给你任何明显的内联 CSS 性能问题。它是网页代码的标准元素，即使通常有更好的方法。至于长字符串……好吧，浏览器的渲染引擎针对解析长字符串进行了高度优化，所以我认为几个长ID不会造成任何问题。
如果您遇到一般性能问题，我会说这听起来比这更深层次。
我建议使用像 Firebug 或 Chrome 开发者工具这样的工具在网站上运行一些分析，并更详细地找出它慢的地方。可用于这种调试的工具现在非常先进，通过一些工作，您应该能够非常准确地确定问题所在。也许是服务器端代码很慢：您会看到 HTML 和 Ajax 的页面加载时间很长。或者某些 Javascript 例程可能很慢：分析工具会准确显示哪些调用花费的时间最多。
我的直觉是，你发现的这些东西是一个更根本的潜在问题的征兆：坦率地说，在我看来，你聘请来编写代码的人听起来并不像他们真的很好在它。试着看看他们写的源代码，感受一下代码的质量。
内联 CSS 从不缓存，就像 HTML 从不缓存一样。外部 CSS 文件确实会被用户的浏览器缓存和重用——因此会影响性能。（同样适用于 Javascript 内联文件和外部文件。）
内联 CSS 也很难维护，并且会使 HTML 文件本身更大。我不认为长ID本身是一个问题。
这些 id 是使用 ASP.NET WebForm 框架自动生成的。要查看它们是否是性能问题，您可以使用适用于 chrome 或 firefox 的 page speed 插件。我在这一点上的猜测是它们不是，因为浏览器通常将它们存储在哈希图中，因此查找它们的速度非常快。
https://developers.google.com/speed/pagespeed/
至于渲染时间，请使用页面检查器（内置 chrome/Safari）或 firebug（Firefox 插件）。网络窗格通常会告诉您在每个资源上花费了多少时间。
我的猜测是滞后是在任何数据发送到客户端之前。当页面上有很多控件，或者需要从数据库中获取大量数据时，WebForm 可能会占用大量资源。检查ViewState的使用。（如果您不知道它是什么，请在 google 上查看）如果您不小心，WebForm 可以在您的页面中推送数百千字节的数据，并且每次单击按钮时这些数据都会发送回服务器。
好狩猎！