Бойове хрещення
Після невеликих пошуків вдалося зібрати тестове оточення під Firefox 3, що використовує base64- кодування картинки у вигляді. ico. Вдалося зробити однотонне зображення (палітра 4 біта) розміром в 318 байтів (проти 894 стандартних; менше майже в 3 рази). З палітрою в 2 біта виникли труднощі під Safari, коректний результат отримати не вдалося, проте, можливо, його також можна використовувати. Може бути, комусь здасться, що 576 байтів - це дуже мало. Але варто зауважити, що, по-перше, деякі іконки використовують фактично тільки 2 кольори, тому їх можна стиснути до ще меншого розміру. По-друге, при великих розмірах (32x32, 48x48) виграш у відсотках буде таким же. Т. е. Іконки в 16 Кб можна буде спокійно зменшити рази в 3-7. І це без урахування вирізання невикористовуваних фреймів в них (адже формат дозволяє створювати анімовані ікони).
оптимальні розміри
Шляхом нехитрих обчислень заголовків, зсувів і палітр можна отримати деякі цифри для розміру найбільш стандартних favicon .ico (розмір картинки - 16x16 пікселів). Для 32х32 і 48х48 розмір файлів повинен збільшитися приблизно в 4 і 9 разів відповідно.
Таблиця 2.4. Розмір файлу favicon .ico 16x16 в залежності від використовуваної палітри
Розмір (в байтах)
Для динамічних іконок можна сміливо множити розмір одиночній іконки на число фреймів, бо заголовок у всього файлу всього 62 байта, основна частина - саме дані.
PNG - бути чи не бути?
А якщо ще і стиснути?
Якщо ми не можемо адекватно використовувати нормальні формати (PNG. GIF) для подання favicon .ico, то чому б не задіяти gzip-стиснення для її видачі клієнтському браузеру? Можна, можливо. І все актуальні браузери це розуміють. Розмір при цьому становить близько 300 байтів (зменшується в 3 рази в порівнянні з вихідним). Повторюся, мова йде про можливості для зменшення favicon .ico в цілому, а не про абсолютні цифри. Якщо у вас на сервері вже використовується стиснення, просто додайте туди компресію для image / x-icon і забудьте про неї.
data: URI нас врятує?
висновок
Одним з найбільш спірних моментів в презентації Yahoo! була заява про те, що favicon .ico "заважає" при завантаженні сторінки. Як можна судити по логам сервера при завантаженні сторінки, цей файл дійсно запитується десь в середині загального процесу завантаження, орієнтовно після CSS-файлів і до фонових зображень, тому його оптимізація може виявитися одним з ключових моментів для прискорення завантаження сайту в момент першого відвідування (з порожнім кешем).
Також заради простого поваги до користувачів (навіщо їм загрожують зайві 10 Кб коду, який Отріс у них в області 16x16 пікселів?) Не варто роздувати його розмір без особливої необхідності. Поважайте своїх відвідувачів.
ріжемо cookie
В якості заключного акорду при розгляді зменшення кількості переданих даних між сервером і клієнтом потрібно обов'язково згадати cookie.
Cookie є одним з http-заголовків, які браузер посилає на сервер. а сервер вправі їм відповісти (якщо копнути глибше, то існує пара заголовків: Cookie і Set-Cookie - але в даному випадку це не так істотно). Загальний розмір http-заголовків зазвичай не перевищує 500-1000 байтів, проте cookie можуть істотно його збільшити (так як на них накладається обмеження в 4 Кб).
При обсягах корисної інформації в кілька КБ розмір cookie може надати критичне вплив на швидкість передачі даних. Давайте розглянемо, які існують способи зменшення цих витрат.
Оптимізуємо розмір, зону і час дії
У більшості випадків користувачеві просто не потрібно пересилати величезні масиви даних кожен раз - для нього цілком можливо обмежитися тільки сесійним ключем. Виходячи з цього варто переглянути логіку використання заголовків cookie і залишити тільки дійсно необхідні.
Як варіант, можна встановлювати cookie тільки для певних розділів на сайті або обмежуватися тільки поточної сесією користувача на сайті (яка не буде зберігатися при повторному заході).
Також у cookie можна варіювати термін дії, що буде дещо нівелювати їх вплив, якщо користувач буде заходити на сайт досить рідко: з кожним новим заходом cookie з браузера пересилатися не будуть, однак їх буде відправляти сервер. Тому дана міра продуктивність особливо не підвищить.
Хостинг для компонентів без cookie
Для високонавантажених проектів, які активно використовують cookie і прагнуть мінімізувати витрати від них, варто розглянути винос статичних ресурсів на окремий хост. для якого cookie взагалі не будуть встановлюватися.
В даному випадку можна розглянути використання поддомена (що може виявитися марним, якщо cookie виставляються на * .domain.ru) або домену верхнього рівня (в такому випадку доведеться реєструвати окремий домен для зберігання статичних ресурсів). Однак в обох випадках можливі проблеми з локальними проксі-серверами: вони можуть відмовитися кешувати файли з фізично різних доменів.