Уменьшить скорость загрузки и нагрузку на сервер

У меня статический сайт, на шареде и больше в пиках держит.

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

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

Вот это ТС и должен донести до Таймвэба.

Пусть обоснуют, чем именно вызвана нагрузка?

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

В кризис все выживают как могут

У меня был выключенный кэш по двум причинам:

- очень обновляемый сайт в некоторые периоды дня

- что-то ломалось при включенном кеша.

Уменьшал картинки, смотрел по логам куда идут запросы с 404 ошибкой, и фиксил их, уменьшение количества скриптом, их асинхронная подгрузка, уменьшение css файла с 100б до 30 - все это не дало ничего ощутимого.

А вот включенный кеш дал. Я нашел нормальный компонент кеша, потестил пару дней - нагрузка упала в 2,5 раза.

В итоге, в то короткое время, когда нужно быстрое обновление, ставлю кеш - 3 минуты, в остальное время - 15 минут, и норм.

Это УЖЕ говорит о проблемах в проектировании. TTL в качестве инвалидации это конечно хорошо, но... как правило это таки запасной вариант. Ну что, что вы там меняете? Статьи или что-то вроде? У них нет времени изменения? По нему инвалидировать не пробовали? Ну и запросы. Запросы смотреть надо обязательно.

0.25с это много. Не капец как много, но много. Не помню как оно в вашей ЦМФ, но если есть, то вероятно надо жадность включить и т.п. Посмотрите что за запросы в базу идут. Завтра будет 50тыс, и опять будете бегать, но так просто включением кривенького кешера не отделаетесь. Так что лучше решайте сейчас.

Для чего?

Для статики?

И.. почему много?

Мы говорим о проблемах нагрузки на сервер. Для 250мс нужно чем-то нагрузить сервер. Толстый сервер а не домашний комп. В 90% случаев это слишком большое количество запросов к базе. Иногда другие слабые места.

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

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

Общий посыл - разместите сервер ближе к G - получите быстрый ответ.

Не используйте js и библиотеки - получите плюсики

Не используйте CSS-fw получите плюсики

Используйте голый html, а не CMS - получите плюсики.

голый html - никакой нагрузки на сервер.

И все в плюсиках.

Размер Вашего изображения 600байт, его можно ужать до 300байт получите экономию 50%, + в карму два плюсика. Не кажется это смешным?

Размер вашего фалй стилей = 1к, сожмите его и получите размер 900байт - экономия в 10% = два плюсика.

И вы будете продолжать верить в его рекомендации и строго им следовать.

Неа. Пинг и прочие сетевые задержки гуголь вычитает.

Опять мимо. Асинхронная загрузка, равно как и инлайн у него вопросов не вызывает.

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

А это с какого места придумали? Если не ошибаюсь ниже 200мс обработки минусов нет совсем. А 200мс при нормальном кешировании, разумном плане запросов и т.п. - влёт выходит.

Мало того - "голый хтмл" как правило не выдаст всех красивых хеадеров, сжатия кода хтмл, и - gzip самого HTML. А эти вещи гугл любит сильно.

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

В общем Ваш коммент показывает что Вы просто не умеете его готовить.

Вы видно тему не с начала читаете. Гугловская членомерка дает не оценку сайта, а список рекомендаций. Их полезно знать. Но не обязательно свято их соблюдать. Да, баллы у него не количественные а качественные. Т.е. много незначительных нарушений завесят больше чем одно значительное. Но оно ведь не для членомерства. Лично я 95 баллов без ухудшения дизайна и функциональных вещей выжимаю из него легко. Правда не на всех страницах. И в боевых задачах не гоняюсь за показателями, а слежу чтобы было выше 90 или на худой конец 85 если страница сложная и всё. Но подчеркну еще раз - это лишь список подсказок. Не более.

Да, а скачков при загрузке стилей вы тоже не замечаете?

А если у вас jquery библиотеки грузятся, а еще и зависимые тоже async (defer) вот каждый..

А если еще вдруг и шаблонописатель вообще не знает о document.load или тупо игнорирует..

Так что продолжайте гоняться за плюсиками..

инлайн????

Ага... а как же - уменьшите размер html???

Т.е. плевать что там будет "стильная" колбаса.. Главное чтоб зелененьким светилось..

При нормальном кешировании...

Что такое нормальное кеширование. Какие признаки "нормальности"? Какова валидность данных?

Конечно, я не защищаю 2-2,5 сек на загрузку

Но до 1 сек это вполне съедобно. И скорость загрузки - ну как она может быть связана с ранжированием?

Вы давно использовали jpeg interlaced? Ведь задача - отдать как можно быстрее визуальный контент?

Ну лично я попилил себе бутстрап на две части, первая небольшая, грузится в шапке, вторая - всё остальное без разбору идет в подвале.

Для этого разобрался с компиляцией LESS из пхп.

Оно конечно гонка за ачивками и не более. Но попутно я еще пару вопросов решил, так что нормально. За такое решение примерно один бал снимают.)

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

Ну да, вот прям 200кб стилей в инлайн.) Нет конечно. Доли процентов от общего веса. Спорное решение, да. Но... а зачем собственно вам 100% по гугл пейджспиду? Я сказал лишь, что это МОЖНО сделать и оно не будет противоречить не только здравому смыслу, но и мнению гугла.

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

Комментарии - аналогично. В меню кешируем данные (часто меняют "активный" раздел меню), в комментах и т.п. - весь хтмл... "валидность" абсолютная естественно. Если вы заметили я как раз и критиковал инвалидацию по TTL как единственный метод.

1с на загрузку всех данных это хорошо. Ну пусть даже 2с - еще терпимо. Но мы говорим о времени генерации страницы. Генерация в секунду? Вы серьезно?

Это выдача страницы будет секунды 3-5. Растеряете половину аудитории.

0.5с это в сложных случаях. А для простых страниц совет гугла в 200мс вполне себе валидный.

Очень слабо. А к чему вы спрашиваете?)

на чем сайт на пхп?

попробуйте перейти на php7 или еще лучше поставить hhvm