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

26 Январь, 2011

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

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

Как можно быстро увеличить скорость загрузки сайта


Итак, весь процесс оптимизации скорости, на мой взгляд, следует начинать с установки Page Speed. C помощью этого дополнения для Фаерфокса или Хрома вы можете всесторонне оценить скорость загрузки страниц своего сайта и получить ценнейшие рекомендации по ее увеличению (можете также ознакомиться и с другими полезными дополнениями для браузера Мазила).

При первом запуске Page Speed для главной страницы моего блога я увидел вот такую печальную картину:

Всего 72 бала из 100 возможных и куча замечаний отмеченных красных цветом. Правда выполнив практически все рекомендации, которые мне давал этот плагин, главная страница получила от него уже более высокую оценку в 94 бала.

Но кроме Page Speed очень наглядно оценить скорость загрузки сайта и посмотреть все загружаемые объекты можно в онлайн сервисах по измерению скорости загрузки — Pingdom и ему подобных.

По началу происходила подгрузка почти 90 объектов (ccs, js, изображения) и на каждый из них нужен был отдельный http запрос. Но, проанализировав с помощью указанных выше онлайн сервисов все загружаемые объекты, а также следуя советам Page Speed, мне удалось сократить их количество до трех десятков, что не могло не сказаться на общей скорости:

Ну, а теперь вспомним обо всех методах по порядку. И начинать оптимизацию следует, наверное, в порядке отображения проблемных мест в окне Page Speed, ибо это будут самые эффективные и самые не сложные в реализации шаги — что называется «дешево и сердито».

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

Да, да, с помощью настроек web сервера можно управлять поведением браузера посетителей. В этом случае первый сообщает второму время, в течении которого следует хранить в кэше статические объекты для того, чтобы не запрашивать их повторно с сервера.

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

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

Следующим эффективным шагом по увеличению скорости загрузки может быть объединение внешних файлов стилей CSS или скриптов JS. Читайте про то, как объединить внешние CSS в один общий файл и отключение внешних CSS, с которыми я разобрался.

Но вот объединить внешние скрипты мне не удалось, наверное, в силу непонимания даже основ JavaScript. Правда у меня было всего два внешних файла со скриптами, поэтому потеря в скорости загрузки сайта будет не велика.

Но кроме объединения внешних стилей CSS и скриптов (это делается для уменьшения общего числа загружаемых объектов, что позволит уменьшить число http запросов к серверу), эти самые файлы стилей и скриптов можно будет очень эффективно сжать с помощью Gzip (фактически это тот же самый Zip, который вы активно используете на компьютере).

Сжать CSS и Js файлы с помощью Gzip можно в несколько раз, но еще больше уменьшить размер этих файлов можно за счет предварительной оптимизации их кода.

Я писал уже про оптимизацию и сжатие CSS с помощью Page Speed. Правда для этого вы можете воспользоваться специальными программами, которые не только убирают лишние пробелы и комментарии, но и пытаются корректировать сами CSS свойства.

Но мне все же больше по душе простое сжатие, которое осуществляет Пейдж Спид — код остается абсолютно читаемым и даже более удобным в использовании.

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

После этого, применение Gzip архивации к файлам стилей и скриптов вашего ресурса приведет к еще большему уменьшению их размера, а следовательно и скорости загрузки. Но вот именно по сжатию Html, Css и Js у меня возник целый ряд вопросов, которые я с относительным успехом попытался решить.

Статическое Gzip сжатие для снижения нагрузки на сервер


Во-первых, Gzip на сервере при его традиционном способе активации (описано в этой статье — Как включить Gzip сжатие через .htaccess) будет выполняться в реальном времени, т.е. таким образом мы реализовали динамическое архивирование. Что это означает?

Дело в том, что для каждого нового пользователя, открывающего страницы вашего сайта, будет повторно в реальном времени осуществляться архивация на лету файлов Html, Css и Js. Как вы понимаете, во-первых, это будет занимать какое-то время, а во-вторых, сжатие на лету будет потреблять дополнительный ресурс процессора сервера.

