Не указан срок действия кеш

Включаем кеш браузера для Google PageSpeed


Представляем полезную статью «Включаем кеш браузера для Google PageSpeed», чтобы оптимизировать сайт по совету инструмента от Google PageSpeed Insights. Каждый владелец сайта сталкивался с проблемой сложности закешировать js скрипты сторонних DLE сайтов.

Это не такой важный показатель для оптимизации, по сути происходит перенос из шапки сайта CSS и JS элементы в футер, к тому, если посмотреть на ресурсы Google с этим пунктом у них проблемы 🙂

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

Кеш браузера своих элементов

Делаем кеш для разных скриптов, пример взят с блога Devaka ru (на момент написания статьи)
К примеру :

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

Далее выполняем проверку вашей площадки в инструменте Page Speed и если все хорошо, то останутся ссылки на яндекс.метрику, аналитику, социальные сети и т.д.

Примеры сторонних скриптов

Если в первом шаге, все сделали верно, должны увидеть примерно такой список:

Используйте кеш браузера для следующих ресурсов

У вас конечно, может быть всего несколько URL на метрику и аналитику например, но это не столь важно, инструкция исправления одинаков для всех.

Кеш сторонних элементов

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

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

Давайте теперь по порядку!
Шаг 1. Скопируем список всех скриптов на которые указывает Google PageSpeed в блокнот или прямо с браузера.
Шаг 2. Создайте файл на хостинге с расширением php и вставляем в него следующий код:

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

В этой строке меняем 3 значение:
Используйте кеш браузера для Google PageSpeed
1. Скрипт который будем закачивать к себе на сайт

2. Путь куда сохранять файл:

В этом примере это папка js, т.е. точный путь будет www.dle9.com/js/ (папку нужно создавать самим и выставить для неё права CHMOD для записи)

3. Имя скрипта, если с расширением .js, то пишем вместе с ним, если без него или с другим, то делаем все так как в примере выше. Обращайте внимание, чтобы не было файлов с одинаковыми названиями.

Шаг 3. Заливаем отредактированный файл на сервер

И переходим по прямой ссылке, например http://www.dle9.com/downloadjs.php, если все сделали правильно, в папке JS (или какую вы указали в файле), будет лежать нужный файл/файлы.
Используем кеш браузера для Google PageSpeed

Шаг 4. Ставим файл на крон для автоматического обновления файлов

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

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

Не забываем сменить URL и возможно синтаксис команды у вас будет другой, посмотрите примеры cron команд в справке хостинга или утоните в тех.поддержке.

Шаг 5. Меняем путь к JS в счетчике или скрипте

Если был путь в счетчике https://mc.yandex.ru/metrika/watch.js, то заменяем его на путь внутри сайта, например http://www.dle9.com/js/watch.js

Вот и все, теперь в списке PageSpeed Insights у вас не должно быть сообщений о настройке кеша браузера.

Скачать » включаем кеш браузера для Google PageSpeed » инструкцию в архиве

Не указан срок действия кеша

В общем проверяю на https://developers.google.com/speed/pagespeed/insights/ свой сайт, и он мне пишет, что нужно исправить:
del (не указан срок действия)
и так для многих моих картинок и js и css файлов!

Добавлено через 19 часов 2 минуты
ап.

Использование кеша браузера
Доброго времени суток, сталкнулся с такой проблемой как Используйте кеш.

срок действия Dll
в проге 1С 7,7 есть самописная библиотека dll, так вот с 01.11.2010 года она.

Срок действия вип статуса
Привет всем. Подскажите пожалуйста идею реализации платных прав (статусов).

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

WordPress. Как убрать «Используйте кеш браузера» от PageSpeed Insights?

1. Установлен HyperCashe;
2. в htaccess:

3. BWP Minify установлен(тоже с кэшированием)

PageSpeed ругается на JS, png, jpg: «Используйте кеш браузера». Как вылечить такую проблему?
В скобках возле каждого файла: Не указан срок действия

Как использовать кеш браузера пользователей для ускорения сайта (заголовки Last-Modified, ETag, Expires, Cache-Control)

