Размеры сайта: Оптимальная ширина сайта под популярные разрешения экранов (2020)

Размеры макета сайта при разработке адаптивного дизайна

Впервые столкнувшись с задачей разработки дизайна адаптивного сайта, возникают вопросы, связанные с размерами макета. Эти вопросы возникают не только у дизайнера, но и часто у клиента. Дизайнер задает вопрос клиенту, под какие разрешения необходимо разработать макет, а клиент отвечает, под все. И тут возникает ступор, ведь разрешений множество, а если нет опыта, то все кажется сложным. Давайте будем разбираться.

Для начала нужно понимать, что при верстке сайта верстальщик работаем с диапазонами размеров, в которых дизайн корректно отображается.

Разрабатывая же макет будущего сайта в графическом редакторе (Photoshop) или сервисе (Figma), дизайнер не можем работать с диапазонами, ему приходится задавать жесткие размеры макета. Эти макеты веб-дизайнер создает с учетом минимального и максимального разрешения популярных экранов, которое определяет для проекта.

Для ПК версии возьмем разрешение 1920 px с контентной частью в 1280 px. Контентную часть можно сделать и больше, например 1440 px, или во всю ширину, если создается, например сервис или административная панель. На данный момент чаще используемый первый вариант. Для смартфонов самым минимальным разрешением считается 320 px. Таким образом, определили максимальное и минимальное разрешения. Далее нужно определиться с промежуточными разрешениями.

К таким разрешениям, относим планшет с горизонтальной и вертикальной ориентацией на 1024 и 768 px. А также макет для мобильных устройств на 480 px в горизонтальной ориентации. Если не создавать макет на 480, получается слишком большой диапазон разрешений попадающих между 768-320 px. Дизайн на таком промежутке за счет версии в 480 px будет гораздо лучше продуман и удобен.

Иногда вместо 320 и 480 разрабатывается один макет на 360 px. Но тогда верстальщику придется самому проверить дизайн после верстки на разрешение в 320, иначе получим сайт с некорректным отображением.

Итак, определились с разрешениями, под которые требуется создать макеты и таких макетов будет пять.

• ПК – 1920 px файл, контент под 1280 px без учета отступов на скролл и отступов справа и слева;
• Планшет 1024 px без учета отступов на скролл и отступов справа и слева;
• Планшет 768 px без учета отступов справа и слева;
• Смартфоны 480 px без учета отступов справа и слева;
• Смартфоны 320 px без учета отступов справа и слева;

Раньше на скролл отнималось 21 px как стандарт, но ширина скроллинга у браузеров изменилась и отличается. Но это не так важно, главное не забыть и учесть скролл при создание макета для ПК.  Подробнее о том, как учесть скроллинг в макете читайте здесь.

Холст 1920 px создавайте только для ПК версии, на остальных разрешениях в размер. Разрешение в 1920 px дает возможность размещать фоновые изображения в блоках дизайна на ширину экрана.

Что касается отступов по краям

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

Обычно использую следующие отступы:

• Мобильные 10-15
• Планшет 15-20 px. Для разрешения в 1024 px использую холст на 1000 px это за вычетом скроллинга, потом от него отнимаю отступы.
• ПК контентная часть делаю в размер 1200 px, отступы зависят от сетки.

Подходы к созданию макета сайта Mobile First или Desktop First?

Кроме вопроса: «Какой размер макета сайта делать, создавая адаптивный дизайн?»

Задается еще и сопутствующий вопрос: «Какой из подходов создания правильнее Mobile First или Desktop First?»

Mobile First – сначала мобильные, то есть первым делом рисуются макеты для мобильного, разумеется, перед этим делают прототип сайта. А уже потом переходят к созданию планшетной и ПК версии. Некоторые считают, что благодаря такому подходу можно сделать более удобный интерфейс. И этот подход правильнее исходя из популярности и нарастающего трафика мобильного Интернета.

Desktop First

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

Возможно, этот подход мне ближе, так как создаю дизайн сайтов давно. Изначально не приходилось разрабатывать столько макетов, а делалась лишь одна версия для ПК.

Если подумать, то особой разницы в подходах, лично я не вижу. Считаю, что правильно делать, так как удобнее вам, ведь главное результат! Если можете сделать грамотный дизайн, сделав сначала ПК версию, а потом остальные, зачем задумываться над подходом.

Как быть с плотностью пикселей экранов устройств?

Еще один вопрос, который не дает покоя это плотность пикселей. Вернее даже не сама плотность пикселей, а как будет выглядеть дизайн на мобильных устройствах с высоким разрешением.

Часто разрешение у смартфона может быть в разы выше, чем макет, который разрабатывается для ПК версии.

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

Зная множитель плотности пикселей, вы с легкостью определите какой макет и на каком устройстве будет отображаться.

Отсюда следует, что макеты дизайна сайта стоит создавать под обычное разрешение с 1х плотностью пикселей. Иконки и графику рисовать в векторе и использовать svg. При верстке страниц сайта через media queries определять экраны с множителем и подгружать соответствующие растровые изображения, если таковые используются.

Стандартная ширина сайта — какой она должна быть? ⋆

Быстрая навигация по этой странице:

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

О важности вопроса

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

Дело в том, что если если выбранная вами ширина будет больше, чем разрешение экрана у посетителя, то сайт в полном объеме не поместится в браузере, появится горизонтальная полоса прокрутки. В результате этого пользователь не увидит часть информации или ему будет некомфортно работать с вашим проектом. Итог будет один — уменьшение поведенческих факторов.

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

Итак, какой же должна быть ширина сайта в пикселях?

Рассчитываем оптимальный вариант

Для того, чтобы правильно ответить на этот вопрос, нужно обратиться к статистике.

Для моего проекта на момент написания статьи сервис Liveinternet выдавал такую статистику (показаны строки, имеющие долю в статистике более 5 процентов):

• 1366×768 — 23.7%
• 1280×1024 — 15.1%
• 1024×768 — 14.7%
• 1280×800 — 9.5%
• 1920×1080 — 8.4%
• 640×480 — 6.2%
• 1600×1200 — 5.9%

Как видно из статистики, подавляющее большинство пользователей использует мониторы с разрешением шириной от 1280 пикселей и выше. Тем не менее, обратите внимание на строку, выделенную жирным шрифтом: 14,7 % имеет разрешение 1024 пикселей. Это в среднем каждый шестой/седьмой пользователь — достаточно большой процент, который имеет смысл учитывать.

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

Однако 1024 пикселя — это разрешение монитора, а фактически площадь страницы в браузере меньше, так как часть экрана съедает полоса прокрутки (скролл) — это около 24 пикселей.

Следовательно, наша страничка должна открываться не более, чем на 1000 пикселей. Часто дизайнеры или заказчики берут еще 20 пикселей в запас и делают сайт на 980 px.

Таким образом, наиболее оптимальной шириной является 980-1000 px.

Читайте также: Как сделать тег пробела в HTML?

Почему часто используется 960?

Если Вы обратите внимание на шаблоны для WordPress (как, впрочем, и для многих других CMS), то вы заметите, что многие из них ориентированы на 960 пикселей.

Зачем же отклоняться от оптимального варианта в меньшую сторону? Здесь следует отметить, что 960 — это математически очень «удобное число», так как, в отличие от 980, оно делится на каждое из этих чисел: 6, 8, 12, 16, 24 (и, соответственно, на множество других).

Это удобно для создания дизайна по так называемой «сетке» (grid system) — когда при создании макета он мысленно делится на 6/8/12 и т.д. частей и все блоки макета выстраиваются по этим линиям — получается симметрично и красиво (подробнее про это написано на 960. gs и других ресурсах).

Если же вы делаете или заказываете дизайн с нуля и просто хотите, чтобы, например, контентная часть занимала 600 пикселей, а справа был сайдбар — тогда вам необязательно ориентироваться на grid system и 960 пикселей.

Осторожность с резиновым макетом

В каком-то смысле решением рассматриваемой проблемы является резиновый макет — ширина страницы растягивается под ширину экрана, потому заранее учтены все варианты дисплеев.

Однако, по моему субъективному мнению, неограниченно резиновый макет — это зло, так как на дисплее с разрешением более 2000 пикселей весь ваш текст вытянется в несколько длинных строк, которые будет сложно читать.

Представьте, что вы читайте книгу, в которой одна строка имеет длину, предположим, в семьдесят сантиметров или в один метр. Удобно ли вам будет ее читать? Полагаю, что нет, ведь не зря сам по себе книжный формат в среднем не предполагает более 60-80 символов на одной строке. Потому я такую технологию создания сайта не рекомендовал бы.

Потому, если вы делаете или заказываете резиновый макет, позаботьтесь о посетителе — поставьте ограничение около 1200-1300 px как максимальную ширину вашей страницы.

выбираем оптимальный первый экран для Landing page

Экраны лендинга

Главный экран любого лендинга включает заголовок, изображение, УТП и призыв к действию. Этот экран должен заинтересовать пользователя, заставить его двигаться дальше по сайту.

Главный экран лендинга

Посетитель видит всю главную информацию, не прокручивая колесо мыши. Дальше располагается вторая часть, увидеть которую можно только после скроллинга. Здесь подтверждаются все те выгоды, которые представлены на первом экране: закрываются возражения, приводятся факты, прописываются дополнительные сведения. В этой же части лендинга находится форма заявки. Если пользователя убедила информация, находящаяся выше, то он оставит свои контакты. Вот как может выглядеть вторая часть лендинга:

Вторая часть лендинга

Таким образом, схема построения лендинга выглядит так:

Экраны лендинга

Некоторые трудности может вызвать адаптация макета сайта для разных разрешений экранов. Запомните, что ориентироваться вам нужно не на разрешение, а на размер окна браузера. Так, например, вы знаете, что средний размер экрана монитора — 1024×768 пикселей. В таком случае высота макета НЕ должна составлять 768 пикселей в высоту. Она должна соответствовать высоте окна браузера. То же касается мобильных версий макетов.

Какого размера делать лендинг

При разработке landing page нужно делать несколько макетов: для широких экранов, для планшетов и для телефонов. Расположение информационных блоков на макетах будет отличаться в зависимости от экрана.

Основную сложность представляет разработка дизайна первого экрана лендинга. Практика показывает, что для десктопа разработчики чаще всего выбирают ширину в 1000px и высоту в 680px. Причина этого в том, что настроить дизайн сразу под 4 устройства (монитор ПК, ноутбук, планшет и смартфон) довольно сложно. Дополнительная проблема — окно браузера, размер которого пользователи могут менять как угодно.

Зависимость размеров от изменения размера окна браузера

Оптимальная высота лендинга для десктопных браузеров — в районе 600-800px, а для мобильных устройств — 400-500px. Далее расскажем, почему лучшими считаются именно эти варианты.

Сначала рассчитывается усредненная высота всех устройств. Для упрощения задачи нужно сократить количество возможных вариантов. Самый часто встречающийся размер больших экранов (монитора ПК, ноутбука или планшета) — 1000–1200px, маленьких экранов — 320–360px (имейте в виду, что экраны смартфонов Apple имеют высоту 375px).

Получив приблизительные данные, рассчитываем идеальный размер. Большим экранам оптимально будет присвоить 600–800px, а маленьким — 400–500px.

Еще один популярный вариант — использовать в CSS единицы измерения vw (ширина вьюпорта) и vh (высота вьюпорта). Если вы зададите высоту блоку width 100vh, то на любом экране он будет равняться 100 % высоты вьюпорта. В этом случае вам не придется задавать размеры под каждый экран индивидуально, а результат будет хорошо отображаться на большинстве устройств.

Разработку при этом нужно вести максимально внимательно. Разработчик и дизайнер должны прийти к полному взаимопониманию, а ход работ должен постоянно контролироваться. В противном случае вы можете получить «спрессованную» картинку. Случается такое, когда окошко браузера чересчур маленькое, а потому весь контент на сайте показать не удается. Если так получится, вам придется вернуться к первому варианту и задать твердое значение ширины и высоты. Возможно, на большинстве экранов останется лишний скролл, зато контент отобразится корректно.

Если с высотой разобраться сложнее ввиду неодинаковых размеров окошек различных браузеров, то с шириной все гораздо проще. Мы выяснили, что разрешение экрана, например, ноутбука — 1024×768 пикселей. Оптимальной высотой мы обозначили 600px, остальная часть уйдет под меню браузера и строку меню операционной системы. Для ширины достаточно 1000px. Остальное займет полоса прокрутки и вертикальные границы браузера. По этому же принципу рекомендуем выбрать оптимальный размер лендинга для остальных устройств.

Примеры идеального первого экрана

В заключение представим вам примеры отличного оформления первых экранов. Они идеально подогнаны под все размеры устройств и содержат заголовок, иллюстрацию, УТП и призыв к действию.

Однако начнем с лендинга, оформленного неправильно.

Плохой пример оформления лендинга

На этом сайте главного экрана нет как такового. Мы видим фотографию и длинный сплошной текст до конца страницы. Мобильная версия выглядит не лучше:

Отображение лендинга в мобильной версии

Здесь нет ничего, кроме текста. Найти контакты сложно, форма заявки отсутствует, нет УТП и корректных заголовков.

Теперь обратите внимание на следующий пример:

Пример удачного оформления первого экрана лендинга

Мы видим главную страницу, на которой есть важная информация. Листать вниз не нужно, все УТП и преимущества представлены в виде «карусели». На основном экране информация четко разделена по блокам.

Взгляните на пример лендинга компании, занимающейся доставкой полезной еды:

Пример лендинга по доставке еды

Здесь мы видим яркий первый экран с формой заявки и основным преимуществом. Далее следует остальная часть с дополнительной информацией:

Оформление второго экрана лендинга по доставке еды

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

 

Идеальный размер сайта | Записки Web-разработчика

По моему уже все знают, что стандартный размер сайта в рунете почему-то 1000px. “Чтобы за монитор не вылезал”. А как насчет размера сайта равного 960px или 980px? Плохо, мало, некрасиво…

Почему? А вы никогда не задумывались, почему большинство сайтов рунета, как “профессиональных”, так и не очень, выглядят настолько убого? Вот смотришь — и вроде бы все хорошо, цвета, картинки, текст. Но композиция, как говориться, разваливается. На него неприятно смотреть. Даже не на уровне осознания, а как-то неудобно, глаз, как говорится, спотыкается. Тут даже не в размере сайта. Размер сайта тут не причем, дело в другом, о том и эта статья.