У меня ситуация с нагрузкой блога KtoNaNovenkogo.ru довольно-таки плачевна — балансирую на грани фола. Поэтому любая возможность снижения ее, не приводящая к уменьшению скорости загрузки сайта, будет очень даже кстати.

Такой соломинкой, за которую я решил ухватиться, стало статическое Gzip сжатие Html, Css и Js, которое осуществляется предварительно, а пользователям отдаются уже готовые архивы, не замедляя скорость и не создавая лишнюю нагрузку на процессор хостинга.

Особенно актуальна эта проблема для внешних скриптов и стилей (Css и Js), ибо они вообще практически никогда не изменяются, но при этом осуществляется их повторное и бесцельное архивирование на лету при каждом открытии страницы вашего ресурса. Было бы гораздо логичнее заблаговременно закатать их в Gzi, а web серверу указать нужный порядок действий.

С учетом различного восприятия некоторыми браузерами файлов с расширением .gz (архивы Gzip) обычно используют довольно хитрый способ переименования архивов в обычные файлы стилей с расширением .CSS и скриптов.

А в .htaccess будут добавлены строки, объясняющие web серверу, как подавать эти файлы различным браузерам. В общем-то, такая довольно запутанная схема работает и поэтому я опишу подробнее все шаги подготовки Gzip архивов и приведу код для .htaccess.

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

Итак, вам нужно будет скачать на свой компьютер все внешние Css и Js файлы, участвующие в загрузке страниц (после того, как вы осуществили их объединение это будет не сложно) и создать из каждого из них его архивную копию с расширением .gz. Сделать это можно с помощью бесплатной программы 7zip. Дальше давайте покажу на примере, ибо теоретизировать здесь бесполезно.

Возьмем для примера основной файл стилей моего блога style.css. После того, как я его упакую в Gzip с помощью программы 7zip, у меня появится архив style.css.gz.

Но т.к. некоторые браузеры не захотят подключать стилевой файл с расширением .gz, то мы удаляем у него окончание .gz и получаем опять в итоге style.css, но который уже фактически представляет из себя архив (пока еще не запутались?).

Но просто заменить оригинальный файл style.css на сервере (еще не сжатый в Gzip) только что нами созданным архивом, но имеющим по-прежнему название style.css, будет не достаточно.

Ведь некоторые браузеры по-прежнему не поддерживают сжатие (обычно это старые версии, которые тем не менее еще используются пользователями), поэтому рядом с style.css, который уже фактически будет являться архивом (помните мы у него удалили расширение .gz), нам нужно будет положить оригинальный не сжатый файл стилей.

Но назвать мы его должны будем уже иначе, чем style.css. Для этого можно его переименовать, например, таким образом: style.nogzip.css. Теперь на сервере в папке с темой оформления WordPress у меня будет лежать два файла стилевого оформления:
  1. style.css — архив с отрезанным расширением .gz
  2. style.nogzip.css — обычный не сжатый файл стилей, который нужно будет отдавать браузерам, которые не поддерживают сжатие

Данную операцию вам нужно будет проделать для всех внешних стилей и скриптов (Css и Js), которые загружаются вместе со страницами вашего ресурса. У меня их было всего лишь четыре: основной стилевой, в котором у меня также добавлены свойства некоторых плагинов WordPress, а еще файл скрипта из папки с темой оформления и два внешних скрипта от плагина SyntaxHighlighter.

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

<IfModule mod_rewrite.c>
        RewriteEngine On
        RewriteCond %{HTTP:Accept-encoding} !gzip [OR]
        RewriteCond %{HTTP_USER_AGENT} Konqueror
        RewriteRule ^(.*)\.(css|js)$ $1.nogzip.$2 [QSA,L]
</IfModule>
<IfModule mod_headers.c>
        Header append Vary User-Agent
        <FilesMatch .*\.(js|css)$>
               Header set Content-Encoding: gzip
               Header set Cache-control: private
        </FilesMatch>
        <FilesMatch .*\.nogzip\.(js|css)$>
               Header unset Content-Encoding
        </FilesMatch>
</IfModule>

Если вы при переименовании оригинальных файлов стилей и скриптов использовали их названия, отличные от style.nogzip.css, то и в соответствующей строке кода вам нужно будет заменить маску $1.nogzip.$2 на свою. В общем-то, вот и все.

