Я считаю, что Интернет стал незаменимой частью жизни людей. Приложения богатых клиентов, таких как Ajax, Flex и т. Д., Снимают людей более счастливыми испытывать многие функции, которые могут быть реализованы только в C/S. Например, Google Opportunity перенесла все самые основные офисные приложения в Интернет. Конечно, будучи удобным, это, несомненно, делает страницу медленнее и медленнее. Я занимаюсь фронтальным развитием. С точки зрения производительности, согласно опросу Yahoo, бэкэнд составляет только 5%, в то время как фронт-конец достигает 95%, из которых 88%вещей могут быть оптимизированы.
Выше приведено диаграмма жизненного цикла страницы Web2.0. Инженер ярко говорит, что он разделен на четыре этапа: беременность, рождение, выпускной и брак. Если мы сможем реализовать этот процесс вместо простого ответа на запрос, когда мы нажимаем на веб-ссылку, мы можем выкопать много деталей, которые могут повысить производительность. Сегодня я слушал лекцию по исследованию веб -производительности Xiao Ma Ge на Taobao о команде разработчиков Yahoo. Я чувствовал, что я много получил и хотел поделиться этим в блоге.
Я считаю, что многие люди слышали о 14 правилах оптимизации производительности веб -сайта. Более подробную информацию можно найти в Developer.yahoo.com
1. Уменьшите количество HTTP -запросов как можно больше [Контент]
2. Используйте CDN (сеть доставки контента) [Сервер]
3. Добавить истекает заголовок (или контроль от кэша) [Сервер]
4. GZIP Component [Server]
5. Поместите стиль CSS над страницей [CSS]
6. Переместите сценарий в нижнюю (включая вставку) [JavaScript]
7. Избегайте использования выражений в CSS [CSS]
8. Разделите JavaScript и CSS на внешние файлы [JavaScript] [CSS]
9. Уменьшите запросы DNS [контент]
10. Сжатие JavaScript и CSS (включая вставку) [JavaScript] [CSS]
11. Избегайте перенаправления [сервер]
12. Удалить дублирующие сценарии [JavaScript]
13. Настройте теги объектов (ETAGS) [CSS]
14. Сделайте кэш Ajax
Под Firefox есть плагин YSLOW, который интегрирован в Firebug. Вы можете использовать его, чтобы легко увидеть, как работает ваш сайт в этих аспектах.
Это результат использования YSLOW для оценки моего веб -сайта xifengfang. К сожалению, это всего 51 очко. хе -хе. Множество крупных сайтов в Китае не высоки. Я только что проверил это, и Sina и Netease были 31 очко. Тогда счет Yahoo (США) действительно 97 баллов! Можно видеть, что Yahoo приложил усилия в этом отношении. Судя по 14 правилам, которые они суммировали, есть много деталей, которые были добавлены нам сейчас, и некоторые практики даже немного извращены.
Статья 1: минимизировать количество HTTP -запросов как можно больше (сделайте меньше HTTP -запросов)
HTTP -запросы являются накладными расходами, и поиск способов уменьшить количество запросов может естественным образом увеличить скорость веб -страницы. Общие методы - это объединение CSS, JS (слияние файлов CSS и JS на странице соответственно), а карты изображений и спрайты CSS и т. Д. Конечно, возможно, разделение файлов CSS и JS связано с соображениями с точки зрения структуры CSS, обмена и т. Д. Китайский веб -сайт Alibaba должен был развиваться в разделе развитие, а затем объединить JS и CSS на фоне. Это все еще было запросом для браузера, но он все еще мог быть восстановлен до нескольких во время разработки, что было удобно для управления и повторяющихся ссылок. Yahoo даже рекомендует написать домашнюю страницу CSS и JS непосредственно в файл страницы вместо внешних ссылок. Поскольку домашняя страница имеет слишком много посещений, это может сократить количество двух запросов. На самом деле, многие домашние порталы делают это.
Спрайты CSS относится только к объединению фонового изображения на странице в одну, а затем с использованием значения, которое не может быть определена атрибутом фонового положения CSS для получения его фона. Сайты Taobao и Alibaba в настоящее время делают это. Если вы заинтересованы, вы можете взглянуть на фоновые фотографии Таобао и Алибабы.
http://www.csssssprites.com/ Это веб-сайт инструмента, который может автоматически объединять загрузки, которые вы загружаете, и давать соответствующие координаты фоновой позиции. И вывод результатов в форматах PNG и GIF.
Статья 2: Используйте сеть доставки контента
Честно говоря, я мало знаю о CDN. Проще говоря, добавив новую сетевую архитектуру в существующий Интернет, опубликуя контент веб -сайта на сервер Cache, ближайший к пользователю. Благодаря технологии балансировки нагрузки DNS, считается, что источник пользователя обращается к серверу кэша рядом, чтобы получить требуемый контент. Пользователи в Ханчжоу получают доступ к контенту на сервере рядом с Ханчжоу, а пользователи в Пекине получают доступ к контенту на сервере рядом с Пекином. Это может эффективно сократить время передачи данных в сети и улучшить скорость. Для более подробного содержания вы можете ссылаться на объяснение CDN на энциклопедии Baidu. Yahoo! Распределение статического контента по CDN сокращает время воздействия пользователя на 20% или более.
Технологическая диаграмма CDN:
Сетевая схема CDN:
Статья 3: Добавьте заголовок истечения срока действия/контроля кэша: добавьте заголовок истечения срока службы.
Теперь на странице все больше и больше изображений, сценариев, CSS и Flash встроены, и когда мы получаем доступ к ним, мы неизбежно сделаем много HTTP -запросов. На самом деле, мы можем кэшировать эти файлы, истекает заголовок. Срок действия истекает фактически определяет время кэша определенного типа файла в браузере через сообщение заголовка. Большинство изображений не нужно часто модифицировать после публикации. После кэширования браузеру больше не нужно загружать эти файлы с сервера и читать их непосредственно с кэша. Это снова значительно ускорит доступ к странице. Типичный протокол HTTP 1.1 возвращает информацию заголовка:
Http/1.1 200 OK
Дата: пт, 30 октября 1998 г. 13:19:41
Сервер: Apache/1.3.3 (Unix)
Контроль кэша: максимальный возраст = 3600, обязательно-ревалидат
Истекает: пт, 30 октября 1998 г. 14:19:41
Последние модифицированные: понедельник, 29 июня 1998 г. 02:28:12 GMT
ETAG: 3E86-410-3596FBBC
Длина контента: 1040
Контент-тип: текст/HTML
Это может быть сделано, установив контроль кэша и истекает через сценарии на стороне сервера.
Например, если установлено в PHP, истекает через 30 дней:
<!-PHEADER (CACH-CONTROL: UST-Revalidate); $ offset = 60 * 60 * 24 * 30; $ expstr = истекает :. gmdate (d, d myh: i: s, time () + $ offset). Gmt; Header ($ expstr);-> также может быть сделан путем настройки самого сервера, поэтому они не очень ясны, ха-ха. Если вы хотите узнать больше, пожалуйста, обратитесь к http://www.web-caching.com/
Насколько я знаю, время истечения срока истечения срока действия веб -сайта Alibaba Chinese составляет 30 дней. Тем не менее, в течение этого периода были проблемы, особенно при установлении времени истечения сценария, вам следует тщательно рассмотреть его, в противном случае клиент может потребоваться много времени, чтобы воспринимать такие изменения после обновления соответствующей функции скрипта. Я столкнулся с этой проблемой, когда работал над [предложением проекта] раньше. Поэтому мы должны тщательно рассмотреть, какие из них должны быть кэшированы, а какие не следует кэшировать.
Статья 4: Включение сжатия GZIP: компоненты GZIP
Идея GZIP состоит в том, чтобы сначала сжать файлы на стороне сервера, а затем перевести их. Это может значительно уменьшить размер передачи файлов. После завершения передачи браузер повторно заведет сжатый контент и выполнит его. Текущие браузеры могут хорошо поддерживать GZIP. Мало того, что браузер может его распознать, но и основные скалеры также могут его распознать. Все сеоры могут быть уверены. Кроме того, коэффициент сжатия GZIP очень велик, как правило, коэффициент сжатия составляет 85%, что означает, что 100K -страница на сервере может быть сжат примерно до 25 тыс. До того, как будет отправлен клиенту. Для конкретных принципов сжатия GZIP вы можете ссылаться на статью «Алгоритм сжатия GZIP» на CSDN. Yahoo особенно подчеркивает, что весь текстовый контент должен сжимать Gzip: HTML (PHP), JS, CSS, XML, TXT ... Наш веб -сайт выполняет хорошую работу в этом отношении, это A. В прошлом наша домашняя страница не была, потому что на домашних страницах было много JS с кодами рекламы. JS веб -сайтов этих владельцев AD Code не была сжата GZIP, который также будет перетаскивать наш веб -сайт.
Большинство из вышеперечисленных трех баллов являются контентом на стороне сервера, и у меня есть только краткое понимание их. Что не так, чтобы быть исправлено.
Статья 5: Поставьте таблицы стилей наверху
Поместите CSS на вершину страницы, почему это? Поскольку браузеры, такие как IE, Firefox ничего не будет отображать, пока все CSS не будут полностью переданы. Причина так же проста, как сказал Брат Ма. CSS, полное имя: каскадные листы в стиле. Каскад означает, что CSS позади может охватывать предыдущие CSS, а CSS с высоким уровнем может покрывать CSS с низкими уровнями. В [CSS! Важно] эти отношения иерархии были упомянуты в нижней части этой статьи, и здесь нам нужно только знать, что CSS может быть перезаписан. Поскольку предыдущий может быть перезаписан, он, несомненно, разумный для браузера после его полной загрузки. Во многих браузерах, таких как IE, проблема размещения листа стилей в нижней части страницы заключается в том, что он запрещает порядок отображения контента веб -страницы. Если браузер блокирует дисплей, чтобы избежать перекрашения элементов страницы, пользователь может увидеть только пустые страницы. Firefox не блокирует отображение, но это означает, что когда таблица стилей загружается, некоторые элементы страницы могут быть перекрашены, что вызывает проблемы мерцания. Таким образом, мы должны загрузить CSS как можно скорее
Следуя этому значению, если мы внимательно посмотрим на него, на самом деле есть некоторые области, которые могут быть оптимизированы. Например, два файла CSS, содержащиеся на этом сайте, - <link rel = styleSheet rev = styleSheet href = http: //www.space007.com/themes/google/style/google.css type = text/css media = screen/> и <link rel = stylesheet rev = stylesship href = http: //www.space007.com/css/print.css type = text/css media = print/>. Из мультимедиа мы видим, что первый CSS предназначен для браузера, а второй файл CSS предназначен для стиля печати. Из поведенческих привычек пользователя действие для печати страницы должно произойти после отображения страницы страницы. Следовательно, лучший метод должен быть для динамического добавления CSS на страницу после загрузки страницы, чтобы он мог улучшить скорость. (Ха -ха)
Статья 6: Положите сценарии внизу
Есть две цели для размещения сценариев внизу страницы: 1. Поскольку выполнение скриптов сценариев предотвращает блокирование загрузки страницы. Во время процесса загрузки страницы, когда браузер считывает оператор выполнения JS, он обязательно объяснит все это и прочитает следующий контент в следующем. Если вы не верите в это, вы можете написать цикл JS, чтобы увидеть, все еще выйдет вещи под страницей. (Выполнение SetTimeout и SetInterval немного похоже на многопоточное, и следующее визит содержимого будет продолжаться до соответствующего времени отклика.) Логика браузера заключается в том, что JS может выполнять местоположение. Href или другие функции, которые могут полностью прервать процесс этой страницы в любое время, то есть, конечно, он должен быть загружен после его завершения. Следовательно, размещение его в конце страницы может эффективно сократить время загрузки визуальных элементов страницы. 2. Вторая проблема, вызванная сценарием, заключается в том, что он блокирует количество параллельных загрузок. Спецификация HTTP/1.1 рекомендует, чтобы количество параллельных загрузок для каждого хоста браузера не превышало 2 (то есть только 2, а другие браузеры, такие как FF, устанавливаются на 2 по умолчанию, но новый IE8 может достигать 6). Поэтому, если вы распространяете файлы изображений на несколько машин, вы можете достичь более 2 параллельных загрузок. Однако при загрузке файла скрипта браузер не запустит другие параллельные загрузки.
Конечно, для каждого веб -сайта возможность размещения всех сценариев в нижней части страницы все еще сомнительна. Например, страница веб -сайта Alibaba китайского. Во многих местах есть inline JS, и отображение страниц в значительной степени зависит от этого. Я признаю, что это далеко от концепции неинвазивных сценариев, но многие исторические проблемы не так легко решить.
Статья 7: Избегайте использования выражений в CSS (избегайте выражений CSS)
Тем не менее, будут еще два бессмысленных гнездовых слоя, что определенно не очень хорошо. Необходимо лучшее решение.
Статья 8: Поместите как JavaScript, так и CSS в внешние файлы (сделайте JavaScript и CSS внешним) внешним)
Я думаю, что это все еще легко понять. Это делается не только с точки зрения оптимизации производительности, но и с точки зрения простого обслуживания кода. Написание CSS и JS на странице может сократить 2 запроса, но также увеличить размер страницы. Если у вас есть кэшированные CSS и JS, не будет дополнительных HTTP -запросов дважды. Конечно, я также сказал, что некоторые специальные разработчики страниц по -прежнему будут выбирать встроенные файлы CSS и JS.
Статья 9: Уменьшите поиск DNS
Между доменным именом и IP-адресом в Интернете существует переписка один к одному. Доменное имя (kuqin.com) легко запомнить, но компьютер не распознает его. Распознавание между компьютерами должно быть преобразовано в IP -адрес. Каждый компьютер в сети имеет независимый IP -адрес. Работа о преобразовании между доменным именем и IP -адресом называется разрешением доменного имени, также известной как запрос DNS. Процесс разрешения DNS займет 20-120 миллисекунд, и браузер не будет загружать ничего под доменным именем, пока запрос DNS не закончится. Следовательно, сокращение времени запроса DNS может ускорить скорость загрузки страницы. Yahoo рекомендует, чтобы количество доменных имен, содержащихся на странице, было управлять на уровне 2-4, насколько это возможно. Это требует хорошего плана для общей страницы. В данный момент у нас не очень хорошо, и многие рекламные системы, которые управляют очками, утащили нас.
Статья 10: Сжатие JavaScript и CSS (Minify JavaScript)
Очевидно, что сжимать левый и справа от JS и CSS, уменьшая количество байтов страниц. Скорость загрузки страницы естественно быстрее, если у нее небольшая емкость. В дополнение к уменьшению объема, сжатие также может обеспечить определенное количество защиты. Мы хорошо поработали в этом. Общие инструменты сжатия включают JSMIN, YUI компрессор и т. Д. Кроме того, например, http://dean.edwards.name/packer/, мы также предоставляем нам очень удобный онлайн -инструмент сжатия. Вы можете увидеть разницу в емкости между сжатыми файлами JS и несущественными файлами JS на веб -странице jQuery:
Конечно, один недостаток сжатия заключается в том, что читаемость кода исчезла. Я полагаю, что многие фронт-друзья столкнулись с этой проблемой: эффект взгляда на Google очень крут, но при рассмотрении исходного кода есть много персонажей вместе, и даже имена функций были заменены. Я такой потный! Разве это не очень неудобно для технического обслуживания, если ваш собственный код такой же? Текущая практика всех китайских веб -сайтов Alibaba заключается в сжатии на стороне сервера, когда JS и CSS выпускаются. Таким образом, мы можем легко поддерживать наш собственный код.
Статья 11: Избегайте перенаправления
Не так давно я видел статью «Internet Explorer и Limits Connection» на IEBLOG. Например, когда вы вводите http://www.kuqin.com/, сервер автоматически генерирует сервер 301 и обратится к http://www.kuqin.com/. Вы можете увидеть это, посмотрев на адресную строку браузера. Этот вид перенаправления, естественно, также требует времени. Конечно, это всего лишь пример. Есть много причин перенаправления, но неизменная вещь в том, что каждый раз, когда добавляется перенаправление, будет добавлен веб -запрос, поэтому его следует минимизировать.
Статья 12: Удалить дублирующиеся сценарии
Я не хочу этого говорить, но это также верно с точки зрения производительности, но также и с точки зрения спецификаций кода. Но я должен признать, что много раз мы добавим, возможно, дублированный код, потому что график быстрый. Возможно, унифицированная структура CSS и JS -структура могут лучше решить наши проблемы. Точка зрения Xiazhu верна не только для того, чтобы быть непонятной, но и для повторного использования.
Статья 13: Настройка тегов объектов (ETAGS) (настройка ETAGS)
Я тоже этого не понимаю, ха -ха. Я нашел подробное объяснение Inforq «Использование ETAGS, чтобы уменьшить пропускную способность и загрузку веб -приложений». Заинтересованные студенты могут пойти и посмотреть.
Статья 14: Сделайте Ajax Cachable
Аякс все еще должен быть кэширован? При выполнении запросов Ajax вам часто нужно добавлять метку времени, чтобы избежать кеша. Важно помнить, что асинхронный не подразумевает мгновенно. Помните, что даже если Ajax генерируется динамически и работает только для одного пользователя, его все равно могут быть кэшированы.