Здравствуйте, уважаемые читатели блога Goldbusinessnet.com. Продолжаю цикл статей, которые касаются мероприятий по оптимизации, и сегодня настал черед для настройки использования в этих целях кэша браузера со стороны пользователей, что является очередным шагом выполнения рекомендаций Google Page Speed по ускорению сайта.

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

Читайте так же:  Перерасчет воды по одн

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

Рекомендация PageSpeed — используйте кэш браузера

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

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

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

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

Тогда после процедуры gzip сжатия файлов CSS, JS, HTML следующим по приоритету советом была как раз необходимость использования кэша браузера:

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

У моего теперешнего хостера кэширование включено, поэтому при анализе этого блога в упомянутом чуть выше online сервисе Pagespeed отразились опять же только внешние элементы, которые мне не подвластны (Граватар, контекстная реклама, Яндекс Метрика, Гугл Аналитикс):

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

Настройка кеширования в браузере пользователей в целях увеличения скорости сайта

Помните, в начале поста я обмолвился, что предлагаемый вариант не являются стопроцентно универсальным и подойдет не всем? К сожалению, это так. Дело в том, что этот метод годится только для серверов, управляемых ПО Apache (коих, правда, подавляющее большинство).

Более того, описанные ниже телодвижения дадут результат только в том случае, ежели у вас работает Апач в чистом виде. Если используется связка Apache + nginx, то настраивать придется последний, и в этом случае владельцам сайтов на разделенном виртуальном хостинге без помощи не обойтись. Так что придется обратиться к хостеру (впрочем, тоже вариант).

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

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

Находится .htaccess обычно в корневой директории (папке public_html или htdocs) вашего сайта. Для начала проверьте его наличие, подсоединившись к удаленному серверу, где хостится ваш проект, посредством ФТП-соединения (тут у меня разобран по косточкам менеджер Файлзилла). Если вы файла .htaccess в корне не наблюдаете, то попробуйте из верхнего меню FileZilla выбрать «Сервер» — «Принудительно отображать скрытые файлы»:

Если и в этом случае он не появится (что, впрочем, маловероятно), примените замечательный редактор Нотепад плюс плюс и создайте в нем такой файл:

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

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

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

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

Во-первых, необходимо обеспечить своевременное обновление веб-обозревателями кэшируемых объектов в интересах пользователей, которые будут получать в этом случае актуальный контент. Это можно сделать, используя заголовки Last-Modified и ETag (одновременно их оба нет нужды выводить, об этом недвусмысленно говорит сам Гугл).

На практике это означает, что при отправке браузером GET запроса (в данной статье вы найдете подробности о взаимодействии сервера и клиентских приложений) он получит HTTP ответ с кодом состояния 304 (без загрузки оттуда контента), если запрашиваемый ресурс не был изменен. Этот ответ означает, что можно загрузить контент из кеша.

И только в случае изменения содержание объекта будет отправлено для его отображения с сервера в составе ответа 200 (ОК). Подобная схема гарантирует максимальную экономию времени загрузки и одновременно актуальность отображаемой информации.

Во-вторых, нужно обязательно указать, на протяжении какого периода браузер должен хранить в кеше те или иные ресурсы. С этой целью можно использовать Expires либо Cache-Control с параметром max-age. Вывод этих заголовков инициируется с помощью модулей соответственно mod_expires и mod_headers, которые в том числе содержат названия объектов, к которым и будет применены правила хранения их в кеше.

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

Читайте так же:  Пособия егэ по математике 2019

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

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

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

Итак, на основании выше сказанного нам нужно обеспечить вывод одного из заголовков Last-Modified и ETag, а также одного из пары Expires либо Cache-Control: max-age. Для наглядности и расширения диапазона рассмотрим различные варианты.

Вариации кодов для управления кешем с использованием заголовков Last-Modified, Expires и Cache-Control

Если на вашем хостинге уже настроен вывод того же Last-Modified, то пол-дела сделано (к слову, проверить наличие этого важного заголовка можно с помощью онлайн сервисов, включая в их список инструмент для проверки ответа сервера от Яндекса). Если же нет, то сделать это весьма несложно, прописав в том же незаменимом .htaccess пару строк:

