Как мне кажется не обратили внимание на эту статью. Тимура Расулова, Виталия Фиоктистова, Азима Хикматова ... и других ребят программистов (!) очень попросил бы скачать данную статья на русском и дать своё мнение. А то ноутбук вручим , а окажется , что ... :)
С уважением ко всем

Не скажу, что я большой спец в области оптимизации сайтов, но автор провел неплохой обзор и дал толковые рекомендации. Вообщем-то, каждый веб-разработчик сталкивается с задачами ускорения сайтов и применяет описанные в статье методы для решения.
Статья актуальная, не спорю! Но описанные методы стандартные и широко рассмотрены в рунете.
А сайт infocom.uz действительно открывается не очень быстро. Давно заметил, но не испытывал комплексов по этому поводу.

Прочитал статью с интересом. Не знал что можно так просто и быстро оптимизировать сайт. Могу сказать что с трудностями при открытии сайта инфоком.уз сталкиваюсь до сих пор. По моему при прежнем дизайне сайт грузился быстрее. Надеюсь после этой статьи сайт будет загружаться гораздо быстрее :020:. Понравились иллюстрации к статье. Почти все находяться в нужном месте. Большое спасибо автору. :187:

Есть некоторые претензии.
Это во первых: почему-то перечислены программы и плагины для оптимизации, но не даны прямые ссылки на них чтобы скачать.
Во вторых автор использует браузер Файрфокс и его плагины для нахождения некоторых ошибок в коде страниц. Но, например мне, удобно использовать Оперу. Но это так, для заметки.
И ещё, не подумайте занудой, на первый взгляд кажется что статья превышает лимит 20000 знаков в оригинале (на узбекском). Но это конечно не критично.

С уважением.

Ого! Во-первых, перевод на русский сделан чем-то вроде промта, местами очень труднопонимаемо, что имеется в виду.

Вступление - нормально, стандартная вода. Однако список сервисов, распространненных среди 40% пользователей, довольно странный, имхо.

Где пруф? Перечисленные причины - субъективно, и мягко говоря, неправда.


Прямо-таки каждая?


Телепаты на форуме есть? Отзовитесь... Я не улавливаю связи между адресной строкой, компьютером и сайтами...


Понесло... При чем тут TCP (тем более, больше в тексте он не упоминается),


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

Эти программы нужны чтобы быстрей работали скрипты, или чтобы быстрей эти скрипты накликать?

Пример хелловорлда неканоничен и без объяснений новичку абсолютно непонятен.

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

Согласно чьим исследованиям? Британских ученых?


Сравнивать страницу гугла, фликр и одноклассников некорректно - абсолютно разные направления, контент и объем.

???

А если я первым вспомню о сайте защитников белок в Уганде, то что я там найду?


Вообще-то логично, зона .uz кириллицу пока не поддерживает.. Но смысл я уловил - все сайты, кроме яндекса - тормозят.

Некорректно. Если яндекс загрузится за 10 секунд, не факт, что страницы, выданные в поиске, будут столь же быстры.

Longhorn он пользоваться не может, т.к. такой ос (в стабильном состоянии) не существует.
Web Developer Toolbar v4 - параллельный мир? Актуальна версия 1.1.8.
То же и Firebug - последняя версия - 1.4.5
FireFtp является довольно унылой примочкой, впрочем, на любителя.
PHP Designer и особенно DreamWeaver - скорей, для начинающих.

Нижеприведенный процесс сводится к нажатию в YSlow! кнопки Analyze. Как в анализе участвовали Fireftp, PHP Designer и DreamWeaver, остается только гадать.

116 кб - это далеко не много. Не каменный век, чай.

Верно.

Можно, но насколько это оправданно по трудозатратам и эффекту?

А это что за функция? Заголовки кеширования?

Покажите, кто это вообще делает. Если на это ругается YSlow, это не значит, что оно нам нужно.

Не велики, при учете единоразовой загрузки

Это нехорошо, верно.

Серьезная ошибка - 500 Internal Error. А это - небольшой недочет.

Примеры? Насколько это скажется на их качестве?
И что теперь? Кому это когда мешало?

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





Дальше начинается неконтролируемый поток кода, без комментариев, с плохим форматированием, зато с бессмысленными рисунками.
Первый огрызок, как я понял, отвечает за включение компрессии gzip.
Почему нельзя было просто включить компрессию с помощью ob_start('ob_gzhandler', 9), я не понял.

Далее кусок .htaccess с Expires. Грамотно настроенный сервер этого просто не требует.

Что делает последний код, извращающий css регуляркой, я не улавливаю. Но регулярка таких размеров будет тормозить, это точно.

Довольно много терминов в статье набрано с грамматическими ошибками.
Если в начале текст был немного осмысленным, то к концу он превратился в поток кода и картинок. Примеры и сравнения ориентированы на чайников, которым до веб-дизайна еще очень и очень далеко... Как руководство к действию крайне слабо.

Для контентного сайта кстати эти заголовки просто must.

Last-Modified - согласен, а ETag? Он же дублирует last-modified, по сути..

Решил также отписаться по поводу статьи "Проблемы ускорения работы web-сайтов и их решения. Недостатки сайта infoCOM.UZ и его ликвидация".

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

