Home / Work / Diksha Learning Center

Diksha Learning Center Client project

Chamba, Himachal Pradesh · built by Shahrukh Sheikh

Education · PHP 8 · MySQL · Live · Built for speed

A coaching institute website that loads fast and runs itself.

Diksha Learning Center teaches NEET, JEE, NDA and government-exam batches in Chamba. This is its website and the admin panel behind it: every course and teacher has a proper page, a student can ask a question from any course in two taps, and the institute edits everything itself. It also scores 91 on mobile performance on the live site, and this page shows how.

Why it's fast Visit the live site

Live · Custom PHP, no framework · Admin panel with roles · Measured, not claimed

The Diksha Learning Center home page: a violet top bar and white header, a hero with the headline Expert Coaching for Competitive Exams and a photo of three students, three popular course cards for NEET JEE and NDA with fees, and a violet statistics band.

Measured on the live site

Lighthouse on mobile, 3 October 2026.

91

Performance

96

Accessibility

92

Best practices

100

SEO

One Lighthouse 13.5 run against dikshalearningcenterchamba.com with the mobile preset (a mid-range phone on slow mobile data, simulated). Scores move by a few points between runs.

Why it exists

A family searching at night wants answers, not a brochure.

A student or a parent looking for a NEET, NDA or Patwari coaching class in Chamba is on a phone, often on mobile data, comparing a few institutes. They want to see the course, who teaches it, what it costs and how to ask a question, and they'll leave a page that takes too long to appear.

So the site had three jobs. Be quick on a phone. Make every course and every teacher easy to find on Google. And let the institute change its own content, because batches, fees and teachers change every year and a website that needs a developer for each edit goes out of date.

The biggest speciality

Why this website is fast.

Speed is a feature of the code, not a plugin added afterwards.

Most slow websites are slow for the same two reasons: huge photos and heavy code. Diksha attacks both at the source. When the institute uploads one photo, the site makes the right-sized copies by itself. And there is almost no code to download in the first place.

One upload, six images

  • A photo uploaded in the admin is resized to 300, 800 and 1200 pixels wide.
  • Each size is saved as WebP, and also as AVIF when the server can make it.
  • The page asks for the right one with a picture tag and srcset: a small phone gets a small file, in the newest format its browser understands.
  • In the Lighthouse run, each course photo on the home page was 26 to 53 KB.

Almost no code to download

  • Five stylesheets, about 40 KB as written and 9.5 KB on the wire after compression.
  • One script, 2.9 KB (under 1 KB compressed): the mobile menu, the sticky header and the slider. No jQuery, no Bootstrap, no framework on the public site.
  • The home page's own HTML is 9.3 KB compressed.
  • Together, the site's own code is about 10 KB over the wire.

Quick server, no waiting

  • Pages are built on the server in plain PHP and arrive finished, so the phone has nothing to assemble.
  • The server answered in 130 ms in the test.
  • Pages and files are sent compressed (gzip on the live host).

Files kept for a year

  • Images, styles, scripts and fonts are marked cacheable for a year, so a returning visitor downloads almost nothing.
  • Pages themselves are never cached, so a changed fee shows up at once.

No jumping around

  • Every image has its width and height set, so the page doesn't shift as pictures arrive.
  • Layout shift measured 0.01; Google's "good" line is 0.1.
  • The top image is loaded with high priority and the rest are lazy-loaded below the fold.

Responsive to touch

  • Only 20 ms of main-thread blocking in the test: the page responds to taps straight away.
  • Nothing waits on a big script before it becomes usable.

What's still slower than it should be. On the test's slow-phone setting the first paint is 2.6 seconds and the biggest image arrives at 2.9 seconds, which is why performance is 91 and not 100. The reasons are the page's third-party parts, not its own code: Google Fonts and an icon font of about 320 KB, and a YouTube video embedded on the home page that loads with the page and accounts for roughly a megabyte of the 1.8 MB total. Loading the video only when someone taps it, and hosting the fonts on the site itself, are the next two changes.

The site

What a student or parent sees.

Course page

Everything a family asks, on one page.

  • The facts first: category, name, a one-line summary, duration, class size and whether it's online or offline.
  • The fee in rupees, with a "share on WhatsApp" button that sends the course link to a parent or friend.
  • A quick enquiry form sitting beside the course, so the question is asked while the student is still interested.
  • About, why join and subjects covered, each managed in the admin.
  • The teachers who take that course, linked to their own pages.
  • Marked up for Google as a Course, so search can show it properly.
A course page for the NEET and JEE Crash Course: a course fee of 9,999 rupees, a Share on WhatsApp button, course details, a quick enquiry form, a classroom photo, the About This Course text and a Why Join This Course grid of five features.

Screenshots are from my local copy of the site. The home page is the live design, and the courses, fees and photos are the institute's own.

Every feature

Everything the site and its admin panel do.

For students and parents

  • Home page with an auto-playing slider, the most-asked-for courses, the institute's numbers, faculty, reviews, and a free demo-class video with an enquiry form.
  • Course pages for every batch, with online and offline versions listed separately.
  • Faculty pages with each teacher's subjects and achievements.
  • Reviews, blog, FAQ and help centre pages.
  • About and founders pages, plus privacy, terms and cancellation and refund policies.
  • Contact page, a newsletter sign-up in the footer and a confirmation or error message after each form.

