Ускоряем работу сайта на этапе разработки и обгоняем конкурентов в поиске
Приветствую!
В этой статье хочется обсудить такой важный параметр, как оптимизация скорости работы сайта на этапе разработки.
Поисковые системы потихоньку начинают давать всё больше значимости тому, как быстро работает сайт на смартфонах и ПК у пользователей.
В основном идею качества и здоровья сайта продвигает в массы Google.
Web Vitals — это именно его инициатива. Подробно в WV я углубляться не буду, есть куча статей на эту тему, кому интересно позалипать на технические термины — добро пожаловать на web.dev.
Яндекс по-прежнему отдаёт наибольший приоритет поведению пользователей, и именно оно зачастую решает нахождения сайта в топе результатов поиска.
Хотя в последнее время в Яндекс.Вебмастере появился блок с информацией о скорости сайта.
Как его вычисляет Яндекс, участвует ли это значение в формуле расчета ИКСа, и почему там именно 5 пунктов, никто пока не в курсе.
Факт остаётся фактом.
Если у вашего сайта и сайта вашего конкурента примерно одинаковая внутренняя оптимизация, примерно одинаковые закупки внешнего трафика, брендового трафика, ссылочный профиль, номенклатура, количество страниц, поведение, и множество других параметров, но у конкурента сайт работает быстрее, чем ваш, то конкурент будет ранжироваться в результатах поиска выше.
Готовь сани летом
На этапе разработки сайта мало кто вообще о чём-то задумывается, кроме того, как побыстрее сдать сайт заказчику и получить акты выполненных работ.
На моём опыте распределение примерно следующее: 1 из 50 заказчиков думает о скорости работы будущего сайта и полной внутренней оптимизации до запуска проекта и, как следствие, ставит нужные задачи программистам.
Даже не то что думает, а вообще подозревает, что такой параметр как скорость может играть какую-то роль.
Ну, как говорится, успех не для всех. Так что ловите несложную инструкцию и как можно скорее внедряйте это в свой сайт.
Ускоряем работу сайта самостоятельно
Включаем сжатие статических объектов.
Уверен, что малый процент читателей запускает или будет запускать свой сайт на выделенном сервере с самописной CMS, админкой и логикой.
Это далеко не дешёвое занятие, требующее определенных технических знаний, поэтому большинство разворачивает сайты на виртуальном сервере с платной или бесплатной CMS.
Обычно в ISP менеджере хостинг провайдера есть специальный раздел с настройками домена, где можно включить следующие опции.
Это самый простой и быстрый вариант требующий 0 знаний в области разработки. Кстати, рекомендую ставить уровень сжатия 6, чтобы сильно не нагружать CPU вашего сервера.
Включаем сжатие через файл. htaccess.
Тут возможно два варианта, если сервер поддерживает mod_deflate, то код будет такой:
А если не поддерживает, то будем использовать mod_gzip:
Чтобы проверить работает ли gzip-сжатие на вашем сайте, зайдите сюда www.giftofspeed.com/gzip-test/ и запустите тест.
Устранение CSS и JS, блокирующих отрисовку.
Многие думают, что залог зелёной зоны в PageSpeed Insights — это просто вес страницы. Типа, весит страница на сайте 50 мегабайт — плохо, весит 50 байт — жизнь удалась.
На самом деле всё не так. Общий вес документа напрямую не влияет на 100 баллов в тесте скорости. Вопрос в том, как быстро для пользователя будет отображен первый экран контента.
Поисковые системы хотят, чтобы пользователь как можно быстрее увидел контент сайта. Даже если там будут картинки по 20 мегабайт, это не играет никакой роли.
Так вот, некоторые CSS и JS могут серьёзно растягивать время до отображения контента страницы.
Тут возможны два варианта, в общем-то оба рабочие.
Оптимизации CSS и JS вручную на этапе разработки.
Все стили сайта размещаем сразу в теге Head без подключения через статические файлы.
Не используем внешние шрифты, типа Google Fonts. Всё это тормозит скорость отрисовки контента у конечных пользователей.
Если без каких-то внешних скриптов ваш сайт работать вообще не может, то все скрипты грузим асинхронно, пример:
Исключение: некоторые скрипты счетчиков аналитики, пиксели социальных сетей, GTM, скрипты внешних товарных каталогов, и прочие. При их изменении или доработке могут быть серьёзные искажения в аналитике и работе сайта в целом.
Все скрипты, которые работают корректно, объединяем и помещаем как можно ниже в коде сайта.
Подумайте, какие стили и скрипты можно загрузить позже, и реализуйте это.
Тут нам понадобятся атрибуты defer, async, тег script, и несколько часов работы.
Ускорить производительность сайта можно с помощью тега preload. Этот тег указывает, какие ресурсы понадобятся страницам сайта в ближайшие несколько секунд, и загружает их заранее, пример:
Не запихивайте в предзагрузку всё подряд, это только замедлит скорость работы сайта. Подумайте, какие скрипты и стили нужны пользователю, чтобы как можно быстрее увидеть первый экран страницы сайта.
Приоритеты загрузки в Google Chrome можете посмотреть в этой таблице docs.google.com/document/d/1bCDuq9H1ih9iNjgzyAL0gpwNFiEP4TZS-YLRp_RuMlc/
Для фоновой загрузки файлов с низким приоритетом, которые могут потребоваться на других страницах сайта, используйте тег prefetch, пример:
Если нужно заранее установить соединение с внешним сервисом, например Google Fonts, то используйте тег preconnect, пример:
Не нужно злоупотреблять этим тегом, браузер пользователя может его проигнорировать, если уже установлено много соединений или недостаточно памяти на устройстве. Оптимально использовать предварительное подключение до 6 внешних ресурсов. Чем меньше, тем лучше.
Для ускорения резолвинга DNS и экономии до 120 мс используйте тег dns-prefetch, пример:
Этот тег ускоряет начальное соединение с внешним сайтом и работает с старыми браузерами.
Обязательно добавляйте параметр display swap, даже если шрифты загружаются из внешнего источника, пример:
Лучше всего скачать шрифты и подгружать их с своего сервера, всё это увеличивает скорость работы вашего сайта.
Минифицируйте CSS, JS и HTML.
Если вы заказчик, то тут многое зависит от прямоты рук разработчиков, их уровня пофигизма, и конкретики в техническом задании.
Вообще, неплохо сначала выяснить, сколько кода и в каких файлах вообще не используется, но кешируется и загружается у пользователей, тормозя процесс отрисовки первого экрана.
Проверить это очень просто. Нам понадобится браузер Google Chrome.
Давайте проверим, какой объём кода не используется на сайте vc.ru, но его загружает ваш браузер.
Кликаем правой кнопкой мыши на произвольное место страницы, нажимаем «Посмотреть код». Далее выбираем вкладку «Console», чуть ниже около слова «Console» видим три точки столбиком и нажимаем на них, в выпадающем меню нажимаем «Coverage».
В этой таблице нас интересуют файлы, у которых значение «Unused bytes» (Неиспользованные байты) просто зашкаливающее.
У некоторых файлов «Unused bytes» = 100%.
Берём конкретные файлы и разбираемся, как их можно урезать и сократить или вообще отказаться от их использования, возможно ли это, какие последствия, что может поломаться.
Более подробно про инструмент Coverage можно прочитать тут developers.google.com/web/tools/chrome-devtools/coverage
Минифицируем CSS и JS вручную.
Заходим сюда minifier.org, загружаем CSS или JS файлы, жмём кнопку, всё готово.
Обязательно проверяйте работоспособность нового кода с отключенным кешированием на ПК и смартфоне, а лучше всего на копии сайта на служебном домене.
Минифицируем и объединяем CSS и JS через плагины.
Есть множество плагинов для популярных CMS и их вполне можно использовать. Работают сносно. Мусор в коде особо не генерируют и выполняют свои задачи.
Если плагин рушит работу всего сайта, то просто попробуйте другой. Такое бывает.
Годные плагины для Wordpress: WP Super Cache, W3 Total Cache, WP Fastest Cache, Hummingbird, LiteSpeed Cache, WP Rocket, Autoptimize.
Настройки для Битрикс: большинству будет достаточно штатного функционала из коробки, включите кеширование, композитный сайт, и в настройках главного модуля отметьте нужные пункты.
Подключите CDN.
CDN — content delivery network или сеть доставки контента. Если простыми словами, то это сетка серверов по всему миру с специальным ПО, задача которого отдавать статический контент вашего сайта с самого ближайшего к пользователю сервера.
Пример: хостинг вашего сайта физически расположен в Москве, но сайтом пользуется множество пользователей, от Калининграда до Владивостока.
Соответственно, при подключенном провайдере CDN сайт будет молниеносно загружаться у пользователей из Питера с сервера в Питере, а у пользователей из Новосибирска с сервера в Новосибирске, а не с Москвы.
При отключенном CDN контент сайта всегда будет загружаться с сервера в Москве, что замедляет скорость загрузки у пользователей, которые живут за МКАДом.
Для зарубежных проектов лучше всего использовать Amazon CloudFront, Cloud CDN от Google, Windows Azure CDN и конечно же CloudFlare. Это одни из топовых поставщиков CDN.
Для проектов, которые ориентированы только на рунет, лучше всего использовать локальных поставщиков CDN, например G Core Labs, CDN Video, Akamai, Selectel, Leaseweb.
Немного дополнительных плюсов CDN.
Устойчивость к DDoS за счет распределённой архитектуры и высокой мощности серверов.
Уменьшение нагрузки на сервер хостинг-провайдера, на котором расположен сайт.
При кратковременной недоступности сервера хостинг-провайдера сайт будет доступен, так как копия страниц сайта расположена на CDN серверах.
Значительное улучшение SEO-метрик сайта в отдалённых регионах.
Стоимость CDN сервисов обычно зависит от объёмов трафика. Чем больше трафика собирает сайт, тем дороже будет стоить CDN.
Фиксированные тарифы как правило отсутствуют. Более подробный список провайдеров под свои задачи можно найти тут cdnfinder.com.
Настройте Lazy loading и сожмите все изображения.
Lazy loading — это асинхронная загрузка контента до того момента, когда это необходимо.
Пример: при заходе пользователя на сайт для его загрузится только та часть контента, которую он видит. Если пользователь начинает прокручивать страницу вниз, то начинает подгружаться остальной контент сайта. В этом случае ускоряется отдача первого контента пользователю и повышается скорость загрузки сайта. Не нужно ждать, пока весь документ будет загружен.
В некоторых CMS Lazy loading настроен по умолчанию, например в последнем обновлении Wordpress. Можно настроить плагинами, проблем не возникает. Если CMS самописная — всё индивидуально, нужно ставить задачу разработчику.
Используйте современный формат изображений webp.
Это формат сжатия изображений от Google. Разработан в 2010 году. Дело в том, что изображения в формате webp весят в несколько раз меньше, чем изображения других форматов. Иногда в несколько сотен раз меньше.
Всё это влияет на загрузку сайта и скорость работы. Этот формат поддерживается браузерами Google Chrome с версии 9, Opera с версии 11.10, Firefox с версии 65, Microsoft Edge.
Смартфоны на Android спокойно читают формат webp с версии 4.0. Поддержка webp в Safari на Mac и iOS будет доступна с версии 14, выход которой намечен на сентябрь 2020 года.
На данный момент поддержки webp в Safari нет и пользователям этих устройств нужно отдавать jpg или png изображения, а всем остальным webp.
Чтобы подружить большинство популярных браузеров с форматом webp нужно подключать библиотеки libwebpjs/libwebpas на JS и AS соответственно.
Внедрив webp в свой сайт на этапе разработки вы получите большое конкурентное преимущество. В рунете почти никто кроме гигантов этим не заморачивается.
Если вы категорически не можете использовать формат webp в своём проекте, то максимально сожмите изображения без изменения формата.
Делать это можно своим софтом, готовыми плагинами, или вообще вручную.
Годные плагины как правило стоят денег, да ещё и по подписке. Для малых объемов будет достаточно этого сервиса compressor.io.
Настройте длительное время кеширования.
mod_expires — специальный модуль сервера Apache, позволяющий задать время, на которое будут кешироваться статические ресурсы в браузере пользователя.
Кэшируем всё, CSS, JS, шрифты, изображения, пример кода для файла. htaccess:
Кешировать счетчики аналитики и пиксели соц. сетей не получится.
Некоторые умельцы научились это делать с Google Analytcis на стороне пользователей, но я вам этого не рекомендую.
access plus 1 year — означает, что элемент будет кеширован на стороне пользователя сроком на 1 год после первого посещения сайта. При повторном посещении сайт откроется мгновенно, так как большинство ресурсов уже будет в кеше браузера пользователя.
Заблокируйте доступ к сайту для роботов и парсеров.
Существует огромное количество сервисов для SEO/PPC аналитики и не только.
Например, Semrush, Ahrefs, web.archive.org, pr-cy.ru, WebSpy и множество других.
Они парсят и агрегируют огромное количество сайтов и ежедневно создают нагрузку на ваш сайт. Это большая проблема в интернет-магазинах на сотни тысяч и миллионы SKU, может возникать повышенная нагрузка на БД.
Для отсечения самых популярных ботов на уровне сервера можно настроить специальные правила.
mod_setenvif — модуль сервера Apache, с помощью которого мы можем настроить полный запрет доступа к сайту для любых роботов и парсеров.
Пример кода для. htaccess:
Что будет, если робот "AhrefsBot" попробует зайти на сайт? Он получит в ответ ошибку 403 — доступ запрещён, и не сможет загрузить никакой контент сайта.
Важная особенность. При блокировке доступа роботам от популярных сервисов вы и ваши конкуренты не смогут получить никакой аналитики по вашему сайту, у систем просто не будет никаких данных.
Если ваша работа завязана на аналитику в Semrush, Ahrefs, Similarweb, и прочих сервисах, то настройку подобной блокировки нужно делать внимательно.
Чрезмерная нагрузка бывает редко. Обычно такие жесткие блокировки используют опытные веб-мастера, которые хотят скрыть сетки своих сайтов и не хотят палить рабочие фишки и актуальные схемы в SEO.
Вместо заключения
Даже если вы внедрите хоть что-нибудь из текста выше — ваш сайт начнёт работать быстрее.
Думайте о скорости работы сайта на этапе разработки. Это влияет на SEO и конверсии, а в конечном итоге на деньги.
Полезные сервисы и плагины для оценки скорости работы сайта:
Перед минификацией CSS ещё можно прогнать его через Critical, чтобы разделить файл на две части: то, что нужно для отображения верхней части сайта обязательно, и всё остальное. Первый файл кинуть в HEAD, а второй уже в самом низу.
Обидно, когда гугловская рекапча 3 не даёт пройти гугловский тест Core web vitals в гугловской PageSpeed.
Статья прикольная, жаль никто никогда не рассказывает как на практике решить проблему внешних скриптов, как правильно сделать criticalpath и как грамотно настраивать wp super cache.
Это индивидуально. Например на одном шаблоне wp super cache работает, а на втором после активации ошибка 500. Бывает настройки разные для сайтов на одинаковый платформе с одинаковым плагином. В общем, надо тестировать комбинации настроек и смотреть что выдает PageSpeed, выбирать лучший вариант.
Возьмите за правило размещать изображения в тегах , а все остальные элементы (иконки, логотипы и т.д.) помещайте в теги
.
не очень понял о чем это.
Ускорять битрикс, 1с и прочее крайне запарно. Там от веса картинок и css, js файлов мало что зависит. Хоть все на свете сожми, не факт что в зеленую зону попадешь. Надо об этом думать на этапе написания тз.
Одного может быть недостаточно. Вполне нормально использовать для кеширования wp rocket, а для оптимизации css и js другой плагин. У меня на одном сайте стоит wp rocket + Smush Image Compression and Optimization. И работает лучше, нежели один wp rocket. Не факт, что в вашем шаблоне будет так же. Я искал лучшее сочетание просто методом перебора, в любом случае у плагинов есть moneyback если что.
На счет оптимизации:
В шапке нет ни описания на чем сервер, ни вообще что за сайт и на чем сделан(cms или фреймворк какого языка).
Конечно, читая текст можно понять о чем речь, но по факту это очень странные советы, применять которые надо внимательно разобрав, в первую очередь задать - а это вообще к вам относится? и только потом начинать использовать.
Я смотрю тут серьёзных разработчиков нет , не слово про , cdn , http/3 , и тем более апачь ну не смешно ли ? А где haproxy spring nginx ? Видно сразу что pagespeed больше 95 не у кого не был.
1. CDN вполне себе нормально описан в посте. Будьте чуть повнимательнее.
2. Стандарт http/3 пока только готовится к релизу, его ни apache, ни nginx не поддерживают из коробки пока. Да и вторую версию чтобы врубить на том же Debian 9, нужно прилично попотеть. Мне кажется, что тонкая серверная настройка выходит за рамки подобных статей.
3. Насчёт HAProxy и прочих балансировщиков, равно как и иной тонкой настройки серверных компонентов - см. предыдущий пункт. Разработка и оптимизация интернет-ресурса - не то же самое, что настройка серверной инфраструктуры.
4. Синтаксис, пунктуация и общий тон комментирования.
Если Unix готовить не умеете то не беритесь, Дебиан мало поддерживаеться в отличие от Убунты , да и из изходников скомпилить вообще не трудно
http/2 уже в поддержке с nginx 1.9.5 22.09.2015
Сейчас комп версия 96-100, мобильная 95-98. Тут мне кажется на любом сайте как ни оптимизируй, всегда будут разные показатели. Сайт на вордпресс, шаблон сам делаю. Обычная вдс, сильных манипуляций не делал в плане оптимизации. Картинки отдает WebP. В целом структура шаблона аналогичная виси.
Серьезный проект сделать можно на чем угодно, было бы желание. Что по вашему серьезный? Детский лепет какой-то. На вордпресс полно известных и посещаемых порталов. Его легко доработать под свои нужды и не боятся обновлений и слета всех функций.
Вопрос средств. Не у всех есть сходу деньги на разработку таких порталов. Кто-то начинает с того же вордпресс. Что то на php, что это.
WordPress — это CMS, а Laravel — фреймворк (framework). CMS ориентирована на обычного пользователя (контент-менеджера, редактора, администратора сайта), фреймворк на программиста. Обе системы Open source. Обе бесплатны.
Вк, хабр и этот сайт и другие, написаны на php. Остальное дело удобства и знаний. Я не программист. Мне проще с вордпресс начать, даже изучать php лучше и проще на нем, а потом уже лезть во фрейворки или при росте проекта уже нанимать в команду программиста и выстраивать портал на том же laravel.
Так что фигню городите тут.
Есть конечно у ВП слабые места, база данных тяжеловата будет. Это я бы сказал самый критичный ее момент, но он по сути легко решается. Остальные недостатки это уже вкусовщина и мелочи. Которые тоже решаются.
Ну если вы не программист то что рассуждаете ? Во первых Wordpress это тоже framework ВО вторых торможения базы идёт от проектирования без индексов , втретьих я в Веб разработке более 10 лет, и вот смотрю на это как вы (любители) с пеной у рта пытаетесь что доказать обсолютно не разбираясь в Fullstack . Просто смешно ...
А мне смешно, как всякие "иксперты" с пеной у рта доказывают, что на том же вордпресс нельзя создать что-то более менее крупное. Но есть другая категория людей, которая берет и делает. Тот же лайфхакер. Дневная посещаемость их сайта составляет 1 млн человек.
Что делать, если в вопросе Coverage в десктопе CSS файл почти весь используется, а на мобильном - частично ? Развести их в два файла, чтобы один подключался на мобильном, а другой - на десктопе ?
Отличная статья. Всегда придерживаюсь правила быстрой загрузки в мобильной и десктопной версии. И в данный момент разрабатываю шаблон под вордпресс, закрыв сайт от всех и открываю только для проверки в сервисах скорости и верстки. Пару месяцев обычно оттачиваю все, на новом шаблоне.
Часть 2 тут - https://vc.ru/dev/158627-uskoryaem-rabotu-sayta-na-etape-razrabotki-i-obgonyaem-konkurentov-v-poiske-chast-2
Перед минификацией CSS ещё можно прогнать его через Critical, чтобы разделить файл на две части: то, что нужно для отображения верхней части сайта обязательно, и всё остальное. Первый файл кинуть в HEAD, а второй уже в самом низу.
Комментарий удален автором поста
Спасибо, годная статья. Однозначно в закладки.
😢 когда у тебя сайт на tilda
Конструктор для лендинга ок. Для полноценного сайта не годится, какой бы там функционал не был. Это мое мнение.
Обидно, когда гугловская рекапча 3 не даёт пройти гугловский тест Core web vitals в гугловской PageSpeed.
Статья прикольная, жаль никто никогда не рассказывает как на практике решить проблему внешних скриптов, как правильно сделать criticalpath и как грамотно настраивать wp super cache.
Это индивидуально. Например на одном шаблоне wp super cache работает, а на втором после активации ошибка 500. Бывает настройки разные для сайтов на одинаковый платформе с одинаковым плагином. В общем, надо тестировать комбинации настроек и смотреть что выдает PageSpeed, выбирать лучший вариант.
Возьмите за правило размещать изображения в тегах , а все остальные элементы (иконки, логотипы и т.д.) помещайте в теги
.
не очень понял о чем это.
Ускорять битрикс, 1с и прочее крайне запарно. Там от веса картинок и css, js файлов мало что зависит. Хоть все на свете сожми, не факт что в зеленую зону попадешь. Надо об этом думать на этапе написания тз.
Там есть волшебная кнопка "Композитный сайт", многие магазины начинают работать значительно быстрее.
На Wordpress есть смысл несколько плагинов вместе для ускорения использовать ? Например, WP Rocket + что-то еще ? Или лучше выбрать один ?
Одного может быть недостаточно. Вполне нормально использовать для кеширования wp rocket, а для оптимизации css и js другой плагин. У меня на одном сайте стоит wp rocket + Smush Image Compression and Optimization. И работает лучше, нежели один wp rocket. Не факт, что в вашем шаблоне будет так же. Я искал лучшее сочетание просто методом перебора, в любом случае у плагинов есть moneyback если что.
WP Rocket несомненное один из лучших плагинов, в нем есть всё, своих денег точно стоит.
Отличная статья. Будет полезно думаю расписать более подробно по Битриксу, думаю многие строят сайты на нем. Какие есть полезные модули, решения и тд.
Битрикс обычно покупают для интернет-магазинов, там может быть прикручено всё что угодно, поэтому универсальный мануал вряд ли получится собрать.
На счет оптимизации:
В шапке нет ни описания на чем сервер, ни вообще что за сайт и на чем сделан(cms или фреймворк какого языка).
Конечно, читая текст можно понять о чем речь, но по факту это очень странные советы, применять которые надо внимательно разобрав, в первую очередь задать - а это вообще к вам относится? и только потом начинать использовать.
В основном инструкция актуальная для Apache 2.4, популярных cms Битрикс, WP.
Кто умеет поднимать проекты на nginx и так все это знают и даже больше.
ну вот вы напишите что речь о битриксе на апаче, а то будет у кого поднятый кем-то(исполнитель) проект на nginх-e и вообще без cms и беды не миновать)
Добавление кеширующего реверсивного прокси (напр.Varmish) подходит?
Конечно, особенно для сайтов на Symfony2 с высокой нагрузкой.
Я смотрю тут серьёзных разработчиков нет , не слово про , cdn , http/3 , и тем более апачь ну не смешно ли ? А где haproxy spring nginx ? Видно сразу что pagespeed больше 95 не у кого не был.
1. CDN вполне себе нормально описан в посте. Будьте чуть повнимательнее.
2. Стандарт http/3 пока только готовится к релизу, его ни apache, ни nginx не поддерживают из коробки пока. Да и вторую версию чтобы врубить на том же Debian 9, нужно прилично попотеть. Мне кажется, что тонкая серверная настройка выходит за рамки подобных статей.
3. Насчёт HAProxy и прочих балансировщиков, равно как и иной тонкой настройки серверных компонентов - см. предыдущий пункт. Разработка и оптимизация интернет-ресурса - не то же самое, что настройка серверной инфраструктуры.
4. Синтаксис, пунктуация и общий тон комментирования.
Если Unix готовить не умеете то не беритесь, Дебиан мало поддерживаеться в отличие от Убунты , да и из изходников скомпилить вообще не трудно
http/2 уже в поддержке с nginx 1.9.5 22.09.2015
http/3 уже можно собрать https://habr.com/ru/news/t/506322/
да и использовать для разработки уже можно
https://github.com/aiortc/aioquic/blob/main/examples/http3_server.py
по Поводу Haproxy , y ну вот это явно солиднне и интереснее чем унылое говно на апаче
https://medium.com/@pawilon/tuning-your-linux-kernel-and-haproxy-instance-for-high-loads-1a2105ea553e
Темболее тут некоторые битрикс используют , в то время как ужаснее кода и и глупее программистов чем битрексеры это ещё поискать надо .
Может реальную оптимизацию вы просто не умеете готовить ?
PS: Это я ещё с кубернетис не упомянул
Вы так ничего и не поняли. Но это не важно, мне ваш тон не нравится. Всего доброго.
Заднюю включил
Сейчас комп версия 96-100, мобильная 95-98. Тут мне кажется на любом сайте как ни оптимизируй, всегда будут разные показатели. Сайт на вордпресс, шаблон сам делаю. Обычная вдс, сильных манипуляций не делал в плане оптимизации. Картинки отдает WebP. В целом структура шаблона аналогичная виси.
Вордпрес это начальный уровень, серьёзные проекты делаются на других вещах бэк laravel/dgango/spring фронт vue/react/angular
Серьезный проект сделать можно на чем угодно, было бы желание. Что по вашему серьезный? Детский лепет какой-то. На вордпресс полно известных и посещаемых порталов. Его легко доработать под свои нужды и не боятся обновлений и слета всех функций.
Тото vc.ru , habr , auto.ru , vk.com , ok.ru на вордпрес не сделали
Вопрос средств. Не у всех есть сходу деньги на разработку таких порталов. Кто-то начинает с того же вордпресс. Что то на php, что это.
WordPress — это CMS, а Laravel — фреймворк (framework). CMS ориентирована на обычного пользователя (контент-менеджера, редактора, администратора сайта), фреймворк на программиста. Обе системы Open source. Обе бесплатны.
Вк, хабр и этот сайт и другие, написаны на php. Остальное дело удобства и знаний. Я не программист. Мне проще с вордпресс начать, даже изучать php лучше и проще на нем, а потом уже лезть во фрейворки или при росте проекта уже нанимать в команду программиста и выстраивать портал на том же laravel.
Так что фигню городите тут.
Есть конечно у ВП слабые места, база данных тяжеловата будет. Это я бы сказал самый критичный ее момент, но он по сути легко решается. Остальные недостатки это уже вкусовщина и мелочи. Которые тоже решаются.
Ну если вы не программист то что рассуждаете ? Во первых Wordpress это тоже framework ВО вторых торможения базы идёт от проектирования без индексов , втретьих я в Веб разработке более 10 лет, и вот смотрю на это как вы (любители) с пеной у рта пытаетесь что доказать обсолютно не разбираясь в Fullstack . Просто смешно ...
А мне смешно, как всякие "иксперты" с пеной у рта доказывают, что на том же вордпресс нельзя создать что-то более менее крупное. Но есть другая категория людей, которая берет и делает. Тот же лайфхакер. Дневная посещаемость их сайта составляет 1 млн человек.
И ты говоришь о фронте а оптимизация более сильная на бэке
Круть какая! Как раз сейчас голову ломаем, как ускорить сайт без большой разработки. Спасибо большое.
а как закрыть доступ к phpmyadmin на том же webhost1?
Супер, очень полезно. Спасибо за ваш труд!
Что делать, если в вопросе Coverage в десктопе CSS файл почти весь используется, а на мобильном - частично ? Развести их в два файла, чтобы один подключался на мобильном, а другой - на десктопе ?
Да, отдавать разные файлы в зависимости от устройства.
Отличная статья. Всегда придерживаюсь правила быстрой загрузки в мобильной и десктопной версии. И в данный момент разрабатываю шаблон под вордпресс, закрыв сайт от всех и открываю только для проверки в сервисах скорости и верстки. Пару месяцев обычно оттачиваю все, на новом шаблоне.