Сопровождение и развитие

Контент-маркетинг стал одним из ключевых инструментов поддержки, сопровождения и развития веб-сервисов. Однако создавать статьи, которые не только интересны, но и приводят к продажам, — задача непростая. Важно грамотно и удобно упаковывать информацию и, конечно же, делать это системно, чтобы достигать высокой конверсии.. В Цифровом Элементе мы нашли способ упростить этот процесс для вашего бизнеса: делимся опытом, показываем решения и рассказываем, как сделать контент действительно работающим. Содержание Посадочные страницы, лонгриды Конструктор посадочных страниц Как сделать посадочную страницу для БУС в стороннем сервисе Вывод Посадочные страницы, лонгриды И так, давайте сперва разберёмся с понятиями. Посадочные страницы (целевые страницы, лендинги или landing page) используют для сбора данных посетителей, оформления покупки, регистрации и других действий. Универсальных стандартов оформления нет, но чаще всего это длинная, адаптированная под любые устройства, красивая и быстрая страница. Лонгриды (long read) — это подача материала в формате текста, разбитого мультимедийными блоками (изображения, видео, веб-элементы). Их цель — удержать внимание читателя до конца статьи. Здесь тоже нет строгих правил. Назначение у посадочных страниц и лонгридов разное, но технически они устроены одинаково: каждая состоит из блоков с пользовательским контентом. Прежде чем рассказать о нашем решении, посмотрим, какие инструменты для создания таких страниц уже существуют. Компания Цифровой Элемент уже много лет разрабатывает сайты на платформе 1С-Битрикс:Управление сайтом и является золотым сертифицированным партнёром 1С-Битрикс. В далеком прошлом (лет 10 назад) перед нашей командой разработки встала задача — создать собственный конструктор посадочных страниц. Задача оказалась довольно интересной и очень полезной в будущем. Конструктор посадочных страниц Как сделать конструктор красивых посадочных страниц на Битриксе? Сниппеты Самый простой способ — работать с набором сниппетов. В 1С-Битрикс сниппет — это готовый фрагмент кода или разметки (HTML, PHP, иногда с элементами шаблонов Битрикса), который можно вставить в визуальный редактор страницы. Он служит для ускорения работы редакторов и контент-менеджеров: вместо того чтобы писать код вручную, достаточно выбрать нужный сниппет из списка, и в текст автоматически подставится заранее заготовленный блок — например, кнопка, таблица, форма или любой другой элемент интерфейса. Таким образом, сниппеты позволяют: стандартизировать оформление типовых элементов, снизить вероятность ошибок при ручной верстке, немного ускорить работу с контентом. Пример сниппетов Плюсы сниппетов в 1С-Битрикс Простота использования — сниппет можно вставить буквально в пару кликов, без знания кода (если пользоваться готовыми заготовками). Скорость работы редактора — вставка готового блока занимает секунды, а не минуты, как при ручной верстке. Гибкость — можно создавать собственные сниппеты под конкретные задачи компании, накапливая библиотеку типовых блоков. Единый стиль — за счет повторного использования одних и тех же сниппетов страницы выглядят более целостно и аккуратно. Минимальная нагрузка на сайт — сниппеты после вставки становятся частью HTML-страницы, поэтому загружаются очень быстро. Доступность — инструмент встроен в систему, не требует отдельной установки или дополнительных модулей. Подходит для прототипирования — можно быстро собрать черновик страницы или лендинга без долгой верстки. При использовании сниппетов в 1С-Битрикс нужно учитывать ряд особенностей: Легко сломать, особенно через визуальный редактор. Изменения приходится вносить вручную на всех страницах. Удаление и правки возможны только с HTML-знаниями. Нет параметров и наследования — каждый блок создаётся отдельно. Нет поддержки адаптивных изображений. Копирование создаёт независимые дубликаты контента. Компоненты Когда данные уже хранятся в базе сайта на Битриксе (например, в каталоге, справочнике или инфоблоке), логично использовать для их вывода компоненты. Благодаря параметрам компонентов можно создавать универсальные блоки. Так, один и тот же компонент способен формировать разные варианты: “2 картинки плиткой”, “4 картинки плиткой”, “8 картинок плиткой” — достаточно просто указать нужное значение параметра “количество картинок”. В 1С-Битрикс компонент — это готовый функциональный модуль, который выполняет определенную задачу на сайте и выводит результат прямо на страницу. Он состоит из двух частей: логики (PHP-код, который получает и обрабатывает данные, например, из инфоблока или каталога), шаблона (HTML/JS/CSS-оформление того, как эти данные показываются пользователю). Благодаря параметрам компоненты можно настраивать под разные сценарии — от простого списка новостей до сложных каталогов с фильтрацией и корзиной. По сути, это строительные блоки Битрикса: из них собирается сайт, и каждый блок отвечает за свой участок функционала. Пример компонента Плюсы компонентов в 1С-Битрикс Универсальность — один компонент можно использовать для разных задач, меняя только параметры (например, количество элементов или источник данных). Автоматизация — данные подтягиваются напрямую из базы (инфоблоков, каталогов, справочников), не нужно вставлять и обновлять их вручную. Гибкость настроек — можно управлять выводом: сортировкой, количеством элементов, отображаемыми полями, фильтрацией. Повторное использование — один и тот же компонент можно подключать на разные страницы без дублирования кода и контента. Целостность данных — при изменении информации в базе она автоматически обновляется во всех местах, где используется компонент. Масштабируемость — удобно создавать новые блоки и страницы на основе готовых шаблонов. Поддержка кэширования — несмотря на минусы в скорости, при грамотной настройке кэша можно значительно ускорить работу компонентов. Интеграция — легко связать с другими функциями Битрикса (формами, каталогами, CRM и т.д.). Однако есть ряд особенностей такого подхода, которые нужно учитывать: Результат видно только после сохранения страницы. Контент нужно опубликовать, чтобы увидеть его вживую. Копирование требует переноса и страницы, и данных. Работа медленнее из-за запросов к БД и кэшу. Инфоблок и один компонент Еще один вариант реализации конструктора посадочных страниц в 1С-Битрикс:Управление сайтом — это отказаться от визуального редактора и построить страницы на основе отдельного инфоблока. Логика проста: Раздел ИБ = страница Элемент ИБ = блок страницы Вывод блоков выполняет компонент bitrix:catalog.section, которому в параметрах задается ID нужного раздела (страницы). У каждого элемента есть свойство “Тип” — оно определяет, какие данные хранятся и как именно шаблон компонента отобразит блок. У этого подхода также есть свои нюансы: Страницу можно увидеть только в публичной части после сохранения данных. Копирование работает частично — без доработок или решений из Маркетплейса изображения не перенесутся. Для настройки инфоблока и шаблонов потребуется программист. Встроенный поиск Битрикса либо не увидит такие страницы, либо создаст битые ссылки без серьёзной доработки. Как сделать посадочную страницу для БУС в стороннем сервисе Сегодня существует множество инструментов для создания посадочных страниц, лонгридов и даже целых сайтов. Чаще всего они работают на отдельном домене или поддомене, что неудобно для проектов на Битриксе — интеграция возможна только через поддомены. Среди популярных решений — Tilda, Wix, LP Generator и так далее. Некоторые сервисы, например Tilda, позволяют экспортировать результат в архив с исходным кодом (HTML, CSS, JS). Но прямой интеграции с 1С-Битрикс нет: файлы приходится вручную загружать на сайт, а при каждом изменении страницы повторять процедуру заново. Это проблема для автоматизации. Мы познакомились с Tilda уже после старта собственной разработки и увидели ключевые преимущества нашего конструктора: автоматическая адаптивность изображений под разные устройства; блоки, выполненные в фирменном стиле компании; отсутствие ручного экспорта-импорта при любом изменении; работа напрямую с базой данных сайта — формы сохраняются сразу, примеры и инфографика строятся на реальных данных из инфоблоков. Наше решение позволяет глубоко интегрировать контент в бизнес-процессы. Вывод В таблице мы собрали результаты исследования и собственного опыта: сравнили три подхода и отметили их ключевые особенности, чтобы вам было проще выбрать решение под свою задачу. Сниппеты Компоненты Инфоблок Сторонний сервис Визуальное редактирование Да Нет Нет Да Необходимость знания HTML Да Нет Нет Нет Простое копирование страниц Да Нет Нет Нет Адаптивный дизайн и изображения Сложно Да Да Да Скорость работы Очень быстро Быстро Быстро Быстро Настройки используемых блоков Нет Да Да Да Внутренний поиск 1С-Битрикс Да Нет Нет Нет Выбор оптимального решения для создания посадочных страниц и лонгридов на платформе 1С-Битрикс всегда зависит от конкретных бизнес-задач, технических ресурсов и желаемой скорости реализации. Сниппеты остаются простым вариантом для базовых задач, компоненты предлагают больше возможностей для сложных автоматизированных проектов, а сторонние сервисы позволяют работать без привлечения разработчиков, хотя и ограничивают интеграционные возможности. Ключевым фактором выбора является степень интеграции инструмента с вашей CRM-системой, каталогом товаров и другими бизнес-процессами. Разработанное нами решение сочетает визуальную простоту конструктора с функциональностью платформы Битрикс, помогая создавать не просто привлекательный, но и реально работающий контент для достижения бизнес-целей. Сопровождение и развитие Заказать услугу Статьи по теме: Интеграция Битрикс24 и 1С: автоматизация бизнеса, обмен данными, настройка синхронизации Как настроить воронку продаж в Битрикс24 Как настроить источники в Битрикс24