Причиной случит невероятный отрыв технологий — представители которых в основном инженеры или просто нерды, от искусства. И в частности графического дизайна — представители которого учились в художественных учреждениях и знают такие очевидные для них вещи как “пропорции” и “золотое сечение”. А еще немного в сторонке от вебстроительства клубятся те, кто знает что либо про эргономику и дизайн пользовательского интерфейса.

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

Возникает вопрос — как же вы сможете добиться нормального визуального и пользовательского оформления создавая сайт самостоятельно? Для этого уже давным давно придуманы многочисленные методы — например вы можете использовать модульные сетки, или использовать уже готовые решения — особенно для сайтов, где важнее юзабилити, а не дизайн. Все методы, позволяющие достичь ощущения равновесия, красоты, порядка и гармонии графическом и веб-дизайне, базируются на понятии золотого сечения.

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

Золотое сечение

Начиная с эпохи ренессанса, много художников и архитекторов старались приблизить композиции своих работ к золотой пропорции, особенно популярной была форма “золотого прямоугольника”, у которого одна сторона была длинее другой именно в этом отношении. Основанием к этой моде стало доказательство того, что такая форма, наиболее органична, универсальна, гармонична и эстетически приятна для восприятия. Эта пропорция встречается повсеместно в природе и вселенной. Использование этого метода поможет существенно улучшить ваш дизайн.

Ключом для перехода от плохого дизайна к хорошему можно назвать числе 1,618033988749895… и далее. Обычно для удобства используют число 1,6, 1,618 или 1,62. Это и есть золотая пропорция, золотое сечение.

Так почему же не применять его в веб дизайне? Применяют и очень успешно. Но не в России. Пример вычислений касательно разлиновки веб сайта вы видите ниже.

Объясняю пример. Вы хотите создать сайт с фиксированной шириной 960px. Мало? Об этих ширинах потом. Если мы делаем блог, то сайдбар у нас располагается справа, а контент слева. Размеры области контента, относительно сайдбара считаются так:

1. Cначала сосчитаейте ширину области контента. Про правилу золотого сечения она должна быть на 1,6 меньше, чем ширина сайта (960px). Поделим 960 на 1,62, получим 593px.
2. Отнимите от общей ширины получившуюся: 960px – 593px = 367px.

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

Конечно веб дизайне не должен весь полностью быть строго выверен по линейке в пропорциях. Например сайт The 404 Blog сделан не совсем по строгим канонам, однако он тоже смотрится очень хорошо и правильно.

Несмотря на то, что дизайн этого блога неправилен с точки зрения сечения, пользователи не замечают этого, потому что они интуитивно делят страницу на два блока: 583px (630px – 31px – 31px) и 299px (330px – 31px). Причина в пассивной игре боковых полей (линии по 31 px), они обеспечивают пропорциональные промежутки и отступы от края до контента.

И хотя отношение между областями сайта равно 630 : 330 px ≈ 1.91 (не 1.62), а отношение между размерами текстовой области и меню равно 583 : 299px ≈ 1. 92 (не 1.62), дизайн смотрится хорошо. Это достигается благодаря балансу — все элементы страницы имеют одинаковые пропорции 1,92. Отсюда и создается ощущение гармонии и эстетичности.

Также надо заметить, что такие отступы от краев, равны 31px не случайны еще по одной причине. Как я уже упоминал ранее, в записи про создание этого сайта существуют стандарты, по которым наиболее удобная для чтения длинна строки находится между 50–80символами текста в строке. Однако на данном сайте длина строки примерно равна 100 символам. Такой размер тоже вписывается в общую пропорциональную концепцию размеров сайта.

Посчитаем. Золотое сечение равно 1,62, на этом сайте пропорция равно 1,92. Соответственно 1,92/1,62=1,18. Округлим до 1,20. Умножаем: 80*1,2 = 95. Таким образом все укладывается в рамки законов природы. Для грубых набросков вы можете использовать отношение 5 : 3.

Правило трети

Изначально правило трети использовалось как упрощенное понимание золотого сечения и понимания пропорции и композиции. Использование правила трети позволит вам быстро составить композицию не имея на руках калькулятора.

Каждую композицию нужно разделить на девять равных частей, посредством линий, равноудаленных друг от друга и от границ композиции по вертикал и по горизонтали. Короче девять клеточек). Четыре точки-пересечения в центральной части — точки наибольшей важности в композиции, где следует размещать главные объекты. Выравнивание по правило трети дает больше экспрессии и жизни, по сравнению с обычным центрированием.

Применение правила трети возможно и в отношении к размерам сайта. Вернемся к нашим 960px, при этом его высота может варьироваться от 750px до 950px. Произведем следующие действия:

1. Разделите ширину на 3, получим 320px
2. Разделите среднюю высоту вашей страницы на 3 ( (750 + 950 px) / 2 ) / 3 ≈ 285px.
3. Следовательно каждый прямоугольник должен быть размером 320px × 285px.
4. Постройте сетку из девяти квадратов, 3 × 3

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

Пример можно увидеть, посмотрев на сайт demandware.com. Рассматривая этот сайт можно заметить, что актуальные данные расположены в точках пересечения. Также стоит отметить, что нижние блоки информации располагаются в соответствии с правилом трети и расположены строго под нижней линией, что соотносит пропорции размеров сайта как 2 : 1.

Заключение

В размерах сайта категорически важны правила золотого сечения и правило трети. Они совершенно зря забывают подавляющее большинство всех вебмастеров и дизайнеров. С помощью этих методик вы улучшаете восприятие вашего ресурса пользователем, повышаете юзабилити сайта и делаете его красивым. Главным достоинством этих методик является их абсолютная универсальность.

Стандартная ширина сайта в пикселях

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

Если у вас возникал или сегодня возникает подобный вопрос, то это говорит о том, что вы движетесь в верном направлении. Ведь в реальности ширина страницы на сайте обладает важным значением в его оформлении.

Если ширина, которую вы выбрали, будет больше, чем разрешение дисплея у посетителя, то страница сайта не сможет полностью поместиться, возникнет горизонтальная полоска прокрутки. В итоге, пользователь не сможет увидеть часть предлагаемой информации или же, ему станет весьма некомфортно взаимодействовать с вашим ресурсом. Результатом будет ухудшение поведенческих факторов.

Если же наоборот, и вы сделаете минимальную ширину, в особенности, если часть, где контент, станет очень маленькой, то сайт снова будет иметь несуразный и некомфортный вид. Вам следует осуществить проверку сайта в различных разрешениях и вы сами сможете убедиться в этом.

Рассчитываем оптимальный вариант

Необходимо рассчитать оптимальную версию. Для однозначного ответа на данный вопрос нужно исследовать имеющуюся в настоящее время статистику. В момент написания данной статьи присутствовала следующая статистика:

• 1366×768 — 23.7%
• 1280×1024 — 15.1%
• 1024×768 — 14.7%
• 1280×800 — 9.5%
• 1920×1080 — 8.4%
• 640×480 — 6.2%

Из предоставленных показателей очевидно, что большее число пользователей использует мониторы с разрешением, начиная от 1280 пикселей и заканчивая более высокими показателями. Но следует сфокусироваться на строке, которая выделена жирным шрифтом. Отображенные в ней данные есть у каждого шестого или седьмого пользователя — это довольно высокий процент, требующий внимания.

Поэтому ширина сайта должна быть не больше 1024 пикселей, в противном случае, каждый шестой посетитель не будет испытывать удобств при использовании вашего проекта.

Но 1024 px — это разрешение самого монитора, хотя параметры страницы гораздо меньше в браузере, потому как, частью дисплея поглощает полоса прокрутки. Из этого следует, что страничка обязана быть не больше 1000 пикселей. Довольно часто клиенты или дизайнеры берут запасные 20 пикселей и создают сайт на 980 пикселей.

Итак, самая оптимальная ширина – это 980-1000 px.

Почему часто используется 960?

По какой причине часто используется 960? Если вы присмотритесь к шаблонам для WordPress, то сразу же увидите, что множество из них заточено на 960 пикселей. Не стоит отказываться от лучшего варианта. Надо заметить, что 960 является математически «удобным числом», потому как делится на такие числа, как шесть, восемь, двенадцать и т.д.

Это весьма удобно для того, чтоб создавать дизайн «сетке» — то есть, в ходе создания макета он делится на шесть, восемь и двенадцать частей, а блоки макета располагаются по данным линиям. В итоге выходит симметрично и привлекательно.

Если вы разрабатываете дизайн с самого начала и желаете, к примеру, чтобы контентная часть достигала 600 пикселей, то вовсе не обязательно подстраиваться под 960 пикселей.

Осторожность с резиновым макетом

Резиновый макет в определенном смысле разрешает упомянутую выше проблему. Это когда ширина страницы способна растянуться под ширину экрана и потому учтены предварительно все версии дисплеев.

Но данный макет – это своего рода зло, потому как на дисплее с наличием разрешения больше, чем 2000 пикселей, имеющийся текст станет вытянутым. В итоге получатся длинные строки, весьма сложные для восприятия и чтения.

Представьте себе, что вы занимаетесь чтением книги со строкой около семьдесят сантиметров длины. Удобно вам будет читать ее? Скорее всего нет, ведь средний формат книги предполагает не больше 60-80 символов на строке. Именно поэтому, подобная технология создания сайта не приемлема.

Если вы создаете резиновый макет, то вам стоит позаботиться о посетителе — поставить ограничение, примерно 1200-1300 пикселей максимальной ширины страницы.

Стандартные размеры сайтов — Dark Owl

Технология разработки веб-сайтов — очень многогранный процесс. Но все же все его стадии можно разделить на две основных составляющих — функционал и внешнюю оболочку. Или, как принято в среде вебмастеров, бек енд и фронт енд соответственно. Люди, которые заказывают свои веб-сайты у студий веб-разработки, зачастую наивно полагают, что стоит сосредоточиться только на функционале, и это будет правильное решение.

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

Первый краеугольный камень, с которым сталкивается проектировщик интерфейса, или дизайнер, — это ширина макета сайта. Ведь для неё необходимо отрисовывать интерфейсы. Чисто интуитивно возникают два подхода — либо делать отдельные макеты для каждого популярного разрешения экрана, либо создать одну версию сайта для всех отображений. И оба варианты будут неверны, но обо всем по порядку.

Стандартная ширина сайта в пикселях для рунета

До развития адаптивной верстки массовым явлением была разработка сайта с шириной в тысячу пикселей. Эта цифра выбиралась по одной простой причине — чтобы сайт помещался в любой экран. И в этом есть своя логика, но давайте предположим, что все же у человека как минимум HD-монитор на десктопе. В таком случае ваш макет будет казаться крошечной полоской в середине экрана, где все слеплено в одну кучу, а по бокам огромное незадействованное пространство. Теперь давайте предположим, что человек зашел на ваш веб-сайт с планшета с экраном 800 пикселей по ширине, причем в настройках стоит галочка «Показывать полную версию веб-сайта». В этом случае ваш сайт также будет отображаться некорректно, так как просто-напросто не влезет в экран.

Из этих соображений можем сделать вывод, что фиксированная ширина для макета нам точно не подходит и необходимо искать другой способ. Давайте проанализируем идею отдельного макета для каждой ширины экрана.

Макеты на все случаи жизни

Если вы выбрали как стратегию создать макеты для всех размеров экранов, присутствующих на рынке, то тогда ваш сайт станет самым уникальным во всем интернете. Ведь просто невозможно сегодня охватить весь спектр устройств, пытаясь сделать точную настройку под каждый вариант. Но вот если ориентироваться на самые популярные разрешения мониторов и экранов устройств, то идея неплоха. Единственный её минус — финансовые затраты. Ведь когда проектировщик интерфейсов, дизайнер и верстальщик будут вынуждены 5 или 6 раз выполнять одну и ту же работу, проект будет стоить несоизмеримо больше изначально заложенной в бюджет цены.

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

Самые популярные размеры сайтов

Компромиссом между двумя крайностями является отрисовка макета для трех или четырех размеров экранов. Среди них один обязательно должен быть макетом для мобильных устройств. Остальные должны быть адаптированы для маленького, среднего и большого десктопного экрана. Как выбрать ширину сайта? Ниже приведем статистику сервиса HotLog за май 2017 года, которая демонстрирует нам распределение популярности различных разрешений экранов устройств, а также динамику изменения этого показателя.

Из таблицы можно узнать, как определить размер сайта, который нужно использовать. Помимо этого, можно сделать вывод, что наиболее распространенным сегодня форматом является экран 1366 на 768 точек. Такие экраны устанавливают в бюджетные ноутбуки, поэтому их популярность закономерна. Следующим по популярности является Full HD-монитор, который является золотым стандартом для видеороликов, игр, а значит, и для создания макетов сайта. Дальше в таблице мы видим разрешение мобильных устройств 360 на 640 точек, а также различные варианты десктопных и мобильных экранов после него.

Проектируем макет

Итак, проанализировав статистику, можно сделать вывод, что оптимальная ширина сайта имеет 4 вариации:

1. Версия для ноутбуков с шириной 1366 пикселей.
2. Full HD-версия.
3. Макет размером 800 пикселей по ширине для отображения на маленьких десктопных мониторах.
4. Мобильная версия сайта — 360 пикселей по ширине.

Допустим, мы определились, какой необходимо использовать размер создаваемого исходника для сайта. Но такой проект все равно будет затратным. Так что рассмотрим ещё варианты, на этот раз без использования фиксированной ширины.

Делаем макет гибким

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

Что такое золотое сечение, и как его применить к верстке веб-страниц?

Ещё в эпоху Возрождения многие архитекторы и художники пытались придать своим творениям идеальную форму и пропорцию. За ответами на вопросы о значениях такой пропорции они обращались к царице всех наук — математике.

Ещё со времен античности была изобретена пропорция, которую наш глаз воспринимает как самую естественную и изящную, ведь она повсеместно встречается в природе. Открывателем формулы такого соотношения был талантливый древнегреческий архитектор по имени Фидий. Он рассчитал, что если большая часть пропорции относится к меньшей так, как целое относится к большему, то такая пропорция будет смотреться наилучшим образом. Но это в том случае, если вы хотите разделить объект несимметрично. Такую пропорцию стали позже называть золотым сечением, что все равно не переоценивает её значение для мировой истории культуры.

