Оптимізація програмного коду називають зміну коректного коду, спрямоване на підвищення його ефективності. «Оптимізація» має на увазі внесення невеликих змін, які зачіпають один клас, один метод, а найчастіше - кілька рядків коду. Великомасштабні зміни проекту або інші високорівневі способи підвищення продуктивності оптимізацією не зважають. Це не найефективніший спосіб підвищення продуктивності. Поліпшення архітектури програми, перепроектування класів і вибір більш ефективного алгоритму - призводять до більш вражаючих результатів. Крім того, оптимізація коду не найлегший спосіб підвищити продуктивність: легше купити нове обладнання або компілятор з поліпшеним модулем оптимізації. Нарешті, це не найдешевший спосіб підвищити продуктивність: на оптимізацію коду вручну спочатку йде багато часу, а потім оптимізований код важче супроводжувати.

оптимізація програмістом.

1). Розширити структуру даних додаванням додаткової інформації або змінити уявлення даних в цій структурі. 2). Обчислення результатів заздалегідь і їх зберігання, для подальшого використання. 3) . Застосування упаковки даних. 4) . Внутрішній цикл повинен містити min можливу кількість перевірок, а найкраще тільки одну. 5) . Видалення безумовних переходів. 6) . Логічні перевірки повинні бути розташовані так, щоб більш швидкі умови, які частіше виявляються правильними, стояли перед більш повільними умовами, які рідше виявляються правильними. 7). Логічна функція на невеликому безлічі вихідних значень може бути замінена таблицею, що представляє це безліч. 8). Видалення однакових виразів. 9). Якщо два і більше однакових вираження часто обчислюються поспіль, їх слід винести в підпрограму. 10) . Зміна типів даних може виявитися ефективним способом скорочення коду і підвищення його швидкодії. 11) . Переписування коду на низкоуровневом мовою.При низькому швидкодії код слід переписати на мові низького рівня. Якщо ви пишете на С ++, мовою низького рівня може бути Assembler. Переписування коду на низкоуровневом мовою зазвичай позитивно впливає на швидкодію коду.

оптимізація компілятором.

Методи оптимізації коду можуть застосовуватися на різних рівнях синтаксичних конструкцій: 1 ). на рівні оператора - більшість компіляторів виконують деяку оптимізацію на цьому рівні. 2 ). на рівні блоку - оптимізуючий компілятор виділяє операційну структуру програмі шляхом конструювання орієнтованого потокового графа програми, в кіт кожна вершина являє основний блок, а зв'язку м / у вершинами представляють потоки управління. Більшість компіляторів виробляють оптимізацію на рівні блоку. 3 ). на рівні циклу. 4 ). на рівні програми - найбільш складний рівень оптимізації.

Чим вище рівень оптимізації, тим більше можливостей підвищення швидкодії програмного модуля. Однак витрати на застосування більшою мірою оптимізації можуть значно збільшити час компіляції.

42. Оформлення програм: основні пункти.

1) Опис реалізації (мова, середовище програмування, тестування, передбачуваного виконання):

· Розміри в байтах, операціях, рядках;

· Розміри необхідної пам'яті під дані;

· Необхідні технічні ресурси.

2) Звернення до підпрограми (число, тип і порядок передачі вхідних параметрів): спосіб передачі (за посиланням або за значенням).

3) Опис повертаються параметрів:

· Параметр, який повертає сама функція;

· Опис вхідних параметрів, які функція змінює.

4) Опис виняткових ситуацій і реакція програми на них.

5) Опис повідомлень програми, якщо вони є.

6) Короткий опис алгоритму:

· Якщо має назву, то вказати його;

· Назвати джерело або де наведено текст програми, звідки було взято алгоритм;

· Можна привести блок-схему.

8) Описати все вхідні і вихідні файли і короткий їх вміст.

9) Привести структури записи всіх файлів:

· Розбивка по полях записи;

Оптимізація програмного коду - це модифікація програм, виконувана компілятором з оптимізацією або інтерпретатором з метою поліпшення їх характеристик, таких як продуктивності або компактності, - без зміни функціональності.

