Оптимизация JS и CSS | Корректная загрузка ресурсов сайта

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

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

На скриншоте перечень мер оптимизации по результатам теста LightHouse. 70% - касаются js и css.

Несмотря на то, что наиболее сильное влияние загрузка js и css оказывает на показатели Time to Interactive и Total Blocking Time. Для целей SEO, в первую очередь, важна отрисовка первого экрана. Чтобы не останавливаться на этом, ниже даю небольшой чек-лист для оптимизации FCP:

  • Используйте правильную очередность загрузки ресурсов.
  • Подключайте js и css по типам страниц, чтобы время загрузки не уходило на неиспользуемые файлы.
  • Откажитесь от запросов @import url("style.css").
  • Стили, влияющие на FCP расположите inline внутри html-странички.
  • Минимизируйте количество js кода для отрисовки первого экрана.

Рекомендации к JS и CSS по LightHouse

- Устраните ресурсы, блокирующие основной поток

Объявление на vc.ru Отключить рекламу
Маркетинг
Как создать ценностное предложение в b2b и привлечь покупателей. Принципы, методы, инструменты
Как продвигать сложные продукты с длинными циклами сделки, такие как, например, ИТ-платформы, консалтинговые услуги…

Такие ресурсы - это <script> (без defer и async) и стили <link rel="stylesheet">, подключаемые в <head>. Как правило, наибольшую нагрузку вызывают скрипты, подключенные через внешний ресурс, а также js сервисов веб-аналитики.

Отсюда вытекают 2 рекомендации

1. Все ресурсы нужно хранить локально. Внешний запрос может осуществляться слишком долго.
<link href="/templatev1.css" type="text/css" rel="stylesheet">

Когда вы скопируете код и сохраните его локально. У вас появятся возможности по дополнительной оптимизации. Вы сможете:

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

Минифицировать - сжимать файлы.

Комбинировать файлы - объединять несколько небольших файлов.

2. Всем ресурсам, не связанным с отображением элементов первого экрана, нужно обеспечивать асинхронную загрузку. <script async="" src="/analytics.js"></script>

Подключение скрипта в <head> - это и есть блокировка загрузки страницы. Если вы посмотрите на свой сайт внимательно, то поймёте, что 90% всего js используется ниже первого экрана. А если это не так, то следует к этому прийти.

Располагайте скрипты в <body> и указывайте атрибуты async или defer для асинхронной загрузки:

<!DOCTYPE html> <html> <head> <link href="style.css" rel="stylesheet"> </head> <body> <div><img src="awesome-photo.jpg"></div> <script src="app.js" async></script> </body> </html>

Например, jQuery часто не нужно загружать сразу. Однако, на большинстве сайтов вы увидите, что jQuery стоит в <head> первым js ресурсом. Убрать запрос к jQuery из <head> и вызов его в <body> по необходимости будет правильным решением.

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

{ "author_name": "Александр Поспелов", "author_type": "self", "tags": [], "comments": 51, "likes": -2, "favorites": 70, "is_advertisement": false, "subsite_label": "seo", "id": 181843, "is_wide": false, "is_ugc": true, "date": "Sat, 28 Nov 2020 19:34:36 +0300", "is_special": false }
Объявление на vc.ru Отключить рекламу
Карьера
Решение конфликтов, эмпатия и понимание цели: soft skills руководителя команды разработчиков
Управление командой специалистов — непростая задача. О том, как превратить группу разработчиков в единую команду…
0
51 комментарий
Популярные
По порядку
Написать комментарий...
9

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

Ответить
3

Статья ради статьи, согласен

Ответить
0

Статья херпоймирадичего.... За каким лядом я это прочёл?))) 

Ответить
1

"Про работу со шрифтами" - будет отдельная статья.

Ответить
1

не надо, пожалуйста))

Ответить
1

Ну как бы AJAX тот же Яндекс как не понимал, так и не понимает. Да и гуглобот со скрипом до сих пор. 

Ответить
0

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

Ответить
0

Можно и во времени произвольно путешествовать, только нужно знать как.

Ответить
0

Хорошо.
Но потом.

Ответить
5

