Можно ли получить доступ к текущему коэффициенту масштабирования элемента %-width с помощью Javascript, не вызывая перекомпоновки?

Я пытаюсь исправить медленно работающий javascript в медленном пользовательском интерфейсе, и я сузил основную причину до вызова jQuery .width(), используемого для просмотра фактического размера элемента width: 100% в пикселях в адаптивном макете, в процессе, который должно происходить часто в ответ на действия пользователя.

Я добавил измерения на основе меток времени, и они показывают, что только на них приходится около 33% времени задержки, что делает разницу между ощущением пользовательского интерфейса резким и вялым. Удалив эту строчку, пользовательский интерфейс кажется быстрым, но он ставит вещи не в то место...

Кажется точно установлено, что .width() относительно медленный в jQuery> 1.8 в основном по двум причинам:

• #P4# <блочная цитата> #P5# #P6#
• #P7# <блочная цитата> #P8#

Цель вызова width() в моем коде — посмотреть, уменьшился ли адаптивный дизайн и насколько. Ему нужно посмотреть на элемент-оболочку виджета, который имеет width: 100%; (но может быть в столбце или другом контейнере, в зависимости от того, на каком сайте/странице он размещен), и нужно увидеть, какой % от максимальной ширины этой оболочки он фактически показывает в .

Другой код, основанный на другой системе координат, дает мне местоположение в пикселях для метки, затем мне нужно использовать коэффициент масштабирования (по существу = $wrapper.width() / maxWidth;), чтобы уменьшить местоположение, чтобы, например, при просмотре страницы в узком окне/устройстве и размер оболочки составляет 50% от его максимального размера, верхнее и левое смещения меток составляют 50% от их значений по умолчанию.

Есть ли способ получить доступ к этим данным о том, насколько был уменьшен элемент %-width, не вызывая перекомпоновки и других вещей, которые замедляют вызовы .width()?

Вещи, которые я пробовал или исключил:

• .outerWidth() работает так же медленно, как .width()
• .get(0).clientWidth (чистый вариант Javascript / non-Jquery) также почти такой же медленный, как .width() (предположительно, поэтому виновником является перекомпоновка)
• Я заметил, что в большинстве браузеров, если я делаю что-либо из этого, за которым следует любое из вышеперечисленных в другом измерении (например, .get(0).clientWidth, за которым следует .outerHeight()), вызовы после первого будут очень быстрыми (примерно в 20 раз быстрее) . Предположительно, поскольку перекомпоновка только что была выполнена и к свойствам элемента только что был получен доступ, они каким-то образом кэшируются. Но эффект не сохраняется для повторных вызовов функции, только в пределах одного вызова функции.
• .css("width") явно бесполезно, потому что во всех случаях это просто дало бы мне 100%
• Я думал получить ширину окна, но все усложняется в зависимости от макетов столбцов страницы, на которой размещается этот элемент. Например, если моя оболочка имеет макет с двумя столбцами, а окно немного шире, чем точка останова, которая сворачивает два столбца, окно будет шире, чем максимальный размер элемента оболочки, но элемент оболочки не будет в 100% от его максимальной ширины.

[ Обновление ] Я думал, что нашел способ обойти необходимость решения проблемы и расположить ярлыки без доступа к масштабированию элемент: поскольку у меня уже была переменная maxWidth в пикселях и смещения в пикселях, у меня было достаточно данных, чтобы вычислить процентное смещение для моих меток с leftOffset_px / maxWidth_px и topOffset_px / maxHeight_px, затем + '%' и применить это как смещение CSS top и left каждой метки. Это смехотворно быстрее - теперь менее 1 миллисекунды, настолько быстро, что моя функция на основе временных меток не может это измерить!

К сожалению, у меня также есть другая функция, которая проверяет, что метки с фиксированной шириной не выходят за пределы адаптивного контейнера, и для этого мне делает нужно учитывать либо текущую ширину в пикселях контейнера или его коэффициент масштабирования.