Останні три слова в цьому визначенні є дуже важливими: хоч як мене покращувала оптимізація характеристики програми, вона обов'язково повинна зберігати початковий сенс програми при будь-яких умовах. Саме тому, наприклад, в GCC існують різні рівні оптимізації
Йдемо далі: оптимізації бувають машинно-незалежними (Високорівневими) і машинно-залежними (Низькорівневими). Сенс класифікації зрозумілий з назв, в машинно-залежних оптимізацію використовуються особливості конретно архітектур, в високорівневих оптимізація відбувається на рівні структури коду.

Оптимізації також можуть класифікуватися в залежності від області їх застосування на локальні (оператор, послідовність операторів, базовий блок), внутріпроцедурние, межпроцедурние, Внутрімодульное і глобальні (оптимізація всієї програми, «оптимізація при складанні», «Link-time optimization»).

Налагодження модуля з метою виявлення логічних помилок

налагодження ПС - це діяльність, спрямована на виявлення та виправлення помилок в ПС з використанням процесів виконання його програм. тестування ПС - це процес виконання його програм на деякому наборі даних, для якого заздалегідь відомий результат застосування або відомі правила поведінки цих програм. Зазначений набір даних називається тестовим або просто тестом. Таким чином, налагодження можна представити у вигляді багаторазового повторення трьох процесів: тестування, в результаті якого може бути констатовано наявність в ПС помилки, пошуку місця помилки в програмах і документації ПС і редагування програм і документації з метою усунення виявленої помилки. Іншими словами:

Налагодження \u003d Тестування + Пошук помилок + Редагування.

У зарубіжній літературі налагодження часто розуміють тільки як процес пошуку і виправлення помилок (без тестування), факт наявності яких встановлюється при тестуванні. Іноді тестування і налагодження вважають синонімами. У нашій країні в поняття налагодження зазвичай включають і тестування, тому ми будемо слідувати традицією. Втім, спільний розгляд в даній лекції цих процесів робить вказане різночитання не таким істотним. Слід, однак, відзначити, що тестування використовується і як частина процесу атестації ПС.

Принципи та види налагодження програмного засобу

Успіх налагодження ПС в значній мірі зумовлює раціональна організація тестування. При налагодженні ПС відшукуються і усуваються, в основному, ті помилки, наявність яких в ПС встановлюється при тестуванні. Як було вже зазначено, тестування не може довести правильність ПС, в кращому випадку воно може продемонструвати наявність в ньому помилки. Іншими словами, не можна гарантувати, що тестуванням ПС практично здійсненним набором тестів можна встановити наявність кожної наявної в ПС помилки. Тому виникає два завдання. Перше завдання: підготувати такий набір тестів і застосувати до них ПС, щоб виявити в ньому по можливості більше число помилок. Однак чим довше триває процес тестування (і налагодження в цілому), тим більшою стає вартість ПС. Звідси друге завдання: визначити момент закінчення налагодження ПС (або окремої його компоненти). Ознакою можливості закінчення налагодження є повнота охоплення пропущеними через ПС тестами (тобто тестами, до яких застосовано ПС) безлічі різних ситуацій, що виникають при виконанні програм ПС, і відносно рідкісне прояв помилок у ПС на останньому відрізку процесу тестування. Останнє визначається відповідно до необхідної ступенем надійності ПС, зазначеної в специфікації його якості.

Для оптимізації набору тестів, тобто для підготовки такого набору тестів, який дозволяв би при заданому їх числі (або при заданому інтервалі часу, відведеному на тестування) виявляти більше число помилок в ПС, необхідно, по-перше, заздалегідь планувати цей набір і, по-друге, використовувати раціональну стратегію планування (проектування) тестів. Проектування тестів можна починати відразу ж після завершення етапу зовнішнього опису ПС. Можливі різні підходи до вироблення стратегії проектування тестів, які можна умовно графічно розмістити між наступними двома крайніми підходами. Лівий крайній підхід полягає в тому, що тести проектуються тільки на підставі вивчення специфікацій ПС (зовнішнього опису, опису архітектури і специфікації модулів). Будова модулів при цьому ніяк не враховується, тобто вони розглядаються як чорні ящики. Фактично такий підхід вимагає повного перебору всіх наборів вхідних даних, так як в противному випадку деякі ділянки програм ПС можуть не працювати при пропуску будь-якого тесту, а це значить, що містяться в них помилки не будуть проявлятися. Однак тестування ПС повним безліччю наборів вхідних даних практично нездійсненно. Правий крайній підхід полягає в тому, що тести проектуються на підставі вивчення текстів програм з метою протестувати всі шляхи виконання кожної програм ПС. Якщо взяти до уваги наявність у програмах циклів з перемінним числом повторень, то різних шляхів виконання програм ПС може виявитися також надзвичайно багато, так що їх тестування також буде практично нездійсненно.