На мой взгляд - это очень поверхностная статья. Например, вопрос подключения скриптов на сайт. Если у нас легаси ресурс и ранее вообще не использовались атрибуты асинхронной загрузки, то самое верное решение - defer, за счёт того, что он не блокирует отрисовка страницы и формирование dom при загрузке скриптов, а так же гарантирует порядок исполнения скроптов после события domcontentloaded, переносить скрипты из head не нужно. Использование же async в большенстве случаев вызывает race condition и самое главное, что если ресурс с качается быстрее, чем html распарсится, то он будет так же блокирующим ресурсом (банальный пример: пользователь вернулся на ваш сайт и ему из кеша идут ресурсы). Async вообще лучше использовать для различных метрик, с которыми не общается твой код, а они живут сами по себе. Использование critical css т.е. inline внесение css первого экрана в head в саму структуру html приводит к раздуванию самого html которому не всегда дают правила кеширования, т.е. вынуждая каждый раз загружать большой html. Плюс ко всему, такой подход частенько вынуждает переставать layout страницы и просаживал метрику смещения layout того же lighthouse. Моя практика использования cdn (системы распределенной поставки ресурсов) показала, что лучше с ней, чем без неё в большинстве случаев, а что бы минимизировать негативный эффект на TTFB за ресурсом, то делать prefech или preconnect в зависимости от ситуации. 

Ответить
0

Вы разработчик или SEO-специалист?
Я имею в виду - отличная тема для статьи.

Ответить
5

Разработчик. Не уверен, что хорошая тема т.к. на том же хабре достаточно статей описывающий различные методики оптимизации перфоманс. Но я бы с удовольствием почитал про 2 штуки:
1) решенные кейсы. Типа берём сайт, проводим анализ различным туллингом со скриншотами и объяснением полученных данных, далее на основе результатов делаем заключение с указанием вещей, что и как поправить и после выполнения рекомендаций - сравнение на до и после. 
2) доказать зависимость поисковой выдачи от результатов перфоманс гугла. Типа мой сайт просел на 5 баллов, что это для меня значит и как повлияет? А 20 баллов посадка? А если у меня 0 из 100 баллов, мой сайт пропадёт из выдачи (споллер, нет)? Т.е. зачем вообще для seo делать оптимизацию перфоманс (именно для seo, а не для пользователя)? Мой опыт показал, что она есть..... но слишком призрачна. В основном все диктуется - есть баллы и мы должны получить их много потому что где то кто то сказал, что это влияет на поисковую выдачу. 

Ответить
1

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

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

Ответить
0

Согласен про оправдание 'зарплат'. Большинство клиенту чешут: нужно увеличить скорость загрузки, оптимизировать скрипты, css (даже, сука, не представляя как, бля, можно оптимизировать скрипт метрики, или пикселя фейсбука) , а по факту, эта оптимизация ни на что не повлияет! Совсем никак. Только в конкуренции с соседом (когда сайты один в один, ссылки, контент и прочее), только тогда сайт, который быстрее, будет в выдаче выше. 

Ответить
0

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

Ответить
3

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

Во вторых, каким боком здесь seoшник? Который может только дать рекомендации по оптимизации сайта!! На фиг ему знать как это делать? Какой, бля, seoшник полезет править dom-climata.ru, который на bitrix? Кто его туда пустит то?

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

Обращаясь к автору: попробуйте это опубликовать на habr! Думаю даже не пропустят.))) 

Ответить
3

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

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

Ответить
0

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

Ответить
2

Добавлю ко всему вышесказанному, что про внешние ресурсы тоже тема не раскрыта.

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

Например качаем себе метрику. В самом файле watch.js подключаются дополнительные файлы.

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

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

Возможно у коллег есть решения?
Спасибо

Ответить
1

В одном из эфиров раскрыли эту тему на 100% и дали даже скрипт для обертывания скриптов аналитики. Выкачивать не надо. Надо просто отложить в потоке на 100-300 миллисекунд и будет всё хорошо.
Смотрите

Ответить
1

1) Смотреть 1 час видео без таймкодов непозволительная роскошь)

2) Речь про setTimeout()? Мне казалось такие задержки еще хуже делают, разве нет - код по идее все-равно парсится?

Получается загнать в JS встраивание скрипта аналитики и пр. (а не тегом script) и отложить выполнение вместе с инициализацией?

Если речь про async и defer, то если скрипты уже в футере - толку от них не много. Читал тут: https://habr.com/ru/post/323790/#gde-raspolozhen-element-script-
Можно, правда, добавить link preload.

3) Это разве решает вопрос загрузки внешнего содержимого? Или просто парсер не загружает их потому что не компилит отложенное выполнение и, получается не видит их в сурсе?

Ответить
0

1. Таймкоды есть, будьте внимательнее, прежде чем писать.
2. Речь про то, что мы рассказываем на видео.)
3. Мы про всю логику рассказываем на этом видео.
+ вы просто можете купить наши скрипты и пробовать их внедрять:
https://pagespeed.loading.express/scripts