Вернемся к веб-дизайну

Всё очень просто — используя золотое сечение, вы можете проектировать страницы, которые будут максимально приятны человеческому глазу. Рассчитав по определению формулы золотого сечения, получаем иррациональное число 1,6180339887…, но для удобства можно использовать округлённое значение 1,62. Это будет означать, что блоки нашей страницы должны быть 62% и 38% от целого, независимо от того, какой размер создаваемого исходника для сайта вы используете. Пример вы можете увидеть на такой схеме:

Используйте новые технологии

Современные технологии верстки веб-сайтов позволяют максимально точно передать задумку проектировщика и дизайнера, поэтому теперь можно позволить себе реализацию более смелых идей, чем на заре интернет-технологий. Больше не требуется сильно ломать голову над тем, какой должен быть размер сайта. С приходом таких вещей, как блочная адаптивная верстка, динамическая подгрузка контента и шрифтов, разработка сайта стала в разы приятнее. Ведь такие технологии имеют меньше ограничений, хоть все же они и есть. Но как известно, без ограничений не было бы и искусства. Мы предлагаем вам использовать один поистине творческий подход к проектировке — золотое сечение. С его помощью вы сможете эффективно и красиво заполнить рабочее пространство, какие бы размеры сайтов вы ни задавали в своих шаблонах.

Как увеличить рабочее пространство сайта

Велика вероятность того, что у вас не будет достаточно места, чтобы вместить все элементы интерфейса в макет небольшого размера. В таком случае придется начать думать творчески или же ещё более творчески, чем вы делали до этого.

Максимально высвободить место на сайте можно, спрятав навигацию во всплывающее меню. Такой подход логично использовать не только на мобильных устройствах, но и на десктопах. Ведь пользователю не нужно все время смотреть на то, какие рубрики есть на вашем сайте — он пришел за контентом. А желания пользователя нужно уважать.

Примером хорошего способа скрыть меню является следующий макет (фото ниже).

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

Впрочем, делать это необязательно, вы можете оставить навигацию, которая будет всегда на виду. Но ведь можно сделать это красивым дизайнерским элементом, а не просто перечнем популярных ссылок на сайте. Используйте интуитивно понятные иконки в дополнение к текстовым ссылкам или даже вместо них. Это также позволит вашему сайту более эффективно использовать экранное пространство на устройстве пользователя.

Лучший сайт — адаптивный

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

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

Чем отличается адаптивный дизайн от наличия разных версий у сайта

Адаптивный дизайн отличается от мобильной версии сайта тем, что в последнем случае пользователь получает html-код, который отличается от десктопного. Это является недостатком с точки зрения оптимизации производительности сервера, а также поисковой оптимизации. К тому же сложнее становится считать статистику по разным версиям сайта. Адаптивный подход лишен таких недостатков.

Адаптивность под различные устройства достигается за счет макета с процентным заданием ширины либо с помощью переноса блоков в доступное пространство (в вертикальной плоскости на смартфоне вместо горизонтальной на десктопе), либо же создания индивидуальных макетов под разные экраны.

Более подробно узнать об адаптивном дизайне и его разработке вы сможете из учебников.

Управление ограничениями размера хранилища для сайтов — SharePoint in Microsoft 365

• 27.03.2021
• Чтение занимает 6 мин

В этой статье

Объем места в хранилище Microsoft SharePoint для вашей организации зависит от количества лицензий (см. ограничения для SharePoint).The amount of Microsoft SharePoint space your organization has is based on your number of licenses (see SharePoint Limits). Если вы являетесь глобальным администратором в Microsoft 365, вы можете добавить место в хранилище для вашей подписки, если останется недостаточно места.If you’re a global admin in Microsoft 365, you can Add storage space for your subscription if you run out.

Просмотр полного и свободного места в хранилище для вашей организацииView the total and available storage space for your organization

1. Перейдите на страницу «Активные сайты» в новом Центре администрирования SharePoint и войдите, используя учетную запись с правами администратора в вашей организации.Go to the Active sites page of the new SharePoint admin center, and sign in with an account that has admin permissions for your organization.

2. В правом верхнем углу страницы отображается объем места в хранилище, используемый всеми сайтами, и общий объем хранилища, доступный для вашей подписки. In the upper right of the page, see the amount of storage used across all sites, and the total storage for your subscription. (Если в вашей организации настроена поддержка нескольких регионов в Microsoft 365, то на этой панели также отображается объем места в хранилище, использованный во всех географических расположениях.)(If your organization has configured Multi-Geo in Microsoft 365, the bar also shows the amount of storage used across all geo locations.)

   Примечание

   Значение используемого объема хранилища не учитывает изменения, сделанные за последние 24–48 часов.The storage used doesn’t include changes made within the last 24-48 hours.

Настройка автоматических или ручных ограничений размера хранилища для сайтовSet automatic or manual site storage limits

По умолчанию хранилище SharePoint доступно в виде центрального пула, место в котором могут занимать все сайты.By default, your SharePoint storage is available in a central pool from which all sites can draw. Глобальному администратору SharePoint нет необходимости перераспределять место в хранилище в соответствии с его использованием.You, as a global or SharePoint admin, don’t need to divvy up storage space or reallocate space based on usage. Это происходит автоматически: сайты используют столько места, сколько им требуется.That’s all handled automatically: sites use what they need when they need it. Если ранее вы настроили ограничения вручную, а затем перешли на использование пула, все ограничения в SharePoint будут сброшены на 25 ТБ (25 600 ГБ).If you previously set storage limits manually and switch to using pooled storage, SharePoint resets all the limits to 25 TB (25600 GB). (Обратите внимание, что общий объем хранилища для вашей организации может быть меньше 25 ТБ.)(Note that the total storage for your organization might be less than 25 TB.)

Если вы предпочитаете точно настраивать место в хранилище, выделенное каждому сайту, можно выбрать ручное управление хранилищем и указать ограничения для отдельных сайтов. If you prefer to fine tune the storage space allocated to each site, you can set your storage management option to «manual» and specify individual site storage limits.

Примечание

Некоторые функции постепенно развертываются в организациях, выбравших целевой выпуск в Microsoft 365.Some functionality is introduced gradually to organizations that have opted in to the Targeted release option in Microsoft 365. Это означает, кто некоторые функции, описанные в этой статье, могут отсутствовать или выглядеть иначе.This means that you might not yet see some features described in this article, or they might look different.

1. Перейдите на страницу «Параметры» в новом Центре администрирования SharePoint и войдите, используя учетную запись с правами администратора в вашей организации.Go to the Settings page of the new SharePoint admin center, and sign in with an account that has admin permissions for your organization.

2. Выберите Размеры хранилища для сайтов. Select Site storage limits.

3. Выберите Автоматически или Вручную, затем нажмите кнопку Сохранить.Select Automatic or Manual, and then select Save.

Управление ограничениями размера хранилища для отдельного сайтаManage individual site storage limits

Выполните эти действия, чтобы указать ограничения хранилища для отдельного сайта, если используется ручное управление хранилищем.Follow these steps to specify individual site storage limits when your storage management option is set to «manual.» Рекомендуется также настроить оповещение по электронной почте, чтобы вы и другие администраторы сайта получали уведомления о приближении размера сайтов к предельному.We recommend that you also set an email alert so that you and other site admins can be notified when sites are nearing the storage limit. Сведения об установке ограничений хранилища по умолчанию для новых сайтов см. в статье Управление созданием сайтов.To learn how to set the default storage limit for new sites, see Manage site creation.

1. Перейдите на страницу «Активные сайты» в новом Центре администрирования SharePoint и войдите, используя учетную запись с правами администратора в вашей организации.Go to the Active sites page of the new SharePoint admin center, and sign in with an account that has admin permissions for your organization.

2. Выберите сайт, затем выберите Хранилище.Select a site, and then select Storage.

3. Введите максимальный размер хранилища сайта в гигабайтах.Enter the maximum storage in GB for the site.

   Примечание

   Максимальное допустимое значение составляет 25 600 ГБ, но размер хранилища вашей организации может быть меньше.The max value you can enter is 25600 GB, although this may be more space than your organization has. Чтобы узнать, как рассчитывается общий объем вашего хранилища, см. Ограничения SharePoint.To learn how your total storage is calculated, see SharePoint Limits.

   При настройке ограничений размера хранилища с помощью PowerShell можно ввести значения в мегабайтах.If you set site storage limits in PowerShell, you enter them in MB. Значения преобразуются и округляются в меньшую сторону до ближайшего целого числа, чтобы в Центре администрирования SharePoint отображалось значение в гигабайтах.The values are converted and rounded down to the nearest integer to appear in GB in both the SharePoint admin center. Например, значение 5000 МБ превращается в 4 ГБ.So a value of 5000 MB becomes 4 GB. Минимальный размер хранилища составляет 1 ГБ. Если задать значение меньше 1024 МБ с помощью Windows PowerShell, это значение будет округлено до 1 ГБ.The minimum storage limit is 1 GB, so if you set a value of less than 1024 MB by using PowerShell, it will be rounded up to 1 GB.

4. Убедитесь, что включены уведомления, чтобы администраторы сайта получали сообщения электронной почты, когда объем данных в хранилище сайта приближается к предельному. Make sure Notifications is turned on to send an email to site admins when the site approaches the storage limit. Затем введите процентное значение заполнения хранилища для отправки таких сообщений электронной почты.Then, enter a value as a percent for how full you want the storage to be when the email is sent.

5. Нажмите Сохранить.Select Save.

Если в хранилище сайта закончится свободное место, администраторы сайта могут запросить дополнительное место в хранилище, выполнив следующие действия:If a site runs out of storage, site admins can request more by following these steps:

1. Вернитесь на страницу «Параметры сайта».Go to the Site Settings page.
2. В разделе Администрирование семейства веб-сайтов выберите Метрики хранилища.Under Site Collection Administration, select Storage Metrics.
3. Выберите Запросить дополнительную квоту в правом верхнем углу. Select Request more quota in the upper right.

При этом сообщение электронной почты с запросом места в хранилище будет отправлено глобальным администраторам и администраторам SharePoint в организации.This sends a storage request email to the global and SharePoint admins in the organization.

Отслеживание ограничений размера хранилища сайта с помощью PowerShellMonitor site storage limits by using PowerShell

При ручном управлении ограничениями хранилища необходимо регулярно отслеживать их, чтобы убедиться, что они не влияют на производительность сайта.If you manage storage limits manually, you need to regularly monitor them to make sure they aren’t affecting site performance. Рекомендуется также настроить собственные оповещения по электронной почте, чтобы уведомлять администраторов сайтов до того, как размер сайта достигнет предельного.We recommend that you also set up your own alert emails to notify site admins before a site reaches the limit. Встроенные сообщения электронной почты с предупреждениями о квоте обычно отправляются еженедельно для сайтов, достигших заданного уровня.The built-in storage quota warning emails are typically sent weekly for sites that have reached the specified warning level. Вследствие этого администраторы сайтов зачастую слишком поздно получают электронные сообщения с предупреждениями о достижении квоты хранилища.So site admins often receive the storage quota warning email too late. Например, если для задания таймера предупреждения о дисковой квоте (это задание приводит к отправке предупреждения) запланирован еженедельный запуск по воскресеньям, но ограничение квоты будет достигнуто в понедельник, администратор сайта получит сообщение электронной почты с предупреждением только через 6 дней.For example, if the Disk Quota Warning timer job (which triggers the warning email) is scheduled weekly and sends the email warning every Sunday, but a site reaches the quota warning limit on Monday, the site admin doesn’t receive the alert email for 6 days. В этом случае может быть достигнут предельный размер хранилища, а сайт станет доступным только для чтения, прежде чем администратор сайта получит предупреждение.This site could reach the maximum storage limit and be set to read-only before the site admin receives the alert email.

Для мониторинга сайтов можно использовать следующий сценарий Microsoft PowerShell.You can use the following Microsoft PowerShell script to monitor your sites. Этот сценарий получает все данные, а затем создает и отправляет администратору сайта предупреждения о хранилище.This script pulls the data, composes, and then sends a storage warning alerts to the site admin.

1. Скачайте последнюю версию командной консоли SharePoint Online.Download the latest SharePoint Online Management Shell.

   Примечание

   Если вы установили предыдущую версию командной консоли SharePoint Online, перейдите к разделу «Установка и удаление программ» и удалите компонент «Командная консоль SharePoint Online».If you installed a previous version of the SharePoint Online Management Shell, go to Add or remove programs and uninstall «SharePoint Online Management Shell. «

   На странице Центра загрузки выберите нужный язык и нажмите кнопку «Скачать».On the Download Center page, select your language and then click the Download button. Вам будет предложено скачать версию x64 или x86 файла MSI.You’ll be asked to choose between downloading a x64 and x86 .msi file. Для 64-разрядной версии Windows скачайте файл x64, а для 32-разрядной — файл x86.Download the x64 file if you’re running the 64-bit version of Windows or the x86 file if you’re running the 32-bit version. Если вы не знаете свою разрядность, см. статью Какая у меня версия операционной системы Windows?If you don’t know, see Which version of Windows operating system am I running?. После скачивания файла запустите его и следуйте инструкциям мастера настройки.After the file downloads, run it and follow the steps in the Setup Wizard.

2. Подключите SharePoint, используя права глобального администратора или администратора SharePoint в Microsoft 365.Connect to SharePoint as a global admin or SharePoint admin in Microsoft 365. Сведения о том, как это сделать, см. в статье Начало работы с командной консолью SharePoint Online.To learn how, see Getting started with SharePoint Online Management Shell.