Приведенный автором пример PHP-кода не очень удачен, в данном случае вполне можно было обойтись и без динамической генерации html и вывод хоть того же банального phpinfo() был бы интереснее. Ну да ладно, была просто показана простая демонстрация динамической генерации контента.
К большому сожалению, это далеко не всегда. 50-100 мс это очень хорошее время генерации страницы и далеко не всем сайтам удается его добиться.
Опять же непонятно откуда такие данные. Учитывая, что в большинстве браузеров таймаут соединения 30 секунд, то психика пользователя уже была повреждена заранее, раз он смотрит уже 8 минут на пустую страницу с сообщением об ошибке.

"Коллбэк или напрямую" в данном случае детали несущественные, их можно было опустить, как и указанные выше для красного словца протоколы TCP/IP и http(s). Далее, как отметил Тимур Расулов выше, поиск.uz это некорректая ссылка и это проблема неграмотности пользователя, т.к. если он дальше введет яндекс.ru то и это его не спасет. Другое дело, многие не очень хорошо знакомые с компьютером пользователи так и открывают сайты, к примеру, пишут в адресной строке "одноклассники" - тот же любимый автором Firefox передаст этот запрос в поиск по умолчанию, например, Google, где первая ссылка в результатах поиска уже будет вести туда куда надо.

Далее идет обзор инструментария, стоит отметить, что указанные программы работают не только под Windows, но и, например, Linux, если постараться, то под линуксом и фотошоп можно запустить.
Инструменты для разработчика действительно нужные и полезные, но в данной статье они нужны не все, те же PHP Designer, FireFtp и дримвьювер в оценке загрузки сайта практически бесполезны.
Здесь чистой воды лукавство. Чтобы получить эти данные, нужно нажать 1 кнопку в приведенном автором плагине YSlow или неприведенном PageSpeed и данные будут получены в считанные секунды.
Далее идут результаты работы YSlow, полезность которых трудно переоценить.
Вот эти мнимые "заслуги" раздражают. Было бы намного лучше, если бы автор описал процесс, например, так: "Любой может оценить свой сайт подобным образом, а именно: <сценарий установки и запуска>".
5 раздела я так и не нашел, зато нашел в самом конце статьи 4 ссылки (торг, уфорум, зиенет, церт.уз) и 1 отчет YSlow по cert.uz. Видимо, это и имелось в виду. Ни анализа, ни раскрытия недостатков я так и не увидел.

Далее, автор приводит решения поставленных проблем и просит особого внимания на каждый пункт. И оно еще как понадобится, потому как дальше идут практически одни скриншоты вперемешку с PHP и HTML-кодом. Текстовых описаний дальше практически нет совсем, и это в самой интересной части статьи - чувствуется, что автор слишком устал и просто вывалил все результаты на пользователя. Авось кто-нибудь разберется и что-нибудь да пригодится.
Да, автор, привел, скорее всего, работающий пример сжатия на PHP и конфигурацию .htaccess, но без описания установки и использования данное решение абсолютно бесполезно.
Стоит также отметить, что использовать динамическое сжатие контента очень накладно даже с помощью Apache, не говоря уже о скрипте PHP, выполняющем эту работу. Оптимальным решением здесь является статическое сжатие файлов и последующая их отдача легким веб-сервером наподобие nginx, а сжатие на лету только для динамического контента средствами веб-сервера, а не php-скриптом.

Далее, автор приводит якобы разработанную им программу минимизации CSS-файлов. Однако, если присмотреться, то можно узнать не сильно замаскированный интерфейс CSSTidy. http://www.dedoimedo.com/images/comp...idy-online.jpg
Далее идет скриншот упаковщика яваскрипта Дена Эдвардса Packer без какого-либо описания и предупреждения, что несмотря на хорошую степень сжатия, данный упаковщик сильно потребляет ресурсы процессора при распаковке на клиенте.
Потом идут скриншоты CSS-спрайтов (я догадался, а вы?), кусок html-кода с применением технологии data:URI (никаких пояснений, все же и так это знают) и длинный кусок кода с регулярными выражениями, в котором я так и не смог разобраться.
Резюме: Теория сильно хромает, практика клиентской оптимизации более менее освоена, сама статья находится в состоянии примерно 20% завершения, несколько ошибок и наглое присвоение чужой работы (скорее всего эта программа сдается в качестве диплома или курсовой).

Можно было бы дать хотя бы ссылки на webo.in, их готовое решение http://www.web-optimizer.us/ru/, которое, кстати, поддерживает уже сегодня кучу цмсок и движков, блог клиентской оптимизации на habrahabr.ru, best practices yahoo, если уж совсем влом статью дописывать.
Незнание и ошибки можно простить, в конце концов, не ошибается только тот, кто ничего не делает, но вот за воровство и лень я ноутбук бы не дал.

Ну на мой взгляд достаточно прилично :)
Немного - это jQuery сжатая в 15 кб.

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

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

На оптимизации картинок также можно выиграть несколько килобайт, может даже и десятков при сильно запущенном случае. Причем качество не сильно страдает, можно использовать онлайн сервисы, такие как smushit или консольные утилиты типа pngcrush. Об этом уже много где писалось, так что я вас вряд ли чем-то удивлю.
Загрузка большого количества фоновых рисунков - опять же, большая трата http-запросов, следует слить их в один спрайт или раздавать прямо в css через data:uri.