Правда, работать этот метод будет опять же при условии наличия «чистого Апача» (но ведь как раз этот случай мы и рассматриваем). Будем считать, что заголовок Last-Modified, в качестве значения которого, кстати, будет выводится дата последнего изменения, настроен.

Теперь настала очередь Cache-Control с параметром max-age, в качестве значения которого будет прописан срок хранения в кеше каждого конкретного статического объекта. На сцену выходит модуль mod headers, код которого и следует вставить в .htaccess:

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

Время сохранения кеша определяется с помощью параметра max-age, его значение выставляется в секундах. Благодаря комментариям (которые, к слову, вы можете спокойно удалить), стоящим после символа решетки «#», основа этой конструкции, думаю, понятна.

Однако, вместо mod headers вполне можно воспользоваться модулем mod expires, выводящим заголовок Expires (который, по мнению самого Гугла является предпочтительнее, поскольку имеет более широкую поддержку). При этом фрагмент кода для его включения будет таким:

Точкой отсчета срока годности кэша в случае использования заголовка Expires является дата первой загрузки. Причем, в отличие от Cache-Control, где временной период определяется только в секундах, здесь он может указываться в любом временном формате, включая year (год).

Для того, чтобы убедиться в этом, посмотрите на участок кода, касающийся изображений. Там я специально указал время в различных единицах исчисления: 1 month (месяц), 4 weeks (недели), 30 days (дни), 43829 minutes (минуты), 2592000 seconds (секунды).

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

В дополнение к упомянутым модулям полезно задействовать еще и mod setenvif. Дело в том, что веб-обозреватели семейства Microsoft Internet Explorer и некоторые версии Мазилы корректно не воспринимают в ответе сервера HTTP заголовок Vary, который также вносит свою важную лепту в управление кэшированием. Этот модуль как раз позволяет решить эту проблему, исключая Vary из состава ответа сервера:

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

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

Код формирования заголовков Etag и Expires для настройки кэша

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

Но если в качестве значения Expires отображается дата последнего изменения, то в ETag используется тот или иной уникальный идентификатор ресурса (чаще в этой роли выступает версия файла). Для активации ETag требуется лишь ввести в тот же .htaccess одну строчку:

Ну а затем применить уже известный нам модуль mod expires. Можно добавить и mod setenvif, который, как я уже сказал выше, запрещает формирование заголовков Vary для определенной группы веб-браузеров, чтобы гарантировать образование кеша с их стороны:

Здесь использован комплекс с минимумом типов задействованных объектов, но зато наиболее востребованных (CSS, JavaScript и изображения), который также должен быть достаточным, чтобы обеспечить максимальную эффективность в ускорении сайта. При желании к комплекту «jpg|jpeg|gif|png|ico|css|js» можно добавить другие виды файлов.

Кроме того, в приведенном выше примере кода для всех файлов действует один и тот же период «жизни» кеша, равный одному году («access plus 1 year»), который является рекомендуемым со стороны Гугла. Но можно для каждой группы объектов указать свой временной отрезок по примеру содержания модулей mod_expires и mod_headers из предыдущего раздела статьи.

Проверка наличия нужных заголовков в ответе сервера

После того, как вы вставите код в файл .htaccess, можно проверить, находятся ли необходимые заголовки в составе ответа сервера. Для этой цели можно воспользоваться каким-нибудь онлайн сервисом, например, Checkmy.ru, где в качестве клиента (User Agent), посылающего HTTP-запрос на сервер, выбираем любой браузер, а также вводим URL ресурса (для примера я взял путь до изображения, используемого в одной из статей блога):

Читайте так же:  Приказ росстата форма 2 тп воздух

После нажатия кнопки «Отправить запрос», через несколько секунд появится результат:

Как видите, в моем случае присутствуют все четыре заголовка. Я говорил, что обязательно должны выводится по одному из пар «Last-Modified — ETag» и «Expires — Cache-Control», остальные излишни. При этом полный комплект, насколько можно судить, не причинит вреда.

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

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