3. Скопируйте следующий текст с объявлениями переменных и вставьте его в любой текстовый редактор, например в Блокнот.Copy the following text with the variable declarations, and paste it into a text editor, such as Notepad. Необходимо задать входные значения, соответствующие вашей организации.You must set all of the input values to be specific to your organization. Сохраните файл, затем переименуйте его в «GetEmailWarning.ps1».Save the file, and then rename it «GetEmailWarning.ps1».

   Примечание

   Можно использовать любое другое имя файла, однако необходимо сохранить файл в текстовом формате ANSI с расширением PS1.You can use a different file name, but you must save the file as an ANSI-encoded text file with the extension .ps1.

   #Connect to SharePoint admin center using an admin account
   #Specify the URL to your SharePoint admin center site, e. g. https://contoso-admin.sharepoint.com
   
   $url = 'https://contoso-admin.sharepoint.com'
   
   #Specify a folder path to output the results into
   $path = '.\'
   
   #SMTP details
   $Smtp = '<SmtpServer>'
   $From = '<SenderEmailAddress>'  
   $To = '<RecipientEmailAddress>'
   $Subject = 'Site Storage Warning'  
   $Body = 'Storage Usage Details'
   
   if($url -eq '') {
       $url = Read-Host -Prompt 'Enter the SharePoint admin center URL'
   }
   
   Connect-SPOService -Url $url
   
   #Local variable to create and store output file  
   $filename = (Get-Date -Format o | foreach {$_ -Replace ":", ""})+'.csv'  
   $fullpath = $path+$filename
   
   #Enumerating all sites and calculating storage usage  
   $sites = Get-SPOSite
   $results = @()
   
   foreach ($site in $sites) {
       $siteStorage = New-Object PSObject
   
       $percent = $site.StorageUsageCurrent / $site.StorageQuota * 100  
       $percentage = [math]::Round($percent,2)
   
       $siteStorage | Add-Member -MemberType NoteProperty -Name "Site Title" -Value $site.Title
       $siteStorage | Add-Member -MemberType NoteProperty -Name "Site Url" -Value $site. Url
       $siteStorage | Add-Member -MemberType NoteProperty -Name "Percentage Used" -Value $percentage
       $siteStorage | Add-Member -MemberType NoteProperty -Name "Storage Used (MB)" -Value $site.StorageUsageCurrent
       $siteStorage | Add-Member -MemberType NoteProperty -Name "Storage Quota (MB)" -Value $site.StorageQuota
   
       $results += $siteStorage
       $siteStorage = $null
   }
   
   $results | Export-Csv -Path $fullpath -NoTypeInformation
   
   #Sending email with output file as attachment  
   Send-MailMessage -SmtpServer $Smtp -To $To -From $From -Subject $Subject -Attachments $fullpath -Body $Body -Priority high
   

4. Где:Where:

   • $url — URL-адрес Центра администрирования SharePoint.$url is the URL of your SharePoint admin center. Если оставить переменную $url пустой, появится запрос на ввод URL-адреса сайта Центра администрирования.If the $url variable is left empty, you will be prompted to enter the URL of your admin center site.

   • $path — путь в файловой системе для вывода CSV-файла.$path is the file system path you want the CSV file to output to.

   • <SmtpServer> — имя почтового сервера средства миграции SharePoint.<SmtpServer> is the name of your SharePoint Migration Tool mail server.

   • <SenderEmailAddress> — учетная запись глобального администратора или администратора SharePoint, которая будет отображаться в строке «От» предупреждения, отправленного по электронной почте.<SenderEmailAddress> is the global admin or SharePoint admin account that appears in the From line in the warning email.

   • <RecipientEmailAddress> — учетная запись администратора, для которой будет отправляться предупреждение по электронной почте.<RecipientEmailAddress> is the admin account that will receive the email warning.

5. В командной консоли SharePoint Online перейдите в локальную папку, в которой сохранен файл сценария.In SharePoint Online Management Shell, change to the local directory where you saved the script file.

   ./GetEmailWarning.ps1
   

После успешного выполнения сценария в расположении, указанном переменной $path в сценарии, создается текстовый файл.After the script successfully completes, a text file is created in the location that you specified in the $path variable in the script.

Примечание

Если появится сообщение об ошибке, указывающее на невозможность выполнения сценариев, необходимо изменить политики выполнения.If you get an error message about being unable to run scripts, you might need to change your execution policies. Дополнительные сведения см. в статье Сведения о политиках выполнения.For info, see About Execution Policies.

Тестовая HTML-страница веб-сайта на размер в килобайтах

Рост среднего размера веб-страницы

Размер веб-страницы важен! Дело не в дизайне или тематике веб-сайта, это гораздо проще — все зависит от размера экрана монитора посетителей веб-сайта. Если веб-сайт не оптимизирован для каждого размера монитора, это автоматически раздражает пользователя, и поэтому очень важно сделать ваш веб-сайт удобным для просмотра с любого устройства, от огромного монитора до экрана небольшого мобильного телефона.

Первая веб-страница появилась в 1990 году. Добавление на веб-сайты всевозможных шрифтов, изображений, видео и файлов CSS / JS, а также с годами технического развития, размеры страниц значительно увеличились. Согласно информации, предоставленной httparchive.org, в 2010 году средний размер веб-страницы составлял 702 КБ, а в 2017 году — 3422 КБ.

Почему размер страницы сайта имеет значение

Если вы спрашиваете себя о правильном размере вашего веб-сайта, вы на правильном пути.На самом деле ширина страницы является ключевым фактором в дизайне веб-сайта. Если вы решили выбрать ширину, превышающую разрешение экрана пользователя, вскоре вы заметите, что веб-сайт не полностью помещается в браузере, и появится горизонтальная полоса прокрутки. В результате пользователь может не увидеть часть необходимой информации или ему будет неудобно работать с вашим проектом. Результат будет один — снижение поведенческих факторов.

Размер сайта напрямую влияет на скорость загрузки.Ускорение работы веб-сайтов важно не только для владельцев сайтов, но и для всех пользователей Интернета. Более быстрые сайты создают счастливых пользователей. Последние данные показывают, что повышение скорости сайта также снижает эксплуатационные расходы.
Google для веб-мастеров

С другой стороны, если вы установите слишком маленькую ширину, особенно если контентная часть вашего веб-сайта довольно тонкая, то, опять же, ваш веб-сайт будет выглядеть неудобно.

Давайте узнаем немного больше о размерах веб-сайтов из официальной статистики.Согласно последним данным, собранным в 2019, наиболее удобные размеры веб-страниц:

1. Статистика разрешения экрана рабочего стола по всему миру

Ширина x высота	1366 × 768	1920 × 1080	360 × 640	1440 × 900	1536 × 864	1600 × 900
Использование	22,7%	17,94%	7,8%	6,3%	5. 05%	4,55%

2. Статистика разрешения экрана мобильных устройств по всему миру

Ширина x высота	360 × 640	375 × 667	414 × 736	720 × 1280	360 × 720	320 × 568
Использование	33,54%	11,07%	5,15%	3,89%	3,67%	3,53%

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

Одна из таких функций — это возможность узнать разрешение экрана в пикселях. Разрешение экрана — это размер изображения, которое вы видите на своем мониторе, в точках (пикселях). Проще говоря, разрешение — это плотность этих точек на вашем экране в данный момент времени.Эта плотность измеряется шириной и высотой экрана.

Почему размер страницы увеличивается и как его уменьшить

Это можно объяснить рядом факторов, которые вносят значительный вклад в увеличение размера страницы. Ниже вы можете найти ключевые.

1. JavaScript

JavaScript был создан с целью добавить интерактивности HTML-страницам. JavaScript дает HTML-дизайнерам мощный, но удобный инструмент программирования.Хотя большинство дизайнеров HTML не имеют ничего общего с настоящим программированием, JavaScript упростил их работу еще больше, поскольку это язык сценариев с очень простым синтаксисом. Первая вариация появилась в 1995 году. Она многократно улучшалась, пока не достигла нынешней формы. Таким образом, это эффективный инструмент, который предоставляет дизайнерам следующие возможности и функции:

• Добавление или удаление тегов;
• Изменение стилей страниц;
• веб-игр;
• Информация об активности пользователя на странице;
• Внесение изменений в код;
• Анимация веб-страницы.

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

Сценарии могут замедлять загрузку страницы и влиять на размер страницы. Для решения этой проблемы веб-мастера используют опцию кеширования сайта. Это помогает сократить время между запросом пользователя и ответом сервера.

2.Изображения

Изображения являются основной причиной увеличения размера страницы за последние 7 лет. С годами изображения стали более частыми, и это одна из основных вещей, используемых для привлечения внимания пользователей. Люди редко находят статью интересной для чтения без изображений, и никто не собирается покупать вещь, не увидев примера того, как она выглядит.

Есть много инструментов для сжатия размера изображения, но оно сохраняет такое же высокое качество, что влияет на размер сайта:

Кроме того, форматы WebP и FLIF нацелены на дальнейшее уменьшение размера изображения и, таким образом, помогают уменьшить размеры веб-страниц.

3. Шрифты

Как шрифт может повлиять на скорость веб-страницы? Как и в случае с изображениями, качество шрифтов постоянно улучшалось, и теперь доступны миллионы разновидностей шрифтов для создания собственного стиля. Около 57% сайтов сейчас используют пользовательские шрифты. В 2017 году шрифты среднего сайта занимали около 113 КБ места, тогда как в 2010 году это число составляло всего 2 КБ. Шрифт очень важен для личного брендинга. Поскольку это влияет на размер страницы, вам необходимо выбрать шрифт, который не только будет соответствовать стилю вашего сайта и бренда, но и будет быстро загружаться.К счастью, есть решение, если вы уверены, что пользовательские шрифты важны для дизайна вашего веб-сайта: создание файла WOFF2.

Сколько шрифтов — это слишком много шрифтов? Основное правило гласит, что — это тройка, и лучше придерживаться двух.

4. Видео

Использование видео на веб-сайтах также с годами все больше растет. Видео часто используются для привлечения внимания аудитории, для презентации продукта и в качестве эффективного инструмента SEO.Однако качественное видео действительно влияет на размер сайта. За последние шесть лет размер среднего видео вырос до 174 КБ, и хотя он по-прежнему занимает примерно 7,7% от общего размера веб-сайта, вскоре это станет более серьезной проблемой, если сжатие видео не улучшится. Просто вставьте код iframe с YouTube, Vimeo и Amazon CloudFront, если хотите, чтобы ваш сайт загружался быстро. Используйте всю мощь этих мощных интернет-видео. Это их работа, и они хорошо с ней справляются.

5.Реклама

В современном мире реклама стала более сложной. Они больше не состоят из простого текста. Чтобы привлечь как можно больше внимания, менеджеры социальных сетей обычно добавляют в свою рекламу фотографии, анимацию или даже видео, что, естественно, увеличивает размер и время загрузки веб-сайта. Чтобы решить эту проблему, пользователь может использовать блокировщик рекламы, который может помочь уменьшить видимость рекламы (ваш браузер не будет загружать их), и, следовательно, скорость загрузки должна увеличиться в несколько раз.

Загрузка 16,3 МБ без блокировщика рекламы занимает около 33 секунд, в то время как использование блокировщика рекламы значительно сокращает время загрузки до 7 секунд и снижает вес до 3,5 МБ.
nytimes.com

Это особенно эффективно на мобильных устройствах или планшетах. Вам нужно следить за рекламой на сайте, чтобы увидеть, как она влияет на скорость. Отрегулируйте и измените объявления на своем веб-ресурсе, чтобы они занимали как можно меньше байтов и не увеличивали размер страницы. Или вы даже можете полностью удалить рекламу, если увидите, что она слишком сильно замедляет работу сайта.

Проверьте SEO-оценку вашего сайта

Проведите аудит своего сайта, чтобы определить, на каких страницах есть ошибки SEO, как их исправить и получить больше трафика

Размер веб-страницы на мобильных устройствах

По статистике, люди чаще пользуются мобильными устройствами. Только за последние два года количество пользователей мобильных устройств увеличилось на сотни миллионов по той причине, что гораздо быстрее и удобнее использовать телефоны и планшеты вместо ПК или ноутбука.

В идеале мобильная версия веб-сайта должна загружаться менее чем за 3 секунды, и чем быстрее, тем лучше. ОЧЕНЬ МЕДЛЕННЫЙ САЙТ может быть ОТРИЦАТЕЛЬНЫМ фактором ранжирования (подтверждено Google). Не существует установленного порога или показателя скорости, которому нужно соответствовать, просто чтобы сделать вашу страницу максимально быстрой.
Шон Андерсон

Это означает, что скорость страницы пострадает, если она не оптимизирована для мобильных устройств. Это жизненно важно для каждого сайта!

Проблемы мобильного проектирования

• Форма экрана. Экран смартфонов выше, чем в ширину, в отличие от настольного компьютера или ноутбука.
• Размер экрана. Различные модели смартфонов имеют разные размеры экрана, но обычно максимальная ширина для мобильного дизайна составляет 340 пикселей.
• Взаимодействие с пользователем. В сотовых телефонах нет мыши. Поэтому такие эффекты, как «размытие» или «размытие», не работают.
• Навигация. Большинство владельцев веб-сайтов хотят отображать верхнюю панель навигации во всю ширину.Однако в портретном режиме он не работает.
• Меньшая пропускная способность. Многие клиенты используют «данные» в городах или на природе, поэтому скорость Интернета у них может быть ниже. Иногда лучше заменить полноэкранное фоновое видео на мобильной версии вашего сайта.

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

Ваш сайт должен работать как можно быстрее. Для этого нужно сделать все возможное, чтобы сократить время загрузки для всех устройств: уделять больше внимания изображениям, так как они занимают большую часть (около 44%) от общего размера. Однако, чтобы соответствовать средним размерам веб-страницы, все аспекты (от шрифтов до рекламы) должны быть оптимизированы, как упоминалось выше — это очень важно не только для привлечения новых посетителей, но и для удержания внимания ваших постоянных клиентов и пользователей на долгое время. много лет.

Наталия Фиалковская

SEO специалист

Наталия — SEO-эксперт Sitechecker. Она отвечает за блог. Невозможно жить без создания ценного контента о SEO и цифровом маркетинге.

Каков идеальный размер экрана для адаптивного дизайна

По состоянию на 2020 год в мире насчитывается 3,5 миллиарда пользователей смартфонов. Это 45% населения Земли. По состоянию на 2019 год люди выходили в Интернет с более чем 9000 различных устройств. Каждый пользователь ожидает, что каждый веб-сайт, к которому он обращается, будет безупречно отображаться на его мобильном устройстве.Это означает, что разработчики веб-сайтов должны создавать веб-сайты, которые будут отображаться на экранах разных размеров по всему миру.

