DA-IICT Students: Performance Tuning a Full Stack Internship Project With Measurable Results

You make a full stack project measurably faster by recording a baseline first (Lighthouse for the front end, query timings for the back end), fixing the biggest bottleneck first, and re-measuring after every change. For a 14-day internship, the order that pays off most is images, then database queries, then caching and bundle size, with a before-and-after table as your proof.

This guide is written for DA-IICT students who have a small full stack project (a React or plain JavaScript front end, a Node, Django or similar back end, and a SQL or MongoDB database) and want a portfolio line that says “reduced X from A to B” instead of “improved performance”. It is an independent guide. It does not come from the institute and implies no endorsement by it.

Why measured results beat “I optimised the app”

Recruiters and interviewers read hundreds of project descriptions. Claims such as “optimised performance” are impossible to check. A claim such as “cut Largest Contentful Paint from 4.1 s to 1.9 s by compressing hero images and lazy loading” can be tested, discussed and defended. Performance work is also one of the few areas where a small project can show real engineering judgement: you form a hypothesis, change one thing, and observe the result.

Three habits separate credible tuning from guesswork:

• Baseline before touching code. Without a “before” number there is no result to report.
• One change at a time. If you change images, queries and caching together, you cannot say which one helped.
• Repeat runs. Lighthouse scores vary between runs. Take the median of at least three.

Setting up a repeatable Lighthouse measurement

Lighthouse is built into Chrome DevTools (the Lighthouse panel) and also runs from the command line. To get numbers you can compare, keep the conditions identical every time.

Steps for a fair baseline

1. Run the production build of your front end, not the development server. Development builds are unminified and will mislead you.
2. Open the page in an Incognito window so extensions do not alter results.
3. Open DevTools, choose the Lighthouse panel, select Mobile, and tick Performance.
4. Run the audit three times and note each result. Record the median.
5. Save the report (the “Save as HTML” or JSON option) and name it with the date and a label such as baseline.
6. Repeat for each key page: for example the landing page, a list page with data, and a detail page.

If you prefer the command line, this is an illustrative command (adapt the URL to your project):

npx lighthouse http://localhost:3000 --preset=perf --output=json --output-path=./reports/baseline-1.json

The metrics worth recording

Lighthouse gives lab data from one simulated device. Treat it as a diagnostic tool, not as a verdict on real-world users, and say so when you present your numbers.

Measuring the back end before you optimise queries

Lighthouse shows symptoms; it does not show why your API is slow. Measure the back end separately.

• Time each endpoint. Use the DevTools Network tab (the “Waiting for server response” part of the timing breakdown) or a tool such as Postman or curl with timing output.
• Log query counts per request. Many ORMs can log SQL. If one page load fires 60 queries, you have found an N+1 problem.
• Inspect the plan. In PostgreSQL or MySQL, run EXPLAIN ANALYZE (PostgreSQL) or EXPLAIN (MySQL) on the slowest query. Look for full table scans on large tables.
• Seed realistic data. A table with 20 rows hides every problem. Generate several thousand rows so differences become visible.

Fixing slow queries: the practical order

1. Remove N+1 queries

This happens when you load a list of items and then run one more query per item to fetch related data. Fix it with a join, or with your ORM’s eager-loading feature (for example select_related or prefetch_related in Django, include in Sequelize, populate in Mongoose).

2. Add indexes where filters and sorts happen

Index columns that appear in WHERE, JOIN and ORDER BY clauses on larger tables. Confirm with the query plan that the index is actually used. Do not index everything: each index slows writes and uses storage.

3. Select only what you need

Replace SELECT * with named columns, and stop sending whole records to the browser when the list view needs only a title and an ID.

4. Paginate

An endpoint that returns every row will get slower as data grows. Add LIMIT and an offset or cursor, and return a modest page size.

5. Cache stable results

For data that rarely changes, such as category lists, cache responses in memory or in Redis if you already use it, and set sensible Cache-Control headers for static assets.

Fixing images, usually the biggest front-end win

• Resize to display size. A 4000-pixel photo shown in a 600-pixel slot wastes bandwidth.
• Use modern formats. WebP or AVIF are usually much smaller than JPEG or PNG at similar quality. Keep a fallback if you must support older browsers.
• Lazy load below-the-fold images with loading="lazy", but do not lazy load the main hero image, since that delays LCP.
• Set width and height attributes so the browser reserves space and CLS stays low.
• Use srcset so phones download smaller files than desktops.
• Compress as part of the build, not by hand each time, so the gain survives future changes.

A prioritised fix list for a two-week project

Rank fixes by expected gain divided by effort. This ordering suits most student full stack projects, but your own baseline should overrule it where the data disagrees.

Worked example: a hypothetical product-listing app

The numbers below are illustrative. They show how to structure a report and are not results from a real run.