Ответить
1

1. Это если перейти на youtube) Можно сделать так: https://youtu.be/_3c0aPSkNdc?t=1482

2. Сами же говорите про потерю показов (да, в рамках рекламных баннеров, но все же) https://youtu.be/_3c0aPSkNdc?t=1567

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

Описывали это решение в качестве ознакомления в данной статье:

Ответить
0

"Описывали это решение в качестве ознакомления в данной статье:"
Ну, так скажем, описали это не вы, а я. И вы просто скопировали из моей статьи от января 2020 (https://vc.ru/services/103768-kak-nakruchivayut-100-ballov-na-google-pagespeed). И сервис фейк как вы видите находится на loading.express домене.
И нет, вы просто не так поняли как это работает.
Мы говорили про скрипты аналитики. Если вам интересно как откладывать рекламные баннеры или скрипты, то про это был отдельный эфир: https://www.youtube.com/watch?v=_lBZf2BbJAY. Там тоже есть тайм коды.

Аналитику надо откладывать и размазывать скрипты по потоку.
Но закрывать и скрывать от Lighthouse лучше не надо.
Некоторые оптимизаторы PageSpeed этим пользуются, но мы предпочитаем зарефакторить JS.

Ответить
1

Ну вы тоже не первопроходец в данном вопросе, вот статья от февраля 2019 (на год раньше вашей). https://tinyurl.com/y3te772q

Уверен, можно найти больше, но да, мы брали за основу вашу статью и показывали как раз как НЕ НАДО делать.

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

Возможно чуть меньше нагрузка на ЦП будет единовременная. Но, блин, серьезно? JS скриптики создают супер нагрузку на проц в 2021 году?

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

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

Удачи в поиске клиентов.
Спасибо за содержательную беседу.

Ответить
0

"Возможно чуть меньше нагрузка на ЦП будет единовременная. Но, блин, серьезно? JS скриптики создают супер нагрузку на проц в 2021 году?"

Это шикарный вопрос. И если вы так удивляетесь, то вы даже не представляете НАСКОЛЬКО сильная нагрузка может быть от 53 слайдеров слик на странице сайта.

Ответить
1

При чем тут 53 слайдера на странице? Какой одаренный на голову делает страницу такой длинны и с таким количеством слайдеров?

Ответить
0

К нам не приходят простые сайты.
53 слайдера это из вчерашнего ускоренного сайта случай.
А насчет одаренного  —  их 99% на рынке, сидят и "верстают" из "сверстанного" шаблона...

Ответить
0

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

Ответить
0

Да, клиенты это не публичная инфа.
Выслал в личку.

Ответить
0

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

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

Скрипты за 500 рублей - хорошая попытка подколоть. Но мы скорее продаем ускорение сайта под ключ за 90 000 рублей. А за 2900 вы можете купить наши скрипты-наработки и пробовать ковыряться самостоятельно.

Успехов в понимании темы про быстрые сайты!

Ответить
0

Бла-бла-бла

Ответить
0

"Бла-бла-бла"
Говорю же, вы не слышите.

Ответить
0

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

Это не профессионально.

Ответить
0

Я вам предлагаю посмотреть видео, где мы показываем код скрипта. БЕСПЛАТНО, посмотрите, чтобы понять принцип.

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

Тогда вы поймете, что вариантов больше и нет. А уносить скрипты к себе - ну такое.)

Ответить
0

Вы непробиваемый. Я - РАЗРАБОТЧИК. Видео я УЖЕ посмотрел, и это мое резюме по нему. Что такое setTimeot() я знаю, спасибо, как работает тоже.

Вы, судя по видео - не разработчик ( не разбираетесь в терминах и т.д.), а продажник в вашем тандеме. Строите из себя Стива Джобса, продавая скрипт к которому есть вопросы, которые вы игнорируете.

Ответить
0

В видео длительностью в почти час, вы показываете один скрипт?
В тренингах больше контента :)

Ответить
0

Да, понимаю, что час выдержать невозможно для поколения Z. Максимум времени есть 15 секунд или минута если уж прям совсем.)) 
Но да, для этого нужен час. И да, мы показываем избыточно на видео, что именно предлагаем сделать.
Есть и вопросы от зрителей, потому что это прямой эфир.
Есть и другое. тайминг помогут вам посчитать точнее, сколько мы рассказываем именно про скрипт и его логику.
И да, правильно вы написали, это именно тренинг.
Удачи, Никита.

Ответить
0

