Оригинальная ссылка (нужно пересечь стену):Developers.Google.com/Web/Женщины большие…
оригинальный автор: Дэйв Гэшпереводчик:Слушая дождь в западном здании
Аннотация: эта работа является одной из вводных статей по оптимизации веб-производительности на веб-сайте разработчиков Google. Другие статьи из этой серии, а также соответствующие дополнительные статьи серии будут опубликованы в будущем, и вы можете обратить на них внимание.(Пожалуйста, укажите источник)
Everything a web page needs to be a web page -- text, graphics, styles, scripts, everything -- must be downloaded from a server via an HTTP request. It's no stretch to say that the vast majority of a page's total display time is spent in downloading its components, not in actually displaying them. So far, we've talked about reducing the size of those downloads by compressing images, minifying CSS and JavaScript, zipping the files, and so on. But there's a more fundamental approach: in addition to just reducing download size, let's also consider reducing download frequency.
Все, что нужно веб-странице — текст, изображения, стили, скрипты и т. д. — должно загружаться через HTTP-запросы. Бесспорно, что большая часть времени, необходимого для рендеринга веб-страницы, тратится на загрузку этих компонентов, а не на их фактическое отображение. До сих пор мы говорили об уменьшении размера загружаемых файлов, о том, как сжимать изображения, минифицировать CSS и Javascript, архивировать эти файлы и т. д. Но на самом деле есть путь ближе ко дну: в дополнение к уменьшению размера загрузки мы также можем рассмотреть возможность уменьшения количества загрузок.
Reducing the number of components that a page requires proportionally reduces the number of HTTP requests it has to make. This doesn't mean omitting content, it just means structuring it more efficiently.
Сокращение количества компонентов, необходимых для веб-страницы, может соответствующим образом уменьшить количество HTTP-запросов. Но это не значит, что вы выбрасываете какой-то контент, а чтобы упорядочить эти части более эффективным образом.
Объединить текстовые ресурсы
Many web pages use multiple stylesheets and script files. As we develop pages and add useful formatting and behavior code to them, we often put pieces of the code into separate files for clarity and ease of maintenance. Or we might keep our own stylesheet separate from the one the Marketing Department requires us to use. Or we might put experimental rules or scripts in separate files during testing. Those are all valid reasons to have multiple resource files.
Сегодня многие веб-страницы используют несколько файлов стилей и файлов сценариев. По мере того, как мы продолжаем разрабатывать страницу и добавлять к ней требуемый стиль и код поведения, мы часто размещаем некоторые блоки кода в отдельных файлах, чтобы код был понятным и простым в обслуживании. Например, мы будем отделять собственные файлы стилей от файлов, требуемых отделом маркетинга, в процессе тестирования мы будем отделять какие-то экспериментальные правила стиля или скрипты. Эти методы подходят для использования нескольких файлов стилей.
But because each file requires its own HTTP request, and each request takes time, we can speed up page load by combining files; one request instead of three or four will certainly save time. At first blush, this seems like a no-brainer -- just put all the CSS (for example) into a master stylesheet and then remove all but one from the page. Every extra file you eliminate in this way removes one HTTP request and saves round-trip time. But there are caveats.
Но так как для каждого файла нужен свой запрос, а каждый запрос занимает определенное время, мы можем объединить файлы для ускорения загрузки страницы, один запрос вместо трех-четырех запросов существенно экономит время. Хотя на первый взгляд эта операция кажется неграмотной — объединить весь CSS (это просто пример, это могут быть и другие файлы) в один большой файл стилей, а остальные файлы удалить со страницы. Но каждый удаленный файл сокращает один запрос, что, в свою очередь, сокращает время обращения к серверу. Тем не менее, есть некоторые предостережения, о которых следует знать.
For Cascading Style Sheets, beware the "C". Cascade precedence allows later rules to override earlier ones without warning -- literally. CSS doesn't throw an error when a previously-defined property is reset by a more recent rule, so just tossing stylesheets together is asking for trouble. Instead, look for conflicting rules and determine whether one should always supercede the other, or if one should use more specific selectors to be applied properly. For example, consider these two simple rules, the first from a master stylesheet, the second imported from a stylesheet provided by Marketing.
Для каскадных таблиц стилей обратите особое внимание на каскадирование. Каскадная функция приведет к тому, что правила стиля в конце переопределяют правила стиля в начале без какого-либо запроса. Кроме того, CSS не выдает никаких ошибок при сбросе свойств, определенных в предыдущих. Таким образом, простое слияние файлов стилей вместе может вызвать некоторые проблемы. В дополнение к этому нам также необходимо найти конфликтующие правила стиля и определить порядок между ними, или следует ли правилу стиля использовать более квалифицированный селектор, чтобы убедиться, что они в порядке. Например, два простых правила стиля в приведенном ниже коде: первое взято из основного файла таблицы стилей, а второе импортировано из файла таблицы стилей, предоставленного отделом маркетинга.
h2 { font-size: 1em; color: #000080; } /* master stylesheet */
. . .
h2 { font-size: 2em; color: #ff0000; } /* Marketing stylesheet */
Marketing wants their h2s to be prominent, while yours are meant to be more subdued. But due to the cascading order, their rule takes precedence and every h2 in the page will be big and red. And clearly, you can't just flip the order of the stylesheets or you'll have the same problem in reverse.
Маркетинг хочет, чтобы ихh2Они подсвечиваются, а у вас обычно тускнеют. Но из-за каскадного порядка их правила имеют более высокий приоритет, так что каждыйh2Элементы станут больше и станут красными. Кроме того, вы не можете решить проблему, просто поменяв порядок этих файлов.
A little research might show that Marketing's h2s always appear inside a specific class of section, so a tweak to the second rule's selector resolves the conflict. Marketing's splashy h2s will still look exactly as they want, but without affecting h2s elsewhere in the page.
Проведите небольшое исследование, и вы обнаружите, что отдел маркетингаh2Они всегда находятся в блоке фиксированного класса, поэтому мы можем разрешить этот конфликт, немного изменив селектор второго правила. Таким образом, отдел маркетингаh2Они имеют тот же эффект, что и раньше, не затрагивая остальную часть страницы.h2их.
h2 { font-size: 1em; color: #000080; }
. . .
section.product h2 { font-size: 2em; color: #ff0000; }
You may run into similar situations when combining JavaScript files. Completely different functions might have the same names, or identically-named variables might have different scopes and uses. These are not insurmountable obstacles if you actively look for them.
Однако вы можете столкнуться с той же проблемой даже при объединении файлов JavaScript. Функции с несвязанными функциями могут иметь одно и то же имя; переменные с одним и тем же именем имеют разные области действия и использование. Это не неизбежные препятствия, если вы удалите их осторожно.
Combining text resources to reduce HTTP requests is worth doing, but take care when doing so. See A Caveat below.
Объединение ресурсов текстового типа может сократить HTTP-запросы, что стоит сделать, но требует особой осторожности в процессе. Пожалуйста, посмотри "заметка"один период.
Объединить графические ресурсы
On its face, this technique sounds a bit nonsensical. Sure, it's logical to combine multiple CSS or JavaScript resources into one file, but images? Actually, it is fairly simple, and it has the same effect of reducing the number of HTTP requests as combining text resources -- sometimes even more dramatically.
На первый взгляд эта технология кажется немного нереалистичной. Это, безусловно, логично для объединения нескольких ресурсов CSS или JavaScript в один, но как насчет изображений? На самом деле слияние изображений тоже очень простое и имеет тот же эффект, что и слияние текстовых ресурсов — иногда даже сильнее.
Although this technique can be applied to any group of images, it is most frequently used with small images such as icons, where extra HTTP requests to fetch multiple small graphics are particularly wasteful.
Хотя этот метод можно применять к любому набору изображений, в большинстве случаев он чаще используется для изображений небольшого размера, таких как значки (поскольку в этом случае) требуется дополнительный запрос на получение нескольких таких изображений небольшого размера. очень расточительно.
The basic idea is to combine small images into one physical image file and then use CSS background positioning to display only the right part of the image -- commonly called a sprite -- at the right place on the page. The CSS repositioning is fast and seamless, works on an already-downloaded resource, and makes an excellent tradeoff for the otherwise-required multiple HTTP requests and image downloads.
Основная идея этой технологии заключается в том, чтобы физически объединить изображения небольшого размера в файл изображения, а затем использовать функцию фонового позиционирования CSS для отображения соответствующих частей, которые необходимо отобразить на соответствующей позиции страницы — это обычно называют «аspriteФункция позиционирования CSS не только быстра, но и естественна, и может быть очень эффективной в противодействии HTTP-запросам и загрузкам изображений.
For example, you might have a series of social media icons with links to their respective sites or apps. Rather than downloading three (or perhaps many more) individual images, you might combine them into one image file, like this.
Например, предположим, что у вас есть набор значков для сайтов социальных сетей, каждый из которых связан с соответствующим веб-сайтом или приложением. Вместо того, чтобы загружать каждую иконку с помощью трех (возможно, большего количества) запросов, (на данный момент) вы можете объединить их в один файл изображения, например так:
Then, instead of using different images for the links, just retrieve the entire image once and use CSS background positioning ("spriting") for each link to display the correct part of the image for the link.
Затем единожды получается только общее изображение, и используйте позиционирование фона CSS (спрайты), чтобы убедиться, что каждая ссылка правильно демонстрирует соответствующую часть общего изображения.
Here's some sample CSS.
Вот пример кода CSS:
a.facebook {
display: inline-block;
width: 64px; height: 64px;
background-image: url("socialmediaicons.png");
background-position: 0px 0px;
}
a.twitter {
display: inline-block;
width: 64px; height: 64px;
background-image: url("socialmediaicons.png");
background-position: -64px 0px;
}
a.pinterest {
display: inline-block;
width: 64px; height: 64px;
background-image: url("socialmediaicons.png");
background-position: -128px 0px;
}
Note the extraneous background-position property in the facebook class. It's not necessary, as the default position is 0,0 but is included here for consistency. The other two classes simply shift the image left horizontally relative to its container by 64px and 128px, respectively, leaving the appropriate image section visible in the 64-by-64 pixel link "window".
Обратите внимание, что в классе facebook в приведенном выше кодеbackgournd-positionатрибут, по сути, не нужен, т.к.positonЗначение свойства по умолчанию равно0,0, который написан здесь из соображений согласованности. Два других класса обрабатываются относительно контейнера, который их содержит, соответственно.64pxа также128pxГоризонтальное смещение для того, чтобы соответствующая ссылка на картинке была частью64X64Размер в пикселях отображается правильно.
Here's some HTML to use with that CSS.
Вот пример HTML-кода, использующего приведенный выше код CSS:
<p>Find us on:</p>
<p><a class="facebook" href="https://facebook.com"></a></p>
<p><a class="twitter" href="https://twitter.com"></a></p>
<p><a class="pinterest" href="https://pinterest.com"></a></p>
Instead of including separate images in the links themselves, just apply the CSS classes and leave the link content empty. This simple technique saves you two HTTP requests by letting CSS do the image shifting behind the scenes. If you have lots of small images -- navigation icons or function buttons, for example -- it could save you many, many trips to the server.
В приведенном выше коде вместо размещения изображения между каждым тегом ссылки по отдельности достигается тот же эффект, просто применяя класс CSS и оставляя содержимое ссылки пустым. Этот трюк использует CSS для смещения изображения, сокращая два HTTP-запроса. Когда у вас много маленьких изображений — значки навигационного меню, кнопки действий — это значительно сокращает количество взаимодействий с сервером.
You can find a brief but excellent article about this technique, including working examples, at WellStyled.
существуетWellstyledВыше есть простая, но отличная статья об этой технике с некоторыми рабочими примерами, которые вы можете проверить.
Предостережение
In our discussion of combining text and graphics, we should note that the newer HTTP/2 protocol may change how you consider combining resources. For example, common and valuable techniques like minification, server compression, and image optimization should be continued on HTTP/2. However, physically combining files as discussed above might not achieve the desired result on HTTP/2.
Одна вещь, которую мы должны отметить в приведенном выше обсуждении слияния текста и изображений, заключается в том, что новыйHTTP/2Соглашения могут изменить наши представления о консолидации ресурсов. Например, следует оставить распространенные и ценные методы, такие как минимизация кода, сжатие на стороне сервера и оптимизация изображений. Однако, как мы обсуждали ранее, физическое слияние файлов может не дать желаемых результатов.
This is primarily because server requests are faster on HTTP/2, so combining files to eliminate a request may not be substantially productive. Also, if you combine a fairly static resource with a fairly dynamic one to save a request, you may adversely affect your caching effectiveness by forcing the static portion of the resource to be reloaded just to fetch the dynamic portion.
Это главным образом потому, чтоHTTP/2В протоколе производительность сервера запросов стала более эффективной, поэтому уменьшение количества запросов путем слияния файлов может не дать особого эффекта. Кроме того, если вы уменьшите запросы, объединив значительное количество статических ресурсов в один достаточно динамический ресурс, вы, наоборот, также можете повлиять на эффект кеша, потому что это приведет к принудительному обновлению статической части, чтобы получить динамический часть, часть проблемы.
The features and benefits of HTTP/2 are worth exploring in this context.
HTTP/2Эти особенности и преимущества , заслуживают изучения в рамках темы этой статьи.
Позиция JavaScript и встроенный push
We're assuming so far that all CSS and JavaScript resources exist in external files, and that's generally the best way to deliver them. Bear in mind that script loading is a large and complex issue -- see this great HTML5Rocks article, Deep Dive Into the Murky Waters of Script Loading, for a full treatment. There are, however, two fairly straightforward positional factors about JavaScript that are worth considering.
В настоящее время мы предполагаем, что все CSS и JavaScript являются внешними ресурсами, что является лучшим способом их передачи. Имейте в виду, что загрузка скриптов — это большая и сложная проблема — см. эту замечательную статью на HTML5Rocks,Deep Dive Into the Murky Waters of Script Loading. Ниже приведены два прямых фактора, которые стоит учитывать: «эффекты местоположения».
Расположение скрипта
Common convention is to put script blocks in the page head. The problem with this positioning is that, typically, little to none of the script is really meant to execute until the page is displayed but, while it is loading, it unnecessarily blocks page rendering. Identifying render-blocking script is one of the reporting rules of PageSpeed Insights.
Обычно мы размещаем блок скрипта в шапке страницы. Есть проблема с таким способом размещения скриптов, обычно практически никакой скрипт на самом деле не нужно выполнять, когда страница загружается и не отображается, из-за чего рендеринг страницы блокируется. Из-за этого идентификация кода блокировки такжеPageSpeed InsightsИнструмент устанавливает одно из правил отчетности.
A simple and effective solution is to reposition the deferred script block at the end of the page. That is, put the script reference last, just before the closing body tag. This allows the browser to load and render the page content, and then lets it download the script while the user perceives the initial content. For example:
Простой и эффективный способ решить эту проблему — переместить эти отложенные блоки скрипта в конец страницы. То есть поместите скрипт вbodyперед закрывающим тегом тега. Таким образом, после того, как браузер загрузит и отобразит содержимое страницы, пользователь может почувствовать начальный контент при загрузке этих скриптов. Например:
<html>
<head>
</head>
<body>
[Body content goes here.]
<script src="mainscript.js"></script>
</body>
</html>
An exception to this technique is any script that manipulates the initial content or DOM, or provides required page functionality prior to or during rendering. Critical scripts such as these can be put into a separate file and loaded in the page head as usual, and the rest can still be placed last thing in the page for loading only after the page is rendered.
Но есть особый случай, некоторые сценарии должны работать с начальным содержимым, DOM или должны обеспечивать некоторые необходимые функции страницы до или во время рендеринга страницы. В этом случае мы можем вынести эти критичные скрипты (Critical script) в отдельный файл, а затем загрузить его в начало страницы как обычно, в то же время другие могут быть загружены после рендеринга страницы. только что загруженные, размещаются в конце страницы.
The order in which resources must be loaded for maximum efficiency is called the Critical Rendering Path; you can find a thorough article about it at Bits of Code.
Мы называем этот порядок загрузки, который должен загружать ресурсы наиболее эффективно, «Критический путь рендеринга»; по этой теме см.Bits of CodeВыше есть подробное введение.
Расположение кода
Of course, the technique described above splits your JavaScript into two files on the server and thus requires two HTTP requests instead of one, exactly the situation we're trying to avoid. A better solution for relocating critical, pre-render scripts might be to place them directly inside the page itself, referred to as an "inline push".
Упомянутый выше метод разбивает JavaScript на два файла, поэтому он также требует двух HTTP-запросов вместо одного, чего, очевидно, следует избегать, насколько это возможно. Хорошим решением является извлечение этих критических, предварительно загруженных скриптов прямо на страницу, это называется «встроенным нажатием».
Here, instead of putting the critical script in a separate file and referencing it in the page head, add a block, either in the head or in the body, and insert the script itself (not a file reference, but the actual script code) at the point at which it's needed. Assuming the script isn't too big, this method gets the script loaded along with the HTML and executed immediately, and avoids the extra HTTP request overhead of putting it in the page head.
То есть вместо того, чтобы помещать «критический сценарий» в отдельный файл и ссылаться на него в начале страницы, вместо этого помещать сам сценарий (не ссылку на файл, а фактический код) в<script>...</script>блок и вставьте его туда, где это необходимо (голова или тело). Предполагая, что сценарий не очень большой, этот подход позволяет загружать сценарий вместе с HTML и выполнять его немедленно, избегая накладных расходов на дополнительные HTTP-запросы.
For example, if a returning user's name is already available, you might want to display it in the page as soon as possible by calling a JavaScript function, rather than wait until after all the content is loaded.
Например, если имя пользователя возвращается, вы, возможно, захотите, чтобы он был отображен на странице как можно скорее, а не в ожидании загруженного контента.
<p>Welcome back, <script>insertText(username)</script>!</p>
Or you might need an entire function to execute in place as the page loads, in order to render certain content correctly.
Или иногда вам может понадобиться целая функция для правильного выполнения при загрузке страницы, чтобы правильно отобразить содержимое.
<h1>Our Site</h1>
<h2 id="greethead">, and welcome to Our Site!</h2>
<script>
//insert time of day greeting from computer time
var hr = new Date().getHours();
var greeting = "Good morning";
if (hr > 11) {
greeting = "Good afternoon";
}
if (hr > 17) {
greeting = "Good evening";
}
h2 = document.getElementById("greethead");
h2.innerHTML = greeting + h2.innerHTML;
</script>
<p>Blah blah blah</p>
This simple technique avoids a separate HTTP request to retrieve a small amount of code and allows the script to run immediately at its appropriate place in the page, at the minor cost of a few dozen extra bytes in the HTML page.
Этот простой метод с небольшими затратами в десятки байт позволяет избежать дополнительных HTTP-запросов и позволяет немедленно выполнить сценарий в правильном месте.
Резюме
In this section, we covered ways to reduce the number of HTTP requests our pages make, and considered techniques for both text and graphical resources. Every round-trip to the server we can avoid saves time, speeds up the page load, and gets its content to our users sooner.
В этой статье мы упомянули некоторые способы уменьшить количество HTTP-запросов и рассмотрели некоторые методы работы с файлами и изображениями в этой области. Каждое обращение к серверу, которого мы можем избежать, может ускорить загрузку страницы, что, в свою очередь, может очень быстро отобразить контент для пользователя.