модульне тестування

Кожна складна програмна система складається з окремих частин - модулів, що виконують ту або іншу функцію в складі системи. Для того, щоб упевнитися в коректній роботі системи в цілому, необхідно спочатку протестувати кожен модуль системи окремо. У разі виникнення проблем це дозволить простіше виявити модулі, що викликали проблему, і усунути відповідні дефекти в них. Таке тестування модулів окремо отримало назву модульного тестування ( unit testing).

Для кожного модуля, що піддається тестуванню, розробляється тестове оточення, що включає в себе драйвер і заглушки, готуються тест-вимоги і тест-плани, які описують конкретні тестові приклади.

Основна мета модульного тестування - впевнитись у відповідності до вимог кожного окремого модуля системи перед тим, як буде проведена його інтеграція до складу системи.

При цьому в ході модульного тестування вирішуються чотири основні завдання.

1. Пошук і документування невідповідностей вимогам - це класична задача тестування, що включає в себе не тільки розробку тестового оточення і тестових прикладів, а й виконання тестів, протоколювання результатів виконання, складання звітів про проблеми.

2. Підтримка розробки та рефакторінга низкоуровневой архітектури системи і межмодульного взаємодії - це завдання більше властива "легким" методологій типу XP, де застосовується принцип тестування перед розробкою (Test-driven development), при якому основним джерелом вимог для програмного модуля є тест, написаний до самого модуля. Однак, навіть при класичній схемі тестування модульні тести можуть виявити проблеми в дизайні системи і нелогічні або заплутані механізми роботи з модулем.

3. Підтримка рефакторинга модулів - це завдання пов'язана з підтримкою процесу зміни системи. Досить часто в ході розробки потрібно проводити рефакторинг модулів або їх груп - оптимізацію або повну переробку програмного коду з метою підвищення його сопровождаемости, швидкості роботи або надійності. Модульні тести при цьому є потужним інструментом для перевірки того, що новий варіант програмного коду працює в точності так само, як і старий.

4. Підтримка усунення дефектів і налагодження - це завдання пов'язана зі зворотним зв'язком, яку отримують розробники від тестувальників у вигляді звітів про проблеми. Докладні звіти про проблеми, складені на етапі модульного тестування, дозволяють локалізувати і усунути багато дефекти в програмній системі на ранніх стадіях її розробки або розробки її нової функціональності.

В силу того, що модулі, що піддаються тестуванню, зазвичай невеликі за розміром, модульне тестування вважається найбільш простим (хоча і досить трудомістким) етапом тестування системи. Однак, незважаючи на зовнішню простоту, з модульним тестуванням пов'язано дві проблеми.

1. Не існує єдиних принципів визначення того, що в точності є окремим модулем.

2. Відмінності в трактуванні самого поняття модульного тестування - розуміється чи під ним відокремлений тестування модуля, робота якого підтримується тільки тестовим оточенням, або мова йде про перевірку коректності роботи модуля в складі вже розробленої системи. Останнім часом термін "модульне тестування" частіше використовується у другому сенсі, хоча в цьому випадку мова скоріше йде про інтеграційний тестуванні.

Іноді буває складно вирішити, яку конструкцію краще використовувати i ++ або ++ i, або вибрати між конструкцією if-else і switch. У цій статті, написаній спеціально для спільноти iT works, представлені найбільш реальні засоби оптимізації коду, які повинен знати кожен професійний програміст.

Деякі вважають, що часи оптимізації на рівні коду пройшли назавжди, проте це не так. Зараз існує безліч платформ в яких немає таких могутніх компіляторів як в Microsoft Visual Studio. Наприклад шейдерниє мови (hlsl, glsl) або код для CUDA, PlayStation3, SPU або мобільні платформи. Залежно від організації коду, може в десятки разів відрізнятися його ефективність іноді через неефективність компілятора, на частіше через доступ до пам'яті.

Програмуючи для різних платформ вивчіть можливості вашого компілятора і особливості архітектури процесора (якщо ви пишете для конкретної консолі). Проведіть тести продуктивності різних варіантів оптимізації. Часто складно припускати, які саме способи будуть найбільш ефективними. А ця стаття підкаже різні прийоми, які можуть вам допомогти. Однак не слід оптимізувати сліпо, без попереднього аналізу і профілювання. Пам'ятайте, що передчасна оптимізація - це зло.