Imagine a student’s e-commerce demo with a product list page showing 24 items. The baseline median of three mobile Lighthouse runs looks poor, and the Network tab shows a 5.8 MB page. The student logs SQL and finds the list endpoint runs one query for products plus one query per product for its category: 25 queries per request.

Notice what the table teaches. Each step changes only a few columns, so the student can attribute gains honestly. The image work moved LCP and weight but not the API time; the query work moved the API time but barely touched CLS. The one-line résumé claim writes itself: “Reduced mobile LCP from 4.6 s to 2.2 s and API response from 780 ms to 120 ms on a 24-item listing by fixing an N+1 query, adding an index and optimising images.”

Dhirubhai Ambani University (DA-IICT) students: fitting performance work into your calendar and records

DA-IICT now presents itself as Dhirubhai Ambani University (formerly DA-IICT), and its About page describes it as a private university established under a Gujarat state government Act. Its Programs of Study page says the undergraduate curricula include research and industry internships, but it gives no credits, duration or evaluation rules there. So do not assume an online internship project will count towards any course requirement; treat it as a self-driven portfolio project unless a faculty member or office tells you otherwise in writing.

Timing matters too. The 2026-27 academic calendar lists Autumn end-semester exams from 23 November to 2 December 2026 for most batches, with BS-MS and B.Tech. 2026-batch exams on 30 November to 5 December. A Rural Internship Period is listed for 3 to 31 December 2026. Because today is 13 November, a sensible plan is to do only the baseline and the quick image fixes before exams, then finish the query work afterwards. Check the calendar page for the current version, since dates can be revised.

If you later want to cite this work in placement applications, the Placement Cell page lists a placement policy, a Placement and Internship Affairs Action Committee (PIAAC), recruiter information and contact details. Those are the places to ask how project work should be presented.

Verification steps for DA-IICT students

1. Email your programme coordinator or academic office and ask in writing whether an external online internship can be recorded in any form, and what proof they would need.
2. Ask the Placement Cell, via the contact details on its page, whether PIAAC has rules on internships taken outside institute-arranged channels.
3. Re-open the academic calendar a week before you start and confirm exam and break dates for your batch.
4. If your department runs a project or internship course, ask the instructor for the written evaluation rules before you reuse this work for credit.
5. Keep screenshots, Lighthouse JSON reports and your Git history as your own evidence, whatever the institute decides.

A 14-day plan for tuning your project

The free two-week online internship at CareerSwami runs 14 days, with a free offer letter and a free completion certificate after successful completion, and it offers 26 tracks. If you are building a full stack project there, this schedule fits inside that window. It is a suggestion, not a requirement of any track.

Checklist for writing the results up honestly

• State the test conditions: device mode, browser, build type, data size.
• Report medians and say how many runs you took.
• Include the baseline even when it looks embarrassing; it is the point of the exercise.
• Name each change next to the metric it moved.
• Mention what did not help. A failed experiment shows judgement.
• Link the committed Lighthouse reports in the repository.
• Add a short note that lab results differ from real users on real networks.

Frequently Asked Questions

Which Lighthouse score should I aim for?

Do not chase a number such as 100. Aim for clear improvement over your baseline and for good values on LCP, TBT and CLS. A story of “46 to 88 with explained causes” is stronger than an unexplained 100.

Why does my Lighthouse score change between runs?

Lab tests depend on CPU load, network simulation and background processes. Close other tabs, use Incognito, and take the median of at least three runs.

Should I optimise the database or the images first?

Check your baseline. If the page weight is several megabytes, start with images because they are cheap to fix. If the API response is slow, start with queries. The prioritised table above is a default, not a rule.

Do indexes always make queries faster?

No. On tiny tables the database may ignore them, and every index adds cost to inserts and updates. Confirm usefulness with the query plan and test with realistic data volumes.

Can I use this performance project for college credit at DA-IICT?

The institute’s programme page mentions internships in the curricula but gives no credit or evaluation rules, so that is not something to assume. Ask your department in writing before counting it for any requirement.

Does lazy loading hurt performance?

It helps for images below the fold but hurts when applied to the main hero image, because it delays LCP. Load the hero normally and lazy load the rest.

How much data do I need to see real query problems?

Several thousand rows in the main tables is usually enough to make missing indexes and N+1 patterns visible. Use a seed script so the data is reproducible.

Is Lighthouse enough to prove my app is fast?

It is a strong start but only a lab measure. Pair it with endpoint timings and, if possible, a few tests on a real mid-range phone, and describe the limits of your testing.

Related Full Stack Web Development guides

• Pt. Ravishankar Shukla University Students: Writing the Internship Completion Report Day by Day
• Kanyashree University Students: Staying Safe and Confident in an Online Web Dev Internship
• Usha Martin University Students: Using an Open-Source Contribution as Your Internship Task
• All Full Stack Web Development internship guides