Другими словами, им нужен адаптивный дизайн.

Но, как знает каждый дизайнер, создание адаптивного дизайна должно начинаться со знания, для каких размеров экрана нужно проектировать. В этой статье исследуется этот вопрос и обсуждаются лучшие размеры scream для адаптивного дизайна.

Что такое адаптивный дизайн?

Адаптивный веб-дизайн относится к стратегии дизайна, которая создает веб-сайты, которые хорошо работают на мобильных, планшетных и настольных устройствах.Веб-сайты без адаптивного дизайна рискуют оттолкнуть значительное количество пользователей — 80% пользователей заявили, что они откажутся от веб-сайтов, которые не работают на их устройствах.

Кроме того, Google рассматривает «удобство для мобильных устройств» как параметр для ранжирования. Цитата из центрального блога Google для веб-мастеров,

«. Начиная с 21 апреля (2015 г.), мы будем расширять использование удобства для мобильных устройств в качестве сигнала ранжирования. Это изменение повлияет на мобильный поиск на всех языках мира и окажет значительное влияние на наши результаты поиска.Следовательно, пользователям будет проще получать релевантные высококачественные результаты поиска, оптимизированные для их устройств ».

Как найти идеальный размер экрана для адаптивного дизайна?

Примечание: Чтобы понять, почему адаптивный дизайн является неотъемлемой частью успеха веб-сайта, нужно понимать огромную и постоянно увеличивающуюся природу фрагментации устройств. Загрузите нашу электронную книгу о фрагментации устройств, чтобы получить самую свежую информацию об этом явлении.

Статистика разрешения экрана мобильных устройств по всему миру: январь 2020 г. — январь 2021 г.

Источник изображения

Обратите внимание на переход пользователей от экранов меньшего размера (360 * 640) со значительным падением с января 2020 г. по январь 2021 г.Несмотря на то, что это очень важный размер мобильного экрана, большая часть аудитории по-прежнему остается на нем. Хотите проверить, как ваш сайт выглядит в этом разрешении? Протестируйте сейчас.

Статистика разрешения экрана в мире: январь 2020 г. — январь 2021 г.

Источник изображения

Согласно мировой статистике разрешения экрана (январь 2020 г. — январь 2021 г.), наиболее часто используемые разрешения на мобильных устройствах, настольных компьютерах и планшетах: :

• 1920 × 1080 (8.89%)
• 1366 × 768 (8,44%)
• 360 × 640 (7,28%)
• 414 × 896 (4,58%)
• 1536 × 864 (3,88%)
• 375 × 667 (3,75%)

Бесплатный тест на отзывчивость на часто используемых разрешениях

Попробуйте проверить отзывчивость своего веб-сайта на реальных устройствах.

Конечно, упор на мобильность не означает отказа от настольных устройств. Как показано в таблице ниже, настольные устройства по-прежнему составляют значительную часть использования Интернета.

---

Знаете ли вы , как определять отзывчивые точки останова?

---

Доля рынка настольных компьютеров, мобильных и планшетов в мире: январь 2020 г. — январь 2021 г.

Источник изображения

Согласно документации Microsoft,

С огромным количеством целевых устройств и размеров экрана в экосистеме Windows 10 , вместо оптимизации пользовательского интерфейса для каждого устройства мы рекомендовали разработать несколько категорий ширины клавиш (также называемых «точками останова»):

• Маленький (меньше 640 пикселей)
• Средний (от 641 до 1007 пикселей)
• Большой (1008 пикселей и больше)

Несмотря на эту информацию, помните, что не существует стандартного размера экрана для веб-дизайна.В зависимости от характера веб-сайта пользователи могут использовать определенные устройства, которые не поддерживают указанные выше размеры и разрешения экрана. Чтобы определить правильный размер экрана для веб-дизайна, инвестируйте в аналитику. Узнайте, что ваша целевая аудитория, скорее всего, будет использовать. Если эти устройства не соответствуют вышеупомянутому разрешению, включите их в список.

Проверить скорость реакции веб-сайта бесплатно

---

Знаете ли вы: Как протестировать свой веб-сайт на экранах разных размеров с помощью бесплатных инструментов? Выяснить.

---

Лучшие практики для реализации адаптивного дизайна

Становится намного проще разработать веб-сайт для нескольких размеров экрана, следуя следующим рекомендациям:

• Знайте свои точки останова : В адаптивном дизайне точка останова — это «точка» », При котором содержание и дизайн веб-сайта будут адаптироваться определенным образом, чтобы обеспечить наилучшее взаимодействие с пользователем. Чтобы сделать веб-сайт адаптивным, дизайнеры должны добавить точку останова, когда контент выглядит смещенным.В зависимости от количества устройств, на которые выравнивается сайт, необходимо установить несколько точек останова, чтобы обеспечить его отзывчивость. Обратитесь к этой статье об адаптивных точках останова, чтобы подробно узнать о них и их эффективности.
• Создание гибких дизайнов : Гибкий дизайн — это макет дизайна, который может сдвигаться (расширяться и сжиматься), чтобы соответствовать области просмотра устройства, на котором он работает. Фиксированный макет дизайна будет нежелательно искажать каждый видовой экран, по которому они не выровнены. Работайте над макетами дизайна, используя% единиц, а также максимальную ширину, чтобы макет соответствовал видовым экранам мобильного устройства, не становясь слишком широким на видовых экранах настольных устройств.
• Уменьшение трения : Это в основном означает, что конструкция должна быть простой в использовании на нескольких устройствах. Адаптивный дизайн включает не только то, как выглядит веб-сайт, но и то, как он работает с точки зрения доступности и удобства использования. Сосредоточьтесь особенно на трении на маленьком экране, потому что по мере уменьшения размеров экрана веб-элементы имеют меньше места для рендеринга и с большей вероятностью будут скремблироваться и искажаться.
• Design Mobile-First : Поскольку трение более вероятно на небольших экранах, проектируйте с подходом, ориентированным на мобильные устройства.Сложнее сузить макет рабочего стола для мобильного окна просмотра, тогда как сделать наоборот проще. При проектировании, ориентированном на мобильные устройства, дизайнер включает в себя все, что абсолютно необходимо для обеспечения оптимального взаимодействия с пользователем.

Вот несколько способов адаптировать дизайн, ориентированный на мобильные устройства, к большему количеству экранов:

1. Расставить приоритеты по важным параметрам меню
2. Убрать все визуальные отвлекающие факторы
3. Оптимизировать дизайн для удобного касания — все легко нажимать
4. Удалите ненужные формы и информационные поля
5. Выделите основной CTA
6. Заметно предложите функции поиска и фильтрации

• Больше функциональности, меньше набора : Очевидно, печатать на мобильных устройствах сложнее, чем на настольных.Поэтому имеет смысл свести к минимуму необходимость набора текста на мобильных версиях веб-сайтов. Замените набор текста сознательным использованием функций устройства, таких как GPS, считывание QR-кода, биометрическое удостоверение личности и т. Д. Сделайте так, чтобы пользователям было проще делиться информацией, писать по электронной почте или звонить по соответствующим номерам, разместив ссылки, запускающие необходимые функции. Имейте в виду, что лучший адаптивный дизайн предполагает упрощение и устранение неудобных мобильных взаимодействий.
• Тестировать, тестировать, тестировать : как только разработчик или дизайнер знает, какие размеры экрана лучше всего подходят для адаптивного дизайна, он выполняет работу и создает адаптивный веб-сайт.Однако, чтобы убедиться, что веб-сайт действительно отображается так, как задумано, на устройствах, для которых он был создан, его необходимо протестировать именно на это. Легкий способ сделать это — использовать средство проверки адаптивного дизайна. Вместо того, чтобы запускать веб-сайт через отдельные устройства с разными окнами просмотра, введите URL-адрес в средство проверки и посмотрите, как он отображается на множестве новейших устройств при разном, часто используемом разрешении устройства. Приведенная выше программа проверки предлагает отзывчивую проверку на последних мобильных устройствах, таких как iPhone X, Galaxy Note 10, iPhone 8 Plus и других.Кроме того, используйте облако BrowserStack, чтобы проверить, как веб-сайт отображается на тысячах мобильных и настольных устройств. Просто зарегистрируйтесь бесплатно, выберите необходимое устройство, перейдите на веб-сайт и проверьте, как оно выглядит в реальных условиях пользователя.

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

Попробуйте адаптивную проверку бесплатно

Средний размер веб-страницы составляет 3 МБ. Насколько мы должны заботиться?

СРЕДА 9 АВГУСТА 2017

Пару месяцев назад кто-то спросил, писал ли я недавно обновление для раздуваемых страниц. Ответ был отрицательным. Я написал много сообщений о раздувании страниц еще в 2012 году, когда средняя страница составляла 1 МБ. На мой взгляд, тема была хорошо освещена. Мы знаем, что общая тенденция заключается в том, что страницы становятся больше с довольно постоянной скоростью роста.Не было ощущения, что есть много новой территории, которую нужно покрыть.

Также: мне показалось, что Илья Григорик уронил микрофон на страницу раздутой беседы с этим классным постом, где он проиллюстрировал, почему «средняя страница» — это миф. Среди многих вещей, которые Илья заметил после анализа данных HTTP-архива для настольных сайтов, когда у вас есть выбросы, которые весят более 30 МБ и более 90% ваших страниц имеют размер менее 5 МБ, «средний размер страницы» 2227 КБ (в 2016 году) не соответствует не значит много.

Микрофон упал.Мы все какое-то время смотрели на него на полу, а затем пошли прочь. А теперь я хочу предложить бродить обратно. Почему? Потому что средняя страница теперь имеет размер 3 МБ, и похоже, что сейчас хорошее время, чтобы остановиться, проверить наши предположения и спросить себя:

Есть ли причина учитывать размер страницы как показатель производительности? А если мы не считаем размер страницы значимой метрикой, о чем нам следует заботиться?

Прежде чем мы углубимся в эту тему (снова), несколько важных замечаний

• Средние значения, которые мы собираемся рассмотреть, взятые из HTTP-архива, — это всего лишь средние значения для больших наборов данных. Они не представляют «типичный» веб-сайт, потому что не существует такого понятия, как типичный веб-сайт.
• Эти числа в основном уместны, если рассматривать их в историческом контексте. Они представляют тенденции — вот и все.
• Эти числа ни в коем случае не должны даже удаленно использоваться в качестве эталона для вашего собственного сайта. Вы не обязательно достигли чего-то великого, если ваши страницы меньше этого, и вы не потерпели неудачу, если ваши страницы больше.
• Не все страницы становятся больше. Многие стали меньше с годами. Может быть, ваш один из них!

Графики или этого не было, правда?

Здесь вы можете увидеть рост страницы с 2011 по настоящее время с разбивкой по типам контента:

Первое, что бросается в глаза, — это большого объема страницы, занимаемой видео . Это не большой сюрприз, учитывая популярность видеороликов о героях и тому подобное, но все же интересно отметить, что это, похоже, составляет большую часть недавнего роста.

Использование пользовательских шрифтов продолжает расти : 69% из 500 000 лучших веб-сайтов используют их. Интересно отметить падение общего количества килобайт в 2016 году.

Интересно построить график некоторых текущих данных HTTP-архива (ниже) и посмотреть, какие показатели остаются неизменными относительно размера страницы, а какие — нет.

Вы можете видеть выше, что начало рендеринга довольно согласовано независимо от размера страницы .Это довольно интересно, потому что предполагает, что большие страницы не обязательно связаны с тем, когда пользователи начинают видеть контент.

Кроме того, вы также можете увидеть, насколько легко ввести в заблуждение onload как показатель производительности, потому что он так сильно коррелирует с размером страницы. На этом графике резкий рост загрузки немного скрывает тот факт, что индекс скорости имеет довольно значительную тенденцию к росту — с 2393 (~ 2,4 секунды) для страниц в когорте 500 КБ до 10266 (~ 10,3 секунды) для страниц в когорте 20 МБ.Это служит хорошим напоминанием о том, что Speed ​​Index — это, как правило, надежный синтетический показатель для пользовательского опыта .

Прогноз: 4 МБ страниц к 2019 г.?

Я предлагаю это как интересную тему для разговора, а не как повод для паники. Если предположить, что размер страницы увеличится примерно на 16% по сравнению с прошлым годом, средняя страница может превысить 4 МБ всего за два года.

Но опять же, возвращаясь к мысли Ильи, это всего лишь средний показатель. Страницы размером 4 МБ уже здесь.Согласно HTTP-архиву , сегодня почти 16% страниц — другими словами, примерно 1 из 6 страниц — имеют размер или более 4 МБ. Я обычно вижу страницы (и я уверен, что вы тоже) размером 10 МБ или больше. Когда я говорил об этой проблеме с Марком и Стивом, Марк сослался на тот факт, что он создавал страницы размером 30 МБ, которые все еще были высокопроизводительными.

Если вы заботитесь о пользовательском опыте, размер страницы — не тот показатель, который нужно отслеживать.

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

Возьмем, к примеру, Amazon. Он широко считается лидером в производительности, но при этом имеет относительно тяжелые страницы (я определяю «тяжелые» как 3 МБ или более) и медленное время загрузки (я определяю «медленные» как 5 секунд или более). Но для Amazon размер страницы и время загрузки — это неправильные показатели.

Например, глядя на эту недавнюю страницу результатов теста для домашней страницы Amazon (которая весит чуть более 5 МБ), вы можете увидеть время начала рендеринга 1,4 секунды и хорошо заполненное окно просмотра на 2.5 секунд — несмотря на то, что страница не загружается полностью до 18,8 секунды.

(Если вы еще не являетесь пользователем SpeedCurve и хотите поработать с панелью синтетического мониторинга SpeedCurve, ознакомьтесь с нашей демо-учетной записью, которая позволяет вам просматривать данные для нескольких медиа-сайтов, включая The Guardian, Huffington Post и The New York Times. Еще лучше, подпишитесь на бесплатную пробную версию и попробуйте SpeedCurve. )

На вынос

1.Размер страницы имеет значение, но, возможно, не так, как вы думаете