Якщо ви є програмістом в VS під Windows, то швидше за все з багатьма описаними прийомами оптимізації компілятор ефективно впорається. Зверніть увагу на пункти роботи з пам'яттю, а так же я рекомендую ознайомитися з технікою Data oriented design. Деякі поради щодо її використання шукайте в статті.

Тож почнемо:

1. Використовуйте векторизацію даних і векторні команди їх обробки (наприклад SSE в CPU або упаковуйте дані якщо використовуєте шейдери або CUDA). Це дозволить використовувати SIMD (Single Instruction, Multiple Data) архітектуру, що значно підвищить швидкість обчислень. Якщо ви вирішите використовувати цей метод, то не забувайте про вирівнювання даних в пам'яті.

2. Ефективніше складати і множити в перемішку, ніж спочатку все скласти, а потім все помножити. Це відбувається від того, що додавання і множення виконуються різними модулями процесора і можуть виконуватися одночасно.
int a, b, c, k, m, n, t, f1, f2, f3, g1, g2, g3; a \u003d b + с; k \u003d m + n; t \u003d a + k; f1 \u003d f2 * f3; g1 \u003d g2 * g3; Менш ефективно ніж: a \u003d b + с; f1 \u003d f2 * f3; k \u003d m + n; g1 \u003d g2 * g3; t \u003d a + k;

3. Немає різниці по швидкості в роботі з float і double при додаванні і множенні. Вони виконуються за рівне число тактів процесора і використовують одні й ті ж регістри. При розподілі і добуванні кореня, float працює швидше. Однак якщо ви будете використовувати великі обсяги даних, то за рахунок кеша швидше буде працювати той тип, який займає менше пам'яті (тобто float), тому в загальному випадку саме його переважно використовувати. Вибирати double має сенс коли потрібна велика точність.

4.
Припустимо є. const float a \u003d 100.0f; float some1 \u003d some3 * 1.0f / a; float some2 \u003d some4 * 1.0f / a; більш ефективно написати не: const float a_inv \u003d 1.0f / a; some1 \u003d some3 * a_inv; some2 \u003d some4 * a_inv; а так: some1 \u003d some3 * (1.0f / a); some2 \u003d some4 * (1.0f / a); Чому це буде ефективніше? Оператори з рівним пріоритетом виконуються послідовно. Це означає, що буде виконано спочатку множення, а потім розподіл. Якщо ж обрамити операцію ділення в дужки, то її виконає компілятор, а в реальному часі буде виконуватися тільки операція множення. Що гойдається відмінностей варіанту 3 від варіанту 2, то в 3-му варіанті не створюється додаткової змінної, немає потрібні дивлячись на код думати про те, що це за змінна. А ефективність 2-го і 3-го варіанти буде однаковою.