Теперь сервер не будет каждый раз на лету сжимать Css и Js, а будет сразу же отправлять браузерам заранее сжатую вами копию, а в случае браузера, который не понимает Gzip — оригинальную версию файла вида подобного style.nogzip.css.

На лицо будет небольшое увеличение скорости загрузки сайта и снижение нагрузки вашего ресурса на хостинг. Вот только у меня через пару дней произошел конфуз. Видимо очистился кэш моего браузера и вид админки WordPress резко изменился — отвалилось стилевое оформление.

Но проблема довольно быстро решилась проведением описанных выше манипуляций с используемым в админке файлом стилей. В моем случае это был colors-classic.css из папки:

/wp-admin/css

Дальше мне захотелось применить статическое Gzip сжатие для файлов Html, которые тоже сжимаются сервером налету, создавая дополнительную нагрузку. Тут я нашел решение довольно простое, применительно к WordPress. Дело в том, что у меня уже очень давно используется плагин для кэширования Hyper Cache.

В его настройках имеется область «Compression», которая, как я поначалу думал, отвечает за компактное размещение кэшированных страниц на жестком диске хостинга. Мне показалось, что архивирование кэшированных страниц будет отъедать ненужное время у процессора и благополучно его отключил.

Но вот немного поискав информацию на тему Gzip сжатия Html страниц, я изменил свое мнение об этих настройках компрессии в плагине Hyper Cache.

Похоже, что поставив галочку в этом поле «Enable compression», мы тем самым активируем предварительное сжатие кэшированных страниц блога по алгоритму Gzip.

Утверждать это на сто процентов не берусь, но после активации компрессии в настройках Hyper Cache я наблюдаю уже в течении продолжительного времени снижение нагрузки на сервер. В общем похоже, что как и всегда — ларчик просто открывался.

Кстати, если ваш проект построен на базе Joomla, то для нее есть несколько очень неплохих (по отзывам пользователей) компонентов, позволяющих максимально задействовать описанные мною способы повышения скорости загрузки сайта, но при этом все будет значительно проще, т.к. многое сделано автоматически с минимальными вашими затратами по настройке.

Сам я эти компоненты еще не тестировал, но как только соберусь, то обязательно о них напишу. Пока же лишь приведу ссылки на эти компоненты для Джумлы: jFinalizer и WEBO Site SpeedUp.

Оптимизация графики и уменьшение количества запросов

Также очень существенное влияние на скорость загрузки может оказать оптимизация графики. Как я уже писал ранее, оптимизировать изображения можно в Page Speed. Но это будет удобно только в случае небольшого их количества.

Лично я для пакетной оптимизации использовал онлайн сервис PunyPNG, о котором уже довольно подробно писал. Можно также воспользоваться и другим очень популярным онлайн сервисом для сжатия фото без потери качества от Yahoo.com — Smush.it. Но степень сжатия фото в PunyPNG мне показалась выше, возможно за счет использования более удачных скриптов.

Я скопировал папку с изображениями своего блога на компьютер и загрузил их все (пачками по 15 штук, ибо существует в PunyPNG такое ограничение) на этот онлайн сервис, а затем скачал общий архив, содержащий уже оптимизированные картинки с моего блога.

В общем, потратив полчаса мне удалось сжать PNG изображения примерно на 7 процентов в среднем, а Gif и Jpg процентов на 5.

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

Ну и последним, а также одним из самых действенных способов ускорения, может быть уменьшение количества http запросов, которое будет формироваться при загрузке страниц вашего ресурса. Уменьшить их можно, снизив число объектов загружаемых вместе с веб страницей. Мы уже говорили в начале статьи об объединении внешних Css и Js файлов как раз для этой цели.

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

Для уменьшения их количества нужно проанализировать, необходимо ли подгружать то или иное изображение вместе со страницей. Я таким образом избавился от пары десятков лишних http запросов. Те же фоновые картинки из состава шаблона, которые все же окажутся необходимыми для функционирования вашего ресурса, можно объединить в так называемые CSS спрайты. В результате, вместо десятка запросов понадобится сделать только один.

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

