El_grapaduro: Я что-то сомневаюсь, что яву умеют поисковики читать...
Яву они точно не умеют "читать".
new-2: Противоречие в том, что если ссылки в скриптах читаються "на раз", зачет читать талмуды по тому, как сайт на аякс сделать видимым. Просто делай тогда и все.
AJAX != JS
Если JS Гугл ещё худо-бедно разбирает, то AJAX-запросы он точно посылать никуда не будет.
Trol: Спасибо вам, сейчас закомментировал все str_replace, посмотрел, и действительно всё время уходит на запись :( str_replace занимает всего доли секунд. Может подскажите возможно ли ускорить процесс записи в файл? Может есть какие расширения для этого? Или может с FAT32 PHP намного быстрее работает? Я уже и eAccelerator и Zend ставил, не помогает.
Если скорость записи так критична, то смотрите в сторону SSD.
Смена ФС навряд ли сильный прирост даст. Не говоря уже о модулях.
Toy: У меня есть набор стилей применимый к любой странице сайта (main.css), затем есть файлы post.css и contact.css, в них содержатся стили которые используются только на соответствующих страницах. Затем minify автоматически совмещает файлы main.css и post.css для страниц post в один файл, также для contact - main.css и contact.css.
Так заморочился для оптимизации (по совету Google PageSpeed).
Не могли бы вы дать ссылку на этот совет? Я что-то не смог найти.
Такая оптимизация кажется сомнительной. Скорее всего основных стилей будет больше (main.css), чем стилей для конкретных страниц (post.css , contact.css). Поэтому на выходе будут получаться очень похожие (за счет основных стилей) файлы для страниц post и contact. И это не учитывая ещё лишние запросы.
У меня например есть общий набор стилей для всех страниц + для каждой страницы свои специфические стили. Это удобно при разработке, но на продакшн версии, я использую minify и собираю стили (общие + для страницы) в один файл. В итоге получаю один файл стилей для каждой страницы и при этом в стилях нет селекторов, не используемых на отображаемой странице.
Грубо говоря, на каждую страницу приходится свой файл со стилями?
Я что-то сомневаюсь, что яву умеют поисковики читать...
Яву они точно не умеют "читать".
Противоречие в том, что если ссылки в скриптах читаються "на раз", зачет читать талмуды по тому, как сайт на аякс сделать видимым. Просто делай тогда и все.
AJAX != JS
Если JS Гугл ещё худо-бедно разбирает, то AJAX-запросы он точно посылать никуда не будет.
Единственная проблема, почему вам пока не стоит на него переходить — это неполная поддержка браузерами.
Почитал по ним, прирост совсем не существенный для такого заморачивания :( Но расширил кругозор, спасибо :)
Пожалуйста :)
Прирост скорости в несколько раз должен быть. Или вам больше нужно?
Спасибо вам, сейчас закомментировал все str_replace, посмотрел, и действительно всё время уходит на запись :( str_replace занимает всего доли секунд.
Может подскажите возможно ли ускорить процесс записи в файл? Может есть какие расширения для этого? Или может с FAT32 PHP намного быстрее работает? Я уже и eAccelerator и Zend ставил, не помогает.
Если скорость записи так критична, то смотрите в сторону SSD.
Смена ФС навряд ли сильный прирост даст. Не говоря уже о модулях.
У вас mfunc неправильно настроен. В этом теге должна быть указана сама функция тоже. Посмотрите внимательно примеры в FAQ.
Если не поможет, то в настройках плагина включите Late Init.
Ставите скрипт на выполнение в Крон каждые 5 минут. И не забудьте на kusokkoda.txt поставить права для записи.
В PHP-коде на форуме некоторые символы "обрезаются". Здесь нормальная версия.
Через СМС-гейт можно сделать. Правда, придётся за каждую СМС платить.
У меня есть набор стилей применимый к любой странице сайта (main.css), затем есть файлы post.css и contact.css, в них содержатся стили которые используются только на соответствующих страницах. Затем minify автоматически совмещает файлы main.css и post.css для страниц post в один файл, также для contact - main.css и contact.css.
Так заморочился для оптимизации (по совету Google PageSpeed).
Не могли бы вы дать ссылку на этот совет? Я что-то не смог найти.
Такая оптимизация кажется сомнительной. Скорее всего основных стилей будет больше (main.css), чем стилей для конкретных страниц (post.css , contact.css). Поэтому на выходе будут получаться очень похожие (за счет основных стилей) файлы для страниц post и contact. И это не учитывая ещё лишние запросы.
На каждую типовую страницу.
Скорее наоборот, на каждую нетиповую страницу свой файл стилей? Или я опять неправильно понял? Пример: "/post/1", "/post/2", "post/3", "/contact".
У первых 3 страниц будет свой файл стилей (post.css), а у страницы /contact будет отдельный (contact.css)?
Делайте как вам удобно.
У меня например есть общий набор стилей для всех страниц + для каждой страницы свои специфические стили. Это удобно при разработке, но на продакшн версии, я использую minify и собираю стили (общие + для страницы) в один файл. В итоге получаю один файл стилей для каждой страницы и при этом в стилях нет селекторов, не используемых на отображаемой странице.
Грубо говоря, на каждую страницу приходится свой файл со стилями?