Building Tinder Online

Tinder - En av de mest populära online-datingtjänsterna är nu tillgänglig på webbplattformen över hela världen.

Tinder Online

Vi börjar denna resa för inte så länge sedan när företaget redan satsade stort på inhemsk appupplevelse och teknik för maskininlärning.

Vi inser att inte alla användare har den senaste mobila enheten med stor lagring och höghastighets nätverkshastighet för att driva vår ursprungliga klient. Webbplattformen tjänar sedan ett mycket bra syfte - kan köra mestadels var som helst med en relativ lite krävda resurser.

Vårt webbteam har en relativt liten storlek, men vi börjar med ett stort uppdrag - vi vill leverera den performanta och smidiga webbupplevelsen med banbrytande webbteknologi.

Tinder Gold (Premium Feature)

Arkitektur

Tinder Online byggs med en React / Redux-stack.

För att bygga en högpresterande och skalbar webbapp skapade vi hela användargränssnittet med React, med fokus på att bygga återanvändbara komponenter som sedan är sammansatta i visningsbehållare. Denna flexibla kompositionbarhet underlättar snabb iteration och en underhållbar kodbas.

Vi använder en Redux-butik för att fortsätta vårt applikationsläge. Vårt tillstånd är konstruerat via ImmutableJS och Normalizr, vilket gör att vi kan utföra effektiva och utförande statliga operationer. Memorerade väljare gör vår butikstillträde mycket performant.

Tinder online - svep överallt

När vi först lanserar upplevelsen till målmarknader använder vi en serverlös lösning. Vi distribuerade statiska tillgångar för att s3 och utföra den fullständiga klientsidan för applogik. Vi flyttar sedan till en isomorf Node-app för att betjäna mer komplicerade användningsfall.

Vi konstruerar det ursprungliga applikationstillståndet (dvs funktionsflaggor och internationalisering) serversidan med en enkel NodeJS / Express-server och gör ett mycket cachbart app-skal med dehydratiserat tillståndsklientsida. Den fullständiga applikationslogiken och datainhämtningsflödet initialiseras sedan efter rehydratisering av applikationstillståndet.

Biverkningar och asynkrona operationer som API-förfrågningar hanteras med Redux Sagas. Vi kvarstår delar av vårt tillstånd som användarinställningar, plats och applikationsinställningar med IndexDB i webbläsare som stöds och faller tillbaka till localStorage vid behov. Den persistenta butiken förbättrar appens startprestanda och användarupplevelse kraftigt.

App-renderingens logik och ruttinställningar är centraliserade och konfigurerade på översta nivån. Denna abstraktion gör det möjligt för oss att separera sidnivålogik från komponentnivålogik och gör det enkelt att hantera ruttnivåskoddelning och olika sidövergångseffekter. Vi utvecklar också en proxyreaktionskomponent för att implementera dynamisk Javascript-laddning och förbelastning av resurser för nästa rutt.

Kärnupplevelsen och animationen bygger på React Motion. Internationaliseringen hanteras av React Intl. Vi använder React I13n för att skilja instrumenteringslogik från UI-logik genom att skapa pluggbara lyssnare för olika spårningssystem.

Prestanda

Vårt mål är att tillhandahålla en sömlös upplevelse som liknar våra inhemska klienter för de flesta av våra användare oavsett nätverksskick eller maskinvarubegränsningar. Därför är prestanda högsta prioritet för oss när vi bygger funktioner.

Vi fokuserar på två huvudområden - nätverksprestanda och ger prestanda.

Nätverksprestanda

För att stödja användare med långsammare nätverk är webbappen optimerad för att begränsa nätverksbelastning, analys av tid för dokument och återgivningstid. I allmänhet vill vi ladda de kritiska tillgångarna tidigt och snabbt och skjuta upp de valfria resurserna.