Я уже стал задумываться о таком радикальном шаге, как сделать свой блог практически статическим, в корневой папке которого будут лежать обычные файлы Html, а весь движок WordPress будет работать в отдельной папке. Таким образом нагрузка будет сведена к минимуму.

Реализовать это в WordPress можно с помощью чудо плагина Really Static. Правда его версия еще не доросла до единички, но отзывы о его работы встречаются исключительно положительные. Фактически он является полным аналогом известного скрипта Maxsite Cache, который, например, использует Михаил Шакин на своем блоге.

Ценой за снижение нагрузки станет потеря некоторого функционала, но думаю, что правильными настройками обновления кэша (в данном случае он будет из себя представлять обычные Html странички, как на сайтах начала этого тысячелетия) можно будет свести все эти недостатки к минимуму. Во всяком случае у Шакина я никакого криминала не замечаю, когда читаю его блог.

Если кто-то уже имеет опыт работы с WordPress плагином Really Static, то буду очень благодарен, если оставите свой отзыв о нем в комментариях. Спасибо за внимание. Статья незаметно подошла к концу. Пора наводить на нее лоск и готовить к публикации.

Удачи вам! До скорых встреч на страницах блога KtoNaNovenkogo.ru

Еще:

Рубрики :Скорость загрузки сайта

Комментарии и отзывы

st1xer

Сорри за оффтоп, но не мог не поинтересоваться: ты в курсе что Perfect Money уже давно не платят за баннер? Или я чего то не знаю?..

Strikestar

Сейчас как раз тоже пытаюсь увеличить загрузку блога и статья как никогда кстати :). Разрешите задать Вам вопрос... Меня интересует как лучше поступать — выносить java скрипты в отдельный файл или вставлять их прямо в шаблоне? Page Speed проверял так и так — видимой разницы нет...

basoy

Ай спасибо вам за статью)Читал все ваши предыдущие посты по увеличению скорости, но так как обычно не пользуюсь Firefox, было влом устанавливать Firebug и ограничивался только использованием hypercache. Седня все таки решился проделать все описанные манипуляции...и, о чудо — действительно помогло! Я теперь фанат этого блога))

Игорь

Спасибо за хорошую статью.

Мой сайт сделан на Джумле. Рекомендую CssJsCompress. После установки скорость загрузки уменьшилась в разы!

Strikestar

Игорь: скорость уменьшилась? То есть еще медленнее стало? Может перепутали...

Fedor

Помогите!

Возникла проблема!

Забыл сделать бекап файлов Joomla, скопировал оригиналы файлов (CSS и js), которые хотел сжать, потом все сделал, вроде бы работает, но перестала работать административная панель, вернее она работает в виде списка ссылок, а ни как до этого...

попытался вернуть все, как было, проблема осталась...

Дмитрий

Fedor: ну, у меня тоже самое было (писал об этом в статье). Вам нужно будет файл CSS, который отвечает за стилевое оформление админки Joomla таким же образом сжать в Gzip и переименовать. Либо вернуть все назад и в .htaccess тоже.

Fedor

Дмитрий:

а можно ссылочку на статью. а то как-то вообще не комфортно стало.

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

Fedor

Всё! разобрался! Спасибо )

кстати, в Joomla у меня не получилось реализовать, всё то, что написано в статье, вернее про сжатие. Но все равно спасибо.

akkadites

Эта статья почему-то мне наибольше понравилась из последних. Наверное из-за актуального вопроса. Но кажется Вы что-то намутили. У меня теперь страницы Вашего блога без css-оформления грузятся — всё белое. И файлы syntaxHighligter не находятся -404 ошибка при запросе. О статическом сайте я что-то не понял. Тогда комменты будут отключены, или полустатика? Не знаю, по-моему идея не лучшая. А насчёт уменьшения http-запросов это дельный совет. Я например, у себя в блоге java-скрипт, который выводит кнопочки социалок закинул на моёместо.ру и он оттуда грузится, т.е. запрос посылается уже не к моему хостеру. там же по видимому и css можно хранить. а изображения храню на сайте http://pic4you.ru/6167/ — так и места на хостинге не надо и нагрузка идёт не «на мой сервер». Есть в этом случае конечно и риск потерять всё если эти серверы рухнут, но с задачей уменьшения нагрузки на сервер хостера думаю справляется. также и с синхронизацией могут быть проблемы, хотя моёместо работает очень быстро как мне кажется. может и ошибаюсь, а может кому и пригодится.

