Управление/удаление ненужных сценариев на сайте Kentico

Question

Мы строим сайт Kentico 8.2 с использованием модели портала ASPX +. Глядя на визуализированный HTML на моем сайте, я вижу много ненужного Javascript, который Kentico сбросил на мою страницу. Более того, это происходит в верхней части моей страницы в верхней части элемента формы.

Например, это рендеринг функции JS ASP.NET __doPostBack, хотя я не использую какие-либо элементы управления, которые этого требуют. Другие скрипты добавляются в качестве WebResource.axd и ScriptResource.axd.

С первого взгляда кажется, что эти сценарии представляют собой структуру Microsoft AJAX, используемую с UpdatePanel и т. Д. Я полагаю, что они добавили функции менеджера портала при использовании этой страницы в пользовательском интерфейсе Kentico. Предположительно, они также используются с некоторыми встроенными веб-частями.

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

Я пробовал скрывать элементы управления <ajaxToolkit:ToolkitScriptManager /> и <cms:CMSPortalManager /> на моей главной странице при рендеринге реального сайта, но это приводит к тому, что шаблоны имеют <cms:CMSWebPartZone />.

Кто-нибудь знает, как обеспечить устранение этого раздувания, когда это не требуется? Или, по крайней мере, вызывать эти сценарии в конце страницы, чтобы они не слишком мешали производительности?

Answer 1

К сожалению, строительные площадки в пределах Kentico с использованием страниц ASPX и ASPX + Portal автоматически генерируют дополнительную разметку, такую ​​как __doPostBack, WebResource.axd и ScriptResource.axd.

Я бы не рекомендовал удалить какой-либо код по умолчанию на вашей главной странице. Это приведет к поломке вещей (как вы уже пережили).

Однако наличие этой разметки не должно вызывать серьезной проблемы при работе страницы. Понятно, что это не идеально.

Что я могу сделать, чтобы уменьшить попадание является следующее:

• Отключение ViewState везде, где возможно. Например, либо на уровне страницы, либо на уровне Webpart/User control.
• Переместите ViewState в нижней части страницы (в настройках Kentico), поэтому страница меньше «тяжелая».
• Убедитесь, что вы кешируете все, что можете. Например, мебель для сайта, используемая вашими веб-страницами и шаблонами (изображения/js и т. Д.) На уровне IIS и на уровне Kentico с использованием их API.

Читая эту статью из документации Kentico предоставляет больше информации в большей глубине: Optimizing website performance

Если вы действительно хотите «полный контроль» над HTML вынесенным Кентико это позволяет создавать шаблоны с использованием MVC. Но это не даст вам гибкости для изменения шаблонов страниц, перемещая веб-части в администрировании CMS. Я предполагаю, что вы выбрали подход Portal Portal именно по этой причине.

Надеюсь, это поможет.

Answer 2

В дополнение к замечательному ответу @ sbhomra у меня есть несколько вопросов, предложений и комментариев.

Сколько секунд или миллисекунд вы говорите по поводу производительности? Если вы думаете, что получите несколько миллисекунд назад, не стоит пытаться восстановить все функциональные возможности. Если вы говорите секунду или два, там примерно 15 разных вещей, которые вы можете изменить в настройках и свой код, чтобы получить все обратно. Подумайте, сколько кода вы собираетесь писать, поддерживать и обновлять, чтобы получить второй или меньше назад?

Ресурсы загрузки WebResource и SciptResource, которые скомпилированы в библиотеки на веб-сайте. Поэтому, если кто-то создал внешнюю библиотеку и эта библиотека загрузила изображение, которое было скомпилировано в нее, вы получите эту ссылку WebResource.axd на своем сайте. Вам придется физически удалить эти библиотеки из экземпляра Kentico.

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