У вас могут быть большие, надежные страницы, которые по-прежнему выглядят быстро. Но вы должны заботиться о раздутии страниц с точки зрения того, как это влияет на мобильных пользователей, особенно мобильных пользователей, которые имеют дело с ограничениями полосы пропускания или ограничениями данных. На Fluent в июне этого года Тим Кадлек выступил со страстным докладом, посвященным этой проблеме. Вы также должны проверить изящный онлайн-калькулятор Тима, который рассчитывает стоимость ваших страниц в странах по всему миру в долларах.Это откровение.

Что вы можете сделать: Если вы не используете активно бюджеты производительности для установки пороговых значений для таких показателей, как размер страницы, начало рендеринга и индекс скорости, вам следует начать. Мне нравится это короткое поясняющее видео, которое объясняет, как работают бюджеты производительности.

2. Беспокойство по поводу изображений, но не слишком

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

Что вы можете сделать: Находите и исправляйте проблемные изображения на своих страницах.

3. Беспокойство о CSS и JavaScript

Если вы обслуживаете асинхронные версии ваших таблиц стилей и скриптов, вы должны знать, что они могут полностью заблокировать ваши страницы, потому что они сильно загружают процессор.

Что вы можете сделать: Асинхронные сценарии лучше синхронных, но есть аргумент в пользу откладывания сценариев (если вы можете с этим справиться).И если вы еще не измеряете использование ЦП, подумайте о том, чтобы начать сейчас.

4. Если вы заботитесь об оценке пользовательского опыта, используйте специальные показатели.

Корреляция размера страницы с пользовательским опытом — это все равно, что представить кому-то полный фуршет и предположить, что он представляет собой то, что они на самом деле ели. Чтобы правильно измерить пользовательский опыт, нам нужно сосредоточиться на контенте — таком как навигационная панель или изображение главного продукта — которые пользователи действительно хотят использовать. Лучшая метрика производительности для измерения взаимодействия с пользователем — это показатель, который измеряет, как долго пользователь ждет, прежде чем увидит этот важный контент.

Что вы можете сделать: Здесь на помощь приходят настраиваемые таймеры через спецификацию W3C User Timing. Чтобы реализовать настраиваемые таймеры, вам необходимо идентифицировать критически важный контент на ваших страницах, а затем добавлять метки и меры для отслеживания, когда они отображаются . Стив написал отличное сообщение в блоге, в котором более подробно рассматриваются настраиваемые таймеры, а также приводится несколько примеров показателей, которые помогут вам начать работу. Если вам интересно измерение UX, я настоятельно рекомендую это проверить.

Подводя итоги …

Мы, сотрудники SpeedCurve, не думаем, что вам нужны дополнительные данные о производительности. Мы думаем, что вам нужны правильные данные о производительности. Вот почему мы всегда работаем над разработкой показателей, которые дадут вам осмысленное представление о том, как пользователи воспринимают ваш сайт. Именно поэтому мы считаем, что установка бюджетов производительности и предупреждений для этих показателей имеет решающее значение. (Если вы еще не используете SpeedCurve для мониторинга производительности своего сайта, настройте бесплатную пробную версию здесь .)

Ключом к хорошему пользовательскому опыту является быстрая доставка критически важного контента. Это легко сказать, но исторически было сложно сделать.Пользовательские метрики — огромный шаг вперед в эволюции. Если вы используете специальные метрики, мне бы хотелось услышать, как они работают на вас и чему вы на них учитесь. И если вы не используете специальные метрики, мне любопытно узнать, какие препятствия для вас существуют.

комментарии предоставлены

Как определить размер веб-страницы — глобальное предупреждение

Я много говорю о размере веб-страницы. Но что это значит? Позвольте мне объяснить и показать вам, как вы можете проверить это самостоятельно.

Размер веб-страницы — это размер файлов, загружаемых для отображения страницы. Может быть разница между передаваемым размером и фактическим размером файлов (скажем, в разархивированном виде), но вы можете найти больше об этом в статье «Создание».

Есть 2 способа проверить размер веб-страницы:

1. Использование онлайн-инструмента
2. Использование консоли вашего браузера

Давайте рассмотрим оба аспекта более подробно.

Проверить онлайн

Существуют онлайн-инструменты для проверки размера веб-страницы.Например, вы можете сделать это с помощью https://tools.pingdom.com. Введите или вставьте URL-адрес страницы, которую хотите проверить, и готово. Вы получите много данных, среди которых размер страницы.

Я сделал это для этой страницы и получил 23 кб. Точные значения могут отличаться в зависимости от инструмента и второго метода, указанного ниже. Однако различия будут относительно небольшими, особенно для больших страниц. Вы будете иметь представление о том, маленькая это страница или большая.

Проверьте это в своем браузере

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

1. Во-первых, пойдем инкогнито. В вашем браузере могут быть некоторые расширения или надстройки, которые также загружают файлы. Обычно они отключены в режиме инкогнито.
2. Щелкните правой кнопкой мыши и выберите опцию Проверить элемент или что-то подобное. Это откроет дополнительное окно или боковую панель с информацией о HTML-структуре веб-страницы.
3. В дополнительном окне есть несколько вкладок. Вам нужен тот, который называется Network .Обязательно отключите кеш браузера — обычно это значение по умолчанию — чтобы ваш браузер загружал все без ошибок.
4. Обновить страницу.
5. Внизу окна вы найдете результат, который искали. Вероятно, есть 2 значения, которые могут быть одинаковыми в зависимости от того, произошла ли передача в специальном заархивированном формате или нет:
   • Размер передачи : это количество фактически переданных файлов. Это то, что вы хотели знать, потому что это имеет наибольшее влияние, поскольку эта сумма передается с сервера.
   • Размер ресурсов: это фактический размер файлов, используемых для создания страницы.

Размер этой страницы

Хорошо, это своего рода начало, но я проверил размер передаваемых файлов для этой страницы в Google Chrome, и он дал мне 16 КБ. В Firefox это было 23 кб, а в Edge 13 кб. Могут быть значительные различия, особенно при небольших размерах страниц. Некоторые браузеры загружают одни ресурсы, а другие — нет. Firefox загружает, например, 2 дополнительных изображения, чтобы использовать их на своем домашнем экране для посещаемых сайтов.Тем не менее, вы получаете представление о размере страницы относительно среднего значения более 2000 КБ.

Некоторые примеры из жизни

А теперь несколько примеров из жизни. Я проверил размер передачи для домашней страницы 5 популярных сайтов (и Гринпис). Я использовал второй метод, используя Google Chrome на настольном компьютере без прокрутки.

Большинство страниц довольно большие.

Конечно, они содержат много изображений и скриптов, но даже страница поиска Google занимает 380 кб.Это означает, что каждый раз, когда вы посещаете google.com, в атмосферу выбрасывается 0,21 г CO ₂ e. Узнайте больше о выбросах углерода на веб-страницах и о том, как их уменьшить.

Я позволю вам произвести вычисления для других, более крупных страниц. Вот почему я считаю, что размер страницы имеет значение.

Размер этой страницы загружается примерно в 22 кб.

Автор Чаба Варшеги

Чаба — минималистичный веб-разработчик в LittleBigThings и автор этого небольшого блога.Он любит проектировать и создавать вещи. Он ведет блог в основном о WordPress, а также вносит свой вклад в него. Ему нравится находить удовольствие и цель в повседневной жизни, например, думать, что этот блог внесет свой вклад в спасение планеты.

Csaba опубликовал 11 сообщений

Просмотреть все сообщения Csaba Varszegi

Размер сайта и рекомендации по производительности — Configuration Manager

• 13.04.2021
• 17 минут на чтение

В этой статье

Применимо к: Configuration Manager (текущая ветвь)

Configuration Manager лидирует в отрасли по масштабированию и производительности.Другая документация охватывает максимальные поддерживаемые пределы масштабирования и рекомендации по оборудованию для работы сайтов с самыми большими размерами среды. В этой статье приведены дополнительные рекомендации по производительности для сред любого размера. Это руководство может помочь вам более точно оценить оборудование, необходимое для развертывания Configuration Manager.

В этой статье основное внимание уделяется основным факторам, влияющим на производительность Configuration Manager: подсистеме ввода-вывода диска или IOPS.

• Представлены подробные сведения и результаты тестирования, ориентированные на IOPS
• Документирует, как воспроизвести тесты в ваших собственных средах и оборудовании
• Предлагает требования к количеству операций ввода-вывода в секунду для дисковых сред различного размера

Методика проверки работоспособности

Вы можете развернуть Configuration Manager множеством уникальных способов, но при любом обсуждении размеров важно понимать несколько переменных.Одна переменная — это интервал функций , например цикл инвентаризации. Другая переменная — это количество пользователей, развертываний программного обеспечения или других объектов , на которые система ссылается или развертывает. Тестирование производительности применяет эти переменные как часть нагрузки . Нагрузка генерирует объекты с типичной скоростью для корпоративных клиентов, использующих производственные развертывания в средах разного размера.

Примечание

Данные об использовании клиентов позволяют тестировать текущие сборки филиалов с наиболее распространенными сценариями, конфигурациями и настройками для большинства клиентов.Рекомендации в этой статье основаны на этих средних значениях. Ваш опыт может отличаться в зависимости от размера и конфигурации вашей среды. В общем, Configuration Manager требует здравого смысла, когда дело касается объектов и интервалов. То, что вы можете собрать каждый файл в системе или установить интервал цикла равным одной минуте, не означает, что вы должны это делать.

В следующих разделах выделены некоторые ключевые параметры и конфигурации, которые следует использовать при тестировании и моделировании обработки потребностей для крупных предприятий.Эти рекомендации помогают установить базовую ожидаемую производительность системы для предлагаемых размеров оборудования.

Настройки интервалов между объектами

В большинстве случаев тестирования следует использовать интервалы по умолчанию для ключевых циклов в системе. Например, проверка инвентаризации оборудования выполняется один раз в неделю с файлом, размер которого превышает значение по умолчанию .mof . Некоторые повторяющиеся интервалы между функциями, особенно циклы инвентаризации оборудования и программного обеспечения, могут существенно повлиять на характеристики производительности среды.Средам, которые позволяют использовать агрессивные интервалы по умолчанию для сбора данных, требуется оборудование большого размера прямо пропорционально увеличению активности. Например, предположим, что у вас есть 25 000 клиентов для настольных ПК, и вы хотите провести инвентаризацию оборудования в два раза быстрее, чем интервал по умолчанию. Начните с определения размера оборудования вашего сайта, как если бы у вас было 50 000 клиентов.

Объектов

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

Грузы

Тесты

также должны выполняться при нагрузках, превышающих стандартные , средние дневные нагрузки , путем моделирования, генерирующего пиковые нагрузки на систему.Одним из примеров является моделирование развертывания патчей во вторник, чтобы система могла своевременно возвращать обновленные данные о соответствии в эти дни пиковой активности. Другой пример — моделирование активности сайта во время широко распространенной эпидемии вредоносного ПО, чтобы гарантировать своевременное уведомление и ответ. Хотя развернутые машины рекомендуемого размера могут не использоваться в любой день, в более экстремальных ситуациях требуется некоторый буфер обработки.

Конфигурации

Выполните тестирование на различном физическом оборудовании, оборудовании Hyper-V и Azure, используя различные поддерживаемые операционные системы и версии SQL Server.Всегда проверяйте худшие случаи для поддерживаемой конфигурации. Как правило, Hyper-V и Azure возвращают сопоставимые результаты производительности для эквивалентного физического оборудования при одинаковой настройке. Текущие серверные операционные системы, как правило, имеют производительность, равную или лучше, чем более ранние версии ОС. Хотя все поддерживаемые платформы соответствуют минимальным требованиям, обычно последние версии поддерживающих продуктов, таких как Windows и SQL Server, обеспечивают даже лучшую производительность.

Наибольшая вариация связана с используемыми версиями SQL Server.Дополнительные сведения о версиях SQL Server см. В разделе Какую версию SQL Server следует запускать ?.

Ключевые факторы эффективности

Вы можете тестировать и измерять производительность Configuration Manager с разными типами настроек, разными способами и на разных размерах сайта. Следующие настройки и объекты могут существенно повлиять на производительность. Обязательно учитывайте их при тестировании и моделировании производительности в вашей среде.

Осторожно

Хотя некоторые аспекты Configuration Manager имеют официальные максимумы или ограничения пользовательского интерфейса, которые предотвращают чрезмерное использование, выход за рамки рекомендаций может иметь значительные неблагоприятные последствия для производительности сайта.Превышение рекомендуемых уровней или игнорирование рекомендаций по выбору размеров обычно требует более крупного оборудования и может сделать вашу среду недоступной до тех пор, пока вы не уменьшите частоту или количество различных объектов.

Инвентаризация оборудования

Для проверки базовой производительности установите сбор инвентаризации оборудования один раз в неделю с размером файла по умолчанию .mof плюс примерно 20% других свойств. Не включайте все свойства, а собирайте только те свойства, которые вам действительно нужны. Уделите особое внимание при сборе свойств, таких как доступная виртуальная память, которая будет всегда меняться на каждый цикл инвентаризации .Сбор этих свойств может вызвать чрезмерный отток в каждом цикле инвентаризации от каждого клиента.

Инвентаризация программного обеспечения

Чтобы проверить базовую производительность, установите сбор данных инвентаризации программного обеспечения один раз в неделю, только для продукта и сведений. Сбор большого количества файлов может создать значительную нагрузку на подсистему инвентаризации. Избегайте указания фильтров, которые могут привести к сбору тысяч файлов на многих клиентах, таких как * .exe или * .dll .

Коллекции

Базовое тестирование производительности может включать несколько тысяч коллекций с разным объемом, размером, сложностью и настройками обновления.Производительность сайта не зависит напрямую от количества коллекций на сайте. Производительность также является перекрестным продуктом сложности запросов коллекций, полных и инкрементных обновлений и частоты изменений, зависимостей между коллекциями и количества клиентов в коллекциях.

По возможности минимизируйте коллекции, содержащие дорогие или сложные запросы динамических правил. Для коллекций, для которых требуются эти типы правил, установите соответствующие интервалы обновления и время обновления, чтобы минимизировать влияние повторной оценки коллекции на систему.Например, обновите в полночь, а не в 8:00.

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

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