Владимир

Весь цикл статей ни о чём — все предложенные методы не принесут каких либо существенных результатов:

если бы уважаемый хозяин блога хоть немного шарил в том, про что пытается писать, он наверно написал бы не о этой хрени, а о вещах куда более полезных — оптимизации и кеширвании sql запросов и конфигурации nginx. Вот два направления, которые действительно приносят реальные и ощутимые результаты.

Дмитрий

Владимир: довольно категорично, вы не находите, тем более, что результат ускорения сайта налицо. В конфигурировании nginx я разбираюсь, как свинья в апельсинах, но в виде исключения приму ваш гостевой пост на эту тему, если он будет написан в свойственной блогу KtoNaNovenkogo.ru манере (развернуто и максимально подробно, чтобы даже мне было бы все понятно и ясно). Про кеширование запросов sql сам напишу. Спасибо.

K_E_V_in

С помощью старой доброй Acdsee 3.1 можно удалить все метаданные из изображений. Вот простой пример: до удаления меты фото весило 1,6 Мb, после удаления – 300Kb!

NMitra

Тема ускорения сайта давно меня напрягает. Кроме спрайтов никак дело дальше не идет.

Екатерина

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

Спасибо)

Евгений

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

Если с фронтендом все относительно просто(хоть и трудозатратно), то с админ-панелью совладать не выходит.

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

donxd

НЕПОНЯТНО вообще, перерыл много ваших статей по уменьшению веса изображений и ни в одной не нашел — КАК ПОТОМ СЖАТЫЕ ИЗОБРАЖЕНИЯ ЗАКИНУТЬ ОПЯТЬ НА БЛОГ ? — это что надо удалить старые и в каждую статью закинуть новое изображение ? а если у меня статей много — и в каждой по многу изобр. ???

Дмитрий

donxd: у меня все картинки живут в одной папке на хостинге, поэтому я с помощью Filezilla выкачал эту папку на комп, затем потратил пару часов на прогон всех имеющихся там изображение через Punypng (описано в этой статье). Ну,а потом с помощью все того же Фтп клиента закинул папку с уже оптимизированными картинками на хостинг с заменой уже там имеющихся.

donxd

ааа... понятно ... вот тото я не мог найти — у меня блог на бесплатной платформе, на blogspot. Соответственно доступа к хостингу нет, и не откуда скачивать изображения ... там все картинки кидаются в альбом picasa в аккаунте Google через который входишь в блог, но скачать оттуда нельзя. А не знаете как можно на blogspot уменьшить картинки в блоге ?

Владимир Сальников

Уважаймый, Дмитрий.

Править .htaccess категорически не рекомендую. Увы, но эти советы основаны на принципах десятилетней давности, когда и у апача, и у браузеров были проблемы с локальным кэшированием.

На текущий момент рекомендации могут быть только в плане оптимизации html-кода, оптимизации css-стилей, оптимизации js-скриптов, а также уменьшение размеров изображений.

Вмешиваться же в работу кэширования сервера — это извращение.

Во первых – кэшировать статику совершенно нет смысла — она и так отдается сервером на ура.

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

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

Это сжатие, отлично реализует платный плагин MAXCACHE. Сжимать остальное — глупость. С этими советами вы получите ситуацию, когда все Ваши посетители будут наблюдать только старые страницы и файлы, даже если они реально уже изменились.

С уважением, Владимир.

Max

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

Интересно, что вы думаете по поводу этого сервиса http://www.unshit.com/ru/

Дмитрий

Max: ну, как бы, это один из вариантов и, возможно, не оптимальный. А за сервис спасибо, довольно интересный.

Владимир Сальников: спасибо за развернутое замечание.

Николай

Способ со статическим gzip сжатием неплохой, но мне кажется, что папку admin или administrator (для joomla) можно добавить в исключение через .htacces. Если найду способ отпишусь. А по поводу кеширования, для joomla 2.5 нашел плагин JS Cacher, все сжатые js закидываем в папку cache, в плагине настраиваем время и вуаля!