Vi kan förbättra den initiala belastningstiden kraftigt genom att tilldela enskilda resursprioriteringar med hjälp av länkförbelastning och förhämtning tillsammans med koddelning. Vi skickar de minimala resurserna till klienten genom att implementera koddelning, förcache-bitar via en servicearbetare och ladda in tillgångar för nästa förväntade rutt effektivt. Vi använder Workbox för att kontrollera cache-strategier för höga servicearbetare för olika resurser.

Den kritiska återgivningsvägen är optimerad genom att lägga in de flesta av våra gemensamma CSS. Vi använder Atomic CSS för att skapa mycket återanvändbara och komprimerbara stilark. Med Atomic CSS styrs UI-teman och displaylogiken av React-rekvisita, vilket gör vår kod lätt att dela och underhålla. Vår centrala CSS, som innehåller teman, avstånd och responsiv styling, är ungefär 10 kB (gzip) för hela webbplatsen.

För att förhindra att buntstorleken ökar när vi lägger till nya funktioner anger vi prestandabudget för alla våra resurser. Storleken på våra Javascript- och CSS-buntar granskas vid varje åtagande. Att ställa in en bra prestandapaket tvingar oss att bygga mycket delbar komponent. Vi mäter och spårar även prestanda med verktyg som Lighthouse och CSS-statistik före varje utgåva. Användarövervakningsmetoder i realtid som laddningstid och måttid (PerformancePaintTiming) samlas in på klientsidan.

Vår källkod sammanställs och polyfylls av Babel och genereras av Webpack. Genom att utöva buntanalys kunde vi identifiera flera möjligheter för prestationsoptimeringsstrategier som kodningssplitning, trädskakning eller val av alternativa bibliotek. Vi använder också babel-preset-env för att endast inkludera delmängden polyfyll som riktar sig till våra webbläsare som stöds. Det totala resursbehovet för webbappen är cirka 3 MB, vilket är bra för användare som har begränsad enhetslagring.

Framför prestanda

Vi optimerar rendering och animering genom att prioritera Javascript-uppgifter med requestIdleCallback. Icke kritiska uppgifter som instrumentering kommer att schemaläggas till vilotid. Vi ser också till att vår HTML-markering och CSS är mycket optimerade och lata laddningar utanför skärmen via Interaction Observer för snabb rendering och smidig prestanda, även på långsammare enheter.

Vi använder Chrome dev-verktyget och React-utvecklarverktyget för att identifiera flaskhalsen för prestanda som webbläsare ommålning, React re-render eller Javascript-funktioner med hög kostnad.

Vad kommer härnäst

Produktmässigt ser vi mycket positivt användarengagemang på webbplattformen.

När det gäller teknik finns det flera områden som vi snart vill fokusera på.

  • Experimentera med olika tillvägagångssätt för koddelning, såsom att skjuta upp registreringen av Redux reducers och saga hanterare.
  • Använd vår cache-cache för servicearbetare mer för en bättre offlineupplevelse.
  • Ladda ner dyra uppgifter, till exempel att analysera ofta konsumerade API-svar, till webbarbetare.
  • Förbättra prestandan hos moderna webbläsare genom att experimentera med nya webbläsarprimitiv som nätverksinformation API.
  • Experiment distribuera ES-modul till webbläsare som stöds
  • Rearchitect Redux butiksstruktur för att förbättra statlig förvaltning

Vi kommer också att dela mer praxis och lärande till samhället.

Speciellt tack till våra vänner Addy Osmani, Liam Spradlin, Cheney Tsai och andra på Google för att ge bra insikter och förslag för Tinder: s progressiva webbapp!

Den här blogginlägget är ett samarbete från alla medlemmarna i Tinder Web-teamet. Amritha Arakali, Antony Chan, Brendan Todaro, Erik Hellenbrand, Jackie Wung, Jenny Peng, Keith McKnight, Salina Wu och Sid Jain.

Relaterade resurser

  • Introduktion av Tinder online - svep överallt
  • En Tinder Progressive Web App-resultatstudie - Addy Osmani
  • Tinder PWA har nämnts på Google I / O 2017 och Chrome Dev Summit 2017