Далее советую для закрепления материала обратиться к видео и посмотреть последовательно 6 уроков (один из которых посвящен настройке кеширования в браузерах), в которых подробно рассмотрены все наиболее важные аспекты ускорения сайта WP:

Как указать кэширование для файлов jpg?

PageSpeed Insights пишет про Используйте кеш браузера
для изображений

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

(Дальше редиректы идут, я не стал копировать)

Используем кеш браузера для Google PageSpeed

Для тех кто оптимизировал сайт по рекомендациям инструмента от Google PageSpeed Insights, сталкивались в проблемой невозможности закешировать js скрипты сторонних сайтов.

По сути это не столь важный показатель для оптимизации, это как переносить из шапки сайта в футер CSS и JS элементы, хотя у самого Google с этим пунктом проблемы 🙂

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

Кеш браузера своих элементов

Для начала сделаем кеш для своих скриптов, для примера посмотрим на блог Devaka.ru (на момент написания статьи)

http://8dle.ru/assets/copyright.min.js (не указан срок действия)
http://8dle.ru/assets/i/566.jpg (не указан срок действия)
http://8dle.ru/assets/i/icons.png (не указан срок действия)
http://8dle.ru/assets/i/postcomm-left.png (не указан срок действия)
http://8dle.ru/assets/i/postcomm-right.png (не указан срок действия)

Чтобы исправить эту проблему, нужно зайти в файл .htaccess и вставить в самый низ этот код:

После этого можете выполнить проверку своего сайта в инструменте Page Speed и если все хорошо, там должны остаться ссылки на яндекс.метрику, аналитику, социальные сети и т.д.

Примеры сторонних скриптов

Если в первом шаге, все сделали верно, должны увидеть примерно такой список:

Используйте кеш браузера для следующих ресурсов

Правда может быть всего несколько URL на метрику и аналитику например, но это не столь важно, рецепт исправления для всех один и тот же.

Кеш сторонних элементов

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

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

Давайте теперь по порядку!
Шаг 1. Копируете список всех скриптов, которые показывает Google PageSpeed в блокнот или можно прямо с браузера.
Шаг 2. Создаем файл на хостинге с расширением php и вставляем в него следующий код:

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

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

В этой строке меняем 3 значение:

1. Скрипт который будем закачивать к себе на сайт

2. Путь куда сохранять файл:

В моем случае это папка js, т.е. точный путь к ней будет 8dle.ru/js/ (папку нужно создавать самим и выставить для неё права CHMOD для записи)

3. Имя скрипта, если с расширением .js, то пишем вместе с ним, если без него или с другим, то делаем все так как в примере выше. Обращайте внимание, чтобы не было файлов с одинаковыми названиями.

Шаг 3. Заливаем отредактированный файл на сервер

И переходим по прямой ссылке, например http://8dle.ru/downloadjs.php, если все сделали правильно, в папке JS (или какую вы указали в файле), будет лежать нужный файл/файлы.

Шаг 4. Ставим файл на крон для автоматического обновления файлов

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

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

Не забываем сменить URL и возможно синтаксис команды у вас будет другой, посмотрите примеры cron команд в справке хостинга или утоните в тех.поддержке.

Шаг 5. Меняем путь к JS в счетчике или скрипте

Если был путь в счетчике https://mc.yandex.ru/metrika/watch.js, то заменяем его на путь внутри сайта, например http://8dle.ru/js/watch.js

Вот и все, теперь в списке PageSpeed Insights у вас не должно быть сообщений о настройке кеша браузера.

Остались вопросы, задавайте в комментариях!

[Решено] Продление cache time для отдельных элементов

Рекомендуемые сообщения

Последние посетители 0 пользователей онлайн

Ни одного зарегистрированного пользователя не просматривает данную страницу

  • Последние темы
  • Последние дополнения
  • Последние новости
  • Вся активность
  • Главная
  • Поддержка и ответы на вопросы
  • Песочница
  • [Решено] Продление cache time для отдельных элементов
  • Язык
  • Публичная оферта
  • Политика возвратов
  • Политика конфиденциальности
  • Обратная связь

Webrov Group OÜ — Harjumaa, Tallinn, Tornimäe tn 5, 10145, [email protected]

Важная информация

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