http://extensions.joomla.org/extensions/core-enhancements/performance/site-performance/18517?qh=YToxOntpOjA7czo2OiJjYWNoZXIiO30%3D

Жанна

Здравствуйте, у меня есть проблема, касаемая блога на вордпресс — сайт очень медлено грузится(примерно 1 минута требуется для загрузки страницы).

Я установила вордпресс, загрузила шаблон. Т.к. я имею аккаунт на ЖЖ, то сделала импорт публикаци в мой блог. После этого в Параметры->Постоянные ссылки изменила способ отображения ссылок на /sample-post/ . Кроме этого установила плагин Rus-to-Lat и изменила ссылки на статьи на английские.

Если в настройках постоянных ссылок поставить отображение по умолчанию, т.е. http://majoli.ru/?p=123 , то сайт начинает быстро грузиться(доли секунды). Но как только я меняю на http://majoli.ru/sample-post/ , то начинает долго. ПОдскажите, пожалуйста, с чем это может быть связано, и как это исправить.

Мой сайт majoli.ru

Спасибо.

михаил

RewriteEngine On

RewriteCond %{HTTP:Accept-encoding} !gzip [OR]

RewriteCond %{HTTP_USER_AGENT} Konqueror

RewriteRule ^(.*)\.(css|js)$ $1.nogzip.$2 [QSA,L]

как зделать чтоб всем версиям ie выдались не пресованые файлы nogzip.

RewriteEngine On

RewriteCond %{HTTP:Accept-encoding} !gzip [OR]

RewriteCond %{HTTP_USER_AGENT} MSIE

RewriteRule ^(.*)\.(css|js)$ $1.nogzip.$2 [QSA,L]

Шамиль

Я сжал css стили вручную, выполнил всю последовательность включая изменений в .htaccess теперь кроме как в Опере ни в одном браузере сайт не работает корректно. сайт на joomla

Aleksandr

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

Намик

Приветствую грамотного администратора блога. Не первый месяц нахожу здесь полезное для себя. Теперь я вырос (4 года стажа) до уровня написания темы WP с нуля, а вот с функционалом движка еще воюю. Сейчас хочу сделать фишку: удалить все внутренние ссылки на изображения в записях, вида

<a href="http://site.ru/wp-content/uploads/2012/07/picture.jpg"><img class="aligncenter size-full wp-image-531" title="img" src="http://site.ru/wp-content/uploads/2012/07/picture.jpg" alt="img" width="100" height="100" /></a>

Хочу их превратить в такие:

<img class="aligncenter size-full wp-image-531" title="img" src="http://site.ru/wp-content/uploads/2012/07/picture.jpg" alt="img" width="100" height="100" />

И считаю, что это очень облегчит загрузку страниц. Вопрос к вам, мудрейший — в каком служебном файле движка можно прописать такой код (задать команду, исправить значение)? Чтобы код изображения 1 типа превратился в код 2 типа. Ну, и соответственно, чтобы данное изменение коснулось исключительно изображений в записях, из папок uploads. Буду признателен за ответ. Желательно развернутый)

артем

странно PageSpeed онлайн от гугла ставит моему сайту 40 , а Page Speed 77 кому верить. и что делать

Артем

здравствуйте! я задал вопрос относительно gzip-сжатия своему хостеру. вот что они мне ответили: «Подобные вещи на виртуальном хостинге не получиться реализовать. Вы должны понимать, что у нас стандартно-настроенный сервер, поэтому, мы не можем изменять настройки для каждого клиента». Правильно ли я понимаю, что мне на моем хостинге бесполезно подключать указанный в данной статье код для файла .htaccess?

Сергей

Здравствуйте, протестировал сайт «stroyvizag.ru» с помощью PageSpeed Insights есть много ошибок, исправить не знаю как, не программист. Установил плагин WP Minify съехала тема сайта и пропало слайд-шоу.Все исправил, но проблема скорости загрузки так и осталась. Сможете помочь решить мою проблему?

Николай

Я в шоке!!! как у вас быстро грузиться сайт, как добиться таких успехов?

Подписаться не комментируя