Мы пытаемся развернуть Google Chrome в нашей корпоративной сети, но обнаруживаем, что загрузка https-страницы (особенно нашей внутренней) занимает в 2-4 раза больше времени по сравнению с IE. Кто-нибудь испытал это и нашел исправление?
Обновить
Основываясь на предложении Handyman5, я провел диагностику в Chrome и обнаружил, что наибольшее количество времени (более 90% на каждой странице) было потрачено на извлечение статических файлов из кеша и рендеринг страницы. Однако, если я отключу SSL на нашем сайте, это произойдет почти мгновенно.
Есть мысли о том, почему это должно быть?
В Chrome есть отличный встроенный диагностический инструмент, "about: net-internals", который предназначен для устранения неполадок в сети. В частности, у него есть вкладка «События», которая позволяет вам указать URL-адрес, а затем Chrome разбивает весь процесс его загрузки, шаг за шагом, включая разрешение DNS, обращения к кешу и запросы элементов AJAX.
tl; dr Проверьте, как Chrome обрабатывает проверку и отзыв сертификатов.
У нас была очень похожая проблема на объекте, на котором я раньше работал, но с Firefox. Чтобы это было проблемой, вам необходимо подтвердить, что проблема связана только со страницами https. Если нет, это мало что изменит.
С Firefox (я знаю, я знаю, я могу читать, укажу на будущее) у группы людей были проблемы, а у пользователей Internet Explorer (если вы можете в это поверить) - нет. Мы использовали печально известный авторитет ipsCA, потому что он был бесплатным для образовательных учреждений, но в конечном итоге разозлил Firefox своей мрачностью, и проверка сертификатов OCSP была виновата. Оказывается, браузер задерживал обработку списков отозванных сертификатов из-за характера наших сертификатов SSL. Вы, очевидно, как лучшие из нас, не упомянули свою версию Chrome, поэтому трудно сказать, была проблема или все еще проблема. Однако я бы проверил конфигурацию CRL в Chrome. Это решило проблему в Firefox. Кроме того, убедитесь, что ваши сертификаты находятся в хорошем состоянии, то есть являются ли они самоподписанными. Мы отказались от использования самоподписанных, потому что идиоты-пользователи наших сервисов много скулили, а это было бесплатно. Мы думали, что избавляем себя от головной боли, но сделали только хуже.
Мы развернули Google Chrome внутри компании для поддержки специально разработанного приложения (на ASP.NET MVC), но работающего по обычному протоколу HTTP.
У нас также были проблемы с медленными страницами из-за кеша. Кажется, Chrome вытаскивал все статические файлы при каждой загрузке страницы и не сохранял их в своем кеше. В итоге мы просто добавили в наше приложение заголовки с истекающим сроком действия, чтобы принудительно включить кеш, и это сработало.
Вы можете пойти по этому пути (изменить свои веб-приложения, указав стратегию кэширования для каждого типа файлов) или дополнительно изучить поведение кэширования по умолчанию в Chrome.
У других, похоже, есть похожие проблемы (например, http://www.google.com/support/forum/p/Chrome/thread?tid=741fd9e03cfb7e7b&hl=en).
Эта статья может быть полезна, так как в ней рассказывается о кешировании Chrome: http://gent.ilcore.com/2011/02/chromes-10-caches.html
Я столкнулся с той же проблемой. После долгих поисков я обнаружил с помощью инструмента мониторинга процессов (https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx) Chrome сталкивался с множеством конфликтов при попытке записи в% TEMP%. Очистка этого каталога решила проблему для меня.
В конце концов, я не смог найти здесь ответа. Все тесты мониторинга и профилирования показывают, что Google Chrome очень медленно загружает защищенный статический контент из локального клиентского кеша. Понятия не имею почему. Нам пришлось заставить всех наших внутренних пользователей перейти на IE (что и сделали большинство людей с аналогичными проблемами в Интернете).
Если бэкэнд является сервером приложений на основе Java, существует распространенная ошибка Java, из-за которой билеты сеанса TLS вызывают огромную задержку. Вы можете смоделировать ошибку, используя действительно новый openssl s_client и указав ему включить / отключить билеты сеанса.
Настоящий виновник - это JSSE по сравнению с расширениями TLS с нулевыми значениями, которые сеансовые билеты используют при первом запросе.
Любая вероятность того, что на вашем сервере закончились случайные данные. Под Linux, если вы используете /dev/random и закончатся случайные данные, которые ваш сервер заблокирует, и загрузка страницы будет выглядеть так, как будто она зависает.
Обычно /dev/urandom достаточно хорошо. Если это не так, вы можете получить какое-то оборудование, которое будет генерировать для вас случайные данные.
Я вижу, вы используете ASP .NET - я не могу комментировать, является ли это проблемой в Windows, но стоит взглянуть.