Chrome, медленный по https сайтам, особенно внутренним
В конце я не мог найти ответ здесь. Весь контроль и профилирование тестов показывают, что Google Chrome является очень медленным при загрузке безопасного статического содержания от локального клиентского кэша. Никакая идея, почему. У нас должен был быть весь наш переключатель внутренних пользователей к IE (который является тем, что большинство людей с подобными проблемами в сети сделало).
tl; доктор Check, как Chrome обрабатывает проверку сертификата и аннулирование.
У нас была очень похожая проблема в средстве, я ранее работал в, но с Firefox. Чтобы это было проблемой, необходимо подтвердить, что проблема только с https страницами. В противном случае это будет иметь мало значения.
С Firefox (я знаю, я знаю, я могу читать, указать предстоящий), у группы людей были проблемы, в то время как пользователи Internet Explorer (если можно верить этому) не сделали. Мы использовали печально известные ipsCA полномочия, потому что они были свободны для учебных заведений, но в конечном счете взбешенный Firefox с их тенистостью и проверкой OCSP их сертификатов был преступником. Оказывается, что браузер задерживался из-за обработки Списков аннулированных сертификатов из-за природы наших сертификатов SSL. Вы, очевидно, как лучший из нас, не упоминали свою версию Chrome, таким образом, это трудно, чтобы сказать, было ли это проблемой или является все еще проблемой. Однако я проверил бы конфигурацию CRL в Chrome. Выполнение так в Firefox, облегченном, выходит. Кроме того, проверьте, что Ваши сертификаты находятся в хорошем положении, это - то, если они самоподписываются. Что отдало, это для использования являемся мы отодвинутый от самоподписанного, потому что слабоумные пользователи наших сервисов пожаловались много, и это было свободно. Мы думали, что сохраняли нас головная боль, но мы сделали ее хуже.
Chrome имеет потрясающий встроенный инструмент диагностики, "about:net-internals", который разработан, чтобы помочь диагностировать сетевые проблемы. В частности, это имеет вкладку "Events", которая позволяет Вам указать URL, и затем Chrome ломает весь процесс загрузки его, пошаговый, включая разрешение DNS, удачные обращения в кэш и запросы элемента Ajax.
Мы развернули 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
Если бэкенд является основанным на Java appserver, существует общая ошибка Java, которая заставляет Сеансовые билеты TLS вызывать огромную задержку. Можно моделировать ошибку при помощи действительно нового openssl s_client и сообщение этого позволить/запретить сеансовые билеты.
Настоящий преступник является JSSE по сравнению с расширениями TLS с нулевыми значениями, которые сеансовые билеты используют по первому запросу.
Любая возможность, что Ваш сервер исчерпывает случайные данные. В соответствии с Linux, если Вы используете /dev/random и исчерпанный случайные данные Ваш сервер заблокируется, и загрузка страницы будет похожа на него, зависает.
Обычно /dev/urandom достаточно хорошо. Если это не так существуют некоторые аппаратные средства, которые можно получить, который генерирует случайные данные для Вас.
Я вижу, что Вы выполняете ASP.NET - я не могу прокомментировать, является ли это проблемой о Windows, но определенно стоящий взгляда.
Я столкнулся с той же проблемой. После долгих поисков я обнаружил с помощью инструмента мониторинга процессов ( https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx )Chrome сталкивался с множеством конфликтов при попытке записи в% TEMP%. Очистка этого каталога решила проблему для меня.