Found on Google

  • A title, description and canonical link for every page, set from the admin.
  • Structured data: Organization on every page, Course on course pages, BlogPosting on blog posts and FAQ markup on the FAQ.
  • Clean addresses such as /course/neet-jee-crash-course.
  • A sitemap and an RSS feed, and a social-sharing image.
  • Local wording for Chamba, so searches for coaching there can find it.
  • Payment, admin and error pages are marked noindex so they stay out of search.

Enquiries

  • Forms on the home page, course pages and contact page, each recording which one the lead came from.
  • Stored with the course it was about, the phone number tidied to ten digits, and the time.
  • Spam protection without a CAPTCHA: a hidden trap field, a security token, a minimum time to fill the form and a ten-second gap between sends.
  • Read in the admin in a searchable list, one enquiry per page.

The admin panel

  • Dashboard: counts of courses, blogs, reviews, enquiries and admins, revenue, and trend charts.
  • Courses with subjects, features and which faculty take them. Faculty with subjects and achievements.
  • Sliders, reviews, blogs and menus the institute can add, edit, hide or delete.
  • Pages: About, founders, FAQ, help centre, privacy, terms and cancellation, all edited as text.
  • Site settings: email, phone, address and social links shown across the site.
  • Enquiries, enrollments and newsletter sign-ups in searchable lists.
  • An error log that records database errors so they can be read later.

Roles and permissions

  • Several admin accounts, each with a role.
  • Permissions per section: a role can be allowed to view, add, edit or delete, separately for courses, blogs, enquiries and the rest.
  • Every admin page checks the permission before it shows anything, so a front-desk login can read enquiries without being able to change fees.
  • Roles can be edited in the panel without touching code.

Safety

  • Database queries use prepared statements, so typed text can't change a query.
  • Security headers on every response: frame protection, no content-type sniffing and a strict referrer policy.
  • Folder listings are off, and the migrations folder is blocked from the web.
  • Errors are hidden from visitors on the live site and shown only on the developer's own machine.

Online payment

Built, checked and switched off.

The site can take a course fee online with Razorpay. The public course pages don't offer it right now: the "Enroll Now" button is hidden, and students send an enquiry instead. This is how the payment side is built.

  1. Choose

    The student opens a course and starts to enroll with their name, email and phone.

  2. Price

    The server looks up the fee in its own database. The browser never sends a price.

  3. Order

    The server creates a Razorpay order and saves the enrollment as "created".

  4. Pay

    Razorpay's own checkout takes the payment. Card details never touch this site.

  5. Verify

    The server checks Razorpay's signature before marking the enrollment "paid".

  6. Record

    The enrollment, with the payment id, shows in the admin. A repeat check can't pay it twice.

To go live, two things. Un-hide the button, and use live Razorpay keys: my working copy uses Razorpay's test keys, and the keys sit in the code rather than a private settings file. A server-to-server Razorpay webhook is also not built yet, so a student who pays and then closes the tab straight away would stay "created" until the institute checks.

What it needs

To run it.

ServerApache with mod_rewrite. Compression and caching use mod_deflate, mod_expires and mod_headers when available.
LanguagePHP 8, with GD for image processing. AVIF files are made when the PHP build supports it.
DatabaseMySQL, with tables created from a migration script.
LibrariesRazorpay's PHP library, through Composer. Nothing else.
Front endPlain CSS and one small script. No build step.
Third partiesGoogle Fonts, an embedded YouTube video, and Razorpay's checkout when payment is on.

Being honest

What it doesn't do yet.

  • Online payment is switched off on the public site, and the webhook isn't built.
  • No email alerts for new enquiries; someone has to check the panel.
  • Performance is 91, not 100, because of the video embed and the third-party fonts described above.
  • The sitemap is a file, not generated, so it has to be refreshed when pages are added.
  • The admin dashboard's charts load their library from a CDN.
  • No automated tests. It's checked by using it.
  • English only.

FAQ

Questions people ask first.

Why is the website fast?

Because speed was built in rather than added later. Every uploaded photo is automatically turned into three sizes in two modern formats, so a phone gets a small file. The site's own code is about 10 KB over the wire (five small stylesheets and one tiny script, with no framework). The server compresses pages and tells browsers to keep files for a year. See the evidence.

How fast is it, really?

On a mobile Lighthouse run of the live site on 3 October 2026 it scored 91 for performance, 96 for accessibility, 92 for best practices and 100 for SEO, with 20 ms of blocking time and a layout shift of 0.01. The test pretends to be a mid-range phone on slow mobile data, and on it the first paint takes 2.6 seconds. That's the part still to improve, and I say why.

Can the institute update the website without a developer?

Yes. Courses (with subjects and features), faculty, home-page sliders, reviews, blog posts, menus, the FAQ, the About pages and every policy page are edited from the admin panel. Daily running needs no developer.

Can students pay online?

The Razorpay payment flow is built, but switched off on the public site for now: the "Enroll Now" button is hidden, so students send an enquiry and the institute follows up. Turning it on is a one-line change plus live payment keys. The details are below.

Is it a template?

No. It's custom PHP written for this institute. It shares a foundation (admin panel, roles and permissions, the image pipeline, the SEO helper) with my other client sites such as Wander Yak, but the courses, faculty, enquiry flow and design are its own.

What does it need to run?

An ordinary PHP host: Apache with mod_rewrite, PHP 8 and MySQL. No Node, no build step and no framework. Compression and caching switch on automatically when the host has the Apache modules for them.

Where do enquiries go?

Into the admin panel, where each can be opened and read, with the course it was about. Email alerts for new enquiries are not switched on yet, so someone has to look at the panel.

Want the build story: the image pipeline, why the checkout was built first and then switched off, and what the speed test found?

Read the case study