- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году 36,9% всех DDoS-атак пришлось на сферу финансов
А 24,9% – на сегмент электронной коммерции
Оксана Мамчуева
Тренды маркетинга в 2024 году: мобильные продажи, углубленная аналитика и ИИ
Экспертная оценка Адмитад
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
На сайте намечена некоторая реконструция, поэтому хочется, заодно, учесть и пожелания Гугла, которые я читаю уже дней пять.
Общая идеология понятна и вполне резонна: как можно быстрее показывать основную (верхнюю) часть страницы, отложив все второстепенные элементы напоследок.
Перестроил страницу, убрал из <head> некоторые скрипты, перенеся их вниз, и визуально страница стала появляться быстрее. При этом сервис Гугла пишет, что у страницы скорость загрузки 85%.
Но Гугл делает все те же замечания, что и в начале - убрать вообще все скрипты и файлы CSS.
Если это сделать, то на медленном интернете сайт будет вообще невозможно смотреть, ибо сначала на экране какая-то свалка, преобразование которой вряд ли кто-то захочет ждать!
Ради интереса я решил проверить на сервисе Гугла сам Гугл (несколько страниц из developers.google.com/web/). И с удивлением обнаружил, что для них сервис делает такие же замечания, как и мне, а скорость у них 62%!
При этом гугловская страница совершенно не читаемая, поскольку в ней полкилометра CSS и еще больше кода JS, которые не вынесены в отдельные файлы.
Я представил себе, во что превратятся мои макеты, которые я вставляю в CMS, и стало просто жутко, поскольку тогда в них будет вообще невозможно разобраться!
Вот теперь даже и не знаю, что делать...
Может, я очень сильно отстал от жизни? Вот Вы исполняете требования Гугла по части обеспечения скорости?
В гугле работают психи.
Есть сайтик: пяток страниц, 6КБ style.css и 3КБ скриптик. У Гугла аж пена изо рта идет: перемещайте все вниз, сжимайте, переносите куда-нибудь, сайт не оптимизирован!!!
Дебилы.
Еще они очень любят, чтобы сайты превращались в пауков и при загрузке обходили десяток сторонних сайтов: где-то скриптик подцепить, где-то шрифтик и т.д.
Остается только надеяться, что у них там займутся знающие люди этим вопросом. А то у меня сайт по их мнению неоптимизирован и долго грузится, а у них самих ведь полтора часа ждешь пока аналитикс загрузит пункт меню :)
Как-то так...
Владимир-C, чтобы страница до загрузки css-файла не разваливалась, гугл рекомендует прямо в страницу внедрять основные стили (по минимуму).
На практике я не вижу смысла фанатичного исполнения всех требований. Отнеситесь к ним разумно. Если сайт на смартфоне с исчерпанным трафиком, т.е. при ограниченной скорости в 32/64 кбит/сек более-менее шевелится, то на этом можно остановиться.
Владимир-C, чтобы страница до загрузки css-файла не разваливалась, гугл рекомендует прямо в страницу внедрять основные стили (по минимуму).
А остальные стили куда?
Помещать в середине body
Это как-то непривычно...
И валидатор уж точно не одобрит!
А если эти второстепенные стили в отдельном файле, то ссылку на него куда?
Рекомендации гугла не только странные, но и часто расходятся с логикой.
На кой черт пихать css/js в код страницы и каждый раз это грузить, если в виде отдельных файлов он загрузится один раз - а далее уже будет из кеша браться.
Помните, было время, когда Гугл очень агитировал авторов размещать свои фото и показывал их в выдаче?
А потом вдруг взял и от этого отказался!
Не удивлюсь, если и с его нынешними требованиями будет также.
Посыл главный - чтобы грузилось быстро. Если обратить внимание, то больше всего балов pagespeed дает за картинки и включение кэша и конечно же abofe the fold.
Мое мнение - все это бутафория. Главное снизить вес страницы, а дальше хоть трава не расти.
Вот если бы гугл давал реальные плюсики к ранжированию за pagespeed , то ...
Помещать в середине body
Можно в <head></head>
Но повторюсь: не надо стремиться достигнать 100%-й пузомерки. Олимпиаду смотрели (гимнастов например)? Там тоже 10 баллов - идеал, который никто на практике не достигает. Просто смотрите, чтобы не было таких вещей (я недавно столкнулся) как страница лендинга весом 20 мегабайт и подобного. Загрузка файлов со скриптами из хедера опасна тем, что если будет проблема с загрузкой, то будет заблокирована вся страница (если загрузка не асинхронная). Не хорошо, если из хедера грузится десяток файлов со скриптами и стилями, так как много запросов на медленном мобильном канале - не хорошо.
Но если у вас в хедере один небольшой файлик со стилями и небольшой файлик со скриптами и грузятся с того же сервера, то я не вижу смысла их трогать.
Что касается jquery, то у меня нет однозначного ответа. Очень удобно вызывать её первой, чтобы сразу использовать ее мощь. Но если вызывать со своего сервера, то первая загрузка сотни килобайт на gprs может идти полминуты и более, что не хорошо. Если использовать загрузку со стороннего известного сервера, то с большой вероятностью эта библиотека уже будет в кэше у посетителя, но если будут проблемы с этим сторонним сервером или с каналом до него (что иногда случается), то ваш сайт будет полностью недоступен, что очень нехорошо.
Но на практике в большинстве случаев я бы оставил вызов jquery из head и не заморачивался.
Вообще шаблон нужно собирать специальными инструментами, тогда у вас не будет проблем. Будет dev и production версия вашего шаблона. Попробуйте изучите gulp. К примеру, гугл просит css вставлять прямо html, это в принципе корректно, сделайте отдельный файл css header.css который импортится к примеру в general.css. При сборке проекта с помощью gulp можете автоматом брать все стили с header и инжектить в нужное место на страницы. Так когда у вас начнется грузиться страница, сразу будет видна к примеру шапка сайта, пока все остальное подгружается, что на десктопе, что на мобильниках это будет более привлекательно как по скорости, так и для юзера, даже если будут проблемы с подгрузкой другой инфы, юзер будет видеть что отклил уже есть. И не забудьте использовать лоадеры для всех js и css, дабы файлы грузились асинхроно и не блокировали страницу, да и лоадеры удобны, можно задавать нужные последовательности загрузки как для плавного догрузки всего остального на странице, так и для контроля работы скриптов.
Может, я очень сильно отстал от жизни?
/ru/forum/945499
Единственна польза от него для некоторых - можно скачать уже оптимизированные картинки (скрипты ни-ни!):) И увидеть что с кешированием.
Для оценки качества сайта нужно юзать анализаторы скорости загрузки со всеми составляющими. http://tools.pingdom.com/ https://gtmetrix.com/ и тп.
чтобы страница до загрузки css-файла не разваливалась, гугл рекомендует прямо в страницу внедрять основные стили (по минимуму).
Правильно рекомендует. Стили, которые прорисовывают основной костяк сайта в первую очередь запускать, а всякие уже украшения типа раскраски кнопок и полос прокрутки, можно выносить в файл.
С яваскриптами таже песня. Важные грузить в начале, а скрипты всяких тизеров, счётчиков, социальных кнопок в самый низ подключать.