Какое поколение Z? 🤦‍♂️ Я с вами на "вы" общаюсь исключительно из-за правил хорошего тона, а не из уважения к старшему поколению. Расслабьтесь, мы, примерно, ровесники.

Я написал: посмотрел видео полностью, вот прям со всеми затупами вашими, и скрипт на экране сам видел (так что эксклюзивности в ссылках под видео нет если что, я понимаю "маркетинговую составляющую, но выглядит странно). И у меня к этому всему есть вопросы. При этом закономерные и логичные.

Вы их игнорируете и говорите об абстрактном, в том числе и в ваших видео, попутно пытаясь, со своим другом, продать "супер" скрипт.

Из этого могу сделать только один вывод - все это не более чем псевдо-решение, потому что:
1) вы упорно игнорируете конкретные вопросы;
2) предлагаете посмотреть видео, в котором говорите тоже самое и купить скрипты, к которым есть вопросы;
3) прислали сайт, который приводили в пример про 53 слайдера, но там этот пример не подтвердился + я ответил про то как работает JS (про экземпляры);

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

Также, касательно:

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

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

Если вы настаиваете на том что ваше видео супер информативно, я не поленюсь, заморочусь, и нарежу его самые "информативные" моменты. :)

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

Ответить
0

Эх, Никита. Хорошо пишете. Пишите статьи, у вас отлично получается.

Честно - мне лень и у меня мало свободного времени. Чем отвечать на ваши "неудобные" вопросы, я лучше пойду к детям и поиграю с ними в куча-мала.)))
Вы задаёте правильные вопросы, но учить бесплатно - увольте.

Скрипты работают и это факт.
Сотня ускоренных проектов это подтверждает.

"+ я ответил про то как работает JS (про экземпляры);"

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

А то что вы прислали совсем и не ошибка JS.
Это кэш в вашем браузере о несуществующих файлах js.
Кэш + ПВА. Но почему с этим проблемы лучше самостоятельно изучить.

Хорошего дня.

Ответить
0

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

Отвечать на вопросы и конвертировать пользователей в клиентов - ваша задача, неправда ли?

Учить? Учите своих детей, а я указываю на недостатки вашей системы, будучи full stack разработчиком с 10 летним стажем. Поэтому с обучением, до уровня на котором осуществляется дискуссия, вы опоздали, лет так на 7.

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

Ответ про экземпляры я адресовал на ваш тезис про «поток и загрузку». То что меняется дом - факт, но, например, в том же слике добавляются только элементы управления, да классы - основная структура не меняется. И как скрипт решает этот вопрос? Убираете просто слайдер? Крутое решение. Профессиональненьнко.

Что то что я прислал - кеш - спасибо, я в курсе. Схерали он у меня ломает сайт? Или вы каждому пользователю будете писать на сайте «если у вас не работает сайт - почистите кеш. Это вы мудак, а не наши разработчики» 🤣. Это вам ваш товарищ-специалист продиктовал ответ? Мол «да это кеш, пусть почистит». Так я просто серфил страницы.

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

Так что советую протестировать свои наработки. Несмотря на ПВА или момент.

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

Приятных выходных!

Ответить
2

Я не могу понять, сколько ещё надо мегабит скорости, чтобы мы забыли об оптимизации? Не в целом, а вот в такой частности, когда надо усираться ради лайтхауса, который считает, что сайт установки окон в Мухосранске должен быстро грузиться на скорости 2G в стране третьего мира на мобильнике 2003 года? Такой всё это бред. Давно ли вы открывали сайт 4лапы? Типичное тормозное фуфло на битриксе, однако свою роль выполняет. 🤦‍♂️

Ответить
0

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

Ответить
1

Омг. ) 9 секунд на что? )
Вот вам инструмент - https://www.webpagetest.org/
Если ваш сайт набирает Speed Index при тех или иных настройках более 1000, значит он тормозит и надо что-то делать.

Ответить
0

Интересный инструмент. Сейчас попробую. Вот только незадача))): Google для определения скорости загрузки сайта пользуется своим упоротым PageSpeed Insights, и сайты оценивает по нему. Да и Яша от него тоже далеко не отходит...) 

Ответить
0

Вот тоже прикольный инструмент https://tools.pingdom.com/ 

Ответить
0

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

Ответить
0

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

Также с вами соглашусь, что на вкус и цвет фломастеры все разные)

Ответить
0

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

Ответить
0

Сообщение удалено

Ответить
0

Слишком умная статья для vc.ru. Про это лучше писать на хабре.

Ответить

Комментарии

null