Скорость загрузки страниц — один из ключевых факторов, влияющих на успех сайта в интернете. Она влияет на пользовательский опыт, конверсию и SEO. Google учло это уже в 2010 году, сделав скорость загрузки фактором ранжирования. В 2018 году метрики были расширены, а в 2020 — дополнены новыми обновлениями. На сегодняшний день проверка скорости загрузки сайта стала обязательной практикой для всех, кто стремится улучшить производительность своего ресурса. Существует множество инструментов для проверки скорости сайта, которые помогают определить текущие показатели и выявить факторы, влияющие на скорость сайта. Однако одного измерения недостаточно — важно понимать, как ускорить загрузку страницы и какие методы оптимизации наиболее эффективны. В этой статье разберём, как оценить скорость загрузки страниц, какие показатели важны сегодня и что делать, чтобы ускорить сайт. Содержание Что такое скорость загрузки Скорость загрузки основного контента (LCP) Время ожидания до первого взаимодействия с контентом (FID) Совокупное смещение макета (CLS) Как измерить скорость страницы Как улучшить скорость загрузки сайта Вывод Основные метрики скорости загрузки страницы Скорость загрузки страницы — это не просто время, за которое пользователь видит первый пиксель или взаимодействует с элементом интерфейса. Она включает в себя множество параметров, которые Google объединил в метрики Core Web Vitals («Основные интернет-показатели»). Эти метрики измеряют не только технические аспекты, но и восприятие скорости пользователем. Основные метрики Core Web Vitals: LCP (Largest Contentful Paint) — время загрузки самого большого элемента в видимой области. FID (First Input Delay) — время, необходимое для отклика страницы на первое взаимодействие пользователя. CLS (Cumulative Layout Shift) — стабильность макета во время загрузки. Эти показатели помогают оценить, насколько комфортно пользователю работать с сайтом, а не только как быстро он загружается технически. Скорость загрузки основного контента (LCP) LCP — это время, необходимое для загрузки самого большого элемента, который видит пользователь при открытии страницы. Обычно это изображение или текстовый блок, занимающий основное место на экране. Рекомендованные значения для LCP: Хорошо: до 2,5 секунд; Нужно улучшить: 2,5–4 секунды; Плохо: более 4 секунд. Что влияет на LCP: Изображения: оптимизация изображений (формат WebP или AVIF, адаптивные размеры, сжатие) — важнейший шаг. AVIF обеспечивает лучшее сжатие, чем WebP (до 50% экономии), и поддерживается современными браузерами. <picture>> <source srcset="image.avif" type="image/avif">> <source srcset="image.webp" type="image/webp">> <img src="image.jpg" alt="..." width="800" height="600">> </picture>> Время отклика сервера: использование CDN, уменьшение размера ответа сервера и оптимизация базы данных. Код, блокирующий рендеринг: минимизация и асинхронная загрузка CSS и JavaScript. Клиентский рендеринг: оптимизация шрифтов и уменьшение использования тяжелых библиотек. Совет: Используйте инструменты, такие как Google PageSpeed Insights, чтобы определить, что именно замедляет загрузку главного контента. Время ожидания до первого взаимодействия с контентом (FID) FID — это время задержки между отображением интерактивного элемента на странице и моментом, когда он становится функциональным. Например, кнопка может быть видна на экране, но при нажатии на неё пользователь не получает мгновенной реакции. Рекомендованные значения для FID: Хорошо: до 100 миллисекунд; Нужно улучшить: 100–300 миллисекунд; Плохо: более 300 миллисекунд. Что влияет на FID: Объём JavaScript: избыточный или плохо оптимизированный код замедляет обработку взаимодействий. Асинхронная загрузка: использование технологии async и defer для скриптов. Разделение кода: модульный подход помогает снизить время обработки кода. Использование Intersection Observer: для ленивой загрузки. Intersection Observer – это более гибкий способ, чем loading="lazy", особенно для динамического контента. Однако следует помнить, что в случае с изображениями, хорошей практикой для поисковой оптимизации считается оставлять актуальный `src` либо его сжатую легковесную копию. Пример кода: const observer = new IntersectionObserver((entries) => { entries.forEach(entry => { if (entry.isIntersecting) { const img = entry.target; img.src = img.dataset.src; observer.unobserve(img); } }); }); document.querySelectorAll('img[data-src]').forEach(img => { observer.observe(img); }); Совет: Инструмент Lighthouse в Google Chrome поможет выявить проблемные места и оптимизировать их. Совокупное смещение макета (CLS) CLS измеряет стабильность макета страницы. Если элементы на странице перемещаются в процессе загрузки, это создаёт негативный пользовательский опыт. Например, пользователь может попытаться кликнуть на ссылку, но из-за смещения случайно нажать на другое место. Рекомендованные значения для CLS: Хорошо: менее 0,1; Нужно улучшить: 0,1–0,25; Плохо: более 0,25. Что влияет на CLS: Отсутствие размеров у медиафайлов: не указанные размеры изображений и видео приводят к скачкам. Загрузка рекламы: баннеры и сторонние виджеты часто появляются с задержкой, вызывая смещение контента. Порядок загрузки: контент должен загружаться сверху вниз. Резервирование места для рекламных блоков. Если реклама загружается позже, задайте фиксированные размеры для контейнера. При этом старайтесь избегать использования `ad`, `adv` и иных производных словоформ в названии HTML-классов и ID, так как они могут блокироваться косметическим фильтром блокировщика рекламы со стороны пользователя. Пример CSS: .special-container { width: 300px; height: 250px; background: #f0f0f0; } Совет: Укажите фиксированные размеры для всех медиафайлов и избегайте динамической вставки контента без предварительной разметки. Инструменты для проверки скорости сайта Google предоставляет несколько инструментов для анализа скорости загрузки и оценки Core Web Vitals: Google PageSpeed Insights: даёт подробный отчёт по каждой метрике и рекомендации по их улучшению. Google Search Console: позволяет просматривать отчёты по всем страницам сайта, выделяя те, которые нуждаются в оптимизации. Web Vitals Extension: удобное расширение для браузера, которое показывает основные показатели в реальном времени. WebPageTest — позволяет тестировать скорость из разных локаций и на разных устройствах. Lighthouse CLI — интеграция в CI/CD для автоматической проверки производительности. Пример использования Lighthouse CLI: lighthouse https://example.com --output=html --output-path=./report.html Особенности использования инструментов: Лабораторные и полевые данные: лабораторные данные (например, TBT — Total Blocking Time) полезны для отладки, но Google учитывает только полевые данные. Анализ множества страниц: большинство инструментов работают с отдельными страницами, что может затруднять анализ больших сайтов. Совет: Для комплексного анализа используйте WebSite Auditor. Этот инструмент позволяет проверять все страницы сайта на соответствие Core Web Vitals, формировать отчёты и давать рекомендации по оптимизации. Как работать с WebSite Auditor: Введите ключ API и выполните SEO-анализ структуры сайта. Найдите раздел Page Speed и изучите общие отчёты по скорости. В режиме «Страницы» просмотрите список проблем и рекомендации для каждой страницы. Нажав на конкретную страницу, получите список элементов, требующих оптимизации. Как ускорить загрузку сайта Теперь, когда вы собрали список страниц с низкой скоростью загрузки, пора сосредоточиться на оптимизации. Ниже представлены основные рекомендации и практические советы по их применению. 1. Установите размеры изображений Указание размеров изображений в коде помогает браузеру заранее зарезервировать место, исключая смещение контента и улучшая показатель CLS. Пример корректного кода: <img src="pillow.jpg" width="640" height="360" alt="purple pillow with flower pattern" /> 2. Используйте современные форматы изображений Отдавайте предпочтение формату WebP, который обеспечивает более эффективное сжатие без потери качества, снижая вес файлов на 25–35 % по сравнению с JPEG и PNG. Создать WebP-версии можно с помощью плагинов (например, Imagify для WordPress) или конвертеров. Проверить поддержку браузером webp можно посредством тега picture и, в случае ее отсутствия вывести альтернативный формат: <picture> <source srcset="img.webp" type="image/webp"> <source srcset="img.jpg" type="image/jpeg"> <img alt=”” width=”640” height=”480” loading=”lazy” src="img.jpg"> </picture> 3. Сжимайте изображения Даже если вы используете современные форматы, сжатие позволяет уменьшить общий размер файлgов. Инструменты вроде TinyPNG помогают сократить вес изображений до 70 %. Пользователям WordPress подойдут плагины WP Smush или аналогичные. 4. Загружайте отдельные версии изображений для разных устройств Дизайны мобильной, планшетной и ПК-версии сайтов могут сильно разниться, поэтому одно и то же изображение можно загружать в разных размерах и, соответственно, с разным весом, что улучшает скорость загрузки источника: <picture> <source media="(min-width: 768px)" srcset="tablet_image.png"> <source media="(min-width: 1024px)" srcset="desktop_image.png"> <img src="mobile_image.png" alt=""> </picture> 5. Откладывание закадровых изображений Закадровые изображения (те, что вне видимой области) нужно загружать позже. Это позволяет сосредоточить ресурсы на элементах, видимых сразу после загрузки. Для отложенной загрузки изображений существует специальный атрибут loading, который сообщает браузеру о том, что исходный файл изображения следует загружать только по мере попадания в область видимости: <img src="pillow.jpg" width="640" height="360" alt="purple pillow with flower pattern" loading=”lazy” /> Изображения, которые будут востребованы пользователем позднее, могут быть также предварительно загружены с помощью специального тега link, размещаемого в секции head. При этом можно дополнительно указать, на каком именно расширении необходима данная картинка: <link rel=”preload” as=”image” href=”mobileBanner.png” media=”(max-width: 768px)” /> <link rel=”preload” as=”image” href=”desktopBanner.png” media=”(min-width: 1600px)” /> 6. Конвертируйте GIF в видео Видеофайлы легче GIF-анимаций. Используйте форматы WebM и MP4, указав оба варианта для совместимости: <video autoplay loop muted playsinline> <source src="animation.webm" type="video/webm"> <source src="animation.mp4" type="video/mp4"> </video> 7. Удалите неиспользуемый CSS Неиспользуемые фрагменты CSS замедляют построение страницы. Используйте инструменты, такие как DevTools, для определения ненужных стилей. Удалите их или перенесите в некритичные загрузки. div { display: flex; display: -ms-flex; // для современных браузеров вендорные префиксы уже не нужны } 8. Минимизируйте JS и CSS Удалите пробелы, комментарии и ненужные символы из JS и CSS файлов. Для небольших сайтов подойдут онлайн-инструменты вроде CSS Minifier, для WordPress — соответствующие плагины. 9. Извлечение критического CSS Переместите стили, необходимые для отображения верхней части страницы, в <head> HTML-документа, а остальные загрузите асинхронно. <head> <style id=”critical”> /* критические стили */ </style> </head> <body> <script> function onStyleLoad() { // блок критических стилей удаляется после загрузки файла стилей document.getElementById(“critical”).remove(); } </script> <!-- ссылка на файл стилей ближе к концу body —> <link rel=”stylesheet” href=”bundle.css” onload=”onStyleLoad();” /> </body> 10. Улучшите время отклика сервера Медленный сервер может быть результатом ограниченных ресурсов или плохого хостинга. Рассмотрите возможность перехода на более качественный или управляемый хостинг с CDN. 11. Асинхронный JS Сторонние ресурсы, такие как кнопки социальных сетей, могут замедлять загрузку. Используйте атрибуты async или defer, чтобы улучшить производительность. async загружает скрипт параллельно с HTML. defer выполняет скрипт после завершения загрузки HTML. 12. Предварительное подключение к сторонним ресурсам Используйте тег <link rel="preconnect">, чтобы заранее устанавливать соединения с необходимыми ресурсами, что ускоряет их загрузку: <link rel="preconnect" href="https://example.com"> 13. Разделите длинные задачи Длинные фрагменты JS, выполняемые более 50 мс, могут снижать отзывчивость. Используйте DevTools для их выявления и разбивайте на более короткие сегменты. 14. Разделение кода на отдельные bundle Современные сборщики позволяют разделять большие файлы JS и CSS на более маленькие посредством использования динамического импорта и подгружать данный код только тогда, когда это необходимо пользователю: js const moduleA = import(“moduleA.js”); // при правильной настройке сборщика для данного модуля будет создан отдельный JavaScript-файл 15. Предварительная загрузка ключевых ресурсов Используйте тег <link rel="preload">, чтобы указать браузеру приоритет загрузки определенных ресурсов, например: <link rel="preload" as="script" href="script.js"> <link rel="preload" as="style" href="style.css"> 16. Включите кэширование Кэширование ресурсов сокращает время загрузки при повторных посещениях сайта. Настройте HTTP-заголовки для управления кэшированием. 17. Уменьшите размер DOM Сложные структуры DOM замедляют загрузку. Поддерживайте дерево DOM с глубиной не более 32 узлов и 60 дочерними узлами для каждого родителя. 18. Минимизируйте редиректы Уменьшите количество перенаправлений. Каждый редирект добавляет задержки при загрузке страницы. 19. Оптимизация шрифтов с помощью font-display: swap; Это предотвращает блокировку рендеринга текста. ПримерCSS: @font-face { font-family: 'MyFont'; src: url('myfont.woff2') format('woff2'); font-display: swap; } 20. Внедрение HTTP/3 для ускорения передачи данных. HTTP/3 использует QUIC-протокол, уменьшающий задержки. Пример настройки для Nginx: server { listen 443 quic reuseport; listen 443 ssl; ssl_protocols TLSv1.3; add_header Alt-Svc 'h3=":443"; ma=86400'; } 21. Использование Service Workers для кэширования. Пример кода (JavaScript): self.addEventListener('install', (event) => { event.waitUntil( caches.open('v1').then((cache) => { return cache.addAll(['/critical.css', '/main.js']); }) ); }); 22. Tree Shaking для удаления неиспользуемого JS-кода. Пример настройки в Webpack: // webpack.config.js module.exports = { mode: 'production', optimization: { usedExports: true, }, }; 23. Настройка Brotli-сжатия на сервере. Пример для Nginx: gzip on; gzip_types text/plain text/css application/json application/javascript; brotli on; brotli_types text/plain text/css application/json application/javascript; Следуя этим рекомендациям, вы сможете значительно улучшить скорость загрузки сайта и повысить его производительность. Вывод Оптимизация скорости загрузки страниц — это важная составляющая успешного функционирования сайта, которая напрямую влияет на пользовательский опыт, позиции в поисковой выдаче и конверсии. Перечисленные выше проблемы являются наиболее распространёнными, и их устранение зачастую даёт значительные улучшения в работе ресурса. Однако это далеко не исчерпывающий список факторов, влияющих на скорость загрузки. В процессе анализа могут быть выявлены и другие технические проблемы, требующие внимания. Важно отметить, что многие из таких проблем характерны сразу для нескольких или даже всех страниц сайта. Это позволяет решать их массово, что экономит время и ресурсы на оптимизацию. Например, внедрение адаптивных изображений, настройка кеширования или оптимизация CSS и JavaScript могут быть выполнены централизованно, охватывая весь ресурс. Компания «Цифровой Элемент» поможет выявить узкие места вашего сайта, влияющие на скорость его загрузки, и предложит решения, соответствующие современным стандартам веб-разработки. Специалисты компании проведут комплексный аудит, оптимизируют файлы, настроят серверные параметры и обеспечат высокую производительность сайта. Благодаря профессиональному подходу к оптимизации, ваш сайт будет работать быстрее, что положительно скажется на его рейтингах и удовлетворенности пользователей. Статьи по теме: Атака на 1С-Битрикс, рекомендации по защите сайта Безопасность сайта: поиск вирусов и троянов Перевод сайта на 1C-Битрикс на PHP 8.x: пошаговая инструкция Как защитить сайт на WordPress от вирусов и хакеров

Программирование — это искусство. Каждый разработчик, вооружённый своими знаниями, внутренними стандартами и установленными дедлайнами, создает что-то уникальное. Однако в командной разработке важно не просто творить, а создавать работающий код, который будет понятен другим членам команды. Представления о качественном коде могут варьироваться даже у программистов с одинаковым опытом и образованием. В рамках этой статьи под качественным кодом будем понимать: Корректность — код должен соответствовать стандартам платформы и избегать очевидных ошибок, таких как запросы к базе данных внутри циклов или логики внутри шаблонов. Совместимость — обеспечение работы с актуальными версиями PHP и других используемых пакетов, модулей. Единые стандарты — следование принятому в команде соглашению о стиле кодирования. Защищённость — отсутствие уязвимостей, таких как XSS, CSRF, выполнение загруженных файлов от пользователя. Оптимальность — исключение неоптимальных решений, усложняющих поддержку проекта. В команде чаще всего именно тимлиды берут на себя задачу контроля качества кода, но их время ограничено, а менее опытные разработчики могут допускать ошибки. Здесь на помощь приходят автоматизированные процессы. В этой статье мы поделимся с вами нашим опытом обеспечения качества программного кода на PHP, которое мы применяем у нас в команде. Критерии качественного кода Для достижения стабильного качества кода важно внедрить в команде следующие методологии: Версионирование — использование систем контроля версий (Git). Тестирование — написание модульных и интеграционных тестов для проверки функционала. Code Review — регулярная проверка кода другими членами команды. Continuous Integration — автоматизация сборки и тестирования кода при каждом изменении. Линтеры в IDE - проверка кода в программе в момент его написания в программе, которую используют разработчики. Как повысить качество кода Рассмотрим инструменты, которые помогут автоматизировать проверку кода при разработке на PHP. В нашем случае папка local для битрикса лежит в отдельном репозитории и проверяем мы её отдельно. Все конфиги будем рассматривать внутри этой папки. Инструменты анализа кода 1. PHP Code Sniffer Что делает: Проверяет PHP, CSS и JavaScript на соответствие стандартам кодирования. Поддерживает кастомные правила. Широко используется благодаря удобству и гибкости. Используем для: Инструмент чистит оформление кода, исправляет short_tags, проверяет наличие и корректность PHPDoc. Логику не проверяет. Используем для форматирования только. Пример команды запуска для анализа: bash .\vendor\bin\phpcs > check.txt Пример команды запуска для автоисправления: bash .\vendor\bin\phpcbf Пример файла конфигурации (phpcs.xml): xml <?xml version="1.0"?> <ruleset xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot; name="PHP_CodeSniffer" xsi:noNamespaceSchemaLocation="phpcs.xsd"> <file>.</file> <arg name="basepath" value="."/> <arg name="extensions" value="php"/> <arg name="colors"/> <exclude-pattern>/php_interface/migrations/*</exclude-pattern> <exclude-pattern>/vendor/*</exclude-pattern> <!-- Include the whole PEAR standard --> <rule ref="PEAR"> <exclude name="PEAR.NamingConventions.ValidFunctionName"/> <exclude name="PEAR.NamingConventions.ValidVariableName"/> <exclude name="PEAR.Commenting.ClassComment"/> <exclude name="PEAR.Commenting.FileComment.MissingCategoryTag"/> <exclude name="PEAR.Commenting.FileComment.MissingPackageTag"/> <exclude name="PEAR.Commenting.FileComment.MissingLinkTag"/> <exclude name="PEAR.Commenting.FileComment.MissingVersion"/> <exclude name="PEAR.Commenting.InlineComment"/> <exclude name="PEAR.Commenting.FileComment.Missing"/> <exclude name="Generic.Commenting.DocComment.MissingShort"/> </rule> <!-- Include some sniffs from other standards that don't conflict with PEAR --> <rule ref="Squiz.Arrays.ArrayBracketSpacing"/> <rule ref="Squiz.Arrays.ArrayDeclaration"/> <rule ref="Squiz.Commenting.ClosingDeclarationComment"/> <rule ref="Squiz.ControlStructures.ControlSignature"/> <rule ref="Squiz.ControlStructures.ElseIfDeclaration"/> <rule ref="Squiz.Commenting.BlockComment"/> <rule ref="Squiz.Commenting.DocCommentAlignment"/> <rule ref="Squiz.Commenting.EmptyCatchComment"/> <rule ref="Squiz.Commenting.InlineComment"/> <rule ref="Squiz.Commenting.LongConditionClosingComment"/> <rule ref="Squiz.Commenting.PostStatementComment"/> <rule ref="Squiz.Commenting.VariableComment"/> <rule ref="Squiz.Formatting.OperatorBracket"/> <rule ref="Squiz.Functions.FunctionDeclarationArgumentSpacing"/> <rule ref="Squiz.Operators.ComparisonOperatorUsage"> <exclude name="Squiz.Operators.ComparisonOperatorUsage.NotAllowed"/> <exclude name="Squiz.Operators.ComparisonOperatorUsage.ImplicitTrue"/> </rule> <rule ref="Squiz.PHP.DisallowInlineIf"/> <rule ref="Squiz.Scope.MethodScope"/> <rule ref="Squiz.Strings.ConcatenationSpacing"/> <rule ref="Squiz.WhiteSpace.ControlStructureSpacing"/> <rule ref="Squiz.WhiteSpace.FunctionClosingBraceSpace"/> <rule ref="Squiz.WhiteSpace.FunctionSpacing"/> <rule ref="Squiz.WhiteSpace.MemberVarSpacing"/> <rule ref="Squiz.WhiteSpace.OperatorSpacing"/> <rule ref="Squiz.WhiteSpace.SuperfluousWhitespace"/> <rule ref="Generic.Arrays.DisallowLongArraySyntax"/> <rule ref="Generic.Commenting.Todo"/> <rule ref="Generic.ControlStructures.DisallowYodaConditions"/> <rule ref="Generic.ControlStructures.InlineControlStructure"/> <rule ref="Generic.Formatting.DisallowMultipleStatements"/> <rule ref="Generic.Formatting.SpaceAfterCast"/> <rule ref="Generic.NamingConventions.ConstructorName"/> <rule ref="Generic.PHP.DeprecatedFunctions"/> <rule ref="Generic.PHP.LowerCaseKeyword"/> <rule ref="Generic.Strings.UnnecessaryStringConcat"/> <rule ref="Generic.WhiteSpace.IncrementDecrementSpacing"/> <rule ref="PSR2.Classes.PropertyDeclaration"/> <rule ref="PSR2.Methods.MethodDeclaration"/> <rule ref="PSR2.Files.EndFileNewline"/> <rule ref="PSR12.Files.OpenTag"/> <rule ref="Zend.Files.ClosingTag"/> <!-- PEAR uses warnings for inline control structures, so switch back to errors --> <rule ref="Generic.ControlStructures.InlineControlStructure"> <properties> <property name="error" value="true"/> </properties> </rule> <!-- We use custom indent rules for arrays --> <rule ref="Generic.Arrays.ArrayIndent"/> <rule ref="Squiz.Arrays.ArrayDeclaration.KeyNotAligned"> <severity>0</severity> </rule> <rule ref="Squiz.Arrays.ArrayDeclaration.ValueNotAligned"> <severity>0</severity> </rule> <rule ref="Squiz.Arrays.ArrayDeclaration.CloseBraceNotAligned"> <severity>0</severity> </rule> <rule ref="Squiz.Arrays.ArrayDeclaration.CloseBraceNewLine"> <severity>0</severity> </rule> <!-- Check var names, but we don't want leading underscores for private vars --> <rule ref="Squiz.NamingConventions.ValidVariableName"/> <rule ref="Squiz.NamingConventions.ValidVariableName.PrivateNoUnderscore"> <severity>0</severity> </rule> <!-- Only one argument per line in multi-line function calls --> <rule ref="PEAR.Functions.FunctionCallSignature"> <properties> <property name="allowMultipleArguments" value="false"/> </properties> </rule> <!-- Have 12 chars padding maximum and always show as errors --> <rule ref="Generic.Formatting.MultipleStatementAlignment"> <properties> <property name="maxPadding" value="12"/> <property name="error" value="true"/> </properties> </rule> <!-- Ban some functions --> <rule ref="Generic.PHP.ForbiddenFunctions"> <properties> <property name="forbiddenFunctions" type="array"> <element key="sizeof" value="count"/> <element key="delete" value="unset"/> <element key="print" value="echo"/> <element key="is_null" value="null"/> <element key="create_function" value="null"/> </property> </properties> </rule> <!-- Private methods MUST not be prefixed with an underscore --> <rule ref="PSR2.Methods.MethodDeclaration.Underscore"> <type>error</type> </rule> <!-- Private properties MUST not be prefixed with an underscore --> <rule ref="PSR2.Classes.PropertyDeclaration.Underscore"> <type>error</type> </rule> <!-- The testing bootstrap file uses string concats to stop IDEs seeing the class aliases --> <rule ref="Generic.Strings.UnnecessaryStringConcat"> <exclude-pattern>tests/bootstrap\.php</exclude-pattern> </rule> <!-- This test file specifically *needs* Windows line endings for testing purposes. --> <rule ref="Generic.Files.LineEndings.InvalidEOLChar"> <exclude-pattern>tests/Core/Tokenizer/StableCommentWhitespaceWinTest\.php</exclude-pattern> </rule> <rule ref="Generic.PHP.DisallowShortOpenTag"> <exclude name="Generic.PHP.DisallowShortOpenTag.EchoFound" /> </rule> <rule ref="Internal.NoCodeFound"> <severity>0</severity> </rule> <rule ref="Generic.Files.LineLength"> <properties> <property name="lineLimit" value="1110" /> <property name="absoluteLineLimit" value="0" /> </properties> </rule> </ruleset> 2.PHP Mess Detector (PHPMD) Ищет неиспользуемые переменные, избыточную сложность и другие проблемы. Генерирует отчёты в текстовом, HTML или XML-формате. Для нас: Отслеживаем названия методов, переменных, правила SOLID. Следим за чистотой кода. Пример запуска в формате html: bash php phpmd.phar . html phpmd.xml > phpmd_file.html Пример запуска в формате xml: bash php phpmd.phar . xml phpmd.xml > phpmd_file.xml Пример файла конфигурации (phpmd.xml): xml <?xml version="1.0" encoding="UTF-8"?> <ruleset name="My first PHPMD rule set" xmlns="https://phpmd.org/xml/ruleset/1.0.0&quot; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot; xsi:schemaLocation="https://phpmd.org/xml/ruleset/1.0.0.xsd&quot; xsi:noNamespaceSchemaLocation="http://phpmd.org/xml/ruleset_xml_schema_1.0.0.xsd&quot;&gt; <rule ref="rulesets/codesize.xml" /> <rule ref="rulesets/cleancode.xml"> <exclude name="StaticAccess" /> </rule> <rule ref="rulesets/controversial.xml" /> <rule ref="rulesets/design.xml" /> <rule ref="rulesets/naming.xml" /> <rule ref="rulesets/unusedcode.xml" /> <exclude-pattern>*vendor\*</exclude-pattern> <exclude-pattern>*vendor/*</exclude-pattern> <exclude-pattern>*php_interface\migrations\*.php</exclude-pattern> <exclude-pattern>*php_interface/migrations/*.php</exclude-pattern> </ruleset> 3. SonarLint SonarLint — это open-source-инструмент для анализа кода, который помогает выявлять и исправлять проблемы, связанные с безопасностью и качеством, прямо во время написания программного кода. Этот плагин поддерживает работу в различных интегрированных средах разработки (IDE), среди которых популярные решения, такие как IntelliJ IDEA, Eclipse и Visual Studio. Главная задача SonarLint — оперативно предупреждать разработчика о потенциальных проблемах в коде, включая уязвимости, ошибки и отклонения от лучших практик программирования. Инструмент работает в фоновом режиме, анализируя код непосредственно во время его написания или редактирования в IDE, и предоставляет мгновенную обратную связь, часто выделяя проблемные места прямо в редакторе. SonarLint входит в экосистему SonarQube, расширяя её возможности для разработчиков. Что нам позволяет SonarLint: Подсвечивает ошибки разработки Исправляет ошибки разработки Помечает возможные проблемы Проверяет правописание Проверяет стандарты разработки (PSR) 4. PHPStan PHPStan — статический анализатор кода для языка PHP, который проверяет код и выявляет ошибки без его выполнения. Анализатор анализирует типы, переменные, вызовы функций и другие шаблоны кода, чтобы найти несоответствия или потенциальные ошибки. Что нам позволяет PHPStan: Имеет несколько уровней проверки Проверяет логику кода Проверяет правильность вызова методов Проверяет что все переменные, классы, функции, методы, константы созданы и используются. Проверяет, что типизация соблюдается В своей практике используем его только для фреймворков. Очень подстраховывает. Код вызова bash vendor/bin/phpstan analyse . Анализ кода на совместимость с версиями PHP 1. Rector: больше, чем просто обновление версий PHP Автоматический перевод кода на новые версии PHP Rector умеет переводить сайты на более новые версии PHP практически в автоматическом режиме. Он анализирует код, находит устаревшие конструкции и заменяет их на современные аналоги, соответствующие выбранной версии PHP. Это значительно упрощает процесс обновления и снижает риск ошибок. Проверка и исправление phpDoc Инструмент проверяет корректность phpDoc-аннотаций, включая типы параметров, возвращаемые значения и описание методов. При необходимости Rector может автоматически исправить неточности, что особенно полезно для поддержания актуальной документации в больших проектах. Оптимизация кода с помощью "раннего return" Rector умеет преобразовывать вложенные условия в "ранние возвраты" (early returns), что делает код чище, понятнее и легче для поддержки. Например, вместо: if ($condition) { // Действия return $value; } else { return null; } Rector предложит: if (!$condition) { return null; } // Действия return $value; Миграция между фреймворками Rector позволяет автоматизировать переход с одного фреймворка на другой, например, с Laravel на Symfony или с устаревшего кода на современные стандарты. Он анализирует структуру проекта и вносит изменения в соответствии с правилами целевого фреймворка, значительно сокращая время и усилия, затрачиваемые на ручной рефакторинг. Связка с PHPStan для улучшения кода Комбинация Rector и PHPStan — это мощный дуэт для повышения качества кода. Сначала PHPStan выявляет проблемы: некорректные типы, неиспользуемые переменные, ошибки в вызовах методов и т.д. Затем Rector автоматически исправляет эти проблемы, применяя predefined-правила. После этого можно снова запустить PHPStan, чтобы убедиться, что все ошибки устранены. Такой итеративный подход особенно полезен для legacy-проектов, где ручное исправление кода может занять месяцы. Архитектурный рефакторинг Rector способен вносить изменения не только на уровне синтаксиса, но и на уровне архитектуры. Например: Переименование классов, методов и свойств в соответствии с новыми стандартами. Изменение структуры наследования. Выделение повторяющегося кода в отдельные компоненты. Однако стоит отметить, что Rector не перемещает файлы физически — для этого потребуются дополнительные инструменты, такие как rsync. Оптимизация кода Инструмент поддерживает множество правил для улучшения читаемости и производительности кода, таких как: Замена устаревших функций на современные аналоги. Упрощение условий (например, замена вложенных if на ранние возвраты). Удаление неиспользуемого кода. Поддержка PSR и других стандартов Rector помогает привести код в соответствие с актуальными стандартами, такими как PSR-12, автоматически исправляя отступы, оформление методов и другие стилистические элементы. Пример рабочего процесса с Rector и PHPStan Анализ кода Запустите PHPStan, чтобы получить список проблем: vendor/bin/phpstan analyse . Автоматическое исправление Примените Rector для устранения выявленных проблем: php vendor/bin/rector --dry-run > rector-report.txt php vendor/bin/rector Повторная проверка Запустите PHPStan снова, чтобы убедиться, что все ошибки исправлены: vendor/bin/phpstan analyse . Пример файла конфигурации (rector.php):