5. На великих обсягах даних і обчислень на них float вигідніше ніж double (через cache miss "ов, див. Пункт 3).

6.
a, b - будь-який вираз Func1, Func2 - функції, які викликаються для обчислення умови if (a && b) - потрібно першим ставити менш ймовірне умова, для більшої ефективності if (a || b) - потрібно першим ставити більш ймовірне умова, для більшої ефективності if (Func1 () && Func2 ()) - потрібно ставити більш швидкий оператор першим

7.
void Func (int * a) (int b \u003d 10; Наступні рядки однакові по ефективності (за часом виконання): b \u003d 100; * a \u003d 100;) Це відбувається по тому, що доступ до стековой змінної здійснюється за вказівником на стек. Теж йде розіменування покажчика.

8. Якщо є великий масив структур, то потрібно робити розмір його елементів рівним ступеня двійки. Тоді прохід по такому масиву буде значно швидше (в 4 -6 разів), за рахунок вирівнювання покажчика на кожну структуру в масиві.

9.
int a [1000]; for (int i \u003d 0; i<1000; ++i) a[ i ] = 50; Значительно эффективнее будет: int* p = a; for(int i =0; i<1000; ++i, ++p) *p = 50;

10.
SomeClass * p; - покажчик на масив елементів x \u003d * (p ++); - значно ефективніше x \u003d * (++ p); З тієї ж причини що і пункт 1. У першому випадку буде здійснюватися розіменування покажчика і його інкремент паралельно, а в другому - послідовно.

11. Кількість колонок двовимірного масиву бажано має дорівнювати ступеню двійки. Це збільшить швидкість роботи з масивом. Це вирівняє покажчики на перші елементи кожного рядка, що прискорить доступ до елементів.
int mas [10] [16 - кількість колонок бажано має дорівнювати ступеню двійки]

12.
u32 a; f32 b; b \u003d (f32) (i32) a; - швидше b \u003d (f32) a;

13. Уникайте операції приведення типів.
float f; int a; float b \u003d (float) a; - довго int m \u003d (int) f; - дуже довго

14. Розумно використовуйте операції округлення:
тільки для unsigned: (u32) x are 10x times faster than "u32 (floor (x))" u32 (x + 1.0f) are 10x times faster than "u32 (cell (x))" u32 (x + 0.5f) are 10x times faster than "u32 (round (x))"
15.
float f \u003d 1.0f; * (Int *) & f ^ \u003d 0x80000000; - швидше ніж f * \u003d -1.0f;

16. Якщо в switch використовуються послідовні значення параметрів case (case 0: case 1: case 2: ...) то switch значно ефективніше ніж if-else. Це відбувається за рахунок того, що при if-else буде обчислюватися значення кожного умови, а в разі таких параметрів в конструкції switch значення буде обчислено один раз, а потім буде перехід відразу до потрібного пункту.

17. Розгалуження - це зло. Намагайтеся скорочувати їх кількість. Не робіть їх всередині великих циклів. switch - це теж розгалуження. Процесор намагається пророкувати результат умови (branch prediction) і якщо значення вираження майже завжди одне і те ж, то розгалуження не відіб'ється на швидкості виконання коду. Однак в загальному випадку, передбачення розгалуження буде не вірно в 50% випадків, що буде сповільнювати виконання алгоритму. Кожне розгалуження - це перехід до послідовності команд процесора. Такий перехід ламає конвеєр команд процесора і коштує досить дорого.

Це особливо актуально для шейдеров, SPU підпрограм, CUDA підпрограм і в алгоритмах, де йде обробка великої кількості даних. Якщо вам потрібно для ста тисяч частинок виконати якийсь код, то постарайтеся мінімізувати кількість розгалужень. Це може істотно прискорити виконання коду.

Const int NN \u003d 12500000; const int N \u003d 10; наступне погано (200ms на моїй машині): for (int i \u003d 0; i< NN; ++i) { switch(i % N) { case 0: res += 10; break; case 3: res += 30; break; case 5: res += 50; break; case 6: res += 60; break; case 8: res += 80; break; } } гораздо лучше (120 ms на моей машине): const int arr = { 10, 0, 0, 30, 0, 50, 60, 0, 80, 0 }; for(int i = 0; i < NN; ++i) res += arr[ i % N ];

18. Розглянемо приклад. Двовимірний спрайт містить масив вершин vertex [4]. Набагато ефективніше було б зробити одне сховище вершин, а в спрайт індекс зсуву щодо першого елемента.
Це по пам'яті заощадить 16 байт на кожен спрайт, а за швидкістю буде відсотків на 30 швидше прохід по вершинах. Це data orientad design. Для С # він так само справедливий.

Основні напрямки оптимізацій:
1. Зменшення числа розгалужень
2. Угруповання даних за однаковими типами в пам'яті (в C # ніхто ще не відміняв масиви структур)
3. Зменшення розмірів структур

19. inline функції:
+ Дає виграш в швидкості
- увелечівает код
- додає в код залежності (* .h файлів) при компіляції. Це збільшує час і обсяг компіляції при зміні коду в функції

факти:
1. компілятор може не вбудувати функцію (навіть _forceinlie - немає горантіі вбудовування)
2. VS компілятор при включеній оптимізацією за швидкістю вбудовує будь-які функції на свій розсуд, навіть якщо вони не оголошені як inline.

Висновок: потрібно уникати використання inline функцій. Зараз це не потрібно. Винятком може бути тільки дуже часто виконуваний низькорівневий код (як наприклад математичні функції) або, якщо ви пишете програму використовуючи компілятор без повної оптимізації коду (наприклад для компілятора під PlayStation3 використання inline досі актуально).

20. Розглянемо результат зміни порядку змінних в структурі.
struct s1 (short int a; double b; int d;) sizeof (s1 [10]) \u003d\u003d 24 * 10 struct s2 (double b; int d; short int a;) sizeof (s1 [10]) \u003d\u003d 16 * 10 double по 8 вирівнюється завжди

21. Від перестановки місць слоган для float value, сума змінюється:
1e + 8f + 1.23456 - 1e + 8f \u003d\u003d 0 але 1e + 8f - 1e + 8f + 1.23456 \u003d\u003d 1.23456

22. Бінарний пошук не слід використовувати на малій кількості елементів. Якщо кількість елементів менше ніж 40-60 (це число може варіюватися від реалізації алгоритмів, але має приблизно такий порядок), бінарний пошук буде повільніше лінійного.

23.
Можна так: bool b; int a \u003d b? x: y; Але швидше: int b; (0 - false, -1 - true) int a \u003d (x & b) | (Y & ~ b);

24.
int a, b; 1. int x \u003d (a\u003e \u003d b? 1: 0); 2. int x \u003d (a\u003e \u003d b? -1: 0); Можна замінити на: 1. int x \u003d (b - a) \u003e\u003e 31; 2. int x \u003d (b - a) & 0x80000000;

25.
i32 iIndex; Умова: if (iIndex< 0 && iIndex >\u003d ISize) Можна замінити таким: if ((u32) iIndex\u003e \u003d iSize) Умова: if (i\u003e \u003d min && i<= max) Можно заменить таким: if((u32)(i-min) <= (u32)max - min)

26. Вище був приклад, як можна switch перетворити в static const array і звертатися за індексом. Це може бути застосовано наприклад для rtti (run time type identification). Якщо таким чином визначені switch покажчиків на функції, то заміна його доступом до потрібної функції за константне час - може бути дуже корисна. Те ж саме - якщо це машина станів. Замість того, щоб додавати новий елемент в свитч, його можна додавати в масив вище. Але пам'ятайте про пункт 16.

Int func (int index) (switch (index) (case 0: return f_Func1 (); case 3: return f_Func2 (); case 4: return f_Func2 (); .. case .. return f_FuncN ():) return 0; ) замінити на: int func (int index) (static funcPtr array \u003d (& f_Func1, NULL, & f_Func2, ... & f_FuncN) return array [index] ();)

додатково

Додаткові рекомендації по написанню ефективнішого коду, можна знайти в статтях:

При початковій розробці сайту їх власники найбільшу увагу приділяють його зовнішньому сприйняттю і швидкому запуску. Відразу або через кілька місяців після запуску виникає питання про те, як залучити більше клієнтів. Ще через деякий час до верстальщику і програмісту в роботу приходять тз по внутрішній оптимізації сайту, де виявляється, що частина написаного коду потрібно переписати. Тому в цьому пості ми поговоримо про оптимізацію html, css і js коду сайту при його початковій розробці, що дозволить клієнтові заощадити гроші, а розробникам нерви.

Оптимізація js і css

Для початку розберемося з css і js. Для чого потрібна оптимізація css і js?

Близько 50% користувачів йдуть з сайту, якщо він вантажиться більше 3 секунд і при кожній додаткової секунді конверсія сайту падає на 7%. Також швидкість завантаження сайту є одним з факторів ранжирування.

Перше з чого потрібно почати, це послухатися рекомендацій Google. Css і js код не повинен бути в html коді сайту, його потрібно винести в окремі файли. Винятком є \u200b\u200bневеликі інлайновие стилі з 1-2 значеннями. Число підключаються файлів потрібно максимально зменшити, в ідеальному випадку залишивши по одному підключається css і js файлі. Підключення файлів js слід перенести в кінець сторінки (перед відображенням сторінки, браузер повинен виконати її синтаксичний аналіз і якщо при цьому він виявляє зовнішній скрипт, він повинен його завантажити, а це зайвий цикл операцій, який уповільнює показ сторінки.

Також для прискорення завантаження js, css файлів і картинок бажано використовувати кешування і стиснення в формат GZIP.

SEO-верстка сайту: оптимізація html коду або як зверстати так, щоб потім не переробляти

Для правильної майбутньої оптимізації html коду розглянемо всі теги і як вони впливають на SEO.

блок :

• Категорія 1
• Категорія 2
• Категорія 2.1
• Категорія 2.2
• Категорія 3