Webové optimalizace v reálném životě

Optimalizace vlaků Goibibo

Dobrý den, kolegové vývojáři,

Goibibo je jednou z předních online cestovních kanceláří pro rezervaci letenek online na lety, vlaky, hotely, autobusy a auta v Indii . V tomto vás provedu problémy, které jsme měli se stávající implementací vlaků goibibo a jak jsme je vyřešili. V podstatě cesta přestavby vlaků goibibo vertikálně od nuly.

Naše cesta vlaků má 3 hlavní stránky:

Platby jsou řešeny různými nezávislými Moduly.

Problémy, které jsme měli:

1. Parita funkcí:

Přestože naše API poskytovalo mnoho informací, nebyly u klienta spotřebovány. V důsledku toho neexistovala žádná parita ve funkcích mezi mobilními aplikacemi a webovými aplikacemi, což vedlo k velmi jednoduchému uživatelskému rozhraní bez možnosti například filtrování položek.

2. Obtížně čitelný/upravit stávající kód:

Pro někoho, kdo přišel do redux-saga od redux pro globální státní správu bylo stále těžké pochopit koncept redux-saga generators fungují a jak jsou interně propojeny s watchers . Pokaždé, když se dotknu kódu na saga Musel jsem být extra opatrný, protože k údržbě úložiště používá místní úložiště.

3. Žádná adresa URL ke sdílení (stránka s recenzí):

Adresa URL naší stránky recenzí je statická (/trains/booking ), což znemožňuje sdílení s někým jiným na webu. Protože byl vytvořen s (Android/IOS) APP first přístupem.

4. Lepší uživatelský dojem**

Někdy si uživatelé nebyli jisti, jaké povinné informace jim chybí, aby mohli pokračovat, protože jim chyběly vhodné zprávy.

5. Velikost:

Takže slon v místnosti byl Velikost svazku JS . Naší vertikálou byla aplikace s jednou stránkou a jak víte, skončili jsme stažením veškerého obsahu javascriptu dopředu na stránce 1 pro zbývající dvě stránky. Počáteční velikosti byly tedy následující:

JS:

Informace o prohlížeči JS

CSS:

Informace o prohlížeči CSS

To vedlo k tomu, že značné množství uživatelů opustilo náš trychtýř, aniž by si stáhli javascript.

Kroky podniknuté k vyřešení všech výše uvedených problémů:

1. Parita funkcí:

Vzhledem k tomu, že v rozhraní API je již k dispozici mnoho informací, které nejsou integrované, pokračovali jsme v poskytování parity funkcí stávajícímu Dwebu vlaků pomocí (kolotoč nabídek, Filtry, Nejlepší dostupná třída, Alternativní trasa vlaku, Smart Engage, Nabídky). Díky tomu naše průměrná denní rezervace vyskočila z 200-300 na 600-700 na denní bázi.

2. Přepište vlak v lepším odlehčeném rámci

Museli jsme dostat React z obrázku, protože jen abychom ukázali hello World nakonec pošleme kolem 40KB klientovi.

(react - 2.6KB a react-dom - 36KB )

Možnosti našeho rámce přepisování:

a.Žádný rámec:

Udržování webové stránky elektronického obchodu v prostém JS má své vlastní body bolesti, přičemž každý kóduje svým vlastním způsobem (funkční, objektově orientovaný, Es6), což končí tím, že nemá jednotný způsob psaní kódu. Aktualizace DOM také nebude tak optimalizovaná ve srovnání s frameworky jako (react).

b.Svelte:

Měli jsme pravdu v aktuálních trendech a všimli jsme si Svelte a jeho schopnosti posílat kompilovaný kód jako výstup. Takže jsme nakonec udělali POC na Svelte pro naše Search komponenta v Home a zjistili jsme, že celkové množství kódu, který je odeslán klientovi, je menší než 10 kB pro widget Search, což je zase 45+ kB v react .

c. Předběžná akce:

preact [3KB] je lehký react jak tomu říkají a má také podporu pro Hooks s preactX uvolnění. Takže POC, který skončil s velikostí o něco vyšší (2 kB) než Svelte.

Konečný verdikt:

Vzhledem k tomu, že 'Preact' a 'Svelte' byly tak blízko našemu požadavku na dosažení nejlehčího klientského balíčku, rozhodli jsme se vybrat si mezi těmito dvěma frameworky.

Poznámka :Toto byla data v době rozhodování

Se všemi těmi srovnáními jsme se rozhodli jít s 'preact', protože to není velký rozdíl ve velikosti ve srovnání s velte a komunita a dostupnost balíčků jsou příliš dobré.

Zadejte groot

• groot - naše nové úložiště.

Motto groot :

1. Nízká hmotnost:

Naší klíčovou metrikou bylo zobrazit celou cestu do 100 kB. (včetně všech 3 stránek)

2.MPA:

Rozhodli jsme se použít vícestránkový aplikační přístup, protože extra bajt kódu ke stažení při každém přechodu stránky může mít maximálně pouze 20 kB. Ostatní zdroje, které jsou běžné jako vendor.js jsou obsluhovány servisními pracovníky pro každou stránku kromě poprvé.

3. Vykreslení na straně serveru:

Jako každá jiná vertikála v goibibo budou vlaky Server Side Rendered za poskytování smysluplného prvního malování uživateli a za pomoc při indexování SEO.

4. IsoMorphic:

Obsah bude Server Side Rendered se stejnou stránkou používanou v trychtýři i pro stránky SEO. (Tím je zajištěna parita funkcí a zamezuje se tomu, aby několik týmů zpracovávalo více verzí stejné stránky).

5. Balíčky:

Nepřidávejte balíčky, pokud to není nezbytně nutné. Vždy preferujte nativní řešení.

6. Řízení státu:

Rozhodli jsme se využít vestavěný useReducer háček kombinovaný s useContext sloužit jako globální správa stavu pro naši aplikaci. A to nám pomáhá snížit potřebu další knihovny třetí části, jako je redux .

7. Bez Axios:

Rozhodli jsme se nepoužívat Axios, protože přispívá k (4,4 kB gzip) a používat fetch namísto. Použili jsme však node-fetch pro načtení na server.

Náš klient měl u našeho dodavatele pouze následující obsah.

  "dependencies": {
    "preact": "10.0.0",                          
    "react-foco": "^1.3.1",                     
    "siema": "1.5.1",
    // Other Server dependencies     
  }

Velmi malá závislost na klientovi? Ach ano!

Architektura aplikací:

Získání naší první stránky:

Irctc zapomněl heslo

• Začali jsme s lešením preact, protože optimalizovalo sestavení webpacku.
• Vždy však připojil celou komponentu preact k FirstChild těla, ale potřebovali jsme goibibo header což je obyčejná komponenta JS, která má být prvním dítětem.
• Nemohli jsme exportovat webpack Konfigurace 's mimo skafold, takže jsme napsali naši konfiguraci webového balíčku od začátku, což poskytlo větší kontrolu, pokud jde o výstupy sestavení.

Problém CSS:

Získali jsme naše návrhy a implementovali funkcionalitu. Když nastal čas vydání vydání, všimli jsme si, že naše CSS pro tuto stránku má asi 26 kB protože jsme použili obecný soubor css známý jako combinedStyles.css která má mnoho pravidel CSS, která jsou sdílena všemi vertikálami, ale většina z nich nebyla na naší konkrétní stránce použita.

purify-css na záchranu:

Tato knihovna vytvoří nový soubor, který obsahuje pravidla css pouze pro ty třídy, které se používají v naší kódové základně.

Tak jsem vytvořil nový webpack plugin z purify Css.

   plugins: [
        new OptimizeCssPlugin(
          [
            {
              files: ['./src/*/*.js', './src/*/*/*.js', './server/*.js', './server/*/*.js', './server/*/*/*.js', './plain_js/*.js'],
              cssPath: `https://goibibo.ibcdn.com/styleguide/css/newtrains/trainCombined.${Math.ceil(Math.random()*1000)}.css`,
              downloadCssPath: `./static/trains-static/styles/combinedStyles.css`,
              outputCssPath: `./static/trains-static/styles/purified.css`
            }
          ]
        )
     ]
// other configs

To nakonec vyšlo a vedlo to ke zmenšení velikosti combinedStyles.css z 23KB na ~7KB .

Konečně, s úspěchem v tom, že jsme se také zapojili do poskytování obsahu v brotli komprese spíše než gzip což nám také pomohlo snížit velikost zdrojů. Měli jsme náš Fallback to gzip pro uživatelské agenty, kteří nepodporují br komprese.

Zapomenuté heslo je první stránka, kterou jsme vytvořili, a funguje s docela dobrým LightHouse Skóre 91 .

Zveřejněte, že jsme vydali několik adres URL, které jsou relativně nové.

Protože byly výsledky pro stránky mimo hlavní cestu uspokojivé, přesunuli jsme jednu ze stránek do naší cesty, aby se zobrazovala z groot .

Stránka RECENZE:

Stránka recenze je první na stránce cesty, kterou jsme se rozhodli přepsat na groot .

To zahrnovalo,

• Značné změny v Backend API na podporu page refresh a další specifické případy použití vlaků, jako je zobrazení nabídky, aktualizované rozdělení jízdného atd.
• Změny designu
• Další funkce
• Responzivní
• Lepší zpracování chyb uživatelského rozhraní

Vzhledem k tomu, že jsme chtěli poskytnout smysluplnou odezvu vykreslenou na serveru při přistání recenze, nikoli loading shimmer ,

• Dosáhli jsme Backend API z našeho Node Server v groot
• Aktualizovali jsme Store
• Server vykreslil naši komponentu
• K finálnímu dokumentu HTML jsou připojeny další skripty, vyžaduje se css
• Hydrated na Klienta při obdržení odpovědi.

A byli jsme schopni vidět značné zlepšení, pokud jde o výkon.

Opuštění stránky:

Lidé, kteří viděli náš server vykreslený First Paint, ale nemohli načíst JS.

Na naší staré stránce na každých 100 uživatelů téměř 8 z nich nemohlo načíst JS, díky čemuž se jim naše stránka jeví jako neinteraktivní.
Totéž kleslo o 5 procent na 3 za 100 na naší nové stránce. Což je opět více než 50% snížení našich vyřazení stránek.

Porovnání stránky recenze:

Studna!!!

Protože běžné položky jsou ukládány do mezipaměti service worker , přechod z jedné stránky na druhou stáhne pouze stránku specifickou js soubor ze serveru.

Upřímně děkuji @Raghunandan za to, že mi pomohl s jeho skvělými nápady a poskytl mi různé pohledy na řešení problému. Děkujeme @Abhigyaa za to, že Axios přinesl migraci

Veselé kódování!!!

Nezapomeňte mě sledovat 😄

Můj web, blogy a Twitter

To je vše Lidi!!!