Коллекции только с правилами прямого членства и с ограничивающей коллекцией, в которой не выполняются инкрементные обновления, не нуждаются в запланированных полных обновлениях.Отключите расписания обновлений для этих типов коллекций, чтобы предотвратить ненужную нагрузку на систему. Если ограничивающая коллекция использует инкрементные обновления, коллекции только с правилами прямого членства могут не отражать обновления членства в течение 24 часов или до тех пор, пока не произойдет запланированное обновление.

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

Помните, что Configuration Manager создает политики для всех объектов в ваших коллекциях, когда вы нацеливаете на них такие задачи, как развертывание. Изменения членства, будь то запланированное обновление или инкрементное обновление, могут создать гораздо больше работы для всей системы.В последних сборках текущей ветки предусмотрены специальные оптимизации политик для коллекций «Все системы» и «Все пользователи». При нацеливании на все ваше предприятие используйте встроенные коллекции вместо клона этих встроенных коллекций.

Чтобы еще глубже изучить производительность коллекции, просмотрите оценку коллекции в консоли. Для получения дополнительной информации см. Как просмотреть оценку коллекции.

Методы обнаружения

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

Данные открытия — это глобальные данные. Распространенная проблема, связанная с производительностью, заключается в неправильной настройке серверных методов обнаружения в иерархии, что приводит к дублированию обнаружения одних и тех же ресурсов с нескольких первичных сайтов. Тщательно настройте методы обнаружения для оптимизации взаимодействия с целевой службой, например с контроллерами домена Active Directory, избегая при этом дублирования одной и той же области обнаружения на нескольких первичных сайтах.

Общие рекомендации по выбору размеров

На основе предыдущей методологии тестирования производительности в следующей таблице приведены общие требования к аппаратному обеспечению минимум для определенного количества управляемых клиентов. Эти значения должны позволить большинству клиентов с указанным количеством клиентов обрабатывать объекты достаточно быстро для администрирования указанного сайта. Вычислительная мощность с каждым годом продолжает снижаться в цене, и некоторые из приведенных ниже требований невелики для современных конфигураций серверного оборудования.Оборудование, которое превосходит следующие рекомендации, пропорционально увеличивает производительность для сайтов, которым требуется большая вычислительная мощность или используются специальные продукты.

Клиенты для настольных ПК	Тип / роль сайта	Ядра Примечание 1	Память (ГБ)	Распределение памяти SQL Server Примечание 2	IOPS: Входящие Примечание 3	IOPS: SQL Server Примечание 3	Требуемое дисковое пространство (ГБ) Примечание 4
25 тыс.	Основной или CAS с ролью сайта базы данных на том же сервере	6	24	65%	600	1700	350
25к	Первичный или CAS	4	8		600		100
	Удаленный сервер SQL	4	16	70%		1700	250
50к	Основной или CAS с ролью сайта базы данных на том же сервере	8	32	70%	1200	2800	600
50к	Первичный или CAS	4	8		1200		200
	Удаленный сервер SQL	8	24	70%		2800	400
100 тыс.	Основной или CAS с ролью сайта базы данных на том же сервере	12	64	70%	1200	5000	1100
100 тыс.	Первичный или CAS	6	12		1200		300
	Удаленный сервер SQL	12	48	80%		5000	800
150 КБ	Основной или CAS с ролью сайта базы данных на том же сервере	16	96	70%	1800	7400	1600
150 КБ	Первичный или CAS	8	16		1800		400
	Удаленный сервер SQL	16	72	90%		7400	1200
700к	CAS с ролью сайта базы данных на том же сервере	20+	128+	80%	1800+	9000+	5000+
700к	CAS	8+	16+		1800+		500+
	Удаленный сервер SQL	16+	96+	90%		9000+	4500+
5к	Вторичный участок	4	8		500	–	200
15к	Вторичный участок	8	16		500	–	300

Примечания к общим рекомендациям по выбору размеров

Примечание 1: Ядра

Configuration Manager запускает множество одновременных процессов, поэтому для сайтов различного размера требуется определенное минимальное количество ядер ЦП.Хотя ядра становятся быстрее с каждым годом, важно обеспечить параллельную работу определенного минимального количества ядер. В целом, любой ЦП серверного уровня, произведенный после 2015 года, удовлетворяет базовым требованиям к производительности ядер, указанным в таблице. Configuration Manager использует преимущества других ядер помимо рекомендованных. Как только у вас будет минимальное количество ядер, сделайте приоритетными вложения ресурсов ЦП, чтобы увеличить скорость существующих ядер. Не добавляйте более медленные ядра. Например, Configuration Manager обеспечивает лучшую производительность при выполнении ключевых задач обработки с 16 быстрыми ядрами, чем с 24 более медленными ядрами.Эта производительность предполагает, что достаточно других системных ресурсов, таких как IOPS диска.

Связь между ядрами и памятью также важна. В общем, наличие менее 3-4 ГБ ОЗУ на ядро ​​снижает общую производительность обработки на ваших серверах SQL. Если SQL Server размещен вместе с компонентами сервера сайта, вам потребуется больше ОЗУ на ядро.

Примечание

Все наборы для тестирования устанавливают планы электропитания машины, чтобы обеспечить максимальное энергопотребление и производительность ЦП.

Примечание 2: выделение памяти SQL Server

Используйте это значение, чтобы настроить Максимальный объем памяти сервера (в МБ) в свойствах SQL Server.Это процент от общего объема памяти, доступной на сервере.

Не настраивайте одинаковое минимальное и максимальное значения. Это руководство предназначено специально для максимального объема памяти, который вы должны позволить SQL Server выделить.

Примечание 3: IOPS: Входящие и IOPS: SQL

Эти значения относятся к потребностям IOPS для логических дисков Configuration Manager и SQL Server. В столбце IOPS: Входящие показаны требования к IOPS для логического диска с каталогами входящих сообщений Configuration Manager.Столбец IOPS: SQL показывает общие потребности в IOPS для логических дисков, используемых различными файлами SQL Server. Эти столбцы разные, потому что два диска должны иметь разное форматирование. Для получения дополнительных сведений и примеров предлагаемых конфигураций дисков SQL Server и передовых методов работы с файлами, включая подробные сведения о разделении файлов на несколько томов, см. Часто задаваемые вопросы об изменении размера и производительности сайта.

Оба этих столбца IOPS используют данные из стандартного отраслевого инструмента Diskspd .Инструкции по дублированию этих измерений см. В разделе «Как измерить производительность диска». В целом, как только вы удовлетворяете базовым требованиям к процессору и памяти, подсистема хранения оказывает наибольшее влияние на производительность сайта, и улучшения здесь принесут наибольшую окупаемость вложений.

Примечание 4: Требуется место для хранения

Эти реальные значения могут отличаться от других задокументированных рекомендаций. Мы предоставляем эти цифры только в качестве общего ориентира; индивидуальные требования могут сильно различаться.Перед установкой на месте тщательно спланируйте, сколько места на диске потребуется. Предположим, что некоторый объем этого хранилища большую часть времени остается свободным дисковым пространством. Вы можете использовать это буферное пространство в сценарии восстановления или для сценариев обновления, когда требуется свободное дисковое пространство для расширения пакета установки. Вашему сайту может потребоваться дополнительное хранилище для сбора больших объемов данных, более длительные периоды хранения данных и большие объемы контента для распространения программного обеспечения. Вы также можете хранить эти элементы на отдельных томах с меньшей пропускной способностью.

Как измерить производительность диска

Вы можете использовать стандартный инструмент Diskspd , чтобы предоставить стандартизированные предложения по количеству операций ввода-вывода в секунду, которые требуются средам Configuration Manager различного размера. Следующие шаги тестирования и командные строки не являются исчерпывающими, но обеспечивают простой и воспроизводимый способ оценки пропускной способности дисковой подсистемы ваших серверов. Вы можете сравнить свои результаты с минимально рекомендуемыми IOPS в таблице общих рекомендаций по выбору конфигурации.

Результаты тестирования различных конфигураций оборудования в лабораторных условиях см. В разделе «Примеры конфигураций дисков».Вы можете использовать данные в качестве приблизительной отправной точки при проектировании подсистемы хранения для новой среды с нуля.

Как проверить диск IOPS

1. Загрузите утилиту Diskspd.

2. Убедитесь, что у вас есть не менее 100 ГБ свободного места на диске. Отключите все приложения, которые могут мешать работе или вызывать дополнительную нагрузку на диск, например активное антивирусное сканирование каталога, SQL или SMSExec.

3. Запустите Diskspd из командной строки с повышенными привилегиями.

   Дважды запустите инструмент последовательно для тома, который вы хотите протестировать. Первый тест размером 64 КБ со случайными операциями записи в течение одной минуты. Этот тест проверяет загрузку кэша контроллера и выделение дискового пространства в случае, если том динамически расширяется. Отбросьте результаты первого теста. Второй тест должен сразу же, следовать за первым тестом и выполнять ту же нагрузку в течение пяти минут.

   Например, используйте следующие командные строки для тестирования тома G: .

     DiskSpd.exe -r -w100 -t8 -o8 -b64K -c100G -d60 -h -L G: \\ test \ testfile.dat
   
   дель G: \\ test \ testfile.dat
   
   DiskSpd.exe -r -w100 -t8 -o8 -b64K -c100G -d300 -h -L G: \\ test \ testfile.dat
     

4. Просмотрите выходные данные второго теста, чтобы найти общее количество операций ввода-вывода в секунду в столбце операций ввода-вывода в секунду . В следующем примере общее количество операций ввода-вывода в секунду составляет 3929,18 .

     Всего операций ввода-вывода
   | поток | байты | Ввод / вывод | МБ / с | Ввода / вывода в секунду | AvgLat | LatStdDev |
   | -------- | ------------- | --------- | -------- | ------- ---- | -------- | ----------- |
   | 1 | 9651814400 | 147275 | 30.68 | 490.92 | 16.294 | 10.210 |
   | 2 | 9676652544 | 147654 | 30,76 | 492.18 | 16.252 | 9.998 |
   | 3 | 9638248448 | 147068 | 30,64 | 490,23 | 16.317 | 10.295 |
   | 4 | 9686089728 | 147798 | 30,79 | 492,66 | 16.236 | 10.072 |
   | 5 | 95456 | 146346 | 30,49 | 487,82 | 16.398 | 10.384 |
   | 6 | 9677242368 | 147663 | 30,76 | 492.21 | 16.251 | 10.067 |
   | 7 | 9637330944 | 147054 | 30,64 | 490,18 | 16.319 | 10.249 |
   | 8 | 9692577792 | 147897 | 30.81 | 492,99 | 16.225 | 10.125 |
   | Итого: | 77250887680 | 1178755 | 245,57 | 3929.18 | 16.286 | 10.176 |
     

Пример конфигурации дисков

В следующих таблицах показаны результаты выполнения шагов тестирования из раздела Как измерить производительность дисков с различными конфигурациями лаборатории тестирования. Используйте эти данные для приблизительной исходной точки при проектировании подсистемы хранения для новой среды с нуля.

Физические машины и Hyper-V

Оборудование постоянно улучшается.Ожидайте, что оборудование новых поколений и различные комбинации оборудования, такие как твердотельные накопители и сети хранения данных, превысят производительность, указанную ниже. Эти результаты — основная отправная точка, которую следует учитывать при проектировании сервера или обсуждении с поставщиком оборудования.

В следующей таблице показаны результаты тестирования различных дисковых подсистем, включая жесткие диски на основе шпинделей и твердотельных накопителей, в различных конфигурациях лаборатории тестирования. Во всех конфигурациях диски форматируются с кластерами по 64 КБ и подключаются к контроллеру дисков корпоративного класса.Помимо количества дисков в массиве RAID, у каждого из них есть как минимум один запасной диск.

Тип диска	Количество дисков, не включая +1 запасной диск	RAID	Измерено операций ввода-вывода в секунду
15 тыс. SAS	2	1	620
15 КБ SAS	4	10	1206
15 КБ SAS	6	10	1751
15 КБ SAS	8	10	2322
15 КБ SAS	10	10	2882
15 КБ SAS	12	10	3476
15 КБ SAS	16	10	4236
15 КБ SAS	20	10	5148
15 КБ SAS	30	10	7398
15 КБ SAS	40	10	9913
SSD SATA	2	1	3300
SSD SATA	4	10	5542
SSD SATA	6	10	7201
SSD SAS	2	1	7539
SSD SAS	4	10	14346
SSD SAS	6	10	15607

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

Тип диска	Модель	RAID-контроллер	Кэш-память и конфигурация
15k об / мин SAS HD	л.с. EH0300JDYTH	Интеллектуальный массив P822	2 ГБ, 20% чтение / 80% запись
SSD SATA	ATA MK0200GCTYV	Интеллектуальный массив P420i	1 ГБ, 20% чтение / 80% запись
SSD SAS	л.с. MO0800 JEFPB	Интеллектуальный массив P420i	1 ГБ, 20% чтения / 80% записи

Производительность компьютера и диска Azure

Производительность дисков Azure зависит от нескольких факторов, таких как размер виртуальной машины Azure, а также количество и тип используемых ею дисков.Azure также постоянно добавляет новые типы компьютеров и скорости дисков, которые отличаются от приведенной ниже диаграммы. Дополнительные сведения о Configuration Manager, работающем в Azure, и дополнительную информацию о дисковом вводе-выводе в Azure см. В разделе Configuration Manager в Azure часто задаваемые вопросы.

Все диски отформатированы в NTFS размером кластера 64 КБ, а строки с более чем одним диском настраиваются как чередующиеся тома с помощью утилиты Windows Disk Management.

Виртуальная машина Azure	Лазурный диск	Количество дисков	Свободное место	Измерено операций ввода-вывода в секунду	Ограничивающий коэффициент
DS2 / DS11	P20	1	512 ГБ	965	Размер виртуальной машины Azure
DS2 / DS11	P20	2	1024 ГБ	996	Размер виртуальной машины Azure
DS2 / DS11	P30	1	1024 ГБ	996	Размер виртуальной машины Azure
DS2 / DS11	P30	2	2048 ГБ	996	Размер виртуальной машины Azure
DS3 / DS12 / F4S	P20	1	512 ГБ	1994	Размер виртуальной машины Azure
DS3 / DS12 / F4S	P20	2	1024 ГБ	1992	Размер виртуальной машины Azure
DS3 / DS12 / F4S	P30	1	1024 ГБ	1993	Размер виртуальной машины Azure
DS3 / DS12 / F4S	P30	2	2048 ГБ	1992	Размер виртуальной машины Azure
DS4 / DS13 / F8S	P20	1	512 ГБ	2334	P20 диск
DS4 / DS13 / F8S	P20	2	1024 ГБ	3984	Размер виртуальной машины Azure
DS4 / DS13 / F8S	P20	3	1536 ГБ	3984	Размер виртуальной машины Azure
DS4 / DS13 / F8S	P30	1	1024 ГБ	3112	P30 диск
DS4 / DS13 / F8S	P30	2	2048 ГБ	3984	Размер виртуальной машины Azure
DS4 / DS13 / F8S	P30	3	3072 ГБ	3996	Размер виртуальной машины Azure
DS5 / DS14 / F16S	P20	1	512 ГБ	2335	P20 диск
DS5 / DS14 / F16S	P20	2	1024 ГБ	4639	P20 диск
DS5 / DS14 / F16S	P20	3	1536 ГБ	6913	P20 диск
DS5 / DS14 / F16S	P20	4	2048 ГБ	7966	Размер виртуальной машины Azure
DS5 / DS14 / F16S	P30	1	1024 ГБ	3112	P30 диск
DS5 / DS14 / F16S	P30	2	2048 ГБ	6182	P30 диск
DS5 / DS14 / F16S	P30	3	3072 ГБ	7963	Размер виртуальной машины Azure
DS5 / DS14 / F16S	P30	4	4096 ГБ	7968	Размер виртуальной машины Azure
DS15	P30	1	1024 ГБ	3113	P30 диск
DS15	P30	2	2048 ГБ	6184	P30 диск
DS15	P30	3	3072 ГБ	9225	P30 диск
DS15	P30	4	4096 ГБ	10200	Размер виртуальной машины Azure

Дополнительные сведения о доступных в настоящее время дисках см. В разделе Выбор типа диска для виртуальных машин Azure IaaS.

См. Также

Как уменьшить размер страницы в WordPress: практическое руководство

Обновление: март 2021 г.

Когда дело доходит до веса веб-страницы, размер имеет значение. В конце концов, чем меньше размер файла веб-страницы, тем быстрее она загружается. Это и ежу понятно.

Вес страницы — он же размер страницы или раздувание страницы — относится к общему размеру конкретной веб-страницы, включая все файлы, которые используются для создания страницы: документы HTML, таблицы стилей, изображения, сценарии и другие носители.

Это еще одна метрика веб-сайта, которую необходимо отслеживать, помимо скорости страницы, времени безотказной работы, времени до первого байта, HTTP-запросов и т. Д.

Но какое это имеет значение? Это значимая метрика? И как уменьшить размер страницы на вашем сайте WordPress?

Давайте посмотрим.

Средний размер веб-сайта для настольных компьютеров в 2021 году составляет 2038,4 кб

Еще в 1990-х веб-сайты были довольно простыми и состояли из простых файлов HTML и небольших изображений (и GIF-файлов в стадии разработки!).В настоящее время они выросли и включают в себя различные файлы HTML, CSS и JavaScript, изображения, видео, шрифты и другие типы файлов.

Согласно данным, собранным HTTP-архивом, средний размер веб-страницы в 2010 году составлял 467,7 КБ по сравнению с 2038,4 КБ в 2021 году.

Невероятно, но размер мобильных веб-страниц увеличился на 336% с 2010 года, хотя я должен отметить, что HTTP-архив впервые начал собирать данные о весе мобильных веб-страниц в мае 2011 года — средний размер мобильных веб-страниц тогда составлял 144.8кб.

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

• Средний размер веб-страниц, опубликованный HTTP-архивом, является средним размером, взятым из большого набора данных. Представляет ли он «типичный» веб-сайт? Возможно нет. Я имею в виду, что такое типичный веб-сайт?
• Лучше не использовать эти числа из HTTP-архива в качестве эталона для вашего собственного веб-сайта.Это исторические тенденции.
• Некоторые веб-сайты со временем уменьшились. В то время как некоторые веб-сайты в своем подходе стали полностью мультимедийными, с видео, полноэкранными изображениями, пользовательскими шрифтами и другими элементами дизайна, другие придерживаются более минималистского подхода.

Видео составляет 65,9% от среднего веса страницы

В течение долгого времени разработчиков беспокоил размер изображений и их доля в общем размере страницы. Но вау… Посмотрите, как видео полностью обогнало изображения:

Последние данные HTTP-архива показывают, что видео теперь составляет две трети от среднего общего размера веб-страницы.

Для сравнения: в мае 2016 года средний вес видео для настольных компьютеров составлял всего 286,3 КБ. Интересно, что средний размер видео в 2021 году на мобильных устройствах больше, чем на компьютерах.

Использование видео в последние годы резко возросло. Все больше и больше веб-сайтов используют заголовки видео и другие элементы мультимедиа. Согласно WordStream, 87% интернет-маркетологов используют видеоконтент, треть всей онлайн-активности тратится на просмотр видео, а более половины видеоконтента просматривается на мобильных устройствах.

Пользовательские шрифты никуда не денутся

Webfonts также вносят свой вклад в размер страницы, но, как показывает статистика, не стоит беспокоиться о росте их популярности. В ноябре 2010 г. шрифты составляли 59,2 КБ от общего размера страницы по сравнению с 132,1 КБ в январе 2021 г.

Еще более интересным является то, как среднее количество HTTP-запросов для шрифтов увеличилось до четырех в 2015 году, упало до трех в 2016 году и осталось стабильным на уровне четырех с 2017 года — только настольный компьютер вырос до пяти.Это может быть признаком того, что дизайнеры и разработчики выбрали оптимальное количество веб-шрифтов.

Давайте не забудем сценарии и таблицы стилей

Средний вес файлов JavaScript продолжает расти, увеличившись на 316,4% с конца 2010 года. Среднее количество HTTP-запросов для JavaScript также увеличилось.

байт CSS также неуклонно росли — в среднем в 2021 году они составят 73,3 КБ для настольных компьютеров и 68,7 КБ для мобильных устройств.

Имеет ли значение размер страницы? Разве Интернет не становится быстрее?

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

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

Да, Интернет становится быстрее. Браузеры, кеширование, более быстрые сети, CDN и другие технологии делают Интернет быстрее для пользователей. Но это не повод, так сказать, позволять вашему сайту нести лишний жир.

Radware отслеживает время загрузки 100 лучших сайтов электронной коммерции с 2011 года и обнаружил, что время загрузки и время взаимодействия значительно снизились.Причина? Размер и сложность страницы. Поскольку в другое время страницы становятся более раздутыми и сложными, обычно сохраняется тенденция к более медленной загрузке.

Насколько велик идеальный размер веб-страницы?

Эксперт по веб-производительности Тэмми Эвертс рекомендует 1 МБ в качестве идеального размера для быстро загружаемых веб-страниц. Далее она пишет, что многие компании стремятся выделить 1 МБ для своих страниц в рамках своего бюджета производительности.

Чтобы узнать больше о бюджете производительности, ознакомьтесь с этой замечательной книгой Брайана Джексона.

А как насчет ваших мобильных пользователей?

Я уже рассказывал в этом блоге о предполагаемой производительности, поэтому вы знаете все о том, как можно сделать так, чтобы веб-сайты работали быстрее, чем они есть на самом деле, чтобы повысить удобство работы пользователей. Но улучшение воспринимаемой производительности — не всегда ответ, особенно когда дело касается мобильных устройств.

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

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

6 советов по снижению веса страницы в WordPress

1.Оптимизировать изображения

Когда дело доходит до увеличения веса страницы, изображения — это низко висящий плод. Часто это файлы, которые загружаются на веб-странице дольше всего, но их относительно легко оптимизировать.

Для начала найдите время, чтобы просмотреть свои изображения и удалить ненужные. Затем сожмите их с помощью инструмента оптимизации изображений, такого как Imagify. Это удалит ненужную информацию о файле и поможет вашему изображению загрузиться быстрее.

Создание спрайтов CSS может еще больше помочь уменьшить вес страницы.Этот метод позволяет уменьшить несколько изображений в одно изображение. Затем с помощью CSS вы можете управлять спрайтом и отображать на странице только его определенную часть. Есть несколько отличных инструментов, которые могут помочь в создании спрайтов CSS, например SpriteMe.

Ленивая загрузка изображений также может сократить время загрузки страницы, особенно для мобильных пользователей — и это функция, которую вы можете включить в WP Rocket.

Получите WP Rocket сейчас и сразу же протестируйте улучшение!

2. Минимизация и объединение ресурсов CSS и JavaScript

Минимизация и объединение таблиц стилей и скриптов вашего сайта может еще больше упростить ваши ресурсы и удалить ненужный код с вашего сайта.Это не только помогает снизить вес страницы, но также может уменьшить количество HTTP-запросов, необходимых для загрузки вашего сайта.

WP Rocket — это самый простой способ минимизировать и сжать файлы CSS и JS за несколько кликов. Фактически, вы можете минимизировать и объединить свои файлы на вкладке «Статические файлы». Отметьте файлы, которые вы хотите минимизировать и объединить. По завершении нажмите «Сохранить изменения».

3. Используйте сеть доставки контента

Использование CDN может ускорить загрузку ваших страниц для пользователей в местах, находящихся далеко от того места, где находится ваш сервер, т.е.е. международный трафик. Чтобы узнать больше о том, как работают сети CDN, и найти лучшую из них, ознакомьтесь с руководством WP Rocket «Лучшие сети доставки контента для WordPress».

CloudFlare, популярный CDN, можно легко интегрировать с WP Rocket. Для этого перейдите на вкладку «CDN» в WP Rocket, чтобы включить CloudFlare, а затем добавьте свою учетную запись. Для получения дополнительной информации ознакомьтесь с документацией WP Rocket о том, как использовать CloudFlare с WP Rocket.

4. Используйте кеширование браузера

Если браузер пользователя может кэшировать статические файлы, им не обязательно будет загружать их снова при следующем посещении вашего сайта.Поэтому не забудьте включить кеширование браузера для своего сайта в WP Rocket. Кеширование браузера автоматически применяется к серверам Apache, поэтому пользователям не нужно выполнять какие-либо дополнительные действия. Но те, кто находится на серверах NGINX, могут использовать Rocket-Nginx, конфигурацию NGINX, которая делает WP-Rocket еще быстрее, обслуживая статические страницы напрямую, без загрузки WordPress или PHP.

5. Уменьшите количество ненужных веб-шрифтов

Вам действительно нужно восемь шрифтов на вашем сайте? Или подойдут два (один для заголовков и один для текста абзаца)?

Типографика является основой хорошего современного веб-дизайна — она ​​улучшает читаемость, разборчивость, доступность и способствует брендингу.Но это также связано с затратами на производительность, поскольку каждый шрифт, который вы используете, является дополнительным ресурсом, который посетители должны загрузить при посещении вашего сайта.

Жюри не решает, сколько шрифтов — это слишком много, хотя общее практическое правило гласит, что три — это много, и лучше придерживаться двух.

6. Сохраняйте стройность вашего сайта

Лучше меньше, да лучше. Если вы больше не используете на своем сайте плагин, тему, шрифт, скрипт или другие ресурсы, удалите их. Если вы думаете, что вам может понадобиться это позже, вам все равно следует удалить его — вы всегда можете добавить его позже.

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

На вашем сайте могут быть неиспользуемые правила CSS, и в этом случае вы можете использовать такие инструменты, как Unused CSS, чтобы легко находить и удалять правила, которые больше не используются.

Заключение

Вес страницы — важный фактор, напрямую влияющий на скорость страницы.Но это также всего лишь один из важнейших показателей производительности веб-сайта, за которым стоит следить. Поэтому запустите свой сайт с помощью инструмента для проверки скорости и сравните свой сайт, чтобы получить общее представление о размере страницы, прежде чем приступать к любому из приведенных выше советов.

Имейте в виду, что объясненные советы также помогут вам улучшить вашу успеваемость и оценки Core Web Vitals!

Иерархия размеров сайта в обществах среднего уровня

Основные моменты

•

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

•

Обсуждаются пять дополнительных процессов, создающих иерархию размеров сайта.

•

Боевые действия, расщепление, водосбор и сезонность создают иерархию размеров участков Илахита Арапеш.

•

Война, сезонность и палимпсест создают иерархию размеров участков ирокезов из долины Ирокез.

•

Война, расщепление и палимпсест создают иерархию размеров участков в Венгрии бронзового века.

Аннотация

Иерархия размеров участков — это археологический образец, обычно используемый для определения региональной политической иерархии в обществах среднего уровня государственного уровня и без гражданства. Хотя ряд археологов признали, что несколько процессов могут создавать иерархию размеров участков, многие ученые в Северной Америке и Евразии продолжают предполагать, что эта модель поселений порождается исключительно одним процессом — иерархическими, политически централизованными обществами. Я считаю, что это предположение ограничивает нашу способность создать точную базу данных об обществах с возникающим неравенством.В этой статье я рассматриваю процессы, потенциально ответственные за создание иерархии размеров участков, и опираюсь на этноисторические тематические исследования из района Великих озер и Папуа-Новой Гвинеи, чтобы проиллюстрировать эти процессы. Затем я оцениваю возможные механизмы, которые создали иерархию размеров сайтов для доисторического случая в Венгрии среднего бронзового века (1750–1400 до н.э.) — области, где почти повсеместно предполагается, что подпись указывает на региональную политическую иерархию. Однако я обнаружил, что венгерское тематическое исследование вместо этого указывает на несколько других процессов, включая агрегацию, рассредоточение и расщепление сообщества, которые лежат в основе этой модели.Эти примеры предполагают, что иерархии размеров участков, если их некритически интерпретировать как социальные иерархии, могут переоценивать степень политической централизации в доисторических обществах.

Ключевые слова

Иерархия сайтов

Вождества

Социальное неравенство

Модели поселений

Расщепление-синтез

Сезонность

статей Бронзового века

Венгрия

статей

Новая Гвинея

Новая Гвинея полный текст

Copyright © 2014 Elsevier Inc.